color management spec

[Kai-Uwe Behrmann]

Am 30.05.08, 16:47 +0200 schrieb Tomas Carnecky:
> Lubos Lunak wrote:
> > On Friday 30 of May 2008, Tomas Carnecky wrote:
> >> As part of my GSoC project I have to work out a spec that covers how
> >> applications should communicate color management related properties
> >> between each other and the compositing manager. The main idea of the
> >> project is to let the compositing manager do the color management on
> >> behalf of the applications. But before that can happen, the applications
> >> have to tell the compositing manager how they want to have their colors
> >> managed. The following spec I came up with should cover exactly that
> >> communication.
> >  
> >  There are technical things I don't like about the proposal, but before we get 
> > to that, I think this mail is seriously lacking in the "Why" department. For 
> > example: Why the compositing manager should do that? Or: Why do the work of 
> > adding it to compositing managers when many users don't use them for various 
> > reasons and then applications presumably need to handle it themselves anyway?
> 
> Ideally no support at all from applications should be needed. If you for 
> example set the default profile for untagged windows to sRGB (which is 
> what applications implicitly assume) then you get a color corrected 
> display basically for free. I don't primarily target applications that 
> absolutely need color management (professional graphics applications 
> etc.) because those need to do it internally anyway in most cases. For 
> normal desktop users with old computers who can not afford to use 
> compositing managers color management doesn't make much sense. But new 
> computers with wide gamut displays etc. will need color management. And 
> you don't want to add color management to every single application, not 
> only because it would be difficult but also because the performance 
> would be worse then if you did the color conversion in a compositing 
> manager. They already use OpenGL and the GPU, so adding a (one line!) 
> fragment shader isn't that big deal.

To add to this, the project of handling colour management inside compiz 
has many sides which are nice to modularise:
A ) communicate what is required by a application (regions, profiles..),
    and tell what can be done by the windowmanager?
B ) convert a ICC profile conversion into a shader description
C ) wrap most of the above into Oyranos API's and 
    a hopefully small remainder into a compiz plug-in 

Ideally applications see nothing about this. It should be useable
outside compiz as well. If Xorg provides at some point a single path to 
handle colours effectively or we find the required resources to handle 
each and every path, which as far as I know no current OS does, then 
CM in compiz would become obsolete. Until this happens, it can serve as a 
prototype.


And let me ask you, Lubos, why not in compiz? What is difficult with 
it? Or, where else?


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