[GSoC] KWin colour management

[Kai-Uwe Behrmann]

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.

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