[Openicc] Color Management for compositor mutter

[Richard Hughes]

On 5 May 2011 13:07, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Hmm, I guess many things in the world are not clutter centric. OpenICC specs
> describe generic mechanisms not toolkit or applciation centric ones.

Well, that all sounds very lofty and idealistic, but if the core
protocol isn't going to work for one of the biggest desktop
environments in Linux then whether it is or not an OpenICC
specification doesn't matter very much.

> 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.

I guess you're talking to different developers than me.

> 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.

And pretty much *all* the software the studios use.

> 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.

Sure. I agree with you that color correcting the window controls,
widgets and background makes a lot of sense. But I think mixing the
"convert image with specific source profile to screen profile" and
"convert everything else from srgb to screen profile at the same time"
possibly isn't the best idea.

For instance, it's perfectly sane to convert the wallpaper from srgb
to display profile once at session startup, and then the number of
pixels processed in the GPU in the compiz plugin goes down by *two
orders of magnitude*. By converting all the window control theme
colors as individual theme colors before they are rendered, rather
than as bitmaps means you have to run just ~600 bytes through LCMS at
startup. The alternative then is to convert vast swathes of pixels on
the GPU with complicated cut-outs in the window manager.

And of course, using LCMS to convert the theme colors before they are
drawn means that it works with no GPU acceleration. Which may or may
not be important for mobile.

That said, I do think we do need some kind of GPU acceleration for
color correction. For color conversion of video, using the CPU really
sucks. But in this specific case, some of the output pipelines are
using GL already (e.g. gstreamer) and so adding an extra texture
transform into the pipeline really isn't hard at all. The only hard
bit is supporting video streams that are spread over two physical
monitors with radically different profile gamuts, which I'm not sure
is an interesting use case.

> 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.

I have no idea what you said there, sorry.

Richard.