GSoC CM collaboration

[Stephane Marchesin]

On 3/2/08, Hal V. Engel <hvengel at astound.net> wrote:
> On Sunday 02 March 2008 12:43:51 Maarten Maathuis wrote:
>  > 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.
>
>
> No one is proposing a 256 point 3D LUT.
>
>  I would actually put this in a broader context since I personally don't care
>  how the problem is solved as long as there is a solution.
>
>  How do we solve the system wide monitor colorimetric issues that are now
>  becoming so apparent with the advent of wide gamut monitors?   This issue has
>  been there forever but was masked by the fact that most monitors fell within
>  a fairly small range of colorimetric characteristics and this has, until now,
>  allowed us to ignore the issue.  Those days are fast disappearing and will
>  some be gone.
>
>  One way to solve this is to leverage what has been learned about color
>  management and applying this to the whole desktop.  This is what Kai-Uwe is
>  proposing.  There may be other approaches or combinations of approaches that
>  can be used as well.  I am open to any plausible approach and would like to
>  hear how others think this problem can be solved.
>

You certainly can't do something that flexible at the driver level:
the hardware does not allow it. You also cannot modify the pixmap
contents because the application still expects to find its data as it
wrote it. And you don't want to modify every application, of course.
The solution might "simply" be to write a compositing manager that
does whatever lookup you want. Fairly recent X.Org versions allow
that.

Stephane