GSoC CM collaboration
graeme2 at argyllcms.com
Sun Mar 2 16:00:28 PST 2008
Stephane Marchesin wrote:
> You certainly can't do something that flexible at the driver level:
> the hardware does not allow it.
Actually, current GPU hardware does allow for this rather well.
A fully populated 3D color lookup is pretty much out of the
question for every day systems, which is why the usual approach
is to use a sparsely populated table and interpolate (17^3 = 4913
entries or 33^3 = 35937 entries is pretty typical). For optimal
smoothness there are usually 1D input and output tables too.
Typically the cells formed are interpolated using a linear
interpolation, either multi-linear or tetrahedral interpolation.
(For RGB->RGB, tetrahedral is probably preferable from a quality
point of view, since the neutrals are down the diagonals.)
Given that every pixel has to be converted, this operation can
be performance critical. On a conventional CPU it's not easy to
make go fast (I've written a few of these things), but a GPU
has hardware to do exactly this sort of operation, usually
in the guise of interpolation of color values during polygon rendering,
or interpolated texture lookups. I know that some of the
3D studio's use this approach for their previewing of animation's.
See "Using Lookup Tables to Accelerate Color Transformation"
by Jeremy Selan, GPU Gems 2 pp 381 Addison-Wesley for an example.
> 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 would be one approach if you need to maintain pixmap contents
to allow application readback. Of course the color space affects
composition, so ideally you need to convert all the different
colorspaces into an additive space, compose, and then convert
into the monitor space for display. This may not be viable
for interactive systems currently, but having the GPU color
convert into monitor space during composition sure seems feasible
with modern hardware. All you need is some standards as to
how it is to be managed, and an implementation :-) :-)
The other approach is for this all to be the applications problem.
This is the conventional approach, the application calling on
a CMM (Color Management Module) for access to the color profiles,
to do profile linking, and provide the necessary pixel conversion machinery.
More information about the xorg