[Openicc] GSoC CM collaboration

[Kai-Uwe Behrmann]

Am 13.03.08, 01:06 +1100 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
> > Am 06.03.08, 22:53 +1100 schrieb Graeme Gill:

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

Good, so we are done with A.
 
> 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.

... from a graphics point of view.

> > 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 dont care much of some platforms. I care about lots of API's wich are 
cross platform and dont have colour management. The toolkits of many 
applications I use are legacy or have not utilised CM, Java being a rare 
exception.

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

Agreed. Linux is colour management wise broken. We are here to fix that in 
a reasonable timeframe. With the proposed project we could come closer to 
that. 

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

The hardware approach is inflexible. There is no reason not to merge the 
graohic card curves by an advanced applications into the profile ones.
Thats good for banding in 16-bit and HDR. Profilers, as LProf, Argyll and 
others, can do what they want.

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

BSD/Linux is different in regards many regards. osX and later Windows have 
created vendor specific answeres to colour management. I dont plan to omit 
open source specifics.

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