Re: [compiz] color management spec
- From: Tomas Carnecky <tom dbservice com>
- To: Owen Taylor <otaylor redhat 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: Sun, 15 Jun 2008 01:38:36 +0200
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.
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.
] [Thread Prev