Hi Chris, On 20 December 2016 at 18:11, Chris Murphy <li...@colorremedies.com> wrote: > On Tue, Dec 20, 2016 at 10:02 AM, Daniel Stone <dan...@fooishbar.org> wrote: >> On 17 December 2016 at 10:16, Graeme Gill <grae...@argyllcms.com> wrote: >>> 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.
Right: 'ensure whitepoint consistency' is an entirely worthwhile goal, and I think everyone agrees on the point. 'Give clients absolute control over display hardware LUT + CTM' is one way of achieving that goal, but not a first-order goal in itself. The reason applications can't drive the LUT is because, as you say, there's not always just one. If there were only one application, then why not just write directly to KMS? There's little call for a window system in that case. > 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. I agree that there's 'no such thing as an opt in', and equally that there's no such thing as an opt out. Something is always going to do something to your content, and if it's not aware of what it's doing, that something is going to be destructive. For that reason, I'm deeply skeptical that the option is routing around the core infrastructure. As arguments to support his solution, Graeme presents a number of cases such as complete perfect colour accuracy whilst dragging surfaces between multiple displays, and others which are deeply understandable coming from X11. The two systems are so vastly different in their rendering and display pipelines that, whilst the problems he raises are valid and worth solving, I think he is missing an endless long tail of problems with his decreed solution caused by the difference in processing pipelines. Put briefly, I don't believe it's possible to design a system which makes these guarantees, without the compositor being intimately aware of the detail. This doesn't mean that every input pixel must be sRGB and the compositor / GPU / display hardware must transform every pixel, but that the compositor needs to be, at a minimum, aware. Again, I think everyone agrees that the perfect case for deeply colour-aware applications, is that they present content in such a way that, in the ideal steady state, it can be presented directly to the display with a NULL transform. > 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. It isn't a panacea though. It is one way to attack things, but if your foundational principle is that the display hardware LUT/CTM never be out of sync with content presented to the display, then my view is that the best way to solve this is by having the LUT/CTM be driven by the thing which controls presentation to the display. Meaning, the application is written directly to KMS and is responsible for both, or the application provides enough information to the compositor to allow it to do the same thing in an ideal application-centric steady state, but also cope with other scenarios. Say, if your app crashes and you show the desktop, or you accidentally press Alt-Tab, or you get a desktop notification, or your screensaver kicks in, or, or, or ... It seems to me like Niels's strawman was a reasonable foundation on which you could build a protocol which allowed this. Namely, in the ideal steady state, the app would have _effective_ control of the LUTs/CTM. But being mediated by a colour-aware compositor, the compositor would also be able to deal with states other than the application's perfect state, without destroying the user's whitepoint adaptation. It's difficult, but I think also a worthwhile goal. tl;dr we agree on goal but not implementation detail Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel