[OpenICC] Oyranos APIs update

[Kai-Uwe Behrmann]

Am 28.09.05, 00:55 -0600 schrieb 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

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".

> 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

Oyranos has the
oyINPUT_RGB 	standard RGB input profile
setting for this task, which indeed should be allmost sRGB. The 
working/editing space is a different setting.

> 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).


Hmm, I will put it on a feature wish list.

> > > 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.

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.
 
> 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.

Ok, I will change this. Thanks.

> > 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.

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.

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name