Re: [compiz] color management spec

[Owen Taylor <otaylor redhat com>]

On Sun, 2008-06-15 at 11:52 +0200, Kai-Uwe Behrmann wrote:
> 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.

[...]

You use "very simple" here as if it was an insult. 

Inherently, if you want to alpha blend, you want to use intermediate
buffers, then you need a common colorspace. Reject a common colorspace,
then you've thrown out some of the most important tools in the graphics
toolkit.

Let me emphasize here that I'm not trying to sabotage the approach of
doing final color conversions in the CM. I think it's a fine project.

But what I'm arguing against here is putting in a lot of complexity - in
particular, tagging regions of a toplevel with different colorspaces -
to try and achieve future hypothetical advantages that are better 
achieved by using high precision pixel formats.

- Owen

[
If, in certain specialized areas, the precision of 16-bit floats is
insufficient, then certainly 128-bit pixel formats with 32-bit floats
are feasible with current hardware, if memory and bandwidth intensive. 
]