[cairo] Adding a color management interface to GTK

[Kai-Uwe Behrmann]

Am 21.01.10, 15:53 -0800 schrieb Bill Spitzak:
> I think any attempt to do color management is misguided.

Its necessary to share thoughts about visions on order to move on, but IMO
the above sentence reads like a pure overstatement.

> We already have a floating-point api for specifying the colors. This
> means that the sRGB primaries can support an infinite gamut, as I have
> argued earlier.
>
> It is true that images used as sources can only contain clamped sRGB
> values so they have limited gamut. I think it would be far more
> effective to support float and half-float image formats so that an
> unclamped value can be in the image.

What would interesst me is a comprehensible comparision between speed 
adn other footprint of the various encodings (8-bit -> double/gamma) for 
various operations and on different hardware (handheld or ARM -> 
desktop+GPU).

Code expressed in floating point math would be much nicer to understand.

> Any time spent on "color management" that could have been spent
> supporting floating point image data is time wasted, imho.

I do not think this is anymore much related to the original thread. 
I can understand that Gtk maintainers say: "We want cover the majority of
use cases which summarise to 90%" or the like.

Anyway. For Cairo some more coverage seems to be arguable.

Back to floats,
given that ILM had invented a colour management system from scratch for 
OpenEXR should ring some bells.
I wonder why you see color management and float support so exclusive.

For e.g. spectral imaging both CM and floats would be useful. Again its 
interessting that the OpenEXR library is flexible enough to support 
sprectral imaging. (What a pitty that it has not yet proper ICC support,
and the other way around, that ICC has no broad and established support 
for OpenEXRs CM features.)

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org