[Openicc] GSoC CM collaboration

[Graeme Gill]

Gerhard Fürnkranz wrote:

> Actally I find Kai-Uwe's idea not really absurd. Even if they should (hopefully) give very
> similar results, why should we not have the opportunity to select between different pixel
> transformation (interpolation) engines which installed on the system (for instance an IMDI-based
> one, or ultra-fast hardware-aided ones, or a high-accuracy but slower floating point engine),
> independently of the full-featured CMM, which is selected for doing the high-level work (like
> pre-computing the device links for the pixel transformation engine, or handling different
> rendering intents, coping with the special issues when mixing V2 and V4 profiles, conversion
> between XYZ and CIELAB PCS, computing on-the-fly gamut mapping (e.g. BPC), etc.)? Of course this
> requires a well-defined interface to the pixel transformation engines.

If it's part of a high level CMM interface, of course such a thing is possible. Given
that the concept of selecting a CMM is above the heads of 99% of the users of
systems already, I can't imagine that very many people would understand what
such an option is for, never mind what the choices mean though. On odd
occasions for color professionals, yes this would be useful.

But this discussion didn't arise in the context of a pluggable CMM, it arose
in the context of the idea of incorporating color transformations as
part of a compositing engine, which is the implementation most graphic
interfaces are going, given the trend in video memory, graphics hardware
and user interface "bling" (e.g. transparency, animation, zoom views etc.).
The 3D graphics engines have become extremely powerful and flexible,
and are capable of these sorts of compositing and transformation operations
at very high speed, and more. It seems quite feasible therefore to
have an architecture where the compositing engine does the bitmap/window
to composite screen color transformation on the fly. While it might be
technically feasible to make such a color transformation pluggable,
I don't see it as a rational thing to want initially. Just having
one fixed but working implementation would be achievement enough start
with I think!

Graeme Gill.