[Openicc] XICC specification draft

[Chris Murphy]

On Jun 28, 2005, at 3:10 AM, Kai-Uwe Behrmann wrote:


> About the general option I would agree. Nethertheless tagging with the
> display profile instead of declaring the image is prematched is  
> dangerous.
>

The net effect is the same, if the system and the xserver get the  
profile from the same location, you are assured that they are the  
same and that a null transform will occur. But I think an explicit  
"off" switch is preferable because it's very clear, whereas the null  
transform approach involves redundancy and an explanation of the  
concept.


> Someone explained on this list how profile sizes can be striped down.
>

If it was recent and was with respect to output profiles, and remove  
1 out of 6 of the tables, that was me. :) That's perfectly doable,  
it's not a profile in an actual file but rather in a data stream to a  
specific destination (the display), so subsetting them is  
straightforward.




> A
> simple mechanism, which relies on MD5 checksums, would not  
> understand the
> X screen and the image are tagged with the same profile and would  
> repeat the
> conversion. This is approach is in my opinion a workaround only for
> existing systems. We dont need to implement such limitations.
>

Well, again with respect to applications that prematch to the  
*display* profile, there is no reason why they would grab a display  
profile other than the one the xserver is using.

The situation of null transform philosophy that does not work where  
it should, is really another discussion and is an important one, but  
much more complex than what we're talking about here. That  
conversation is about figuring out a clear threshold function (which  
can be different depending on the sophistication of the end user) for  
assuring a null transform. For matrix profiles it's easier to check  
primaries and tone response, ignoring the name of the profile  
(filename or internal name) and other factors, to determine null  
transform. But for output device profiles this is a common problem,  
especially for CMYK because it depends on context.

For example, if source is TR 001 (colorimetric data set for SWOP)  
based, and the destination is also based on TR 001, but the profiles  
are built with different profiling packages, you will invariably get  
a conversion. In many cases you will NOT want such a conversion, but  
in some cases - such as a difference in black generation - you would  
want a conversion, but surely not by default. However the threshold  
functions thus far do not work well (maybe not at all) for output  
device profiles that aren't essentially identical.


>
>
>
>> Or it could be merely tagged as "intentionally device dependent."
>>
>>
>
> We should support this instead. This can be made a simple flag and  
> is much
> more clear.
>

I agree. In any event the application must specifically request this.  
This is important because I think it is very necessary for  
applications of the "average" sort to get the minimum/basic display  
compensation form of color management for free, because of the  
looming issue with a wide variety of display device capabilities in  
the future.



>
>
>
>> 2. Application is not color managed and simply sends what it  
>> things are device
>> dependent drawing commands using today's APIs. An updating  
>> compositer/xserver
>> simply says "aha, ignorant application, I will assume these values  
>> are tagged
>> sRGB for the source profile and perform display compensation using  
>> the
>> destination profile."  Anyone who wants to prevent this from  
>> happening and
>> doesn't care about display compensation can simply set the display  
>> profile to
>> sRGB and again get a null transform.
>>
>>
>
> The same here, basically agree -- null transform is no option. A flag
> would do a better job.
>

No flag required. My suggestion requires an updated xserver (or  
wherever it is, not sure since I'm not a programmer) that arbitrarily  
takes control for any application that does not explicitly ask to be  
freed from display compensation. The app needs to do nothing at all  
different today to get basic, source RGB is assumed to be sRGB and  
destination is assumed to be current display profile and display  
compensation occurs automatically. If this is not desired *THEN* the  
application developer needs to do something (like opt out), or if  
they want better quality than sRGB as the assumed source to opt-in by  
explicitly tagging the RGB data stream with something other than  
sRGB. And I think it's perfectly acceptable to propose only matrix- 
based profiles can be used as this "normalized" profile space by the  
higher end apps.


>
>
>
>> 3. application is color managed, but wants to opt for normalizing  
>> to some
>> larger gamut space (a system compositing space perhaps), so that  
>> it doesn't
>> have to negotiate display compensation itself, especially for  
>> multiple
>> displays, rather allowing the xserver to do this. But the  
>> conversion still
>> needs to be to a space that has a sufficiently wide gamut in order  
>> to not
>> cause clipping in the event the display being used is a wide gamut  
>> display.
>>
>>
>
> IMO we will need a lot of time to have a full covering  
> implementation of
> server side colour management. Anyway it's highly desireable.
>

Yeah. I'm suggesting *all* three of these features be implemented by  
the xserver. Not as a list of choices. Those three are choices for  
applications - one of them *will* apply.

1. Explicit request to opt out, device dependent, prematched.
2. "For free" sRGB assumed source, display profile is destination,  
display compensation. Application developer needs to do nothing  
different than they are today.
3. Explicit request for something other than sRGB as source, by  
tagging RGB data submitted display.



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)