HDR to SDR

[kodawah]

Hello,
not sure if this is a question, feature request or if I'm just doing something wrong. I'm trying to convert an HDR video (smpte2084, with mastering display and color volume side data availabe) to SDR, either bt709 or bt601. Right now I got an hacky solution working, which consists of converting PQ to HLG and then just use the "backward compatible" features of HLG to display SDR.

However I also tried fiddling with the nominal_peak_luminance and the approximate_gamma parameters to be in control of the conversion, and found that (manually) choosing a good peak luma gives considerable results, without clipping artefact mentioned in another thread.

So I guess my questions are:

• is it still valid that zimg can only do HDR2HDR or SDR2HDR (and not viceversa)
• do you know if there is a way to automatically select a good peak luma? I was hoping I could reuse a parameter from the mastering display side data
• does disabling approximate gamma computation help for this task?

Thank you for any insights you can give (and for releasing zimg source code)

[sekrit-twc]

If you set nominal_peak_luminance to a value greater than the peak luminance level in the image, you obviously will not encounter clipping. However, the relative luminosity of specular and diffuse white will be wrong, and there is no method in z.lib to handle this. Approximate (LUT-based) gamma calculation should not cause clipping on images that are not already out of range. The ST.2086 metadata is unfortunately not very helpful in setting conversion parameters, as MaxCLL/MaxFLL are only useful for estimating display power consumption.

Incidentally, the "backward compatibility" of HLG still causes an HDR image to be washed out, since it sets the diffuse white at code value 0.5, which is only 19% physical brightness when interpreted as BT.1886. To retain contrast, a more aggressive compression of the highlights would be needed on a SDR display. The "right" mapping of an HDR image to SDR is not really a scientific topic, since the best interpretation of the scene (and hence the compression curve) depends on what aspects of the scene are to be emphasized.

[kodawah]

Point taken regarding the backward compatibility of HLG, but while theoretically correct when you say hdr->sdr is not a scientific topic, there should be some way of intervention for the user.

For example, the video player mpv exposes a tone-map functionality, allowing to set a default luminance of the display. The algorithm works so that even if the conversion would result clipped, it would still be possible to renormalize the color values within the range of a relative SDR brightness. Do you think this could be an interesting addition to libzimg?

[haasn]

We've actually gone over this before in the context of zimg, see #60 and #61. In fact this issue is probably a duplicate of #60.

[sekrit-twc]

The tone map operators in mpv are quite poor in quality, since they are derived from the Video Game Industry. As noted in #60, z.lib aims to implement generally accepted practices and not original research. My intuition is that (a) z.lib is not a media player, (b) a visually satisfying conversion of HDR to SDR should be done in a video editor, possibly on a per-scene basis, and (c) is likely not a mere compression curve.

[kodawah]

I see your points, thanks for the explanations and help provided.

[haasn]

@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)

[kodawah]

@haasn that document is quite interesting, thanks for posting