[Openicc] Hello *and* (was): LINUX, Gutenprint / CUPS / Color policies

[Chris Murphy]

Hello list,

My name is Chris Murphy, and my company name it Color Remedies, based  
in Boulder, CO. Perhaps I'm best known as co-author for Real World  
Color Management (1st and 2nd editions), published by Peachpit press.  
However my day job is as a trainer and consultant of most things  
color management. I will probably just lurk, but every now and then  
something is sure to get me going prolifically.

In attempting to learn a little bit what this list is about, and  
topics of the moment, I came across the following that I'd like to  
comment on:


Michael Sweet mike at easysw.com
Thu Apr 14 08:11:41 PDT 2005


> Actually, no, that isn't the key.  The printer driver could be a
> relatively dumb program that has no concept of color management and
> just pushes bits around.
>
> The key is to track the colorspace meta data (either a well-known
> colorspace like sRGB or an application-defined profile) so that an
> accurate (or acceptable facsimile) reproduction of those colors can
> be done on the output device.

The lack of understanding this very thing, by Adobe, Apple and  
Microsoft, is what has caused a horribly confusing and inconsistent  
color management user interface and user experience. To this very  
day, when you prematch data in Photoshop (for example) to a specific  
output device profile, Photoshop submits that data as untagged to the  
OS. On OS X 10.3.x, a PDF spool file is produced by the OS. The OS in  
turn refuses to allow the concept of untagged data, so it tags it  
with a bogus profile - Generic RGB. The result is a PDF spool file  
that is borked for the purpose of soft proofing because its  
incorrectly tagged, and it also requires a square dance under a full  
moon with the dog, the pig, and the pony in order to get subsequent  
settings in the print driver correctly set. Choosing a color   
management setting OTHER THAN ColorSync in the print driver causes  
the OS to use Generic RGB as the destination profile. Since source is  
Generic RGB, and destination is Generic RGB, you get a null transform  
of this prematched data. But both source and destination tags are  
totally bogus, and must be bogus, in order for this to work (which is  
why apps that prematch data, like Photoshop, submit untagged data; if  
they submitted tagged data, you'd get an unwanted conversion by the  
OS even if you explicitly do not ask for one).

In effect, the color management systems on these two OS's assume  
either untagged data, or normalized data (to a single space), but not  
prematched data which all of the major desktop publishing  
applications do (Photoshop, InDesign, QuarkXPress, etc.). It is  
possible for ICC-based color management to occur twice.

So I agree with Michael, the key is tracking the metadata. This means  
there are a number of responsibilities on application developers so  
that their app does the "right thing" when it comes to preserving  
this metadata, honoring it (usually by default), while having logical  
ways to ignore it (i.e. there are reasons to ignore embedded CMYK  
profiles in favor of something else, and generally that's not the  
case with RGB), and either normalizing content to a particular color  
space, or making the OS aware of the source profile associated with  
each object.

There are all sorts of applications on Mac OS and Windows that have  
no idea what ICC profiles are in TIFF files, and if you open them and  
resave them as TIFF or JPEG or whatever, the metadata (the ICC  
profile) is dumped. This is inexcusable behavior for the year 2005 on  
modern operating systems, yet here we are. So I'm hoping that these  
kinds of problems can be avoided in the future, on any platform.



Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
-------------------------------------------------------------
Co-author "Real World Color Management, 2nd Edition"
Published by PeachPit Press (ISBN 0-321-26722-2)