GSoC CM collaboration

Graeme Gill graeme2 at argyllcms.com
Mon Mar 3 17:35:02 PST 2008


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.

> 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 ?

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.

> 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
technical development in this area and differences in
needs and tastes of applications and users ?
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.

> 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.

Sorry, I'm still not exactly following you. I would imagine that CMS
selection would be at a fairly high level (it's generally an application
or system configuration function in most Operating Systems that support color
management).

Graeme Gill.




More information about the xorg mailing list