[argyllcms] Re: Calibrate to BT.2100 PQ curve?
- From: Niklas Haas <argyll@xxxxxxxxx>
- To: Florian Höch <lists+argyllcms@xxxxxxxxx>
- Date: Sat, 24 Feb 2018 09:50:13 +0100
On Fri, 23 Feb 2018 18:45:34 +0100, Florian Höch <lists+argyllcms@xxxxxxxxx>
wrote:
Hi Niklas,
Am 23.02.2018 um 18:20 schrieb Niklas Haas:
That also raises a question: do we want to calibrate to "raw" PQ (i.e.
anything above the highest supported brightness level gets hard-clipped
to 1.0), or do we want to include some sort of "knee" function to
automatically roll-off the response near the display's peak brightness?
Cue BT.2390, which is an attempt at such a roll-off function (and seems
to work quite well in practice).
My five cents on 1D (desktop) calibration with PQ: It seems not that
useful in a general sense, because operating systems would have to
actively re-encode their graphical widgets into Rec.2020 with PQ (or
rather DCI-P3 encoded with a Rec.2020 container and PQ transfer) before
sending it to a PQ display, otherwise desktop elements could end up much
too bright and color detail clipped. It seems more useful for already PQ
encoded content (= HDR motion video).
Also, even with the roll-off, unless you also do a saturation adjustment
(like the one mandated in BT.2390), the resulting color on screen would
not maintain hue and saturation (as far as possible).
This basically requires a color managed approach that not just involves
shaper curves (and possibly a matrix), but a full 3D lookup table, i.e.
the use of cLUT profiles.
These are all good points. I think I do agree with you that it's
doubtful any UIs will end up natively supporting PQ. If anything, what
we should transition to is a world in which compositing is done in fp16
linear light. Then UI components can remain more or less as they are,
just encoded on a scale from 0.0-1.0 instead of 0-255 and without a
gamma function applied. On the other hand, stuff like PQ or HLG movie
content can be translated to linear, display-referred fp16 by
appropriate shaders and then composited directly onto the same
backbuffer as UI elements.
Only during the final output pass, do we have to make sure to encode our
resulting figure to whatever curve is the most appropriate for the
monitor in question. And honestly, regardless of what the display does,
we can achieve any curve we want here - as long as we have sufficient
effective precision in the LUTs (most likely 10-bit for any HDR display,
but it could even be more bits with the assistance of on-GPU dithering).
Put another way, what we'd essentially be trying to do is calibrate our
displays to a linear light fp16 response so we can use them with fp16
compositing and get a color correct workflow throughout. (Although for
practical reasons I imagine we'd still throw a simple gamma function in
front of the LUT just to space the values better, if this can be
arranged for by the compositing process. Perhaps even PQ, since it
boasts being the most “optimal” such response)
This is also how I believe HDR color management is best done - by
natively supporting e.g. ICC profiles that allow for values above 1.0.
That is, we should continue living in a world in which 1.0 means the
“reference white” (diffuse white), so that SDR and HDR signals can be
directly mixed together, and do any HDR super-highlight information as
values above 1.0.
Attempts at such implementations exist (tooting my own horn here, e.g.
DisplayCAL has the ability to create input cLUT profiles with PQ
transfer function, including roll-off with saturation adjustment, as
well as 3D LUTs in various non-ICC formats, and madVR also has built-in
support for PQ via shaders).
Florian.
mpv supports PQ, BT.2020 and HLG as well. It's actually funny, because
the reason I wanted this feature in ArgyllCMS is so I could
cross-compare my shader-based PQ implementations against an actual PQ
monitor's response in order to verify the correctness of my algorithms.
And for this I need to first calibrate the monitor against PQ.
So while I agree that it may not be that useful for the general public,
it would certainly be useful to developers in exactly this kind of
scenario. OTOH, a hack-patch would serve my needs here - it's just that
I can't figure out how to get argyllCMS to clip out-of-range information
instead of tone mapping (or whatever).
P.s. If you're curious, I would also appreciate whatever insight or
suggestions somebody could offer based on the mpv implementation,
available here:
https://github.com/mpv-player/mpv/blob/master/video/out/gpu/video_shaders.c#L745
Other related posts:
