[Openicc] Application and Toolkit CM code

[Kai-Uwe Behrmann]

CM in compositors appears more easily adaptable, if it is easy to 
implement and matches the compositors paradigm. During the lifetime of 
X11, and even more to be expected for Wayland, evolved a per window 
paradigm. I think now that widespread CM in compositors is only possible 
this way on a per window base.

But per window colour correction brings at the same time a CM requirement 
for toolkits and/or applications. Realistically, we have at the moment no 
open source toolkit, which does colour correction of all widgets and 
content on its own. There are some first baby steps though. For instance 
Firefox colour converts all content, and I think this includes all 
widgets, to the main montitor.

The advantage of colour correction on application level is independence of 
OS, and compositors. Of course colour managed applications look more 
consistent inside a colour managed OS. But there are as well disadvantages 
such as toolkits and Firefox will not likely tract window transformations.

We need here some flexibility, speed and low power consumption.

I would like to assist in creating code, a library and according widgets 
to help applications to become completely colour managed for displaying.
With such code a app developer idealy renames a widget and sets a colour 
space according to content. If thats not supported in the toolkit 
including a header file and linking against a library is additionally 
needed. Such code would be great to be reuseable.

In scope are applications like vector, pixel image and 3D viewers, 
editors, web browsers with animation, games and others.

Inside the Oyranos project I started some code with a fully CPU colour 
managed image display example app. The code is already deployed inside 
ICC Examin but not yet very generic to be easily reuseable in Qt or Gtk.

What it does is to draw into a offscreen buffer and colour correct that 
for each monitor and blits that back through the toolkit bitmap drawing 
function. That is early colour binding. Moreover there is 3D a widget 
inside ICC Examin modified to make use of a colour server through late 
colour binding. It renders into a intermediate colour space to let the 
colour server do final colour correction on GPU toward each monitor. That 
way, the code inside ICC Examin does not need to know about window 
transformations. Both methods are not yet switchable at runtime, so the 
CPU is slow during scrolling. And without a colour server the 3D widget 
converts to one monitor only, which is not optimal. The following 
points are ideas to improve the existing functionality.

Features for application/toolkit CM:
* CPU per monitor colour correction fallback (present in Oyranos)
* off load of CM to colour server (present in ICC Examin)
* switch to appropriate internal CPU/GPU colour correction on runtime
* fast and low power consumption (using GPU shaders)
* easy way to opt out of CM (present in libXcm)
* select or create a useful intermediate colour space (new)
* support HDR encoding (logarithmic encoding or scaled like scRGB)
* support menus
* demo how to blend sRTGB widgets into ICC tagged content
* support two or better three toolkits
* easy to follow demo code

Technical stuff to figure out:
* support linear space conversion in shaders (needs post linearisation)
* share 3D colour transform tables among application memory
* detection of and communication with a colour server (present in libXcm)
* render to offscreen buffer (present in Oyranos demo code)
* render to offscreen GL buffer to apply shaders (port from CompICC)
* use offscreen buffer inside a application (new)
* combine CPU buffer and GPU on GL texture into one widget (new)
* is 4:2:2 like LogLuv/Yuv encodeable inside ICC profiles?
* find easy and portable shader library or GL methods
* find easy and portable GL texture method
* alternatively explore OpenGTL/OpenCL
* cache colour transforms

Most code can be found on the internet on GPU manufacturers demo code 
pages or gamer forums. Many code is already implemented and available or 
demonstrated. So that project is more of combining, integration and a 
good API design. However some parts like the intermediate space and colour 
transform sharing memory are relatively new. It will need some resources 
to get that project figured out. Lets see where that come from.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org