[Openicc] GSoC CM collaboration

[Kai-Uwe Behrmann]

Am 06.03.08, 18:46 +1100 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
> > Eigther out of gamut marking is not covered by DL's or littleCMS is not 
> > being able to integrate it. It must be solved before we continue in this 
> > direction.
> 
> I don't see the relevance. Out of gamut indications are an application
> level feature.

... ok, so this feature is only available during an early colour binding.

> > As well it is unclear to me, whether we want to expose two CMM selectors 
> > in the CMS configuration panel like:
> > 
> > Profile linking CMM:  [ArgyllCMM v]
> > Pixel rendering CMM:  [ShaderCMM v]
> > 
> > These selectors have indeed advantages, but at the same time they add new 
> > widgets to the UI.
> > What does the colour experts say about the two CMM selectors?
> 
> I may not be understanding you exactly, but if by "Pixel rendering CMM:  [ShaderCMM v]"
> you mean the details of the pixel engine color conversion, I see that
> as unnecessary in any situation in which it makes sense to implement
> such a thing outside a CMM. You are re-implementing due to
> necessity (no CMM has a GPU pixel engine module, and even
> if any did, it probably wouldn't integrate as well as
> purpose written code), so you would make the necessary
> effort to do it well, and any differences between how it
> operates and other options would be minor, and a price paid
> for the advantage it gives.

So you suggest a fixed CMM at the low end because of technical contraints 
to access the GPU? 

My favourite property for the CMS is consistency and connected to this 
only optional exposition of high level details to the early colour path 
(applications, toolkits ...). They should be able to handle that by 
themself by linking to a CMS, but they should not need to. 
Some toolkits will later on allow for passing through colour management 
informations, thus allowing for features deploying more of the CMS. 
Upon this colour management awareness in toolkits it will be easy to build 
applications with many colour management options.

On the other side rejecting the idea of profile linking code in the later 
rendering end, would mean to further increase the requirements for past,
current and future developed toolkits and applications by the need of 
having at least all toolkits to handle colour management properties. 
Given the rather chaotic collection of APIs this would take many years to 
overcome. Colour management is for most developers and users at best a 
welcome thing, and even better at no cost. According will be the response 
to take over the workload, which would be implied by a must requirement to 
the toolkits for doing the profile linking. Linux systems are not so
monolithic to follow easily.


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