Am 23.03.12, 17:10 +0100 schrieb Thomas Lübking:
Am 23.03.2012, 06:27 Uhr, schrieb Kai-Uwe Behrmann <k...@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