On Fri, Mar 1, 2019 at 3:10 AM Pekka Paalanen <ppaala...@gmail.com> wrote: > > On Thu, 28 Feb 2019 18:28:33 -0700 > Chris Murphy <li...@colorremedies.com> wrote: > > > I'm curious how legacy applications including games used to manipulate > > actual hardware LUT in a video card, if the application asked the > > client to do it, in which case it still could do that? > > Hi Chris, > > right now, in no case.
I made a typo. s/client/kernel Or has LUT manipulation only ever been done via X11? > The approach already suggested from my side and other people, that is > encoded in both of the two protocol proposals, is that the client > describes the image content, which allows the compositor to do whatever > the correct transformation is to each display. The client does not need > to do anything per-output (unless it very much wants to). This enables > not just what you mentioned, but also showing the same client pixel > correctly on multiple different outputs at the same time. OK super. > > a. I've already done color management, I *really do* need deviceRGB > > b. display this, its color space is _________. > > Case b) is already in both of the protocol proposals. > > Case a) is in Niels' proposal, but I raised some issues with that. It is > a very problematic case to implement in general, too, because the > compositor is in some cases very likely to have to undo the color > transformations the application already did to go back to a common > blending space or to the spaces for other outputs. Case a) is a subset of the calibration/characterization application's requirement. Even if it turns out the application tags its content with displayRGB, thereby in effect getting a null transform, (or a null transform with whatever quantization happens through 32bpc float intermediate color image encoding), that's functionally a do not color manage deviceRGB path. > > Both types of applications exist. It might very well be reasonable to > > say, yeah we're not going to support use case a.) Such smarter > > applications are going to have to do their color management however > > they want internally, and transform to a normalized color space like > > P3 or Rec.2020 or opRGB and follow use case b.) where they tag all > > content with that normalized color space. > > Right. We'll see. And measurement/calibration/characterisation > applications are a third category completely different to the two > above, by window management requirements if nothing else. It is fair to keep track of, and distinguish a display path with: 1. no calibration and no/null transform; 2. calibration applied, but no/null transform; 3. calibration and transform applied. The calibration application does need a means of ensuring explicitly getting each of those. 1, is needed to figure out the uncorrected state and hopefully give the user some guidance on knob settings via OSD, and then to take meausurements to compute a corrective curve typically going in the video card LUT or equivalent wherever else that would go; 2, is needed to build an ICC profile for the display; and 3, is needed for verifying the path. An application doing color management internally only really needs path 2. Nevertheless, that app's need is a subset of what's already needed by an application that does display calibration and profiling. -- Chris Murphy _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel