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
