[argyllcms] Re: Calibrate to BT.2100 PQ curve?

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Tue, 27 Feb 2018 12:53:07 +1100

Niklas Haas wrote:

Hi,

This is true, but I'm implying that the conversion from linear fp16 to
HDR10/PQ can happen inside the GPU hardware. The only real requirement
here is that the GPU accepts fp16 for scanout before color management
/ compositing, which all three vendors (intel, AMD and nvidia) are
working on.

right, but that is a custom setup. For a color management tool
to work out of the box there needs to be standard API's for
accessing calibration settings and ICC profile installation,
and doing fp16 to output pixel translation using the GPU
doesn't have a standard API, unlike setting VideoLUT curves.

What happens *between* the GPU and the display is ultimately of no real
concern, since ArgyllCMS's only job is to tune the parameters exposed by
DRM/X11 in order to achieve a desired end-to-end response (scanout
buffer -> displayed light).

Well, no. The usual situation for display profiling is that
the task is to characterize the native behavior of the display, i.e.
it's response to values fed into cable that attaches it to the computer.
This information is then what's used to create the translation from a
desired response into actual display values. i.e. it could be used
to setup a linear light fp16 space to real-world-display HDR-10
lookup curves, or any other desired 1D or multi-D conversion,
on a per-application and per color source basis.

As an aside, the DRM people are also working
on an API that would expose more of the GPU's capabilities here. Instead
of just the three 1D LUTs, it will be possible to have something more
like 1DLUT -> Shaper Matrix -> 1DLUT, and I believe even a full 3DLUT is
supported by some (recent?) GPUs.

More machinery there isn't necessarily better. Having matrix and/or
3DLUT machinery is only useful in the direction of emulating some other
colorspace in hardware. While this may be useful in certain niches (such as
"proofing" Video output), for a full color managed system this is not at
all desirable since it will limit the available gamut obtainable from
the display. What is desirable is simple per-channel linearisation
(which typically can be performed in more detail by the hardware
lookup tables), and then exposing the full display gamut to
the color management system via an ICC profile. The Color Management
system (which is fundamentally operated at the application level) or
application itself can then do the correct thing in translating any source
colorspace to the display colorspace being held in the frame buffer
in the way it desires.

