GSoC CM collaboration

[Kai-Uwe Behrmann]

Am 03.03.08, 18:56 +0100 schrieb Olivier Galibert:
> On Mon, Mar 03, 2008 at 06:18:59PM +0100, Nicolas Mailhot wrote:
> > Le Lun 3 mars 2008 18:01, Olivier Galibert a écrit :
> > > Where "the application" can mean in large part "the graphics toolkit",
> > > as in gtk, qt or even cairo.  So it's not necessarily that numerous.
> > 
> > That would mean configuration hell.
> 
> If there is something to configure at the application level you're
> doing it wrong.

Thats an ideal. We have specialised applications which request to take 
over complete control. For instance the already mentioned device 
color calibrators or advanced HDR displaying. As well many imaging 
applications want to retain control over the output. They should be 
enabled by the same CM logic as the composit manager.
 
> > Please don't go there. Most users
> > will want every GUI app colour-managed if possible, so I don't see any
> > win is pushing this in the toolkits now. This is a receipe for a
> > painful convergence process later on.
> 
> The toolkits should be client of a CM library that's actually
> efficient and useful with sRGB (and doesn't mix color spaces, white
> temperature and other crap).  Combine that with an extension that
> would allow you to tell X "this image I'm sending you is CMed for that
> monitor" and you could get a very good result with the GPU only used
> when it couldn't really be avoided.

This can easily be reached otherwise. A toolkit can pre render regions 
starting with colour managed values and pass this to the server with opt 
out for CM. This is not impossible. Still we should create a reference for 
all in the first. When a toolkit, then plays with CM, it should be easier 
to spot problems. 
I am pretty shure some pitfalls are not very obvious. A reference will 
have then its own value.

The biggest problem in the process are ambiguities.


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