[Openicc] XICC specification draft

[Chris Murphy]

On Jun 25, 2005, at 7:26 PM, Bob Friesenhahn wrote:

>> I think in any case it would make sense for applications to  
>> normalize to sRGB as a destination in a a remote display context.  
>> Then the entire xserver window on the remote machine could do  
>> simple full screen display compensation from sRGB to actual  
>> display profile (and if there is no display profile, as could be  
>> expected on some systems, at least there has been at least some
>>
>
> This assumes that the display is a good match for sRGB.  Maybe its  
> capabilities far exceed that of sRGB and the user wants to take  
> advantage of these extended capabilities.

Yes it does. I agree if now is the planning stage for future CM  
behavior, it should be built with the future in mind, not today's  
displays.

Support for wide gamut displays mandates display compensation on a  
wide scale basis or the display is not usable for even reliable  
display of web graphics, let alone more sophisticated image display.  
As I see it, a smarter xserver is unavoidable.

What are the ways to do this?

1. full device independent color data (tagged RGB and CMYK and LAB)  
support between xclient and xserver, and for the xserver to do  
display compensation.

2. xclient normalizes to some yet undecided wide gamut color space;  
and then expect the xserver to do display compensation from that  
space to that of the actual display.

3. xserver informs xclient of remote display's color space; and  
xclient prematches to that space.

Case #3 is probably easiest to implement, and the xclient could  
assume sRGB as the destination if the xserver hasn't reported the  
remote display's profile - i.e. built in legacy support. I imagine  
it's unlikely for all xservers everywhere to instantly have the  
ability to report the local display profile.


> The xclient is the 'application'.  If the client displays to  
> multiple displays, then it will need to know the capabilities of  
> each one. One display might be black and white while the other  
> supports 12-bits/sample RGB.

Well darn. See now in Case #3, the assumption is that *all* xclients  
are smart and are doing display compensation for the remote display.  
This too probably can't always be assumed, can it?

So really this is less about xserver capabilities (other than the  
minimum necessary ingredient which is for it to report a display  
profile back to the xclient or its OS), and about how to have general  
support for displays with various capabilities.

I think it's asking a lot of extra work by application developers to  
have to write display compensation into every single application that  
will display something. It seems redundant. What are the barriers in  
implementing an architecture where the application developer can have  
three options?

1. Assumed source space for all RGB drawing commands (default). This  
would likely be something like sRGB for at least the next five years.  
The window server assumes this as source, then does display  
compensation for all applications.

2. Application explicitly informs window server of some other source  
space to use. (apps requiring more sophistication can opt in for this.)

3. Application explicitly informs window server that data is  
prematched, so it doesn't do any display compensation at all.


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)