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

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Wed, 28 Feb 2018 12:23:23 +1100

Niklas Haas wrote:

Hi,

Hang on - doesn't ArgyllCMS usually profile the display *after* loading
the 1DLUTs? Because in doing so, the 1DLUTs (which are part of the GPU's
scanout logic) effectively become an extension of the display hardware.
(Much like the use of additional shaper matrices during scanout would)

Yes and no. If they are accessible, ArgyllCMS uses the per channel
VideoLUT hardware extensively to access the full output bit depth to
the display by generating test sample specific curves. Typically
dispcal is used to create display calibration curves that set white
point and linearize the display response, and then of course the
calibration curves will be loaded in the HW for subsequent
profiling. If calibration is not desired, then either the existing
VideoLUT curves can be left in place, or the VideoLUT is bypassed
(by loading test sample specific curves) to profile the display
to the highest available precision.

This is true, I was just thinking about the problem in terms of direct
fp16 scanout from a “reference” color space.

That's a reasonable approach for a particular application, but not the system
in general. With the display characterization available via an ICC profile,
an application can setup the conversion from a reference color space
of its choice to the actual display output.

The only important DRM change here would be the ability to set
(arbitrary) HDR10 metadata so that the display is put into HDR mode if
needed.

That would certainly be highly desirable for dealing with HDR displays!

The main problem with HDR in practice is actually more so the fact that
many scenes (both artificial and natural) defy the expectations set
forth by the actual theory behind HDR. Sure, in theory, the scene should
remain mostly in the range 0-100 cd/m^2 with only specular/emmissive
highlights exceeding that range. But then somebody points a camera at
the daylight sky and suddenly you get an image where 70% of the frame is
dominated by a very bright blue sky, vastly exceeding the 100 cd/m^2
range, and the viewer's eyes start bleeding.

Right, but one can't expect a high degree of fidelity in reproducing
such an image if it exceeds the display maximum power and/or light
level. So any mastered media should avoid such content if it is
intended to be displayed in a predictable way.

In principle, the mastering engineer is required by the specification to
tone-map this bright scene as if it were an SDR scene, while allowing
only highlights to exceed the standard range. But if this is the case, I
have yet to come across a HDR sample that is well-mastered.

Ugh. The usual problem then, of a new display feature where the
director can't help but shove it directly in your face, same
as "3D" (i.e. stereoscopic) cinema, same as when stereo sound
was introduced. Lack of subtlety is a fast way of killing HDR off.

