On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone <dan...@fooishbar.org> wrote: > Hi Graeme, > > On 17 December 2016 at 10:16, Graeme Gill <grae...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
