[GSoC] KWin colour management

[Kai-Uwe Behrmann]

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