color management spec

Roland Scheidegger sroland at tungstengraphics.com
Mon Jun 2 06:32:46 PDT 2008


On 31.05.2008 23:16, Tomas Carnecky wrote:
> Maarten Maathuis wrote:
>> It would be a good idea to ask someone what the price of a
>> implementation would be at the level of a compositing manager, maybe
>> even make a draft fragment shader. Because whatever you think up has
>> to fit a typical gpu, otherwise it's a disaster waiting to happen.
> 
> IIRC someone posted a sample C application that uses OpenGL shaders and 
> a color management library (lcms?) to generate the shader and to convert 
> a file from srgb to some other profile. Yay, I found it :) here is the 
> said email:
> http://www.mail-archive.com/lcms-user@lists.sourceforge.net/msg02326.html
> 
> It is basically just a trilinear texture lookup. 3D textures are 
> supported starting with OpenGL 1.3, so any decent driver will support that.
Not so fast. First, the usage of GLSL shaders means you need OGL 2.0.
Now, you could do it with ARB_fragment_program instead, but it does a
dependent (3d, bilinear) texture lookup, which pretty much excludes
older hardware anyway.
Also note that none of the mesa based drivers support a 16-bit int
texture format (since mesa doesn't support it), so they'd downconvert to
8-bit which probably won't work correctly... (hw like the radeon r300
could do it).  And note that for instance the widespread i915 wouldn't
support 16-bit int formats with more than 2 channels afaik, though it
could be fixed by splitting the lut up into 2 textures obviously.
So not to say this doesn't fit typical gpus, but it only fits new gpus
(and mesa doesn't support it in this form neither, though it should be
possible to split up the 4x16 bit channel texture into 2 4x8 bit
textures by separating the low and high bits and reintegrate them back
in the shader I guess, not very efficient...)

Roland



More information about the xorg mailing list