[Openicc] GSoC CM collaboration

[Graeme Gill]

Kai-Uwe Behrmann wrote:

>>See above. The ICC format is a little short in some areas (color space
>>labelling), but some simple extensions can overcome these problems.
> 
> You are talking about CmykOG and similiar?

Actually simple things like no unambiguous labelling for monochrome.

Instead of "grey" for a device channel, it should be the colorant
color, ie. "white" for an emissive display and "black" for a printer.

There's no monochrome L* or Y spaces either. These can come into play
within a comprehensive graphics toolkit.

>>If it is felt desirable to have such legacy applications color managed
>>without changing them, then it is necessary to change the toolkit they use
>>(ie. X11 xlib, xcb etc., or the lower layers those toolkints depend on).
> 
> Keith has rejected this in the past. I dont know if hooks will be accepted 
> in Xorg.

If it's well though out, coherent, and implemented, I'm sure it would
be reconsidered :-).

> Traditionally CMMs contain profile linking and pixel conversion in one 
> endity. This allows for CMM specific profile linking.

Right, but this is mere convenience, not architectural necessity.

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

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

Graeme Gill.