[GSoC] KWin colour management

[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?
> 
> > 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.
> > 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.
> 
> > 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?
> 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".
> 
> 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.
> 
> > 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.
> 
> > 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
Martin Gräßlin
KWin Maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120321/c56161f9/attachment.sig>