[RFC wayland-protocols] Color management protocol

[Chris Murphy]

On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi Graeme,
>
> On 17 December 2016 at 10:16, Graeme Gill <graeme2 at argyllcms.com> wrote:
>>> then no need for any extension. :) compositor HAs to be involved to at
>>> least
>>> tell you the colorspace of the monitor... as the screen is its resource.
>>
>> As I've explained a few times, and extension is needed to provide
>> the Output region information for each surface, as well as each
>> outputs color profile, as well as be able to set each Outputs
>> per channel VideoLUT tables for calibration.
>
> That's one way of looking at it, yes. But no, the exact thing you're
> describing will never occur for any reason. If you'd like to take a
> step back and explain your reasoning, as well as the alternate
> solutions you've discarded, then that's fine, but otherwise, with a
> firm and resolute 'no, never' to this point, we're at a dead end.

We can't have multiple white points on the display at the same time;
it causes incomplete user adaptation and breaks color matching
everywhere in the workflow. The traditional way to make sure there is
only one white point for all programs is manipulating the video card
LUTs. It's probably not the only way to do it. But if it's definitely
not possible (for reasons I'm not really following) for a privileged
display calibration program to inject LUT data, and restore it at boot
up time as well as wake from sleep, then another way to make certain
there's normalized color rendering on the display is necessary.

The holy grail is as Richard Hughes describes, late binding color
transforms. In effect every pixel that will go to a display is going
to be transformed. Every button, every bit of white text, for every
application. There is no such thing as opt in color management, the
dumbest program in the world will have its pixels intercepted and
transformed to make sure it does not really produce 255,255,255
(deviceRGB) white on the user display.

The consequences for a single dumb program, for even 2 seconds,
showing up on screen with 255,255,255 white on an uncalibrated display
is the user's white point adaptation is clobbered for at least 10
minutes, possibly 30 or more minutes. And it doesn't just affect the
other things they're viewing on the display, it will impact their
ability to reliably evaluate printed materials in the same
environment.

So the traditional way of making absolutely certain no program can
hose the workflow is this crude lever in the video card. If you can
come up with an equivalently sure fire reliable s that doesn't demand
that the user draw up a list of "don't ever run these programs" while
doing color critical work, then great. Otherwise, there's going to
need to be a way to access the crude calibration lever in the video
card. Even though crude, this use case is exactly what it's designed
for.


-- 
Chris Murphy