In practice, I work around this by detecting the overall scene
brightness, and if this significantly exceeds the average SDR scene (a
cutoff point of ~25 cd/m^2 works well here), I scale the overall
contrast of the scene such that it retains the usual range. This is by
far the most important step of the tone mapping algorithm I implemented
in mpv, and relies entirely on detecting the scene brightness
dynamically (since the static MaxCLL/MaxFALL metadata is virtually
useless in every test clip I've seen). This algorithm makes outdoor
scenes in HDR samples actually look natural again, and allows us to use
sophisticated tone-mapping curves that are designed to preserve in-gamut
material while tone mapping only highlights without completely
distorting such scenes as a result.

Right, so you need to setup a automatic adjustment algorithm to
do the job that the Colorist should have done while mastering!

That said, even if mastering engineers were to follow the specs, there
are still environments in which the standard 0-100 cd/m^2 range is
uncomfortably bright. I especially run into this problem in dim viewing
environments, where I have to reduce the overall image brightness to
around 50-70 cd/m^2 in order to continue comfortably viewing the image
for extended durations.

Right - overall brightness scaling needed to suite the viewing conditions.

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.

Yes and no. I mean, the bottom line here that I was trying to illustrate
is that what colorspace you encode an image in (e.g. BT.2020) does not
necessarily have anything to do with what color gamut the image actually
contains (e.g. DCI-P3).

Sure - this is a known issue with large gamut encodings.
P3 won't define the image gamut either, unless the Colorist
has expanded the image palette to fill it.

For static images ArgyllCMS has long supported per-image gamut mapping
as a solution. There seems to be chatter about supporting per
frame gamut information for video imagery, but crafting a real time
gamut mapping algorithm that is any better than something static
is non-trivial. Pure luminance compression/tone mapping is far, far simpler.

But I agree, in general, a mode for "native passthrough" would
be a good thing to provide - with the heavy emphasis that this should
under no circumstances be the default behavior for clients with unknown
color space.

It's a matter of how built-in a systems Color Management is. If you
arrange the graphics API so that unlabelled "RGB" is assumed to
be something sane (like sRGB), then people writing non-color
critical applications can ignore the issue. But color managed
applications and color management tools need more control,
including specifying colors in tagged, device independent
and native color spaces, and being able to dictate the finest
details of how color space conversions are performed, as well
as how the display pipeline color/tone handling is configured.

This is a good point. I was mostly thinking about the fact that linear
fp16 allows for much higher quality blending than trying to do those in
the monitor's native color space, especially for something as nonlinear
as PQ.

Yes. Which is why it's good that an application that wants to do
extensive linear light blending should be able to setup buffers
in a linear light space, and have them appropriately color
managed when sent to the display.

The UP2718Q is the one I'm currently sitting in front of, but to call it
a HDR display is borderline false advertising. I basically got it
because it's a decent SDR display that also happens to sort of allow
emulating HDR. It has too many flaws to list, but the most notable ones:

- The Full-Array Local Dimming (FALD) implementation is absolutely
  awful. It only uses 384 zones, which is several orders of magnitude
  below what is needed to actually separate highlights from specular
  regions. So as a result, it would never be able to display HDR
  material correctly, since the local contrast everywhere is still only
  1000:1.

But do they have to be perfectly separated ?
Flare and glare near a highlight should conceal loss of
black level near highlights to a large degree.

- While the FALD is active, you cannot change the brightness controls at
  all. This makes no sense; and I cannot calibrate it to a 100 cd/m^2
  target if it insists on going up to the maximum brightness (>400) on
  pure white signals without incurring significant dynamic range losses
  in the LUT. (And it doesn't help me at all when using a device other
  than my computer as the signal source)

Right, but isn't that merely the issue that the GUI isn't color
managed ? If it was, then all normal (non HDR) content would
remain at 100 cd/m^2 (or whatever the setting is in translating
sRGB into HDR) ?

- The FALD control logic uses a very large averaging window (~1 second
  long), which causes the backlight to trigger brightness changes with a
  significant delay. They also don't implement any thresholding for
  resetting this buffer in the event of a sudden drastic brightness
  change, so going from a bright scene to a dark scene leaves ~1s of
  weird-looking glows randomly on the screen. Also, all moving objects
  leave trailing halos behind them as the backlight slowly turns on and
  off. They most likely implemented this to combat flicker (which would
  be a natural consequence of adjusting the backlight intensity per
  frame).

Wow - that sounds like a terrible implementation. The demo I saw
some years ago of a Brightside display seemed to use instantaneous
back-light adjustments, and was relatively seamless. I would
have expected the technology to have improved since then, not
got worse! (Maybe DELL are simply incompetent in their
implementation ?)

tl;dr it's not a HDR display, and if judges understood display tech you
could probably sue them for advertising it as such. Until we get either
OLED, MLED, QLED or whatever per-pixel HDR implementations that can
actually hit a 100k:1 static contrast, HDR is just plain out of the
picture. And the only useful effect of the FALD (getting rid of IPS glow
on dark scenes) is wasted on the fact that it also makes bright scenes
way, way too bright.

Doesn't match what I know of/saw in the Brightside implementation.

Right, but users still need to make that choice. And an insufficiently
well-informed user might assume that it makes no difference, whereas for
a HDR display, it certainly does.

It's pretty well understood in the Video calibrator world - Plasma, OLED
and HDR are all known to have area brightness limiters.

Cheers,
        Graeme Gill.

Other related posts: