[GSoC] KWin colour management

[Kai-Uwe Behrmann]

Am 20.03.12, 20:12 +0100 schrieb Martin Graesslin:
> 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

> [1] http://community.kde.org/KWin/Mission_Statement
>