[RFC PATCH v2 0/6] Initial per-surface color management

[Kai-Uwe Behrmann]

Am 29.10.2014 um 20:15 schrieb Niels Ole Salscheider:
> On Tuesday 28 October 2014, 15:45:18, Kai-Uwe Behrmann wrote:
>> Am 27.10.2014 um 19:07 schrieb Niels Ole Salscheider:
>>>> The support to mask the area of a surface so that its color space is not
>>>> converted has been removed. Instead, the color profile of the main output
>>>> of that surface can be attached if an application has a need to display
>>>> uncorrected colors.
>>> I had a discussion regarding this with Zoxc on the IRC channel. Does it
>>> make sense to have a surface that is displayed uncorrected on multiple
>>> outputs with different output profiles?
>>> If so then this is not enough to detect that no color conversion should be
>>> applied at all.
>> For measuring the colorimetric performance of outputs, for testing and
>> scalability, it appears the easiest to have a colormanagement-off
>> switch. On osX, without such switch, the mechanism to attach the monitor
>> profile to the input image brings headache to developers and this
>> workaround does not work reliably.
> Sure, I introduced the possibility to disable color correction of a surface 
> for these use-cases in my first proposal.
> But is it really enough to just not apply color corrections to a surface? Or 
> would this use-case require to deactivate color correction completely, as 
> argued by John Kåre Alsaker?

I can only guess what the motivation for a per output switch-off might be:
* graphic cards video lut handling
* compositing space triggering
* consistency with alpha blending behaviour for stacked transparent
surfaces with and without CM enabled
* effects on top of windows (sepia, etc.)

Some of the above mentioned mechanisms are not easy to integrate. So the
best is to have access to each mechanism by an separate API and let
applications handle them on need.

For compositing might arise the need to switch off the compositing
space. So a transparent widget on top of a graphics application will not
make the case to touch the rgb numbers, except for the blending areas of
course. Further the transparent widget can overlap in parts the CM-off
widget and normal areas at the same time. So the compositing of the
different areas has to be handled separately. Given that for different
outputs different colour conversions are needed, that feature appears
not that far stretched. The user experience will be relatively smooth.

In contrary, a global CM-off will have many side effects, which make
potentially a unwanted user experience for Yuv video, or other widgets,
which should not be affected on desktops. On handheld systems, that is
less of concern.

> In the latter case, it might be better to add another protocol that allows 
> such tools to temporarily deactivate any color conversions...