HDR support in Wayland/Weston

[Chris Murphy]

On Fri, Mar 1, 2019 at 3:10 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Thu, 28 Feb 2019 18:28:33 -0700
> Chris Murphy <lists at 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