GSoC CM collaboration

Maarten Maathuis 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.

Maarten.

>
>
>  kind regards
>  Kai-Uwe Behrmann
>  --
>  developing for colour management
>  www.behrmann.name + www.oyranos.org
>
>



More information about the xorg mailing list