And I don't see DRM as a suitable level for such APIs, since
applications don't typically do their graphical output via DRM.
Any modern system (i.e. designed or released since the late 90's)
has Color Management APIs that are an integral part of their graphics
system. This includes X11, OS X and MSWindows which all have basic or
advanced Color Management support amongst the same set of APIs used for
graphical output.

With the help of a shaper matrix it
will definitely be possible to even do gamut extension (BT.709 ->
BT.2020) or color conversion (RGB -> YCbCr) during scanout, so whatever
HDR10 formats would be required should be straightforward to support.

You can't expand beyond the native gamut of the display, and to
do real gamut mapping you need to know what the gamut of the display
is at the point of gamut mapping. This is why Color Management is
fundamentally application driven - only the application writer
knows how they want to handle color space conversions. A modern graphics
API makes color handling of simple applications easy, and
demanding applications and color setup tools possible.

This is very true. PQ is not a very well-designed format for exactly
those reasons, and most HDR10 implementations I have seen have been
nothing but lacking. In particular, I would expect every HDR monitors to
support a brightness/contrast control, which would allow multiplying the
outgoing signal (in linear light) before displaying it on-screen. Sadly,
implementors disagree, leaving my retinas very unhappy.

The key point (illustrated in Rec.2390 section 1.3) is that there is a level
in the dynamic range in which it is necessary to handle real world display
and viewing conditions differently. This is somewhere around diffuse white.
Below that point there may be black level, gamut/contrast adjustment and
brightness accommodation, but within that a high degree of fidelity of
reproduction is desired. Above that level it is necessary to be more
ruthless in compressing and/or clipping and/or spreading highlights or
emissive levels, to accommodate the maximum brightness a display is capable of.

Having a well known encoding level as this break point helps both
display makers and content makers. Content makers have more certainty
about how their material will be displayed and how it will change with
different maximum brightness, and display makers know what the range
of adjustments they can make without fundamentally changing how media
is intended to be displayed.

That aside, a careful reading of the specs (to me) implies that the
standard reference / diffuse white is specified as 100 cd/m², in
particular for PQ signals. [1] So I don't believe there is any user-facing
ambiguity here. You could consider an alternative (but equivalent)
definition of PQ in which all of the EOTF outputs are divided by 100. In
this formulation, PQ now appears like a relative encoding (similar to
the other logarithmic transforms out there, including HLG), with a value
of 520 (10-bit) mapping to the signal level 1.0. This is how e.g. mpv
treats PQ signals.

I'm no longer sure. I haven't taken a deep dive into the (ever expanding)
literature on the state of HDR for a while. If I had a display to play
with I might be tempted to do so again.

[1] For evidence of this, see e.g. the definition of the PQ OOTF, which
    is based on an extension of the BT.709/BT.1886 OOTF as centered
    around a diffuse white of 100 cd/m². More explanations of this is
    provided in e.g. Rep BT.2390, and various other ITU-R et al.
    documents all citing a value of 100 cd/m^2 as the SDR diffuse white,
    and treating the PQ dynamic range to be an extension of this, rather
    than redefinition.

I get the impression that's driven from the BBC end (i.e. WHP 283), which
seems to take a more realistic view of things.

Yes, the use of PQ is very inconsistent. In essence, PQ alone doesn't
tell you anything about the actual signal peak, much like fp16 encoding.
Without additional information about what the peak white of the signal
is expected to be, tone-mapping it is difficult. (In practice, the
metadata is also completely useless and both displays and video players
have to resort to detecting it in realtime for high quality results).

As soon as things go dynamic, static Color Management becomes pretty
useless. The only way it could help is if there were API's to tell
the dynamic code what the actual response of the display is.
Ideally there should also be ways of turning dynamic processing
off, so that static Color Management can be used, or software
(and hence accessible) dynamic processing used instead.

The spec also sort of assumes that displays will be responsible for
performing this tone-mapping, a concept which I find sort of ridiculous.
(The past 15 years of personal experience has taught me that display
firmware programmers are among the most inept programmers out there.
I would much rather trust software to do this, which can be done in a
controllable way)

Yep.

I think ultimately, a compositor would be the best component in charge
of establishing a consistent output, using software. For example, in my
ideal world, the compositor might do the following:

1. Accept a linear FP16 BT.709 buffer from client A, tagged with peak 12.0
   and gamut BT.709
2. Accept a 10-bit PQ BT.2020 buffer from client B, tagged with peak 6.0
   and gamut DCI-P3
3. Accept an 8-bit BT.1886 BT.709 buffer from client C (SDR)

That works for standard Video sources, but not in general. In general
an application needs access to the native display space so that it
can setup the color management the way it needs.

Then it would go ahead and mix those into the same backbuffer, by
transforming them to some reference colorspace (e.g. linear fp16
BT.2020, or scRGB or whatever) while simultaneously tone-mapping to the
display peak and gamut if necessary. This can be handled by a
content-specific 3DLUT, which can be generated based on an ICC profile
or set of ICC profiles.

As a mechanism that's fine, but there is no need or desirability that
the buffer be in a standard space - it should be the native display space.
This eliminates double conversion with all the speed and fidelity
problems it introduces. Naturally the application should be able
to render directly to the display space if it wants too.

Finally, the GPU would, as part of scanout, encode this to whatever
signal the display expects (e.g. 10-bit BT.2020 PQ) with constant HDR10
metadata and calibration curves that are generated by ArgyllCMS in order
to make the end-to-end response from the fp16 backbuffer to the light
on-screen as linear as possible. (Or alternatively: make the output of
the scRGB backbuffer closely follow the desired curve, matching the one
used by the compositor during compositing)

You seem to be assuming that all this is linear light. That's
not perfectly true in practice, so for highest precision you can't
use 1D luts and 3x3 matrices. Instead 3D Luts are needed, and they have
their drawbacks :- memory, speed, smoothness. You don't want to
be throwing them around with multiple conversions. Ideally
you want to have a single 3D Lut conversion at the most in
the rendering pipeline from source colorspace to display colorspace.

Unfortunately, I can't recommend any devices at the moment. They're all
complete garbage from what I've seen, and most of them don't even
implement the HDR10 spec properly.

The one that's caught my eye at the moment is the DELL UP2718Q.
<https://pilot.search.dell.com/up2718q>
Not sure how well it does in practice of course.

Fair enough. It's also worth pointing out that the ITU-R (and others)
have also somehow managed to disagree about how floating point
representations are supposed to work. For example, they seem to think
that encoding a 1.0 is supposed to mean a signal level of 1 cd/m^2,
which I find ridiculous. Clearly, 1.0 would be the display's diffuse
white. But alas.

Hmm. It could be both though - Absolute encoding vs. Relative encoding.

P.s. If we're going to drift on a tangent about HDR display calibration
in general, the most pressing issue is actually the question of what
surface area to use as the test patch. The issue is that all current HDR
displays suffer from the issue that they cannot physically reproduce the
full brightness spectrum across the whole display (nor, honestly, should
they be able to). So while they might be able to hit a 2000 cd/m^2 peak
white for a few pixels, they can't do that for the entire 55" surface
area.

I'm surprised - most software has a capability of setting test patch
size.

The only realistic work-around for the time being would be to agree on
some standard observer (10°?) and calibrate exactly that screen area, and
ignore the fact that larger or smaller areas might appear brighter or
darker than calibrated...

That's the only practical approach. I'd imagine that even characterizing
a displays dynamic maximum white level would be highly problematic,
(in some cases being time as well as area based), so that trying to
create a mapping algorithm to deal gracefully with the limit doesn't
even have a place to start ...

Honestly it's a gigantic mess, and I personally hope HDR either dies a
horrible death or display hardware improves significantly (no dynamic
contrast / dynamic backlight BS, just straight up static contrast using
e.g. OLEDs or MLEDs). We might just have to accept the fact that we
can't calibrate HDR displays until that happens.

Agreed that it needs to improve. It has all the hallmarks of being
rushed to market.

Cheers,

Graeme Gill.



Other related posts: