GSoC CM collaboration
ku.b at gmx.de
Mon Mar 3 10:25:13 PST 2008
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.
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the xorg