GSoC CM collaboration

[Hal V. Engel]

On Sunday 02 March 2008 13:31:43 Stephane Marchesin wrote:
snip
> >
> >  I would actually put this in a broader context since I personally don't
> > care how the problem is solved as long as there is a solution.
> >
> >  How do we solve the system wide monitor colorimetric issues that are now
> >  becoming so apparent with the advent of wide gamut monitors?   This
> > issue has been there forever but was masked by the fact that most
> > monitors fell within a fairly small range of colorimetric characteristics
> > and this has, until now, allowed us to ignore the issue.  Those days are
> > fast disappearing and will some be gone.
> >
> >  One way to solve this is to leverage what has been learned about color
> >  management and applying this to the whole desktop.  This is what Kai-Uwe
> > is proposing.  There may be other approaches or combinations of
> > approaches that can be used as well.  I am open to any plausible approach
> > and would like to hear how others think this problem can be solved.
>
> You certainly can't do something that flexible at the driver level:
> the hardware does not allow it.

I don't think anyone was saying that this is a driver issue although the 
driver might play a limited roll in the solution.  Most of the solution 
likely needs to take place in the layers above the video card driver.

> You also cannot modify the pixmap 
> contents because the application still expects to find its data as it
> wrote it. 

This is clearly true.  This is a transformation that needs to take place 
between the application and the device.  In applications that do this on 
their own the app keeps two copies of the pixmap.  One in it's unaltered form 
and one that has been transformed into the display color space.

> And you don't want to modify every application, of course. 

Currently we have some applications that are color management aware (GIMP, 
Krita, CinePaint, Scribus, Firefox 3....) but with the exception of FireFox 3 
these are all specialized applications and none of them color manage things 
like the window frame, window title bar, menus or buttons.   And there are 
many media applications such as video players and Flash/Gnash that are still 
totally color management dumb.  In addition, adding this functionality is 
non-trivial and doing this to every application or even every media 
application would be a huge undertaking.

> The solution might "simply" be to write a compositing manager that
> does whatever lookup you want. Fairly recent X.Org versions allow
> that.

This sounds plausible.  One of the basic questions is where does this 
functionality belong?  It is fairly apparent that the best place to handle 
this is somewhere between the hardware and the applications since this would 
allow this to be implemented once and it would take care of everything on the 
desktop.  As you point out this likely is not at the video card driver level 
although limited parts of it might best be done there.  Of course X.Org is 
more than just the video drivers and that still leaves room for other parts 
of this to take place in X.Org.  I suspect that the best solution will split 
this between different parts of the software stack.  With some parts 
happening in the video driver, other parts in X.Org and other functionality 
being at the window manager/DE level.  Clearly things like setting CM policy 
belong at the upper level of the stack. 

There are still other areas where X.Org could help out with respect to color 
management.  Some examples:

1. Monitor calibration applications would like to have DDC/CI support.  This 
could be a good GSoC topic.

2. Many video drivers still do not have xrandr 1.2 support which means 
applications that work with video card LUTs such as calibrations software and 
LUT loaders have to deal with more than one API to work on all X based 
systems.   I am not sure if this would make a good GSoC topic.

3. On a similar note one proprietary driver does not support changing the LUT 
with either of the standard APIs and has introduced it's own API for LUT 
manipulations.  This should not be allowed.  There are people from that 
vendor on this list and they should be raising this issue with their 
organization so that it gets fixed.  At this point no calibration software 
supports this hardware while using that driver and when users ask they are 
told to avoid that vendors hardware until the issue is fixed.  This is 
clearly not a GSoC topic.

Hal