[Openicc] Linux CM ideology, was: meta data in test chart

Kai-Uwe Behrmann ku.b at gmx.de
Fri Jan 28 02:25:38 PST 2011


Am 28.01.11, 10:06 -0000 schrieb Richard Hughes:
> On 28 January 2011 07:36, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> During a discussion with Jim Gettys, he stated the right place would be the
>> compositing window manager. So I stopped any effort in bringing CM into Xorg
>> itself. Now I continue with CompICC and libXcm to help in enabling other
>> compositing window mangagers.
>
> This is the same conclusion I came to last year. You can't access the
> 3D engine in Xorg, and without a 3D engine, color conversion is two
> orders of magnitude too slow. I would make one small change tho.
> Dealing with bare compositing managers like compiz means you have a

Compiz is a compositing window manager. It can even run stand alone other 
than Gnome or KDE window managers.

> huge 2D array of pixels to deal with, and have to track "regions" of
> pixels manually and calculate things like the intersection and other
> grotty details.

As any window manager, compiz does window management on top of Xorg 
windows. No need to intersect regions. Simply attach the colour look up 
texture to the window texture in OpenGL and scissor out regions for 
application side colour management, calibration and profiling.

> My idea was to put the pixel conversion higher up in the window
> manager itself, in my case mutter, and use GLSL shaders attached to
> contexts themselves and allow GL and the WM to do all the heavy
> lifting for things like intersections and windows being dragged about.

No need to reinvent the wheel. Tomas did this stuff back in 2008 already.

> My code had actors opt-out of the color conversion, so it was quite
> possible to have the toolbar not CM, and the main content CM aware. It
> also meant the applications themselves didn't need to know what output
> they were on, and things like that.
>
> If anyone is interested, I can push my mutter tree onto github. I
> spent quite a bit of time getting the 3D texture support in clutter,
> but now I think most distros are shipping a 3D texture enabled clutter
> by default.

Does this code support the net-color spec for opt-out of colour 
management?

> As large gamut display devices become more and more "mainstream" I
> think this kind of thing is going to be more and more important.
>
> Richard.

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



More information about the openicc mailing list