[GSoC] KWin colour management
Casian Andrei
I am a final year undergraduate student at the Polytechnic University
of Bucharest, Automation and Computers Faculty. I am interested in the
"Compositor Colour Management" idea from OpenSUSE. It looks like
something I would enjoy doing.
I have acceptable C / C ++ skills and lots of experience with OpenGL.
I am also familiar with Qt. Regarding shaders, I wrote a couple about
2 years ago for an old project, and I still know how they work, so it
would be easy for me to remember. Last GSoC I worked on an OpenGL
interface for VLC, and 2 years ago I worked on capture support in
Phonon.
I need your guidance in order to create a decent proposal. I
understand the project will involve implementing the colour management
features in KWin. As the idea suggests, this would imply making KWin
handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms.
Today I documented myself about colour management in general, and how
it's done in Linux. I also read about ICC, Oyranos, X color management
and related things. Now I'm not completely in the dark as before. I
looked around in the KWin code and I found the area of interest - the
compositor part, more specifically KWin::SceneOpenGL. Since shaders
will be needed, it looks like some custom shaders of type
KWin::ShaderManager::ColorShader would be able to do the job. Please
correct me if this is wrong.
But I am still unsure and I don't have an exact image in mind about
what needs to be done. Clearly, more exploration is needed. I don't
know what to concentrate on - looking around in KWin / Compiz code,
concentrating on libXcm and the X Color Management spec, reading more
about Oyranos and colour management in general?
I tried the Oyranos colour management LiveCD and I saw it doing the
correction magic, but unfortunately I was unable to get compiz working
- with the open source drivers it didn't start because of missing
glx_ext_texture_from_pixmap extension, and there were problems with
the ati drivers - after installing them, the root visual was not a GL
visual (or something like that), and if I tried to do some
configuration with Catalyst, then X froze together with the system
(nothing new for me, that's why I am sticking to the open source
drivers). At least I know ICC profiles for both my monitors were
found, by monitoring with QcmsEvents.
Best regards,
Casian
Kai-Uwe Behrmann
Am 18.03.12, 20:01 +0200 schrieb Casian Andrei:
> Hello,
>
> I am a final year undergraduate student at the Polytechnic University
> of Bucharest, Automation and Computers Faculty. I am interested in the
> "Compositor Colour Management" idea from OpenSUSE. It looks like
> something I would enjoy doing.
Given that colour management inside open source toolkits is a very very
long outstanding issue, and we are still at the beginning with that, it is
unlikely that Qt5 will allow to colour manage _all_ it's widgets by
default. That means, we will see only few graphics applications to do ICC
colour correction themself. Consequently most other desktop applications
and areas will look different on each monitor. In my opinion, the most
easy path towards working end to end colour management inside KDE is to
assume sRGB for all non colour aware applications and do colour correction
unquestioned.
That concept is worked out on OpenICC and used and checked on a daily base
with CompICC. So it is no longer a experimental feature. In
comparision, the concept to colour manage unaware colour content is as
well common practise inside Linux and other OS printing paths. Ghostscript
and likely Poppler will or do already colour convert the mass of todays
/DeviceRGB colour unquestioned. They will implicitely assume that these
colours to be meant as sRGB. I suggest we should follow that route for
displaying inside KWin and improve colour useability on the KDE desktop.
> I have acceptable C / C ++ skills and lots of experience with OpenGL.
> I am also familiar with Qt. Regarding shaders, I wrote a couple about
> 2 years ago for an old project, and I still know how they work, so it
> would be easy for me to remember. Last GSoC I worked on an OpenGL
> interface for VLC, and 2 years ago I worked on capture support in
> Phonon.
>
> I need your guidance in order to create a decent proposal. I
> understand the project will involve implementing the colour management
> features in KWin. As the idea suggests, this would imply making KWin
> handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms.
The idea behind these two atoms is to enable per window colour correction,
which is relatively easy implemented.
In a first step a window manager can be enabled with that feature. It is
completely backward compatible. Graphic applications can be updated step
by step to take advantage of the new ICC support by implementing the X
Color Management protocol. They will profit by getting multi monitor
aware very fast and power efficient colour correction with the smallest
effort. Some few applications exist already, which deploy this scheme.
Qt or KDE widgets can be created to share common code among such apps.
kind regards
Kai-Uwe
Martin Graesslin
> Hello,
taking it to the KWin mailinglist as that's the relevant list in case this
proposal would be accepted.
First of all thanks for considering doing a GSoC project around KWin.
> I need your guidance in order to create a decent proposal. I
> understand the project will involve implementing the colour management
> features in KWin. As the idea suggests, this would imply making KWin
> handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms.
This would probably only be part of it.
>
> Today I documented myself about colour management in general, and how
> it's done in Linux. I also read about ICC, Oyranos, X color management
> and related things. Now I'm not completely in the dark as before. I
> looked around in the KWin code and I found the area of interest - the
> compositor part, more specifically KWin::SceneOpenGL. Since shaders
> will be needed, it looks like some custom shaders of type
> KWin::ShaderManager::ColorShader would be able to do the job. Please
> correct me if this is wrong.
There is more into it: first of all KWin currently does not distinguish between
screens during rendering. To properly have screen aware color correction the
complete compositor has to be made screen aware. The repaint loop has to be
split into multiple rendering passes - one for each screen. This is quite a
change in the way how KWin renders, but might be a useful change.
As a second step all fragment shaders need to be adjusted to do the color
correction. This has to be done extremely efficient. This is a rather critical
code path especially for low-end hardware (think of old Intel GPUs). Given the
constraints of the GPUs a dynamic feature activation is not possible.
What is in general important to know is that we have not had the best
experience with GSoC students doing work on the core of KWin. Given that I
proposed guidelines for future feature additions to KWin by non-core
developers [1].
Furthermore I want to mention that the project would at max be co-mentored
from the KWin team. The slot is provided by the Oyranos community and not by
KDE. This means that the main mentor will be at Oyranos and also whether the
GSoC completes or not will be judged only by Oyranos. A successfully completed
project at Oyranos to write code to KWin does not mean that the code will be
merged into KWin.
Given recent discussions on this mailinglist about Oyranos and colord I am
very unsure whether I want any color management relevant code in KWin at the
moment. I will definitely not accept any code supporting only one of the two
systems and any additional build or run-time dependency to KWin will not be
accepted.
In general there seems to be agreement that color management has to be done
inside the toolkit/application and not inside the compositor. A fully color
corrected compositor seems feasible to me, but one where some applications
need to start opting-out of being color corrected is nothing I want to see in
KWin as it adds significant complexity and overhead to the rendering process.
This is something the Oyranos community has to decide on how they want to have
that handled.
Kind Regards
Martin Gräßlin
KWin Maintainer
Thomas Lübking
> A fully color corrected compositor seems feasible to me
I'm atm. not even sure about that.
I might be utterly wrong, but my impression is that the xvidmode extension
can correct screens (eg. xcalib loads icc profiles), so a screen wide
color correcting compositor would be only required to fix multiscreen (not
multihead) setups which i frankly consider no case either, because a full
correction would just mean to restrict the WG screen to the SRGB one
(yesno?!), what doesn't much sound like a great achievement to me (and is
simply no case in at least the professional context. You don't purchase
_one_ WG screen to use it -restricted- alongside your SRGB screen, but
just purchase two WG screens and give away the SRGB one to one of your
employees at home or whatever)
Cheers,
Thomas
Kai-Uwe Behrmann
> On Sunday 18 March 2012 20:01:01 Casian Andrei wrote:
>> Hello,
> taking it to the KWin mailinglist as that's the relevant list in case this
> proposal would be accepted.
>
> First of all thanks for considering doing a GSoC project around KWin.
>> I need your guidance in order to create a decent proposal. I
>> understand the project will involve implementing the colour management
>> features in KWin. As the idea suggests, this would imply making KWin
>> handle the _ICC_COLOR_OUTPUTS and _ICC_COLOR_PROFILES atoms.
> This would probably only be part of it.
>>
>> Today I documented myself about colour management in general, and how
>> it's done in Linux. I also read about ICC, Oyranos, X color management
>> and related things. Now I'm not completely in the dark as before. I
>> looked around in the KWin code and I found the area of interest - the
>> compositor part, more specifically KWin::SceneOpenGL. Since shaders
>> will be needed, it looks like some custom shaders of type
>> KWin::ShaderManager::ColorShader would be able to do the job. Please
>> correct me if this is wrong.
> There is more into it: first of all KWin currently does not distinguish between
> screens during rendering. To properly have screen aware color correction the
> complete compositor has to be made screen aware. The repaint loop has to be
As a side note, during the last CLT fair there was the idea brought up, to
place ICC colour correction inside a KWin plugin. Is that recommendable?
> split into multiple rendering passes - one for each screen. This is quite a
> change in the way how KWin renders, but might be a useful change.
>
> As a second step all fragment shaders need to be adjusted to do the color
Which shaders and adjusted for what specifically? May you point us to
them, in order to get an idea?
http://quickgit.kde.org/index.php?p=kde-workspace.git&a=tree&f=kwin
> correction. This has to be done extremely efficient. This is a rather critical
> code path especially for low-end hardware (think of old Intel GPUs). Given the
> constraints of the GPUs a dynamic feature activation is not possible.
>
> What is in general important to know is that we have not had the best
> experience with GSoC students doing work on the core of KWin. Given that I
> proposed guidelines for future feature additions to KWin by non-core
> developers [1].
>
> Furthermore I want to mention that the project would at max be co-mentored
> from the KWin team. The slot is provided by the Oyranos community and not by
> KDE. This means that the main mentor will be at Oyranos and also whether the
The actual choosen slot comes from openSUSE, as they like to see a colour
managed KDE too.
> GSoC completes or not will be judged only by Oyranos. A successfully completed
> project at Oyranos to write code to KWin does not mean that the code will be
> merged into KWin.
The more we are interested to see the KWin project being involved.
> Given recent discussions on this mailinglist about Oyranos and colord I am
> very unsure whether I want any color management relevant code in KWin at the
> moment. I will definitely not accept any code supporting only one of the two
> systems and any additional build or run-time dependency to KWin will not be
> accepted.
Has KDE facities to load and apply ICC profiles? ICC support needs at
least a colour management module (CMM) like lcms.
> In general there seems to be agreement that color management has to be done
> inside the toolkit/application and not inside the compositor. A fully color
You are pointing towards osX? I think that Qt and any other toolkit will
need a not small amount of time to implement a similar engineered colour
managed scene graph. Such stuff is certainly deployed inside PDF
workflows. But my feeling says, it is a lot of work to get such a beast
inside a cross platform Qt layer. Very likely not Qt5. How long would we
have to wait for that? 5 years or more realistically 10 years or will
that happen at all?
On the other hand, Xorg architect Jim Getty told me, that compositors
are the right places for colour correction.
> corrected compositor seems feasible to me, but one where some applications
> need to start opting-out of being color corrected is nothing I want to see in
> KWin as it adds significant complexity and overhead to the rendering process.
Opting out of colour management is a pre condition to do
* raw measurements, such as for ICC profile generation
* application side specialised colour correction
It needs to internally store the colour transform per window. If there is
none, then there is no conversion needed.
> This is something the Oyranos community has to decide on how they want to have
> that handled.
Oyranos is only one colour management project inside the OpenICC
community. It is true that I am much behind the concept of implicite
display ICC colour correction. But surely more people have a interest in
that concept being deployed inside KDE.
> Kind Regards
> Martin Grￜￜlin
> KWin Maintainer
kind regards
Kai-Uwe
--
www.oyranos.org
Kai-Uwe Behrmann
> Am 20.03.2012, 20:12 Uhr, schrieb Martin Graesslin <mgrae...@kde.org>:
>
>> A fully color corrected compositor seems feasible to me
> I'm atm. not even sure about that.
>
> I might be utterly wrong, but my impression is that the xvidmode extension
> can correct screens (eg. xcalib loads icc profiles), so a screen wide color
xvidmode gamma ramps are per channel curves. These are very limited
compared to ICC based colour correction. Those gamma curves provide better
gray balance and potentialy white point adjustment. But they do not
describe colour primaries shifts or other more complex distortions. Gamma
curves must be taken into account for ICC profiles. But detailed
characterisation of device colorimetry happens usualy in ICC profiles.
> correcting compositor would be only required to fix multiscreen (not
> multihead) setups which i frankly consider no case either, because a full
> correction would just mean to restrict the WG screen to the SRGB one
The X Color Management spec requires per window colour correction for base
line implementations. Thus it is possible to specify an source space other
than sRGB.
> (yesno?!), what doesn't much sound like a great achievement to me (and is
> simply no case in at least the professional context. You don't purchase _one_
> WG screen to use it -restricted- alongside your SRGB screen, but just
> purchase two WG screens and give away the SRGB one to one of your employees
> at home or whatever)
exactly. Thats why opting out of colour management and being able to
specify a intermediate colour profile is a good thing.
> Cheers,
> Thomas
kind regards
Kai-Uwe
todd rme
> Am 20.03.12, 21:17 +0100 schrieb Thomas Lübking:
>
>> Am 20.03.2012, 20:12 Uhr, schrieb Martin Graesslin <mgrae...@kde.org>:
>>
>>> A fully color corrected compositor seems feasible to me
>>
>> I'm atm. not even sure about that.
>>
>> I might be utterly wrong, but my impression is that the xvidmode extension
>> can correct screens (eg. xcalib loads icc profiles), so a screen wide color
>
> xvidmode gamma ramps are per channel curves. These are very limited compared
> to ICC based colour correction. Those gamma curves provide better gray
> balance and potentialy white point adjustment. But they do not describe
> colour primaries shifts or other more complex distortions. Gamma curves must
> be taken into account for ICC profiles. But detailed characterisation of
> device colorimetry happens usualy in ICC profiles.
This may be an ignorant question, but can xvidmode be extended to
offer more complex correction?
-Todd
Martin Gräßlin
> > There is more into it: first of all KWin currently does not distinguish
> > between screens during rendering. To properly have screen aware color
> > correction the complete compositor has to be made screen aware. The
> > repaint loop has to be
> As a side note, during the last CLT fair there was the idea brought up, to
> place ICC colour correction inside a KWin plugin. Is that recommendable?
screen aware. How should a plugin be able to handle screen aware rendering if
the core does not?
>
> > split into multiple rendering passes - one for each screen. This is quite
> > a
> > change in the way how KWin renders, but might be a useful change.
> >
> > As a second step all fragment shaders need to be adjusted to do the color
>
> Which shaders and adjusted for what specifically? May you point us to
> them, in order to get an idea?
> http://quickgit.kde.org/index.php?p=kde-workspace.git&a=tree&f=kwin
color corrected the answer is simple: all of them.
> > GSoC completes or not will be judged only by Oyranos. A successfully
> > completed project at Oyranos to write code to KWin does not mean that the
> > code will be merged into KWin.
>
> The more we are interested to see the KWin project being involved.
this project. It's the mentor and student who have to ensure to develop code
acceptable to the requirements of KWin development.
>
> > Given recent discussions on this mailinglist about Oyranos and colord I am
> > very unsure whether I want any color management relevant code in KWin at
> > the moment. I will definitely not accept any code supporting only one of
> > the two systems and any additional build or run-time dependency to KWin
> > will not be accepted.
>
> Has KDE facities to load and apply ICC profiles? ICC support needs at
> least a colour management module (CMM) like lcms.
>
> > In general there seems to be agreement that color management has to be
> > done
> > inside the toolkit/application and not inside the compositor. A fully
> > color
>
> You are pointing towards osX?
> I think that Qt and any other toolkit will
> need a not small amount of time to implement a similar engineered colour
> managed scene graph. Such stuff is certainly deployed inside PDF
> workflows. But my feeling says, it is a lot of work to get such a beast
> inside a cross platform Qt layer. Very likely not Qt5. How long would we
> have to wait for that? 5 years or more realistically 10 years or will
> that happen at all?
correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base
technical decisions on "my feeling says".
>
> On the other hand, Xorg architect Jim Getty told me, that compositors
> are the right places for colour correction.
>
> > corrected compositor seems feasible to me, but one where some applications
> > need to start opting-out of being color corrected is nothing I want to see
> > in KWin as it adds significant complexity and overhead to the rendering
> > process.
> Opting out of colour management is a pre condition to do
> * raw measurements, such as for ICC profile generation
> * application side specialised colour correction
>
> It needs to internally store the colour transform per window. If there is
> none, then there is no conversion needed.
to it as it has to be decided whether there has to be a conversion or not.
That's exactly what I wrote and why I don't want the complexity inside KWin.
>
> > This is something the Oyranos community has to decide on how they want to
> > have that handled.
>
> Oyranos is only one colour management project inside the OpenICC
> community. It is true that I am much behind the concept of implicite
> display ICC colour correction. But surely more people have a interest in
> that concept being deployed inside KDE.
totally irrelevant what people want if I have to do a technical decision. I
also want many things but don't get them :-)
Kai-Uwe Behrmann
> On Wednesday 21 March 2012 08:23:39 Kai-Uwe Behrmann wrote:
>>> There is more into it: first of all KWin currently does not distinguish
>>> between screens during rendering. To properly have screen aware color
>>> correction the complete compositor has to be made screen aware. The
>>> repaint loop has to be
>> As a side note, during the last CLT fair there was the idea brought up, to
>> place ICC colour correction inside a KWin plugin. Is that recommendable?
> I'm kind of confused by this question: I just wrote that the compositor is not
> screen aware. How should a plugin be able to handle screen aware rendering if
> the core does not?
I can only speak from the existing colour server plugin. It does handle
per screen colour correction regardless of support in the actual used
compositor. Of course it needs a n-screen loop for drawing all screen
overlapping windows.
>>> split into multiple rendering passes - one for each screen. This is quite
>>> a
>>> change in the way how KWin renders, but might be a useful change.
>>>
>>> As a second step all fragment shaders need to be adjusted to do the color
>>
>> Which shaders and adjusted for what specifically? May you point us to
>> them, in order to get an idea?
>> http://quickgit.kde.org/index.php?p=kde-workspace.git&a=tree&f=kwin
> As KWin renders through shaders and I expect that the screen should always be
> color corrected the answer is simple: all of them.
A 3D texture lookup is done usually only once inside the pipeline. The
plugins inside the kwin/effects path might be used simultaneously.
So placing a additional 3D texture lookup into each of those plugins would
lead to unwanted multiple colour corrections.
>>> GSoC completes or not will be judged only by Oyranos. A successfully
>>> completed project at Oyranos to write code to KWin does not mean that the
>>> code will be merged into KWin.
>>
>> The more we are interested to see the KWin project being involved.
> Whether a project succeeds or not does not depend on KWin being involved in
> this project. It's the mentor and student who have to ensure to develop code
> acceptable to the requirements of KWin development.
Personally I would not make inclusion of code a pre condition for the
success of such a project. Upstream inclusion of code is a high goal for
contributors anywhere. Not many GSoC projects reach that immediately.
>>> Given recent discussions on this mailinglist about Oyranos and colord I am
>>> very unsure whether I want any color management relevant code in KWin at
>>> the moment. I will definitely not accept any code supporting only one of
>>> the two systems and any additional build or run-time dependency to KWin
>>> will not be accepted.
>>
>> Has KDE facities to load and apply ICC profiles? ICC support needs at
>> least a colour management module (CMM) like lcms.
>>
>>> In general there seems to be agreement that color management has to be
>>> done
>>> inside the toolkit/application and not inside the compositor. A fully
>>> color
>>
>> You are pointing towards osX?
> Sorry, but what does it have to do with OS X?
osX is to my current knowledge the only desktop environment with
colour correction to the whole screen. That could be seen as a hint
towards "colour management has to be done inside the toolkit".
>> I think that Qt and any other toolkit will
>> need a not small amount of time to implement a similar engineered colour
>> managed scene graph. Such stuff is certainly deployed inside PDF
>> workflows. But my feeling says, it is a lot of work to get such a beast
>> inside a cross platform Qt layer. Very likely not Qt5. How long would we
>> have to wait for that? 5 years or more realistically 10 years or will
>> that happen at all?
> Do you have any references showing that it is impossible to add color
> correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base
> technical decisions on "my feeling says".
That would mean colour management appears earliest inside Qt 6. But it is
at the moment not clear if that happens at all.
>> On the other hand, Xorg architect Jim Getty told me, that compositors
>> are the right places for colour correction.
> that might be quite true, but not if apps want to opt-out.
The X Color Management spec allows for opt-out inside compositors.
I think to demonstrated you that on osC.
>>> corrected compositor seems feasible to me, but one where some applications
>>> need to start opting-out of being color corrected is nothing I want to see
>>> in KWin as it adds significant complexity and overhead to the rendering
>>> process.
>> Opting out of colour management is a pre condition to do
>> * raw measurements, such as for ICC profile generation
>> * application side specialised colour correction
>>
>> It needs to internally store the colour transform per window. If there is
>> none, then there is no conversion needed.
> in other words: it affects all windows and adds significant rendering overhead
> to it as it has to be decided whether there has to be a conversion or not.
> That's exactly what I wrote and why I don't want the complexity inside KWin.
What would KWin people suggest how and where to place this feature near
KWin?
(CM in Qt is unfortunedly not a secured and short term [one year] option.)
>>> This is something the Oyranos community has to decide on how they want to
>>> have that handled.
>>
>> Oyranos is only one colour management project inside the OpenICC
>> community. It is true that I am much behind the concept of implicite
>> display ICC colour correction. But surely more people have a interest in
>> that concept being deployed inside KDE.
> I'm not sure what you want to tell me with this last sentence. To me it's
> totally irrelevant what people want if I have to do a technical decision. I
> also want many things but don't get them :-)
kind regards
Kai-Uwe
--
www.oyranos.org
Martin Gräßlin
> Am 21.03.12, 18:20 +0100 schrieb Martin Gräßlin:
> > On Wednesday 21 March 2012 08:23:39 Kai-Uwe Behrmann wrote:
> >>> There is more into it: first of all KWin currently does not distinguish
> >>> between screens during rendering. To properly have screen aware color
> >>> correction the complete compositor has to be made screen aware. The
> >>> repaint loop has to be
> >>
> >> As a side note, during the last CLT fair there was the idea brought up,
> >> to
> >> place ICC colour correction inside a KWin plugin. Is that recommendable?
> >
> > I'm kind of confused by this question: I just wrote that the compositor is
> > not screen aware. How should a plugin be able to handle screen aware
> > rendering if the core does not?
>
> I can only speak from the existing colour server plugin. It does handle
> per screen colour correction regardless of support in the actual used
> compositor. Of course it needs a n-screen loop for drawing all screen
> overlapping windows.
different rendering architecture which needs to be adjusted. It is pretty much
irrelevant how it works on Compiz for the usage inside KWin. As I have written
now multiple times: KWin does not support rendering per screen.
>
> >>> split into multiple rendering passes - one for each screen. This is
> >>> quite
> >>> a
> >>> change in the way how KWin renders, but might be a useful change.
> >>>
> >>> As a second step all fragment shaders need to be adjusted to do the
> >>> color
> >>
> >> Which shaders and adjusted for what specifically? May you point us to
> >> them, in order to get an idea?
> >> http://quickgit.kde.org/index.php?p=kde-workspace.git&a=tree&f=kwin
> >
> > As KWin renders through shaders and I expect that the screen should always
> > be color corrected the answer is simple: all of them.
>
> A 3D texture lookup is done usually only once inside the pipeline. The
> plugins inside the kwin/effects path might be used simultaneously.
> So placing a additional 3D texture lookup into each of those plugins would
> lead to unwanted multiple colour corrections.
window is rendered to the screen through a shader. At runtime KWin decides
which shader to be used. As by that there is always only one active shader, so
to have color correction it has to be added to all shaders which render
windows/textures/colors.
This is different to any experience you might have from Compiz 0.8. There the
screen was not rendered with shaders but plugins could use shaders.
>
> >>> GSoC completes or not will be judged only by Oyranos. A successfully
> >>> completed project at Oyranos to write code to KWin does not mean that
> >>> the
> >>> code will be merged into KWin.
> >>
> >> The more we are interested to see the KWin project being involved.
> >
> > Whether a project succeeds or not does not depend on KWin being involved
> > in
> > this project. It's the mentor and student who have to ensure to develop
> > code acceptable to the requirements of KWin development.
>
> Personally I would not make inclusion of code a pre condition for the
> success of such a project. Upstream inclusion of code is a high goal for
> contributors anywhere. Not many GSoC projects reach that immediately.
If you don't aim for inclusion into KWin, I seriously do not see why such a
project is needed. Given the changes inside KWin I doubt any of the code could
be reused let's say a year later.
> > Do you have any references showing that it is impossible to add color
> > correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base
> > technical decisions on "my feeling says".
>
> That would mean colour management appears earliest inside Qt 6. But it is
> at the moment not clear if that happens at all.
Any proof for these bold statements? Anything from Qt where I can see that
this is the case (also for Wayland)? Remember nobody wants to develop for X
anymore ;-)
>
> >> On the other hand, Xorg architect Jim Getty told me, that compositors
> >> are the right places for colour correction.
> >
> > that might be quite true, but not if apps want to opt-out.
>
> The X Color Management spec allows for opt-out inside compositors.
> I think to demonstrated you that on osC.
and I think I explained to you why I don't think that's a good idea for KWin
:-)
>
> >>> corrected compositor seems feasible to me, but one where some
> >>> applications
> >>> need to start opting-out of being color corrected is nothing I want to
> >>> see
> >>> in KWin as it adds significant complexity and overhead to the rendering
> >>> process.
> >>
> >> Opting out of colour management is a pre condition to do
> >> * raw measurements, such as for ICC profile generation
> >> * application side specialised colour correction
> >>
> >> It needs to internally store the colour transform per window. If there is
> >> none, then there is no conversion needed.
> >
> > in other words: it affects all windows and adds significant rendering
> > overhead to it as it has to be decided whether there has to be a
> > conversion or not. That's exactly what I wrote and why I don't want the
> > complexity inside KWin.
> What would KWin people suggest how and where to place this feature near
> KWin?
> (CM in Qt is unfortunedly not a secured and short term [one year] option.)
Well the question is whether such a feature is needed at all. I would say:
* either correct the whole screen
* or let the windows handle it
Now it becomes quite simple: there's an app doing color correction itself. In
that case we can safely assume that the user wants the app to take care -
compositor does no longer color correct the screen.
There is no application taking care of it: compositor renders the whole
screen.
Cheers
Martin
Thomas Zander
> > Personally I would not make inclusion of code a pre condition for the
> > success of such a project. Upstream inclusion of code is a high goal for
> > contributors anywhere. Not many GSoC projects reach that immediately.
>
> If you don't aim for inclusion into KWin, I seriously do not see why such
> a project is needed. Given the changes inside KWin I doubt any of the
> code could be reused let's say a year later.
Thats a very good point, one that may not be quick to grasp by potential gsoc
students. This point should be made very clear otherwise I fear people might
get very dissapointed if their work ends up being discarded. Discarded because
the initial setup wasn't thought through.
I would say that the core aim of the GSOC project should be inclusion in kwins
tree for any KDE people to spent any time on this or even support it.
Otherwise it would be unfair to various people. Like the student and the
hosting org and also to the kde volunteers helping with it.
> > > Do you have any references showing that it is impossible to add color
> > > correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't
> > > base technical decisions on "my feeling says".
> >
> > That would mean colour management appears earliest inside Qt 6. But it is
> > at the moment not clear if that happens at all.
>
> Any proof for these bold statements? Anything from Qt where I can see that
> this is the case (also for Wayland)? Remember nobody wants to develop for
> X anymore ;-)
Color management in Qt is a bit of a weird statement; first of all, support is
already possible as Krita proves. Second, I doubt that 94% of the widgets
actually need color correction of the type that kwin could provide. Who cares
that their text edits and their buttons are color correct?
Its only for canvas-like widgets that this is relevant, and apps have that
option already by linking to LCMS.
So, KWin support would just be a shortcut. A one-stop solution to make all
apps suddenly get sunglasses on. It certainly is not a 'proper' solution, its
a shortcut. So please keep treating it as such.
When people talk about the toolkit adding support its more about convenience
APIs. Think a QPainter method to set a color transform to do correction on
following draws.
When people want support in the toolkit, they want the color selector widget,
the print preview widget etc, that come with Qt to natively use the monitor
profile.
Last, they want the printing to take color management into account.
All of those are possible and likely even welcomed in Qt. The only thing is
that someone has to actually do it. So saying that it won't happen in Qt6 is
a self-fulfilling wish, and I feel its not very fair to plant that doubt in
peoples minds.
> > What would KWin people suggest how and where to place this feature near
> > KWin?
>
> Well the question is whether such a feature is needed at all. I would say:
> * either correct the whole screen
> * or let the windows handle it
>
> Now it becomes quite simple: there's an app doing color correction itself.
> In that case we can safely assume that the user wants the app to take
> care - compositor does no longer color correct the screen.
>
> There is no application taking care of it: compositor renders the whole
> screen.
Sounds good to me.
--
Thomas Zander
Kai-Uwe Behrmann
> I think you do not know how KWin's rendering works. In a simplistic way: a
> window is rendered to the screen through a shader. At runtime KWin decides
> which shader to be used. As by that there is always only one active shader, so
> to have color correction it has to be added to all shaders which render
> windows/textures/colors.
Thanks for the description.
> This is different to any experience you might have from Compiz 0.8. There the
> screen was not rendered with shaders but plugins could use shaders.
>>> Do you have any references showing that it is impossible to add color
>>> correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't base
>>> technical decisions on "my feeling says".
>>
>> That would mean colour management appears earliest inside Qt 6. But it is
>> at the moment not clear if that happens at all.
> Any proof for these bold statements? Anything from Qt where I can see that
> this is the case (also for Wayland)? Remember nobody wants to develop for X
> anymore ;-)
As we discuss a equivalent of colour management in KWin, we talk about
default colour management of all displayed Qt widgets. That is a high goal
and likely coming with some API changes. Such changes need quite some
preparation.
What signs are visible that with the first release of Qt 5 will have full
CM? Even if people would put CM now high on the Qt develpers or similar
agendas, CM will likely not get included soon to be ready for the first
Qt 5 release. Then logically the next feature window is Qt 6.
>>>> On the other hand, Xorg architect Jim Getty told me, that compositors
>>>> are the right places for colour correction.
>>>
>>> that might be quite true, but not if apps want to opt-out.
>>
>> The X Color Management spec allows for opt-out inside compositors.
>> I think to demonstrated you that on osC.
> and I think I explained to you why I don't think that's a good idea for KWin
> :-)
kind regards
Kai-Uwe
Kai-Uwe Behrmann
> Color management in Qt is a bit of a weird statement; first of all, support is
> already possible as Krita proves. Second, I doubt that 94% of the widgets
Krita does colour management inside Krita. IMO that does not belong to a
discussion about Qt itself.
> actually need color correction of the type that kwin could provide. Who cares
> that their text edits and their buttons are color correct?
Many people care about that and even more are positively affected.
> Its only for canvas-like widgets that this is relevant, and apps have that
> option already by linking to LCMS.
It is relevant to the whole desktop experience. What people like to see
are consistent colours on displays and then on prints. And they want to
show the same colours to their friends remotely.
At the moment KDE looks on each monitor different. No one can predict on
what colours come over the internet, being it web sites, email clients or
application toolbars. That's not so good.
> So, KWin support would just be a shortcut. A one-stop solution to make all
> apps suddenly get sunglasses on. It certainly is not a 'proper' solution, its
> a shortcut. So please keep treating it as such.
Yes. There needs work on many layers. All have to play their role. And I
see default colour management in KWin as a big step in a good direction.
> When people talk about the toolkit adding support its more about convenience
> APIs. Think a QPainter method to set a color transform to do correction on
> following draws.
Such a API is specialy tailored to a certain audience. Photographers come
to mind. And I am all for it, but they are only part of the KDE user base.
> When people want support in the toolkit, they want the color selector widget,
> the print preview widget etc, that come with Qt to natively use the monitor
> profile.
> Last, they want the printing to take color management into account.
Good example. The print of a screenshot should look like on screen. So the
first thing is to make screens look consistent. Then printing has a
chance to match that.
> All of those are possible and likely even welcomed in Qt. The only thing is
> that someone has to actually do it. So saying that it won't happen in Qt6 is
> a self-fulfilling wish, and I feel its not very fair to plant that doubt in
> peoples minds.
Agreed with you. And luckily no one says it can not happen for Qt 6.
>>> What would KWin people suggest how and where to place this feature near
>>> KWin?
>>
>> Well the question is whether such a feature is needed at all. I would say:
>> * either correct the whole screen
>> * or let the windows handle it
>>
>> Now it becomes quite simple: there's an app doing color correction itself.
>> In that case we can safely assume that the user wants the app to take
>> care - compositor does no longer color correct the screen.
>>
>> There is no application taking care of it: compositor renders the whole
>> screen.
That could be a start.
kind regards
Kai-Uwe Behrmann
--
www.oyranos.org
Kai-Uwe Behrmann
> On Thursday 22 March 2012 07:02:27 Kai-Uwe Behrmann wrote:
>> Am 21.03.12, 20:34 +0100 schrieb Martin Gräßlin:
>>>>> Do you have any references showing that it is impossible to add color
>>>>> correction to Qt during the lifecycle of Qt 5? I'm sorry, but I don't
>>>>> base
>>>>> technical decisions on "my feeling says".
>>>>
>>>> That would mean colour management appears earliest inside Qt 6. But it is
>>>> at the moment not clear if that happens at all.
>>>
>>> Any proof for these bold statements? Anything from Qt where I can see that
>>> this is the case (also for Wayland)? Remember nobody wants to develop for
>>> X
>>> anymore ;-)
>>
>> As we discuss a equivalent of colour management in KWin, we talk about
>> default colour management of all displayed Qt widgets. That is a high goal
>> and likely coming with some API changes. Such changes need quite some
>> preparation.
>> What signs are visible that with the first release of Qt 5 will have full
>> CM? Even if people would put CM now high on the Qt develpers or similar
>> agendas, CM will likely not get included soon to be ready for the first
>> Qt 5 release. Then logically the next feature window is Qt 6.
> (which is impossible) does not mean that it won't enter any 5.x release.
>
> And that's what I asked for: is there any reference stating that it won't be
> possible to add CM to Qt in the lifetime of Qt 5?
Here my thoughts, why I think CM in Qt is not easily introduced during a
minor Qt 5 release. [Preparation of CM for Qt 6 is a different story.]
Lets hypothetical assume some effort is initiated to bring CM to Qt and
that happens during Qt 5 life time. The new design says by default all
content is considered sRGB, which is by itself reasonable. However
existing applications will initially not know about that changed
convention. There is currently no API to know that. They will play
freestyle as before and colour correct to monitor space without knowing
how to tell anything to Qt. These old style apps will colour correct to
monitor and Qt will colour correct from sRGB to monitor as Qt does not
better know. That is called double colour correction and would be a real
design bug.
The conflict is solveable by making the new drawing API incompatible with
the old one, e.g. requiring a colour space argument. An other way is
verbally declaring sRGB as the default colour space in Qt, which would be
a major API change as well and only reasonable possible during major
version change.
Both is not easy before Qt 5. After the fist Qt 5 release a new drawing
API could theoretically be introduced in parallel to the old one. But old
Qt apps would then look inconsistent compared to ones using the new API.
Not sure if that transition path would be a good option regarding code
complexity. IMO best would be to wait for Qt 6 and then switch completely.
Daniel Nicoletti
> Here my thoughts, why I think CM in Qt is not easily introduced during a
> minor Qt 5 release. [Preparation of CM for Qt 6 is a different story.]
>
> Lets hypothetical assume some effort is initiated to bring CM to Qt and that
> happens during Qt 5 life time. The new design says by default all content is
> considered sRGB, which is by itself reasonable. However existing
> applications will initially not know about that changed convention. There is
> currently no API to know that. They will play freestyle as before and colour
> correct to monitor space without knowing how to tell anything to Qt. These
> old style apps will colour correct to monitor and Qt will colour correct
> from sRGB to monitor as Qt does not better know. That is called double
> colour correction and would be a real design bug.
>
> The conflict is solveable by making the new drawing API incompatible with
> the old one, e.g. requiring a colour space argument. An other way is
> verbally declaring sRGB as the default colour space in Qt, which would be a
> major API change as well and only reasonable possible during major version
> change.
>
> Both is not easy before Qt 5. After the fist Qt 5 release a new drawing API
> could theoretically be introduced in parallel to the old one. But old Qt
> apps would then look inconsistent compared to ones using the new API. Not
> sure if that transition path would be a good option regarding code
> complexity. IMO best would be to wait for Qt 6 and then switch completely.
I'm sorry but you point is wrong here. Even if the real problem was
just API changing
and old applications getting unaware of that this is the easiest thing
to fix. When
people draw API they have this in mind and we don't need a whole new Qt just to
introduce a new feature, easy solution: QApplication::setColorCorrected(true);
Done! All old apps won't be color corrected since they don't set that
and all new
ones will be able to have this.
And I had only to think about it in 2 minutes, surely Qt devs will have a better
solution.
I'm not saying it's easy to add Color Correction to Qt, but API
additions is no excuse.
Sune Vuorela
> people draw API they have this in mind and we don't need a whole new Qt just to
> introduce a new feature, easy solution: QApplication::setColorCorrected(true);
That's crap API thoug.h
QApplication::setBehaveSane(true);
QApplication::setPleaseDontCrash(true);
QApplication::pleaseFixMyBrokenApplication(true);
/Sune
Daniel Nicoletti
through crap API). I'm not an expert in Qt internals but surely
they will think on something much clever.
Thomas Lübking
> Lets hypothetical assume some effort is initiated to bring CM to Qt and
> that happens during Qt 5 life time. The new design says by default all
> content is considered sRGB, which is by itself reasonable. However
> existing applications will initially not know about that changed
> convention.
Errrmmm... how is that please different from opting out of the compositor?
Except that latter does not only hit Qt applications but also *every*
"legacy" stuff around?
> The conflict is solveable by making the new drawing API incompatible with
> the old one, e.g. requiring a colour space argument.
Or by making user code color correction calls
(QApplication::setColorSpec(int spec)?) invalidate/override library
settings?
Cheers,
Thomas
Kai-Uwe Behrmann
Am 21.03.12, 10:25 +0100 schrieb todd rme:
> On Wed, Mar 21, 2012 at 8:39 AM, Kai-Uwe Behrmann <ku...@gmx.de> wrote:
>> Am 20.03.12, 21:17 +0100 schrieb Thomas Lï¿œbking:
>>> Am 20.03.2012, 20:12 Uhr, schrieb Martin Graesslin <mgrae...@kde.org>:
>>>
>>>> A fully ï¿œcolor corrected compositor seems feasible to me
>>>
>>> I'm atm. not even sure about that.
>>>
>>> I might be utterly wrong, but my impression is that the xvidmode extension
>>> can correct screens (eg. xcalib loads icc profiles), so a screen wide color
>>
>> xvidmode gamma ramps are per channel curves. These are very limited compared
>> to ICC based colour correction. Those gamma curves provide better gray
>> balance and potentialy white point adjustment. But they do not describe
>> colour primaries shifts or other more complex distortions. Gamma curves must
>> be taken into account for ICC profiles. But detailed characterisation of
>> device colorimetry happens usualy in ICC profiles.
>
> This may be an ignorant question, but can xvidmode be extended to
> offer more complex correction?
That would end in a all desktop content is sRGB dituation. That would be
fine as long as we know that wide gamut monitors are excluded, like on
fixed hardware. Tablets could do that for their internal displays.
But I am afraid a desktop, which cribbles all wide gamut monitors by
default to sRGB, is suboptimal marketing.
Martin Gräßlin
> Something like that is technical possible. But let me repeat, you get then
> a mixture of colour managed and non colour managed apps with the same
> toolkit, which is completely non understandable for users.
First of all: users don't know anything about toolkits. If they use KDE Plasma
Workspaces (and that's what this whole thread is about), they get three
different toolkits looking exactly the same thanks to the effort of the Oxygen
team. So how should users understand that their Firefox (GTK 2) is not color
corrected, while the Qt app is?
The issue - if there is any at all - will be quite simply resolved by the apps
adjusting to it. It's a three line patch (ifdef, call, endif) for each app. If
users really care about it, they will report bugs to the application ("looks
strange when running with Qt 5.x") or the more advanced will provide the patch
directly (e.g. a distro could very easily do that).
To me it is important to do it right. And if right means legacy is not
supported, than it is like that. To me it looks like you are trying extreme
workarounds just to make everybody happy and especially support legacy. Do
yourself a favor: go for the easy part and forget about legacy :-)
Cheers
Martin
Thomas Lübking
> I was tould by the graphics community to keep the X Color Management spec
> backward compatible with the ICC Profile in X spec, so we did. Thus old
> style applications see a sRGB profile through the ICC Profile in X spec,
> and they continue to work by converting to sRGB.
Sorry again, but does that actually mean that if I have a WG screen and an
application which does not support the opt-out protocol or bought into a
competing* system, it will be reduced to sRGB while the application and
the screen actually could do WG ... but the delete icon in dolphin looks
correct?
Next question: do you have approached the Wayland project on this?
In case, what do they say?
Cheers,
Thomas
------------------
*semi OT sidenote:
This is btw. sth. I do not like at all.
Xorg and fdo do not have the market share -esp. in that market- to afford
two competing color management systems.
I have no idea about the technical, conceptual and maybe religious
differences, but would suggest to iron that out by all means if you ever
want usable CM on this Architecture.
Kai-Uwe Behrmann
> Am 22.03.2012, 19:20 Uhr, schrieb Kai-Uwe Behrmann <ku...@gmx.de>:
>> I was tould by the graphics community to keep the X Color Management spec
>> backward compatible with the ICC Profile in X spec, so we did. Thus old
>> style applications see a sRGB profile through the ICC Profile in X spec,
>> and they continue to work by converting to sRGB.
>
> Sorry again, but does that actually mean that if I have a WG screen and an
> application which does not support the opt-out protocol or bought into a
> competing* system, it will be reduced to sRGB while the application and the
Where would be a competing system on Linux?
> screen actually could do WG ... but the delete icon in dolphin looks correct?
That is correctly described and expected behaviour as developers said.
> Next question: do you have approached the Wayland project on this?
> In case, what do they say?
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
> *semi OT sidenote:
> This is btw. sth. I do not like at all.
> Xorg and fdo do not have the market share -esp. in that market- to afford two
> competing color management systems.
> I have no idea about the technical, conceptual and maybe religious
> differences, but would suggest to iron that out by all means if you ever want
> usable CM on this Architecture.
What other substantial proposals or discussions do you have in mind?
As far as I can see there was no publically discussed *competing* concept
of substance ever brought to the attention of the graphics community.
We only have read some nebulous and non technical statements on the typical
level of marketing.
OpenICC [1] is the fd.o place to discuss such CM stuff or at least the
Xorg email list. In both I am active. I will surely continue to present
and discuss the idea with users and developers in various events.
kind regards
Kai-Uwe Behrmann
--
www.oyranos.org
[1] http://www.freedesktop.org/wiki/OpenIcc/Events/Fosdem/2012
Casian Andrei
And I realized the complications for the strange idea regarding
GLShader are not even remotely necessary, bad thinking on my part.
Explanations below.
2012/3/22 Casian Andrei <skel...@gmail.com>:
> Thank you for all this feedback!
>
> Meanwhile I have been documenting myself and looking into relevant
> code (and following this thread). I can't argue on the complex
> technical issues and decisions.
>
> 2012/3/20 Martin Graesslin <mgrae...@kde.org>:
>> There is more into it: first of all KWin currently does not distinguish between
>> screens during rendering. To properly have screen aware color correction the
>> complete compositor has to be made screen aware. The repaint loop has to be
>> split into multiple rendering passes - one for each screen. This is quite a
>> change in the way how KWin renders, but might be a useful change.
> Okay, this would involve complicated changes, consequently it should
> be like a separate sub-project. At the moment I don't know well enough
> how KWin renders from my limited current understanding of the code,
> but there will be enough time to discuss and see how this could be
> done. It is good if this change is possible without massive intrusive
> modifications throughout KWin.
>
>>
>> As a second step all fragment shaders need to be adjusted to do the color
>> correction. This has to be done extremely efficient. This is a rather critical
>> code path especially for low-end hardware (think of old Intel GPUs). Given the
>> constraints of the GPUs a dynamic feature activation is not possible.
> I have a rather crazy idea about how to achieve this for *all* of the
> fragment shaders without modifying each one. It might be a silly idea,
> but it's worth proposing it.
>
> Every one of these fragment shaders respect the following structure:
> 1. declarations, functions, uniforms, whatever
> 2. void main() {
> 3. fragment shader functionality (whatever the shader does)
> 4. gl_FragColor = some_expression
> 5. } // closing bracket, end of shader
>
> Now, colour correction would require this gl_FragColor result to be
> different, to be altered. If I understand the shader assembly thing in
> CompICC, it would be an alpha demultiply, a 3d texture lookup to
> correct the color, and an alpha remultiply. Let's assume this code is
> kept in a GLSL function, namely "vec4 correctColor(vec4 c)". This
> function will require a sampler3D.
>
> To make the above code do the color correction, we need to do the following:
> * insert the sampler3D declaration and the function definition just
> before main()
> * alter gl_FragColor = some_expression --> gl_FragColor =
> correctColor(some_expression)
>
> These alterations are not *that* complicated, and they shouldn't
> introduce any strange instabilities. Similar, but simpler alterations
> are already made in GLShader::compile() at kwinglutils.cpp around line
> 295. Colour correction could be easily disabled at this point.
>
> The tricky part is how to know what window / screen we're compiling
> the shader for. This can be done with some little complications, maybe
> an extra parameter, or some kind of member for GLShader, or some evil
> static variable / member.
We don't need to know that! Distinguishing between windows and screen
can be done just by binding different lookup textures, no need for
extra parameters or useless complications. The altered shader just
tries to do colour correction. If it gets a default sRGB->sRGB lookup
texture, then no colour correction. And I think there are many ways to
disable it altogether - something like that kwin_shader_debug
definition.
>
> The advantage is that it avoids modifying all the fragment shaders
> everywhere, but it brings these (i hope slight) complications to
> GLShader. What do you think about this?
So, minus the complications.
>
> Oh, and what does "dynamic feature activation" mean? If it means what
> I think it means, then it can be handled by the above idea.
>
>>
>> What is in general important to know is that we have not had the best
>> experience with GSoC students doing work on the core of KWin. Given that I
>> proposed guidelines for future feature additions to KWin by non-core
>> developers [1].
> Those are really strict guidelines, but I guess they are well based
> given the past experiences, so I won't complain. There are a couple of
> points that this possible project does not appear to respect, but
> those are unclear and debatable when applied to this, in my view.
> However, it looks to me as if no further significant features can be
> added to KWin if you respect all those points by the letter.
>
> Probably the colour correction code can be kept isolated in a couple
> of separate files, without interfering much with the normal KWin
> workings. This code would be responsible with getting the lookup
> textures for the monitors (or screens) and the windows (possibly). It
> may turn complicated and large, but at least it would be isolated.
>
>>
>> Given recent discussions on this mailinglist about Oyranos and colord I am
>> very unsure whether I want any color management relevant code in KWin at the
>> moment. I will definitely not accept any code supporting only one of the two
>> systems and any additional build or run-time dependency to KWin will not be
>> accepted.
> Alright, so this colord is a must, eventually. I should document
> myself about colord too. But at least I could ask not to make it part
> of the objectives for the summer.
>>
>> In general there seems to be agreement that color management has to be done
>> inside the toolkit/application and not inside the compositor. A fully color
>> corrected compositor seems feasible to me, but one where some applications
>> need to start opting-out of being color corrected is nothing I want to see in
>> KWin as it adds significant complexity and overhead to the rendering process.
>> This is something the Oyranos community has to decide on how they want to have
>> that handled.
> This is still a hot topic so I would prefer not to comment at the
> moment, and the decision is yours anyway.
>
> Best regards,
> Casian
Kai-Uwe Behrmann
> Am 23.03.2012, 06:27 Uhr, schrieb Kai-Uwe Behrmann <ku...@gmx.de>:
>> Where would be a competing system on Linux?
> 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