[Openicc] Where should CM occur? was: Colormanagement in Gutenprint

[Chris Murphy]

In reading through threads to catch up, I'm seeing a recurring 
discussion on whether color management should be happening in the 
application, the OS (display services or print services) or in the 
printer driver. This is probably more useful for me to write it since 
it's likely just a summary, rather than for the list to read it, but 
here it is anyway.

The old paradigm said that displays were treated as input devices from 
a color management perspective. Raw RGB values were sent to the 
display, because that's all that could be done at the time, and so the 
display profile was the source profile for this data. The new paradigm 
is to customize the image data for each display on-the-fly (display 
compensation), which means the display profile is a destination 
profile.

Essentially, we have a need for normalizing content to a particular 
color space in order to display it, or print it. Either the application 
must do that, and the OS is basically color management ignorant (does 
no further conversion) for both display and print purposes. Otherwise 
the application merely submits metadata (ICC profiles) about the color 
space that applies to each object it wants to display/print and the 
operating system manages how to normalize these objects to the correct 
destination profile (display profile when sending objects to the 
display, and a particular output device profile when sending objects to 
a printer).

Because of the OS specific dependencies necessary for color management 
to happen in the printer driver itself, it seems to me the applications 
are going to have to do the heavy lifting in order to ensure the right 
thing is happening. All platforms have a way to inform them "do nothing 
else" (even if it might be less explicit than we'd like), but not all 
of them have the means for apps to just sent a bunch of metadata and 
hope the OS or the print drivers will honor them and do color space 
conversions correctly. Thus application-level color management is 
easier to implement, and for the developer to choose the relative 
sophistication of the implementation. But it also implies the OS needs 
specific handling for "prematched" data, an area of weakness on Windows 
and Mac OS X currently.

The advantage of system level color management is that you can 
associate device profiles with particular settings in the driver so if 
someone uses a Premium Luster paper type, a particular profile (user 
selectable) will automatically be used rather than the situation where 
you have to select a specific profile *and* the media type settings. 
The more it's desirable for apps to defer to the OS for window/display 
services and print services, the more sophisticated those services must 
be in terms of color management. (Copy/paste between applications comes 
to mind in this area as well, which you can't do without something 
being the intermediary.)

In practice, we have aspects of both implementations. Adobe apps can 
prematch data themselves, or they can submit color metadata downstream. 
But as I've mentioned before the main reason why apps still do this 
today instead of deferring to OS-level color management is because of a 
LACK of sophistication on the part of the OS color management services.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"
Published by PeachPit Press (ISBN 0-321-26722-2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3496 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/openicc/attachments/20050511/e47f45cc/attachment.bin