[GSoC] KWin colour management

[Kai-Uwe Behrmann]

Am 23.03.12, 17:10 +0100 schrieb Thomas Lübking:
> Am 23.03.2012, 06:27 Uhr, schrieb Kai-Uwe Behrmann <ku.b at gmx.de>:
>> Where would be a competing system on Linux?
> Well, I certainly did not read all of that "colord ./. oyranos" flamewar on 
> k-c-d where supporters of either basically tagged the other like incapable 
> and/or irrelevant s..tufff, but I as certain did not dream about it.
>
> So while this might just have been kindergarten s...tuff about "xyz uses mono 
> and we hate mono", I was under the impression that those were conflicting 
> approaches to CM.

That was likely related to Linux CM DB APIs, but not particular to 
compositor CM.

> If it indeed only is about implementation details on the very same protocol,

Yes, we have seen no other descriptions for a compositor CM protocol.

> thus whether colord or oyranos is in use does absolutely not make any 
> difference regarding the compositor, I wish apologize and withdraw that 
> particular concern.
>
>
>
>>> screen actually could do WG ... but the delete icon in dolphin looks 
>>> correct?
>> That is correctly described and expected behaviour as developers said.
>
> Ok, so let me please complete my former question by its implications:
> "Does that actually mean that if I have a WG screen and an application which 
> does not support the opt-out protocol [...], it will be reduced to sRGB while 
> the application and the screen actually could do WG ..."
> ... unless I suspend compositing or switch to another window manager what, 
> because I'm just a user and don't know what a window manager is, likely means 
> to switch to another DE, because "it just works" on - let's say - "Trinity"?

sRGB displaying is for many people the "it just works". They likely will 
find sRGB be more relaxing, if they have a wide gamut display. Look at the 
email threads, where people search for the sRGB emulation mode for these
kind of monitors.

>> We discussed that with Wayland people and the last spec revision was
>> adapted to meet their concerns. So the transition from X Color
>> Management to W(ayland) Color Management should be relativele smooth.
>> 
>> http://lists.freedesktop.org/archives/openicc/2012q1/004595.html
>> http://www.oyranos.org/2012/02/x-color-management-0-4-draft1
>
> Many thanks.
> But that seams clearly away from per-region opt-out but into per-window

correct

> opt-out, doesn't cover different screens anyway and require toolkits "to

For different screens can be colour corrected through X Color Management, 
because the output device spaces are known.
"toolkit" means client side. A client can as well be a application.

> colour correct the whole window" what -if did not terribly misunderstood-

It is about specifying a per window opt-out or per window source colour 
space. A compositor can still apply different per monitor colour 
conversions.

> also means that if Qt & Gtk+ support such, but TCL/TK does not (just examples 
> here), the result would be that w/ or w/o a color correcting compositor, my 
> Qt & Gtk apps just work fine whereas my very important professional offset 
> print preview "POPP" (tm) tool written in TCL/TK only works WITHOUT such 
> compositor (because the canvas is corrected internally and the buttons are 
> all gray anyway) and fails with one.

Your "POPP" (tm) tool written in TCL/TK will hopefull adhere to the ICC 
Profiles in X spec[1]. Otherwise it's behaviour is undefined. Such bug is 
present in Gimp, when the "Use system profile" check box is initially not 
selected. Gimp behaves correctly after enabling this option.

kind regards
-- 
Kai-Uwe Behrmann
www.oyranos.org

[1] http://www.freedesktop.org/wiki/Specifications/icc_profiles_in_x_spec