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