color management spec
tom at dbservice.com
Fri May 30 09:53:38 PDT 2008
Alex Deucher wrote:
> On Fri, May 30, 2008 at 8:08 AM, Tomas Carnecky <tom at dbservice.com> 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
>> How colors should be interpreted is defined in so called 'ICC Profiles',
>> that is a blob that contains all the necessary informations how colors
>> should be interpreted. These profiles are attached to windows so that
>> the compositing manager can get them and do the necessary color
>> conversion. To allow for fine-grained color management (if an
>> application has only a region that it wants to have color managed), the
>> applications have to be able to specify subregions of their window and
>> attach profiles to that. Since toolkits (at least GTK+) already make
>> heavy use of subwindows, using those makes sense to me. So I came up
>> with a document (in the attachment) that describes which window
>> properties and messages are used.
>> Dennis Kasprzyk (compiz developer) wasn't happy that I want to attach
>> properties to subwindows, instead he suggested to attach a list to the
>> top-level window containing tuples of [(sub)window XID / Profile]. But
>> I'd like to keep the properties on the subwindows, I think that will
>> make it easier for toolkits. In GTK+ for example, widgets that create
>> their own subwindow will be able to do the color management completely
>> independent of the other widgets. If all profiles are kept in the
>> top-level window then the widgets first have to find the top-level
>> window and then coordinate with other widgets how to create the list.
>> I'd like to hear other opinions on that.
> I think you may want to start with a basic app to load ICC profiles
> and properly set the LUTs per crtc using xrandr, then move onto the
> per-window stuff. That may be part of your plan already.
IIRC the LUTs can be incorporated into ICC profiles. And we agreed that
that would be preferred over setting the LUTs using xrandr. When you set
the LUT in hardware you have the issue of applications resetting your
LUT (There is an application, I don't remember which, that uses the LUT
and when it finishes it resets it to linear instead of what it was before).
Loading display profiles into xrandr output properties should be done by
the session (gnome-session or whatever kde uses). There are already
tools to load the profiles, but you have to do that by hand, it's not
automated. And that part of desktop color management has completely
different issues, like where and how to store the configuration etc.
More information about the xorg