[argyllcms] Re: Calibrate to BT.2100 PQ curve?
- From: Florian Höch <lists+argyllcms@xxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Fri, 23 Feb 2018 18:45:34 +0100
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.
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.
Other related posts:
