[argyllcms] Re: Calibrate to BT.2100 PQ curve?
- From: Niklas Haas <argyll@xxxxxxxxx>
- To: Graeme Gill <graeme@xxxxxxxxxxxxx>
- Date: Tue, 27 Feb 2018 06:55:58 +0100
On Tue, 27 Feb 2018 12:53:07 +1100, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
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.
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)
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.
This is true, I was just thinking about the problem in terms of direct
fp16 scanout from a “reference” color space. But after re-considering
your other points, I think I agree with you that there's no compelling
reason not to just composite in the monitor's native color space so
there's no additional scanout logic needed. a method that requires only
changes in the compositors and display protocols, and not of the
underlying DRM subsystem.
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.
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.
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.
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.
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.
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. A subjective contrast control is always needed
to account for viewing environment factors such as those. (Fortunately,
this can at least partially be solved via calibration, but that only
helps you if the device you're trying to generate a signal with supports
custom calibration curves)
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 problem with static metadata is that it can't apply to the whole
file, and the data I'm interested in (MaxFALL and MaxCLL) only applies
to the brightest scene in a file. But a movie has many scenes. Knowing
the metadata of a bright outdoors scene does not help you tone-map an
indoors scene that comes after it. Ideally, what I would like to have is
per-scene metadata describing the color volume and brightness range of
that scene, so I can fine-tune the tone mapping algorithm for that scene
while still having it remain static (so the viewer does not notice any
unpleasant "eye adaptation"-like effects as e.g. bright objects pass
through the frame).
In practice, this metadata is absent, which means we're forced to detect
it dynamically - usually in realtime (e.g. in the case of a video player
or display firmware that needs to tone-map each frame as it gets
displayed), and then they also need to care enough to implement scene
change detection logic.
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). If a color managed application such as an image
viewer or video player wants to do its own color management, it can
still embed the result into BT.2020+PQ - it just needs to set the
appropriate metadata (color volume / brightness range) to be the same as
the display's capabilities so that the compositor's tone mapping becomes
a no-op. 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.
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.
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. So it may be the case that a compositor with support for
transparency needs to go through a linear light intermediate step one
way or the other, in which case it could benefit from using fp16 scanout
and out-sourcing the conversion back to the monitor's native color space
to the GPU's LUTs/matrices.
But especially in the short term, and for people who don't care about
transparency effects (useless eye-candy!), doing compositing directly in
the display's color space is going to be the simplest, easiest and most
compatible course of action.
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.
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.
- The FALD makes bright regions of the screen even brighter than their
100 cd/m^2 target (up to ~400 cd/m^2 in practice), which is just way
too bright and hurts the eyes. They should have left the brightness
capped at the normal 100 cd/m^2 (or whatever the user gave as their
'brightness' setting) and only used the dynamic lighting for dark
regions to get rid of IPS glow. Then it would at least be sort of
useful. As it stands, you basically have to turn it off.
- 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)
- 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).
- Either my PS4's or the display's PQ implementation is just plain
wrong, and you can't hardware-calibrate it either. (The hardware
calibration feature only works for traditional SDR modes with the FADL
disabled). Everything looks gray and washed out, almost as if one
device was generating limited range while the other expected full. So
as a result, the HDR mode also seems useless (for the only device that
uses it) and the only way to get “HDR” out of it is to enable the FALD
in SDR mode.
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.
I'm surprised - most software has a capability of setting test patch
size.
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.
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 ...
For FALD implementations in particular, the sanest thing to do is
actually probably to calibrate over the entire range of the display.
Individual highlights may appear brighter than intended, which is sort
of the design goal of HDR. It's probably better than the inverse
(outdoor scenes appearing darker than intended)
Other related posts:
