[Openicc] GSoC CM collaboration

[Kai-Uwe Behrmann]

Am 06.03.08, 22:53 +1100 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
> > So you suggest a fixed CMM at the low end because of technical contraints 
> > to access the GPU? 
> 
> No, mainly because there should be no discernible difference between
> such things if implemented properly. That's one of the properties of
> a color device space to device space transform, it's relatively unambiguous,
> and any differences tend to be dictated by elements that are not discretionary,
> such as CPU/GPU architecture, memory consumption or performance.

Hmm, if so than I was probably wrong in regards of the selectability of a 
pixel rendering CMM. I though of different interpolators. Ok, such can 
happen as well on the earlier end.
 
> > 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.
> 
> You can't have it both ways. There's little point in color management
> if the applications can't be aware of it. You can't make a monochrome
> application color without it being aware of color. Sure you could
> make all its out put red or green or yellow rather than grey, but does
> that prove anything ? In other words, any ongoing or forward looking
> graphics API's have to be expanded a little to accommodate color management.
> To hope this can be made to go away is to postpone real managed color
> indefinitely.

Well, this later concern I share.

The answere, provided it can be understood as question, seems nontheless 
not so clear. So, I want first to rephrase: Can toolkits be forced to 
support colour management? 

I think we have in this thread discussed two answeres.
A: Yes, by implicite colour management for all, with the exceptions for 
   explicite modification or opting out.
B: Yes, by providing colour management on a explicite request only.
   Thus inactive parts are blamed and appear old fashioned.

As you mentioned above, version A is in danger to support a endless 
transition. On the other hand the whole desktop is instandly colour 
manageged, to some degree.
Can we really expect that toolkits, which are not interessted in colour 
management, follow our idea of colour management? 
I know of at least one cross platform toolkit, which must provide 
colour profiles in order to being allowed for displaying graphics, that 
does not even consider to expose the according API. They have reasonable 
interesst to ignore the colour management side. This toolkit is not 
even broken, it is sRGB. 

In a similiar fashion, graphics card gamma tables follow the explicite 
route in managing all content? There are reasons to not use them. Still 
this kind of pills is served to every one. Without having the option to 
opt out, I am not a friend of that. Otherwise it's presence is widely 
accepted, including by me.

B is like a high level feature. One opts in in using thierd party 
libraries and so on. My point here is, as you agreed to place the pixel 
rendering CMM near to Xorg this is is a clear sign colour management is a 
low level feature and should be if possible part of the core. Indeed I'd 
have loved to see CM included in XV, Xlib, OpenGL, Cairo and all these low 
level services. The only positive I would see in the pure explicite CM, as 
suggested in B, that non colour managed toolkits will become at some point 
appearent. This might help in eleminating such shortcomming. But the price 
unfortunedly can be much frustration about CM inbetween.

Given the growing high popularity among Gnome and KDE, I have no doubt 
that CM will soon become part of many API's. HDR will follow.


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