[compiz] color management spec

[Kai-Uwe Behrmann]

Am 14.06.08, 20:13 -0400 schrieb Owen Taylor:
> On Sun, 2008-06-15 at 01:38 +0200, Tomas Carnecky wrote:
> > Owen Taylor wrote:
> > > If the visual of a window is ARGB, it can't hold XYZ or Lab, or most
> > > obviously CMYK data.
> > 
> > > 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.
> > 
> > If you have an image in CMYK the best way to avoid losing gamut, just 
> > like in your AdobeRGB example, is to let the CM convert it at the very 
> > last stage. So it might be useful to be able to upload CMYK pixels into 
> > the xserver and tag the data somehow. I don't see any conflict there as 
> > long as the application and CM agree on the pixel format.
> 
> I think there is a significant difference between having the CM deal
> with the exact interpretation of RGB in a RGB pixel format, and having
> the CM take "random" data stuffed into a RGB pixel and convert it - does
> the user still see something intelligible if the CM/app communication
> goes wrong? If a CM isn't running? If the user takes a screenshot of the
> window?
> 
> Also, of course, CMYK isn't a precisely defined color space like sRGB;
> you'd have to accompany the window with a color profile.
> 
> > > 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.)
> > 
> > First the server would have to support buffers with at least 6 byte per 
> > pixel, which it does not currently. I would love to see support for 
> > arbitrary pixel formats in the xserver. I would even go as far as having 
> > the xserver create bare buffers and then tag them with the pixel format 
> > / icc profile. After all, if a (OpenGL-based) CM is running the xserver 
> > doesn't need to know anything about the windows besides the dimensions.
> 
> There's certainly significant work there at all layers. I believe that
> there was discussion on the cairo mailing list of someone starting doing
> work within pixman, which is certainly a good place to start.
> 
> As above, I'm not sure uninterpreted window buffers is a good idea... or
> really necessary. Better to support a small set of things well than a
> large set of things poorly.

The idea is to have as few as possible colour conversions to gain speed, 
be economic with memory resources and preserve precission. An other goal 
to bring fancy pixel buffers close to the DVI outpu connector is to send 
high bit depth channels over to the monitor device. 

With dual link DVI connections we have since quite some years devices on 
the marked. Recently they became, in the speach of colour management 
experts, affordable. So there are reasons enough to drive this approach. 

About scRGB, Windows has a very simple approach in mind with its kind of 
"single colour space solutions", which might be powerful for its purpose. 
The open source colour management community, read Scribus, Krita, 
Ghostscript, Oyranos ... did not adapt to such a thing in mind or in 
practise. So citing scRGB will fall relatively short in this community. 
We orient much toward ICC and possibly OpenEXR colour management. What is 
good for the internet, and we support this hartedly, might not be good for 
the desktop, printing, movies and other arts.

Please support the search for variable channel, variable bit depth and 
variable coulour space transport definitions.

One of the bricks we need is access from the upper end, e.g. applications, 
to the compositing buffers. The buffers of the later are already in 16-bit 
size. A clever colour conversion module (CMM) could convert their content 
already to support HDR. Whether the way to go is, to bypass toolkits and 
use OpenGL for 16-bit(++) buffers, or toolkits support these kind of 
things has to be researched as well.


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