[Openicc] Color Management for compositor mutter

[Kai-Uwe Behrmann]

Am 05.05.11, 14:37 +0100 schrieb 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.

You want a clutter specific spec for your personal largest convenience. 
Sorry that is not going to work.

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

OpenICC round table in Brussels. Next one will be likely in Montreal in 
some few days.

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

Strong claims and none if any substantiation. That reads like bad 
marketing.

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

I would not wait too long for an other answere in time.

> 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

Most colours are shades and blended and not solid on modern desktops. As 
well most screen content should be converted. For instance I very much 
enjoy watching colour corrected full screen videos.

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

I can not recommend that. See above.

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

The colour texture lookup part of the OpenGL spec is pretty old and very 
well supported in hardware. But of course it makes sense to look for 
bottlenecks, just I did not experience one with static display content as 
Compiz simply idles that out and does nothing after a initial correct 
drawing until something changes and Compiz needs to redraw.

> 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

Sounds useful to me.

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

As I am writing this email I sit in front of a wide gamut and a average 
monitor. As well all laptops with attached monitor should look comparable 
IMO.

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

Agreed, it would have been appropriate you to keep the context working.
Here comes that. Its from you:
>> Wouldn't it be better to allow new applications to opt-in certain
>> window regions?

In other words, it makes no sense to adhere in the print pipeline to a 
opt-out model, while we agree to opt-in for displaying.
It makes sense to use the same basic principle throughout all device 
classes for easier understanding af all involved parties.

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