GSoC CM collaboration

Maarten Maathuis madman2003 at gmail.com
Sun Mar 2 12:43:51 PST 2008


On 3/2/08, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Am 02.03.08, 21:01 +0100 schrieb Maarten Maathuis:
>
> > On 3/2/08, Hal V. Engel <hvengel at astound.net> wrote:
>
>
> > > Because it is a 3D problem. For output devices like monitors color management
>  > >  maps from some absolute color space such as CIELab or CIEXYZ into the devices
>  > >  color space in a way that corrects all colors not just those along the
>  > >  neutral axis.  The most you can do with the video card LUT is to get the per
>  > >  channel gamma to be well behaved and the R=G=B axis to be close to neutral.
>  > >  You can not get colors correct for R!=G!=B.   This is a direct result of the
>  > >  1D limitation of the video card LUTs.
>  > >
>  > >  An example, where this becomes very apparent is with the newer LED based wide
>  > >  gamut monitors.  Even with a well calibrated video card LUT the display
>  > >  colors where R!=G!=B, with out full color management, will be much too
>  > >  saturated to the point of being garish.  These monitors are starting to
>  > >  become fairly common so this will only become more of an issue going forward.
>  >
>  > You're essentially assuming that the individual color channels are not
>  > linearly independent?
>
>
> You cant correct a very saturated red from a wide gamut monitor with just
>  modifying the red curve to a less saturated red, say to match sRGB.
>
>  This colour transformation involves mixing in of some blue and green to
>  reduce the saturation. Hence it is no longer one dimensional.
>
>  You seems to be pretty interessted. Here some links and link collections:
>  http://en.wikipedia.org/wiki/Color_management
>  http://www.behrmann.name/index.php?option=com_weblinks&catid=70&Itemid=95
>
>
>  kind regards
>  Kai-Uwe Behrmann
>  --
>  developing for colour management
>  www.behrmann.name + www.oyranos.org
>
>

I would like to add, that would you propose is unrealistic.

A 256^3 * 3 bytes matrix is 48 MiB large (this would become 64 MiB on
some/most hardware due to a lack of a real 24 bits texture format).
It's also something you don't want to do in software, and still
expensive to do in hardware. It's certainly non-trivial to implement
and i don't expect it to happen.



More information about the xorg mailing list