GSoC CM collaboration
madman2003 at gmail.com
Sun Mar 2 13:19:09 PST 2008
On 3/2/08, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Am 02.03.08, 21:43 +0100 schrieb Maarten Maathuis:
> > On 3/2/08, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> > > Am 02.03.08, 21:01 +0100 schrieb Maarten Maathuis:
> > > > 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.
> > 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.
> You could answere in context to avoid such irritation. No one talked about
> such a large 3D CLUT tables.
Then how would you do the mapping? You have to keep in mind that a gpu
can do is limited, so i assumed mapping each (x,y,z) coordinate to a
screen color value.
I'm just being realistic here, knowing some of the limitations of hardware.
> kind regards
> Kai-Uwe Behrmann
> developing for colour management
> www.behrmann.name + www.oyranos.org
More information about the xorg