Re: [compiz] color management spec
- From: Owen Taylor <otaylor redhat com>
- To: Tomas Carnecky <tom dbservice com>
- Cc: gtk-devel-list gnome org, 'compiz list' <compiz lists freedesktop org>, xorg lists freedesktop org, "Hal V. Engel" <hvengel astound net>
- Subject: Re: [compiz] color management spec
- Date: Sat, 14 Jun 2008 20:13:20 -0400
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
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.
] [Thread Prev