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.
tom
_______________________________________________
compiz mailing list
compiz lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
|
