[compiz] color management spec

[Owen Taylor]

On Sat, 2008-06-14 at 12:51 -0700, Hal V. Engel wrote:
> On Wednesday 11 June 2008 08:33:04 am Owen Taylor wrote:
> 
> > [ Intentionally not trimming quoting much due to various bounces
> from lists
> 
> > ]
> 
> >
> 
> > On Wed, 2008-06-11 at 09:05 +0200, Kai-Uwe Behrmann wrote:
> 
> snip
> 
> > > Tagging the window with the image colour space will render in
> rather a
> 
> > > mosaic of windows.
> 
> >
> 
> > I don't understand this.
> 
> I think you are assuming that the image color space is some kind of
> gamma corrected RGB color space. What is the image color space was a
> CMYK color space or XYZ or Lab? 

If the visual of a window is ARGB, it can't hold XYZ or Lab, or most
obviously CMYK data.

I don't see color management support at the CM level as being a
mechanism to simplify the writing of image handling code, it's a
mechanism to allow the user to see the widest range of accurate colors
possible on their monitor.

For any color space you might want to support on a toplevel you have to
ask "what is the advantage". 

 sRGB: decent compromise between range and precision. Widely used
     standard.
 
 raw monitor color space: allows the application full control. 
     difficulties in multi-monitor setups if the monitors aren't
     identical and calibrated identically.

The reason why you might want to support other color spaces is to get
greater gamut then is possible with sRGB without having to deal with the
difficulties of per-monitor specifics... if I have an image in Adobe RGB
with 8 bits per primary, it might be interesting to preserve that
colorspace and use that as the colorspace on my toplevel, but that's not
done to avoid having colorspace conversion code in the application: it's
done to avoid losing gamut when converting it to something else.

Honestly, the only reason this is at all interesting is the limitations
of RGB 8:8:8. The long term solution here is support for something
like scRGB (http://en.wikipedia.org/wiki/ScRGB_color_space.)

- Owen