[Openicc] color-policy vs. color-infrastructure

[Kai-Uwe Behrmann]

Am 27.02.05, 00:27 +1100 schrieb Graeme Gill:

> So in summary, some candidates for new generation CMM features might be:
> * Support on-the-fly gamut mapping computation

regarding CIE colour spaces. An known issue with them is the lack of gamut 
information. My concern is: how to preserve the same gamut 
mapping behaviour if one gamut boundary (CIE*Lab -> device) is unknown.
Compression makes sense for out of gamut pixel to bring them inside 
destination gamut. Therefor , as I understood, some compression of 
inside colours near the gamut hull is right. Some people take 10% as an 
good value. For Lab it is harder to say, when shall compression start. Has 
the image slightly larger gamut than the destination gamut or is it much 
more saturated? 

What things I could do on application level (CinePaint) to overcome 
this difficulty with CIE*Lab imagery?

Would it
1. be standard and
2. help argyll/lcms
to add the gamut information found in the device profile to the abstract 
profile? I am aware of many colour manipulations making the gamut 
information useless. 

Other options?

> * Support device links as special cases for particular conversions
> * Support rendering intent plane color value extension
> 
> > 2) Storing color corrections as abstract or devicelink-profile
> > ------------------------------------------------
> 
> This is another good idea supported by the ICC format and very
> under-utilized.

CinePaint has the color wheels tool, storing its colour manipulation in an 
abstract profile. This profile type works for 8 and 16 bit depths. I am 
not shure if an device link could be used across bit depths?

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