KWin Color Correction Proposal (GSoC 2012)

Description

This project is aimed at color correction for different outputs (monitors), implemented in the compositor.

At the moment, windows appear differently on different monitors, depending on the monitors characteristics. These characteristics vary much between different devices, so the perceived colors are affected. I notice this on a daily basis when moving windows from one monitor to another.

Color correction solves this by altering the colors displayed on each output, in a way that makes them to be perceived the same everywhere. The ICC profiles for the devices describe their characteristics, so the appropriate correction is performed. Oyranos is able to look up and use these profiles and provide the necessary data for correction. This is already done by the CompICC Compiz plugin.

The X Color Management specification is designed to allow compositors implement color management in a simple way. libXcm helps applications, compositors or color servers adhere to the specification. The initial objective is to implement the baseline specification.

The KWin rendering mechanism needs to be altered to enable color correction. The changes to KWin will be kept at a minimum, so any tasks not directly related to color correction will be implemented as separated from KWin as possible. KWin is large and complex, so preserving it's stability is crucial.

Technical Details

In a general view, this project can be seen as implementing the functionality of the CompICC plugin inside KDE.

Parts of the project

KWin Shader Manager and KWin Shader color correction support
- setup color correction for all shaders
- alterations for shader sources in KWin::GLShader::compile()
Create KWin GLTexture3D (inherits KWin GLTexture), to handle 3D textures needed for correction
KWin Colour Correction Mechanisms
- apply the appropriate lookup texture for each window or screen
- monitor relevant X atoms (maybe _ICC_COLOR_OUTPUTS, or maybe some other specialized atoms)
- map windows to lookup textures (for color correction)
- communicates with Color Server Daemon (either through X11 with atoms or via D-BUS)
- needs to get data for lookup texture from the Color Server Daemon (probably)
- implementation as an effect can be shortly attempted, as a longshot
Color Server Daemon
- possibly a KDED Module
- possibly a daemon from Oyranos
- ICC profile lookup
- textures from profiles and options
- hotplug handling
- move X atoms complying to X Color Management spec
- communication with KWin Color Correction mechanisms (either through X11 with atoms or via D-BUS)
- other things done by CompICC that fit here (anything that doesn't need to be close to KWin)

The work for the project can be categorized into:

KWin rendering modifications (small but tricky)
KWin color correction mechanisms (big)
Color server daemon (big)

KWin modifications

Inside the KWin rendering mechanism, it is likely that a split will be required somewhere in order to render for each monitor in distinct passes. The place for this split could be in KWin::Scene::paintScene().

There is no single shader or pair of shaders that are used to render the screen and windows. Every shader that will eventually be used (including those created by effects) needs to be modified to include color correction. This can be achieved by altering the shader source before it's compiled, in KWin::GLShader::compile(). The alterations are not significant:

insert a sampler3D declaration
insert a function that corrects a color based on the lookup texture - correctColor()
search for "gl_FragColor = expression" assignment at the end of the shader
replace "expression" with "correctColor(expression)" or use a temporary variable by changing to "vec4 temp = expression" and inserting "gl_FragColor = correctColor(temp)"
good care must be taken so this alteration process won't ruin perfectly good shader sources

The correction depends only on the bound lookup texture. I assume binding other textures is inexpensive, so it could be done repeatedly before drawing windows.

I can look at CompICC to see what the proposed Colour Server Daemon needs to do. Oyranos will be heavily used by this part of the project. The trickiest part is the communication with KWin. The texture data needs to be sent somehow. It might be possible with special X atoms, or it could be done with D-BUS.

Possible risks and complications

modifications to the shader sources don't work or will be viewed as terribly ugly hacks (probability: unlikely; damage: very high)
communication between KWin and the color server daemon proves very difficult (probability: low-medium; damage: high)
finding a mix between the functionality of the KWin correction and the daemon will prove difficult or nearly impossible (probability: low; damage: high)
attempts to draw for each output with the appropriate shader will fail (probability: medium; damage: low-medium)
the daemon will be unable to do the necessary operations with the X server (probability: low; damage: medium)
modifications to libXcm (probability: unknown; damage: low)

Timeline

2-3 weeks (+) - KWin rendering modifications
1 week - skeleton for the color server daemon
1 week - basic test functionality for KWin color correction
2 weeks - color server daemon basic functionality
3 weeks - develop the daemon and the KWin changes at the same time and ensure proper integration between them
1-2 weeks - extend color server daemon functionality
1-2 weeks - track down issues, fix bugs, QA

Milestones

implement KWin rendering modifications
basic functionality for KWin color correction mechanisms and the color server daemon
complete functionality for the color server daemon
achieve code quality appropriate for merging

Repository

git://anongit.kde.org/clones/kde-workspace/casianandrei/skelet-workspace branch "color2"
git://anongit.kde.org/kolor-manager.git branch "kded"

Note that KolorManager needs Oyranos.

Contact

Name: Casian Andrei

Devel Blog: http://skeletdev.wordpress.com

IRC: skelet

e-mail: skeletk13 gmail