HDR support in Wayland/Weston

[Chris Murphy]

On Thu, Feb 28, 2019 at 2:35 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Wed, 27 Feb 2019 13:47:07 -0700
> Chris Murphy <lists at colorremedies.com> wrote:
>
> > On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > >
> > > there is a single, unambiguous answer on Wayland: the compositor owns
> > > the pipeline. Therefore we won't have the kind of problems you describe
> > > above.
> > >
> > > These are the very reasons I am against adding any kind of protocol
> > > extension that would allow a client to directly touch the pipeline or
> > > to bypass the compositor.
> >
> > Well you need a client to do display calibration which necessarily
> > means altering the video LUT (to linear) in order to do the
> > measurements from which a correction curve is computed, and then that
> > client needs to install that curve into the video LUT. Now, colord
> > clearly has such capability, as it's applying vcgt tags in ICC
> > profiles now. If colord can do it, then what prevents other clients
> > from doing it?
>
> Hi Chris,
>
> there is no need to expose hardware knobs like LUT etc. directly in
> protocol even for measuring. We can have a special, privileged protocol
> extension for measurement apps, where the measuring intent is explicit,
> and the compositor can prepare the hardware correctly. This also avoids
> updating the measurement apps to follow the latest hardware features
> which the compositor might be using already. An old measurement app
> could be getting wrong result because it didn't know how to reset a new
> part in the pipeline that the compositor is using.
>
> Hence the compositor owns the pipeline at all times.
>
> Permanently setting the new pipeline parameters is compositor
> configuration - you wouldn't want to have to run the measurement app on
> every boot to just install the right parameters. Compositor
> configuration is again compositor specific. The privileged protocol
> extension could have a way to deliver the new output color profile to
> the compositor, for the compositor to save and apply it with any
> methods it happens to use. You cannot assume that the compositor will
> actually program "the hardware LUT" to achieve that, since there are
> many other ways to achieve the same and hardware capabilities vary.
> Nowadays there is often much more than just one LUT. Furthermore, in my
> recent reply to Niels' color management extension proposal I derived a
> case from the proposal where a compositor would be forced to use an
> identity LUT and instead do all transformation during rendering.
>
> Colord is not a client. Colord is currently called from a
> weston plugin, the plugin has access to the compositor internal API to
> set up a LUT. Colord cannot do it on its own.

That all seems reasonable.

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?

Also I'm curious about the multiple display use case. I think it's
quite a lot to ask a client to know about multiple transforms for
multiple displays and which pixels to transform and how, based on
which display those pixels are currently displayed on, and then
somehow to intelligently cache this so it doesn't bog down the whole
system. A use case in particular I'm thinking of is Firefox, where you
really don't want to have to constantly do transforms of everything,
every time a pixel scrolls away and vanishes, but when it reappears
it's reappearing on a different display. And also you'd want the pixel
to look correct from the very instant it appears on a different
display and is correct upon appearing back on the original display or
even looks correct in a split/mirrow window scenario, laptop display +
projector.

At least on macOS and for the most part Windows, most applications
aren't color management aware, and just assume deviceRGB color for
everything; and at least on macOS by default, and Windows as an
option, it's possible for the window manager to substitute what is
really "legacy deviceRGB" for sRGB as an intermediate space and from
there properly do display compensation for pixels on whatever display
they appear on. Ergo, a display calibration app does need a way to
announce its ability so that its test chart isn't being assumed to be
sRGB (or whatever), and a smarter color managed application needs a
way of saying one of two things:
a. I've already done color management, I *really do* need deviceRGB
b. display this, its color space is _________.

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.

And all of this has an equivalent path and transform for printing, and
how to get sane output whether displayed or printed for the same
content.

-- 
Chris Murphy