Re: untagged RGB data
Re: untagged RGB data
- Subject: Re: untagged RGB data
- From: John Zimmerer <email@hidden>
- Date: Fri, 19 Dec 2003 21:19:57 -0800
The Generic CMYK Profile is based on SWOP TR001, probably the CMYK
equivalent to sRGB, so it's not such a bad default.
It's not at all a bad default. But there are other spaces, and
assuming source profile for CMYK is something we will be living with
for a while. And many regularly used CMYK spaces exist that are
nothing like TR 001. Assumed profile workflows for CMYK is something
we will have to live with for years to come, and because of this a
user selectable option for what to assume as the source profile I
think is a good idea, even though TR001 as a default is also a good
idea. And vastly superior to the situation we had on OS 9.
So for now we'll stick with one profile for untagged data at the system
level.
I'm not sure I buy the need for "OS working spaces", since I truly
believe all data should be tagged. And ultimately, this is the domain
of the user space applications (including AppleScript and sips),
since they manipulate color directly. The OS should simply render
source color accurately, and have a single definition (across
workflows and continents) of how untagged source data is treated, per
color space.
There are numerous problems with tagging CMYK images because it's too
easy for tagged images to get repurposed by today's applications when
going to a destination with imperfect registration. Black only text
and drop shadows turn into four color. Two color 9pt text becomes 3 or
4 color. It's a disaster on these kinds of devices.
Frankly, not knowing how CMYK was generated has more problems. At least
having the profile embedded gives the recipient a shot at knowing
whether the file in its current state is appropriate for the given
workflow, and also provides a starting point for creating a device link
profile (after extracting the embedded profile, of course). The profile
isn't to blame for poorly designed workflows.
CMYK profiles are much larger than RGB tags. For people to have to tag
hundreds or thousands of images is an unnecessary workflow in the vast
majority of cases. It unnecessarily makes for larger files and rapidly
gets to the point where you are pushing gigabytes of redundant and
impertinent data over networks, and onto storage. Apple is in a unique
position, technologically, to address this problem with metadata and
networking - but that's a whole separate discussion.
CMYK profiles don't have to be large, they can be 500K or less. Large
profiles can be downsampled, unnecessary tags can be stripped. In
dealing with files that start at 16-bit then get separated to CMYK, I
don't think 500K is too high a price to pay to insure the file is
properly treated further down the workflow. However, if you prefer not
to embed profiles, in Panther you can use Quartz Filters to assign
default RGB, Gray and CMYK profiles as source when printing and saving
as PDF.
The bottom line is that saying all CMYK data should be tagged is not
at all realistic.
I guess it depends on your available storage, your network, and your
workflow.
I agree that all RGB data needs to be tagged. And even grayscale data
should be tagged. But CMYK is different, and it needs to be treated
differently too.
The Quartz Filters let you have your cake and eat it, too.
JZ
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.