[OpenICC] Oyranos APIs update

[Chris Murphy]

On Sep 21, 2005, at 11:12 AM, Kai-Uwe Behrmann wrote:

>> According W3C recommendations and IEC 61699 for consumer-devices,  
>> sRGB is
>> common for untagged RGB-data.
>>
>
> This dont touches data exchange between applications on different  
> systems,
> except the WWW.

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 any kind of application that purports to do color management,  
should be treating such files as sRGB. It's a major problem, in my  
view, of Adobe's implementation that the RGB Working Space is used as  
the assumed source profile for untagged images/objects. This is a big  
problem in particular with their Prepress defaults settings which  
uses Adobe RGB (1998) as the default, in an environment that will be  
opening up a lot of untagged RGB images that are certainly not Adobe  
RGB (1998) images, and will not be creating new documents most of the  
time thus Adobe RGB (1998) is next to useless as a recommended RGB  
Working Space *except* for the profile mismatch warning which is  
sometimes useful for some workflows.

I can think of more useful things to do however. And that's for the  
OS to be aware of the status of the display profile. Is it valid?  
Either way, metadata should be included in all images supporting  
embedded profiles. An image with an embedded profile isn't inherently  
trustworthy. If it comes from a system that doesn't have a calibrate/ 
profiled display, the embedded profile is definitely not describing  
intended color appearance correctly (at least statistically).




>
>
>> Assigning a large-gamut RGB-workingspace to untagged sRGB-data  
>> results to
>> heavy colorshifts.
>>
>
> 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.

Also, again RGB input profile by definition means a scanner or  
digital camera profile. i.e. a profile for an input device. If you  
mean as an assumed source profile, then that's what it needs to be  
called.

> The internet browser should attach the sRGB profile during download.
> Is this realistically thought? Can we expect morzilla and konqueror  
> and co
> do like we suggest?

Why not? As there are increasingly displays that do not behave like  
sRGB, assuming that the display = sRGB, and thus we can assume  
monitor/display RGB (no display compensation) as the source and  
destination profile is simply going to ensure an increasing disparity  
in the color experience on the internet.

>>
>> profile dialogues:
>> show dialogues during
>> - opening untagged data
>> - opening data with profile mismatch
>> - copy and paste with profile mismatch
>> - dont show profile dialogues
>>
>
> Thats nearly what is preferable in CinePaint. Sounds allmost  
> reasonable
> at least to me.
> The second point is an non conversion policy? Whats happens with the
> profile in this situation?

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.





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)