[Openicc] Xorg low level buffers - colour conversion
Graeme Gill
graeme at argyllcms.com
Wed Mar 12 07:49:46 PDT 2008
Gerhard Fuernkranz wrote:
> Btw, can GPUs only do massive parallel floating point operations, or
> also massive parallel integer operations (which is of course only of
> interest if the latter are even faster than the FP operations then)?
It depends on the generation of the GPU. In general the earlier
generations had integer only fragment shaders and floating point
only vertex shaders, but the latest GPU's have moved towards a unified
processing architecture where both integer and floating point calculations
can be done on both vertices and fragments, as well as expanding
the size of floating point numbers they handle.
> Sorry for my ignorance, I'm also wondering, does one just need to write
> the shader program for the color transformation of a single pixel, and
> this program gets then vectorized and applied to each pixel
> automatically (and in parallel) by OpenGL and the GPU?
Yes, that's pretty much it.
> Even if reading back is not so fast, I'm wondering, whether processing a complete
> image by the GPU may be possibly still faster than doing the multi-dimensional
> interpolation for each pixel with the CPU?
I would expect so with a decent GPU. They have dedicated hardware paths for
trilinear 3D texture lookups, making it fairly trivial to implement
a 3D color transform this way. The core step is a single
line of GPU source:
out.rgb = tex3D(lut. scale * in.rgb + offset)
Of course a higher quality implementation would include per
channel in and out tables too.
See "Using Lookup Tables to Accelerate Color Transformation"
by Jeremy Selan, GPU Gems 2 pp 381 Addison-Wesley for more details.
Such an approach is used by many (most ?) of the 3D animation studios
to do color managed previews of animation's. The example OpenEXR
viewer is such an instance.
Graeme Gill.
More information about the openicc
mailing list