[OpenICC] Oyranos APIs update

[Chris Murphy]

On Sep 28, 2005, at 1:45 AM, Kai-Uwe Behrmann wrote:

>> The W3C spec actually only specifies an assumed image gamma of 2.2  
>> if I recall
>> correctly. It doesn't require full blown display compensation.
>>
>> Practically speaking, anything untagged is treated as sRGB or  
>> monitor RGB. In
>>
>
> On an system with mixed colour aware applications, it seems not
> sensible. The user might want to edit an image in CinePaint with  
> colour
> management, and then sent it to OO, wich is not capable of CMS  
> currently.
> An in OO created document should be considered as in the colour space
> used initially in CinePaint. That is what I understand as a policy  
> - "RGB
> working/editing space".

You can't do anything about applications that aren't color management  
aware unless you're willing to build an operating system that second  
guesses the application. If the application doesn't do color  
management, and doesn't opt out of color management explicitly, then  
the window server itself assumes sRGB (or some sensible source space)  
and does on-the-fly display compensation. Only applications that opt  
out of this would be exempt, like games for example.

For applications that are going to expressly opt in for color  
management it does make sense for them to assume sRGB as a source  
profile for untagged objects because the overwhelming majority of  
untagged images in the world are better described by sRGB  
statistically than anything else.


>>> Then we would distinguish between RGB files coming in from:
>>> a) the internet -> sRGB
>>> b) elsewhere -> OY_DEFAULT_RGB_INPUT_PROFILE
>>>
>>
>> "b" is an automation feature. Images that are definitely in a  
>> space other than
>> sRGB should have an embedded profile already in them. If they  
>> don't, then they
>> should be batch processed using a script that does this. I don't  
>> think it
>> belongs in every imaging application as a policy.
>>
>
> But for applications passing the local system / www border. They  
> need an
> way to translate untagged data from the recomended w3c sRGB  
> standard to
> the internal used OY_DEFAULT_RGB_INPUT_PROFILE setting. It is just  
> a try
> of finding an meaningful concept, what colour policies should serve.

sRGB should be the default source profile for a web browser. The  
destination profile is the display profile. There is no reason to  
convert to some other source space, and by definition you don't  
convert from source to source. You convert from source to destination.

>>
>> It's merely raises the question if the user wants to convert  
>> (preserve color
>> appearance) or not convert (preserve numbers). The former is  
>> useful in almost
>> all cases, whereas the latter is preferred for web designers who  
>> want to make
>> sure specific RGB values are used, such as for matching text color  
>> to a
>> background or product color, or whatever.
>>
>
> I heard of many people, which are not willing to do an conversion  
> by an
> untrusted conversion library. ICC transformations are in some areas
> completely untrusted, because of missing precission. Not only the web
> designers want to preserve the numbers. Of course there are diverging
> preferences of users.

It's a valid concern, but doing nothing isn't really possible.  
Something is going to be used as a source profile, the question is  
what? The closest thing to nothing you get is simply turning display  
compensation off. If there are people who want to be deluded about  
the color appearance of their images, then I suppose they should have  
that as an option but I wouldn't make it the default behavior.




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)