GSoC CM collaboration

[Graeme Gill]

Kai-Uwe Behrmann wrote:

> Am 04.03.08, 12:35 +1100 schrieb Graeme Gill:
> 
>>Kai-Uwe Behrmann wrote:
>>
>>
>>>IMO it boils down, whether it makes sense to keep the CMS impact on the 
>>>application side minimal, or accept that a application has to call a CMS 
>>>in order to do any colour management.
>>
>>I'm not a great believer in making wrong architectural decision
>>simply based on the convenience of implementing them.
> 
> 
> What does you mean with "wrong architectural decision"? You are 
> referencing to alternatives.

Just because it's convenient to have a bunch of related
stuff in a bundle called a "CMM", doesn't mean that it's
best to regard it as indivisible. The linking and
pixel transformations functionality typically bundled
in a CMM are related, but separate steps. So if it makes
sense to implement the color transform pixel engine
at one (low) level, it doesn't follow that the linking
part has to be in the same place, or even that they
are from the same CMM. Nor does the reverse follow :- just
because the linking part is at a higher level,
it doesn't follow that the pixel engine has to be at the
same level, or even that there is only one place where
the pixel engine is implemented. The way these two
parts communicate is via device link information
(device color to device color transform shaper/lut/shaper information,
  NOT necessarily in ICC format, or directly related to
  user application level ICC device links).

If there is the possibility of implementing color space
transforms on the fly in a GPU based composting engine,
then that sounds like a rather interesting approach.
But I don't think that the linking part (which involves policy,
preference, innovation and style) should be stuck in there as well.
It doesn't belong there.

Instead what should happen is that at the graphics API level
the application should communicate as simply as possible
what it wants done with the color (ie. what color space
things are in, and what preferences it/the user/system preferences
/system defaults have, or even provide an ICC device link), and the graphics
toolkit should then use the CMM to implement it. If it's got a color
transform capable compositing engine available, it will call on
the CMM to setup the device links, and then pass them
down to the GPU base engine. If it is not running on top
of such a engine, it can call on the CMM to transform
the pixels so it can achieve the same result with
a different implementation. Note that in a real world
system the CMM will be operating as a shared application service,
since it will be highly desirable to cache the device links on
disk, and a smaller number of most frequently used in memory.
For a GPU implementation, some would be cached in the video RAM.

> With this a ArgyllCMM can create its own specialised options tab. What 
> the Argyll CMM shows a user is up to that CMM. Further it is up to a 
> application to implement and show a generic options dialog, which can then 
> show the CMM options.
> I'd for instance expose a precalculation option for the currently used 
> lcms CMM.
> A Argyll CMM could put in options for smart colour management. 
> 
> I dont see problems with individual options and approaches in relation to 
> early colour binding. Oyranos is designed for making this possible.

Fine, but I can't see any of that having a place at the compositing
engine level.

> Hmm, with device links we enter a difficult field. They should be 
> supportable without problems in each CMM. Only it is needed to prepare 
> that on application side, read create the DL and attach it to the plane. 

The device link information is already there. It's what is
communicated between the link code and the pixel engine code.
Note that what I'm talking about here is not anything
directly to do with ICC device link files.

> Early binding + opt out for colour management down the path. I wrote in an 
> earlier email in this thread that this should be part of the GSoC project.

Right, the user interface/CMM selection/profile linking
needs to happen at the user side, not deep in the
frame buffer rendering code.

> Oyranos shall provide the means to customise individual approaches at 
> least on the application side.
> For late binding, read system level, we have to discuss how usefull are 
> advanced options appear. Do we need special CMM options to apply for the 
> whole desktop or do we stay on common ground of ICC with standard options?

But there is no need for late binding at the low system level. Doing the
binding (== device profile linking) at the high system/graphics API
level is fine.

> Oyranos should support advanced technics at least on application level as 
> outlined above. Technically there should be not much difference to 
> system level CM.

There's no need for low level system level CM, just support of 3D color transformation.
Even default color space transformation can be handled this way,
by the higher level system sending the default device link transform
data down to the low level system, if that is where the color transformation
is implemented.

> But the later is better discussed on OpenICC.

I'm thinking that it's useful to expose some of the X11 implementation
community to color management considerations, since it seems that
such knowledge isn't very wide spread.

Graeme Gill.