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
