[cairo] Adding a color management interface to GTK
ku.b at gmx.de
Fri Jan 22 00:41:59 PST 2010
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 ->
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.)
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the cairo