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

[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?
In the latter case, it might be better to add another protocol that allows 
such tools to temporarily deactivate any color conversions...