color management spec

Tomas Carnecky tom at dbservice.com
Fri May 30 07:47:54 PDT 2008


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.

tom




More information about the xorg mailing list