GSoC CM collaboration

[Kai-Uwe Behrmann]

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.

> > 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.
> 
> It's nothing to do with that directly. But if you do the linking way down
> in the rendering code, you've lost control over it. If I want to
> use (say) Argyll "smart" linked profiles, with specific source/gamut
> mapping and the smooth results I get by inverting the output profile
> A2B tables, how are you going to provide it in the rendering module ?

Oh yes. Smart colour management should be possibly. In a early colour 
binding workflow I see no problems. There users should have all sorts of 
control, of course only of the application allowes.

I am about prototyping a toolkit independent Options GUI. Something 
like XForms, but I plan as well for real callbacks.

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.

> Besides, as a CMM implementor or application writer, you can't assume
> that such a facility is available. You need to allow for the fallback
> of no such support. So the primary interface will be at the application
> level (mediated by the graphics toolkit, which can't be unaware of such
> things and be any use), while the final pixel transformation is
> an implementation detail. If the final rendering engine supports
> it, great, do it there. If not, fall back on conventional client side
> transformations. The most concise and unambiguous representation
> of the needed pixel transformations is a device link.

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 most clear and convenient way for all sides seems to me to do such 
advanced things on the application side and opt out for later colour 
management. Then we are back at early colour binding.

> > What is difficult to link the CMS into the backend?
> 
> See above. I'd like _my_ links to be smart linked please.
> How do you provide for that ? How do you provide for

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.

> technical development in this area and differences in
> needs and tastes of applications and users ?

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?

> In other words, I don't think there is a compelling reason
> to go to the trouble of implementing such a facility to
> then have it frozen at the state of the art color linking
> year 2000.

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

Maybe we feel a desire for a difference between applications and desktop 
and then, for instance, hide CMM specifics in the DE control panels.

But the later is better discussed on OpenICC.


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