[Openicc] Color Management for compositor mutter

[Kai-Uwe Behrmann]

Am 05.05.11, 12:16 +0100 schrieb Richard Hughes:
> On 5 May 2011 10:55, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> Texture scaling is a intermediate step. What is interessting is the end
>> state of the windows. If the colour conversion is applied there the
>> net-color spec works pretty naturally.
>
> Of course, except that's not really how clutter works.

Hmm, I guess many things in the world are not clutter centric. 
OpenICC specs describe generic mechanisms not toolkit or applciation 
centric ones.

>> But that appears to be a general problem of
>> compositing at this time in Xorg space.
>
> Yup, and that's why I failed to get anything like
> gtk_widget_set_color_opt_out() working -- the widget had no concept of
> the final window transformation and so couldn't send updated
> coordinates even if it wanted to. That's why I'm kinda confused that
> the net-color-spec talks about XserverRegions.

There is not much of an alternative as we discussed several time on this 
list. The SubWindows idea appears still not useful.

> Backtracking a few hundred steps: Trying to convince an application
> author to add a few low-level libxcm specific calls in an existing
> graphics or profiling application might be a hard sell, and impossible
> for a lot of proprietary software used already by the studios. It

Strange. We discussed the possible transition issues with application 
developers and they agreed, that the net-color spec inbuild backward 
compatibility makes pretty much sense.
The only noticable exception are calibration tools like dispcal. They are 
really affected until they will support the net-color spec or users have 
manually to take care of.

> would also break a lot of expensive software if we rolled out WM CM in
> Linux without _every single existing application_ being ready for it.

Wordprocessors, Thunderbird, Firefox, blender, like most other software 
will simply benefit. sRGB was and is for most application developers 
the utlimate reference for their GUI colours. Colour correction makes 
still sense.

> Wouldn't it be better to allow new applications to opt-in certain
> window regions?

The same way you could suggest to handle pure DeviceRGB as native device 
colour and let 99% of innocent users stand in the rain with never ever 
colour corrected prints. Not my position.


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