[Openicc] GSoC CM collaboration

[Graeme Gill]

Kai-Uwe Behrmann wrote:

> Am 06.03.08, 22:53 +1100 schrieb Graeme Gill:

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

You can of course allow for the selection of different interpolators,
but are you really proposing to setup a framework in which
different GPU based color interpolators are possible, given
that such code is almost certainly going to be tightly integrated
into the compositing engine GPU code ? How many implementations
of a GPU based compositing engine do expect to be produced,
and when ?

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

Either way, it is necessary to modify the graphics API's to make
effective use of color management. Of course it's not possible
to force toolkits to make changes, but the fact is that applications
that require or will benefit from color management will either
choose toolkits that provide it, or do the color management themselves.

The bottom line is that X11 graphics API's/toolkits are well behind
what's on other platforms in this regard. All that's necessary is
to propose and implement some sensible changes to a forward looking
X11 capable API, for instance Cairo, and the rest will follow or become
obsolete.

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

Other platforms toolkits do.

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

I'd call it broken, and so would anyone who went out and spent
a lot of money on a wide gamut LED based display that can't be
used to advantage in such an environment!

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

Video hardware lookup tables primary purpose is calibration, that is
conditioning the behaviour of the device to be repeatable and
well behaved. This then facilitates better profiles and the ability
to avoid the need for constant re-profiling as devices drift.
It is merely a side effect that it affects the appearance of
non-color managed applications. What should ultimately happen
is that programs such as window managers and desktops should
start to color manage themselves, so that their appearance
is constant in spite of different display devices. The easier
this is to do via the graphics API, the faster this is likely
to happen.

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

None of these considerations are new. It's all been figured out and
done on MSWindows and OS X. It's worth taking a look at how
these problems have been already solved.

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

I doubt HDR will follow any time soon. It's still research, whereas
desktop color management has been around nearly 10 years or more.

Graeme Gill.