HDR support in Wayland/Weston

[Chris Murphy]

On Fri, Feb 1, 2019 at 3:43 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Thu, 31 Jan 2019 12:03:25 -0700
> Chris Murphy <lists at colorremedies.com> wrote:
>
> > I'm pretty sure most every desktop environment and distribution have
> > settled on colord as the general purpose service.
> > https://github.com/hughsie/colord
> > https://www.freedesktop.org/software/colord/
>
> FWIW, Weston already has a small plugin to use colord. The only thing
> it does to apply anything is to set the simplest form of the gamma
> ramps.

Short version:
Having just briefly looked that code, my best guess is colord is
probably reading a vcgt tag in the ICC profile for the display, and
applying it to the video card LUT (or one of them anyway).

Super extra long version:
In ancient times (two decades+) there was a clear separation between
display calibration (change the device) and characterization (record
its behavior). Calibration was a combination of resetting and fiddling
with display controls like brightness and contrast, and then also
leveraging the at best 8 bit per channel LUT in the video card to
achieve the desired white point and tone curve per channel.
Characterization, which results in an ICC profile, happens on top of
that. The profile is valid only when the calibration is applied, both
the knob fiddling part and the applicable LUT in the video card. The
LUT information used to be kept in a separate file, and then circa 15
years ago Apple started to embed this information into the ICC profile
as the vcgt tag, and the operating system display manager reads that
tag and applies it to the video card LUT prior to login time. This has
become fairly widespread, even though I'm not finding vcgt in the
published ICC v4.3 spec. But they do offer this document:
www.color.org/groups/medical/displays/controllingVCGT.pdf

There are some test profiles that contain various vcgt tags here:
http://www.brucelindbloom.com/index.html?Vcgt.html

You really must have a reliable central service everyone agrees on to
apply such a LUT, and then also banning anything else from setting a
conflicting LUT. Again in ancient times we had all sorts of problems
with applications messing around with the LUT, and instead of reading
it first and restoring it the same way, they just reset it to some
default, thereby making the ICC profile invalid.

The primary reason, again historically, for setting the white point
outside of software (ideally set correctly in the display itself; less
ideal is using a video card LUT) is because mismatching white points
are really distracting, it prevents proper adaptation, and therefore
everything looks wrong. Ironically the color managed content is
decently likely to look more wrong than non-color-managed content. Why
would there be mismatching white points? Correct white point fully
color managed content in an application window, but not any other
application or the surrounding UI of the desktop environment.

Ergo, some kind of "calibration" of white point independent of the
color management system. Sometimes this is just a preset in the
display's on-screen menu. Getting the display white point in the ball
park of target white point means a less aggressive LUT in the video
card, or even ideally a linear LUT.

Alternatively, you decide you're going to have some master of all
pixels. That's the concept of full display compensation, where every
pixel is subject to color management transforms regardless of its
source application, all normalized to a single intermediate color
space. In theory if you throw enough bits at this intermediate space,
you could forgo the video card LUT based calibration.

The next workflow gotcha, is multiple displays. In designing a color
management system for an OS you have to decide if applications will
have the option to display across multiple displays, each of which
could have their own display profile.

I agree with Graeme that having different pipelines for calibration or
characterization is asking for big trouble. The thing I worry about,
is whether it's possible for each application to effectively have
unique pipelines because they're all using different rendering
libraries. The idea we'd have application specific characterization to
account for each application pipeline just spells doom. The return of
conflicting video card LUTs would be a nightmare.

--
Chris Murphy