Thanks for posting here.
Am 18.03.12, 20:01 +0200 schrieb Casian Andrei:
Hello,
I am a final year undergraduate student at the Polytechnic University
of Bucharest, Automation and Computers Faculty. I am interested in the
"Compositor Colour Management" idea from OpenSUSE. It looks like
something I would enjoy doing.
Given that colour management inside open source toolkits is a very very
long outstanding issue, and we are still at the beginning with that, it is
unlikely that Qt5 will allow to colour manage _all_ it's widgets by
default. That means, we will see only few graphics applications to do ICC
colour correction themself. Consequently most other desktop applications
and areas will look different on each monitor. In my opinion, the most
easy path towards working end to end colour management inside KDE is to
assume sRGB for all non colour aware applications and do colour correction
unquestioned.
That concept is worked out on OpenICC and used and checked on a daily base
with CompICC. So it is no longer a experimental feature. In
comparision, the concept to colour manage unaware colour content is as
well common practise inside Linux and other OS printing paths. Ghostscript
and likely Poppler will or do already colour convert the mass of todays
/DeviceRGB colour unquestioned. They will implicitely assume that these
colours to be meant as sRGB. I suggest we should follow that route for
displaying inside KWin and improve colour useability on the KDE desktop.
I have acceptable C / C ++ skills and lots of experience with OpenGL.
I am also familiar with Qt. Regarding shaders, I wrote a couple about
2 years ago for an old project, and I still know how they work, so it
would be easy for me to remember. Last GSoC I worked on an OpenGL
interface for VLC, and 2 years ago I worked on capture support in
Phonon.
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.
The idea behind these two atoms is to enable per window colour correction,
which is relatively easy implemented.
In a first step a window manager can be enabled with that feature. It is
completely backward compatible. Graphic applications can be updated step
by step to take advantage of the new ICC support by implementing the X
Color Management protocol. They will profit by getting multi monitor
aware very fast and power efficient colour correction with the smallest
effort. Some few applications exist already, which deploy this scheme.
Qt or KDE widgets can be created to share common code among such apps.
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.
But I am still unsure and I don't have an exact image in mind about
what needs to be done. Clearly, more exploration is needed. I don't
know what to concentrate on - looking around in KWin / Compiz code,
concentrating on libXcm and the X Color Management spec, reading more
about Oyranos and colour management in general?
I tried the Oyranos colour management LiveCD and I saw it doing the
correction magic, but unfortunately I was unable to get compiz working
- with the open source drivers it didn't start because of missing
glx_ext_texture_from_pixmap extension, and there were problems with
the ati drivers - after installing them, the root visual was not a GL
visual (or something like that), and if I tried to do some
configuration with Catalyst, then X froze together with the system
(nothing new for me, that's why I am sticking to the open source
drivers). At least I know ICC profiles for both my monitors were
found, by monitoring with QcmsEvents.
Best regards,
Casian
kind regards
Kai-Uwe
--
www.oyranos.org
