[Openicc] XICC specification draft

[Chris Murphy]

On Jun 25, 2005, at 6:38 PM, David Burren wrote:

> In general, "who/what" is expected to set the atom, set display  
> LUTs, etc?  In this case OSX will have set the LUT calibration and  
> it makes sense for the Xquartz server to set the atom.  But be  
> careful not to establish a requirement that the server does it: in  
> a pure X11 system it's probably best for a client to do this and  
> handle the relevant policy decisions.

atom is a term I'm not familiar with, so I'm not sure what it's  
significance is.

Anyway, what really needs to be done is build windowing systems to  
use device independent color. Conversion would be a step that would  
occur just prior to rasterizing, both of which can be done either in  
software or in the video card itself depending on the hardware  
available. For applications to need to know how a display behaves  
seems like a ton of extra work on the part of every application  
developer, especially when it becomes clear as we look to the future  
that display behavior is going to be anything but consistent. We  
won't be able to assume sRGB, or device dependent color for display  
without there being a big step backwards in the quality of on-screen  
color reproduction.

(This doesn't mean that the windowing system has to know what CMYK  
is. But a minimum it would be based on a single RGB space, everything  
from applications being normalized to that space.)

Further, application-based color management only handles color within  
the applications windows. The entire user interface itself needs to  
be color managed or the effect of simultaneous contrast will still  
cause two identical images to have different color appearance on two  
displays.


> Which profile should be used in multi-head configs?  In a  
> traditional multi-head X11 system, each screen can be accessed via  
> a different $DISPLAY (e.g. machine:0.[screen-number]).  Thus each  
> screen can have a different profile atom (yay!).  But with this  
> system there's no facility to move windows between screens or have  
> them spanning screens.

The window server knows what display is being used. And application  
doesn't. Correct? If the rasterization portion of window serving is  
color management aware, it's in a better position to negotiate proper  
display compensation, on-the-fly, than an application.

> So systems like Xcinerama establish a single virtual screen  
> covering the entire multi-head area.  And this is what can happen  
> with Apple's Xquartz.  It just presents a simple single-screen  
> desktop to the X11 clients.  On an Xcinerama system the user will  
> have to choose one profile to use for the entire system.  In  
> Xquartz I expect that the server would have to settle on using the  
> profile for the "primary" display (but at least OSX will have set  
> the calibration individually for each screen).  Not a perfect  
> system, but at least it's no worse than the current behaviour of a  
> lot of "profile-aware" software (e.g. Apple Mail, Safari, iView  
> MediaPro, etc) that only know about a single display profile.

What's acceptable today, with largely similar behaving displays, is  
not what we get to look forward to. There are already two displays  
with Adobe RGB (1998) primaries shipping now. Device dependent color  
is seriously over saturated on such displays. HDR displays are on the  
way.

Also, to date the mentioned applications are very color management  
unaware. They do not do color management themselves at all per se.  
When they see a tagged image, the drawing commands include those  
tags, and using Cocoa they get a lot of this behavior "for free."  
Quartz 2D is implicitly asked by the application to do display  
compensation. I believe up to 10.4.1 the rendering is done by the  
application (CPU cycles are attributed to the application) even  
though the rendering library is OS provided. In 10.4.2 this is  
rumored to be off loaded onto the GPU rather than the app. It's not  
much further to totally abstract the application from what display is  
being used, and that will clearly include display compensation.

I see this legacy behavior as something that is systemic, and once  
all the necessary switches get flipped, all apps are going to have  
multiple display support. That's my expectation anyway, I have no  
idea when that will happen.


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)