Feature request: simple tone-mapping for target transfer function conversions

[lvml]

When converting e.g. from SMPTE-2084 input to bt.709 output, some sort of tone-mapping would be extremely valuable for better looking results, as just using contrast/brightness/gamma adjustments loses valuable information.

mpv has (amongst other options) one very well working, simple function implemented for that purpose: The "hable" tone mapping: https://github.com/mpv-player/mpv/blob/f1436658647aceb7ea58e595439fa6dd5c2cdb97/video/out/opengl/video_shaders.c#L388

Would it be possible to add such also for tone-mapping while converting to a different transfer-function in zimg?

[sekrit-twc]

z.lib aims to implement generally accepted industry practices, rather than original research. To my knowledge, there are no standardized tone (or gamut, also needed) mapping methods in the literature. One issue with ST.2084 that I can forsee is the need for scene-specific information, which is not currently expressible in the API (since it would require recalculating curve parameters).

[lvml]

Providing scene specific information, while certainly great for best conversion results, increases production cost significantly, therefore I am not quite sure the existing proposals (like "Dolby Vision") for such will see widespread use. And broadcasters who need to support live material have no way of manually choosing/inserting scene parameters.

But one thing is for sure: There will be displays around for many years to come that do not support anything beyond bt.709. At the same time, there will be an increasing ratio of cameras, recorders, media, that provide HDR videos (without scene-specific information). So the problem of converting from HDR material to ordinary SDR bt.709 displays will stay with us for quite some time.

The results I see from mpv's mapping are quite good - even with a "one parameter set fits them all"-approach ;-)

[sekrit-twc]

Copied from other issue:

"
@sekrit-twc re: “generally accepted practices”, the ITU-R has published a report BT.2390 “High dynamic range television for production and international programme exchange” in which they go over a number of details concerning HDR, including tone-mapping.

In particular, in section 5.4.1, they present a series of equations which they advise using when tone-mapping a HDR signal to a limited brightness range. Since you were looking for any sort of “standard practice”, whatever the ITU-R says is probably a good reference.

(It's perhaps also worth pointing out that the way mpv does tone-mapping is no longer based on the video game curves but derived from scratch using HDR video files and experimentation. It's still ad-hoc and the ultimately result of my own imagination, but it's much higher quality than what we had before)
"

[lvml]

@sekrit-twc: I saw that "mobius" became the default HDR tone-mapping function for mpv. However, when I compare its results with the former default "hable", I much prefer "hable", and the results with "hable" also look much more similar on the same OLED TV to what the TV itself displays when replaying HDR content.
Thus I am sticking with "hable" in my configuration :-)

[kodawah]

there is a guideline for tonemapping by ITU https://www.itu.int/pub/R-REP-BT.2446