GSoC CM collaboration

[Kai-Uwe Behrmann]

Am 04.03.08, 02:18 +1100 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
> > Am 04.03.08, 00:33 +1100 schrieb Graeme Gill:
> >>Kai-Uwe Behrmann wrote:
> >>>- a ICC profile container attached to window content
> >>
> >>I don't thing that's a good approach, as it would necessitate
> >>incorporating the CMM deeply into things. Better to pass down
> >>a device link and leave the CMM higher up the stack. This
> >>then allows an open choice of CMM's and linking approaches
> >>(intents, smart linking, tuning etc), as well as supporting
> >>device links.
> > 
> > This brings the CMM into the applications and the rending backend.
> 
> You mean it splits it between the application or an upper level and
> the rendering back end. Yes, that's the idea. A typical CMM
> is really these two bits aggregated anyway, the linking code and the
> pixel engine. The lower levels provide mechanism (pixel transformation
> using the GPU), the upper levels provide policy (what profiles and how
> they should be linked).

Ok I see your point.
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.
Considering that most settings are available on server side, I'd guess it 
is easier to to keep the profile linking down the end. As well it fits 
quite nicely to the late binding concept.
(Late binding means, colours get their final values late.)

So far my take was we would have to support late and early colour bindings 
on request. You suggestion feels like a half merger with the early colour
binding.

> > For 
> > what benefit? How does device link profile avoid the presence of a CMM 
> > down the path?
> 
> By avoiding the need to link profiles in the low level code.

What is difficult to link the CMS into the backend?

> > As well, when a user wants to be able to select globaly a certain CMM and 
> > his application opts in for colour management, as should be the default, 
> > then there will be CMM specifics down the path in any case.
> 
> Sorry, I'm not understanding this sentence.

I mean with some functions like selecting a particular CMM, there must be 
the CMM framework of the CMS called. So the CMS is present in the later 
chain anyway.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org