Experimenting with HLG and HDR10 for still images

Entropy512 · February 10, 2021, 10:52pm

Regarding the previous post’s mention of zscale for transfer curve transforms - I dug up my old ffmpeg commands and that’s exactly it.

ffmpeg -loop 1 -r 24 -t 30 -i DSC02708_03.tif -vf pad=1438:2160,zscale=tin=linear:t=arib-std-b67:m=bt2020nc,format=yuv420p10le,pad=3840:2160:1200:0:black -c:v libx265 -preset medium -crf 26 -x265-params "colorprim=bt2020:atc-sei=18:colormatrix=bt2020nc" antelope.mp4

Many TVs become unhappy at unusual/unexpected aspect ratios, which was the reason for the padding tricks. Note that the example above doesn’t use npl - I’m 90% certain you do need to tweak the npl option to get desired results as I believe the default is 100 - e.g. it maps the peak brightness in the TIF to 100 nits which is NOT what you want, I haven’t had time to revisit these efforts other than pulling up some really old command examples so far.

The input TIF was, at the time, a linear TIFF saved from darktable in the Rec.2020 colorspace. I’ll be revisiting this using RT instead sometimes soon (maybe this weekend?). I can’t remember if I scaled the image to be 2160 pixels high prior to saving it out or not.

Also note that ffmpeg in most distributions is not built with zscale enabled as the ZIMG library is not packaged in many distributions, you’ll need to build from source.

Entropy512 · February 11, 2021, 12:45am

OK, here’s the TIF and resulting video from a more recent attempt.

Command line was:
ffmpeg -loop 1 -r 24 -t 30 -i DSC02236.tif -vf pad=3840:2160:302:0:black,zscale=tin=linear:t=arib-std-b67:npl=800:m=bt2020nc,format=yuv420p10le -c:v libx265 -preset medium -crf 26 -x265-params "colorprim=bt2020:atc-sei=18:colormatrix=bt2020nc" naturalbridge.mp4

DSC02236.tif (33.2 MB)

Pixls mangled the MP4, reuploading in a zipfile…

naturalbridge.zip (2.8 MB)

This MP4 file triggers HLG mode when casted to a Vizio P65-F1 using the LocalCast app on Android. Playback via USB should work too?

anon66851888 · February 11, 2021, 7:33am

Yes, that was the point

That’s exactly what we are doing here

Thank you very much, seems to work on my tv too. Now let me do some testing

st599 · February 11, 2021, 10:16am

To further help with experimentation, there’s an interesting report on the ITU website: https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-3-2019-PDF-E.pdf

Tables 1 and 2 show the expected signal levels for reference (18% greycard, greyscale charts etc.) and non-reference items (various skin tones, grass etc.)

They should allow you to adjust the levels in your image to the levels expected in the standard.

kmilos · February 11, 2021, 10:53am

Yep. My -1.36 EV compensation was just one “dumb” way to target 21.4% (0.5 of sRGB) for a quick demo, there are many other options depending on one’s needs and preferences.

anon66851888 · February 11, 2021, 11:17am

Ok, it definitely works. @Entropy512 I’m not really familiar with ffmpeg, so maybe you can help here

If we downscale the images in a raw converter rather than when running this command, we can remove pad=3840:2160:302:0:black, right?
Do we need to specify npl for HLG?
What should we change if we want lossless encode? --lossless for x265?

Thanks again

anon66851888 · February 11, 2021, 11:17am

Also, if someone wants to try this, keep in mind that ART’s and RT’s linear curves are the gamma-corrected curves, so we may need gamma 2.2 rtc from this post Linear gamma preview in RawTherapee - #7 by Morgan_Hardwood or use Darktable

Entropy512 · February 11, 2021, 11:29am

Only if you do cropping to get to a 16:9 aspect ratio. If your camera shoots a typical 3:2 aspect ratio, you need to pad out the sides. In this case, I already downscaled to 2160 pixels high in my converter, but that means the input image was only 3236 pixels wide, not 3840. So I pad it to 3840 wide with a black background, offsetting it by 304 pixels from the left to center it. (304 = (3840-3236)/2)

zscale defaults to npl=100 - which maps the brightest parts of the image to only 100 nits and makes the whole image dark.

Don’t know, my concern is that lossless H.265 might make some display devices very unhappy.

Or to ensure that the exported data is linear, create a linear output profile with Rec.2020 color space. Since RT doesn’t have support for HDR displays (and neither does Linux last time I checked), HDR preview is a lost cause, your preview just plain will NOT be accurate compared to what is shown on your TV via the ffmpeg export process, since RT’s preview output will be SDR.

RTv4_Rec2020_Linear_g=1.0.icc|attachment (732 Bytes)

agriggio · February 11, 2021, 11:40am

Hi,

I’m not sure what you are referring to, can you elaborate? Thanks!

st599 · February 11, 2021, 12:13pm

HLG doesn’t have a concept of NITs unlike PQ, so what is this command doing?

kmilos · February 11, 2021, 12:42pm

And let’s not forget you also have the soft proofing tool in darktable that lets you set the histogram display for HLG/PQ to help you place the level of your subject of interest where you want. (This can be useful even if you end up exporting to linear 16-bit/float TIFF for later encoding…)

anon66851888 · February 11, 2021, 3:03pm

“The curve and histogram is always displayed with sRGB gamma, regardless of working or output profile. This means that the shadow range is expanded and highlights compressed to better match human perception”
https://rawpedia.rawtherapee.com/Exposure#Tone_Curves

agriggio · February 11, 2021, 3:10pm

yes, but that refers to the “creative” tone curve, it has nothing to do with the TRC of the output profile. If you set it to linear, it will be linear (and in fact, even in the “tone curve tool”, if you use an identity curve, the gamma has no effect).

anon66851888 · February 11, 2021, 3:17pm

Sorry, seems like I misunderstood that

Entropy512 · February 11, 2021, 3:31pm

Hmm? I’m seeing references to cd/m2 (aka NITS) when discussing HLG in Rec.2100 (page 7 of https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2100-2-201807-I!!PDF-E.pdf )

zimg’s API documentation describes npl in:

github.com

sekrit-twc/zimg/blob/master/src/zimg/api/zimg.h#L611


      
          	 *
          	 * The default value is NAN, which results in a library default being used.
          	 */
          	double filter_param_a;
          	double filter_param_b;                     /**< @see filter_param_a */
          
          	zimg_resample_filter_e resample_filter_uv; /**< Chroma resampling filter (default ZIMG_RESIZE_BILINEAR) */
          	double filter_param_a_uv;                  /**< @see filter_param_a */
          	double filter_param_b_uv;                  /**< @see filter_param_a */
          
          	zimg_dither_type_e dither_type;            /**< Dithering method (default ZIMG_DITHER_NONE). */
          	zimg_cpu_type_e cpu_type;                  /**< Target CPU architecture (default ZIMG_CPU_AUTO). */
          
          	/**
          	 * Nominal peak luminance (cd/m^2) for standard-dynamic range (SDR) systems.
          	 *
          	 * When a high dynamic range (HDR) transfer function is converted to linear
          	 * light, the linear values are scaled such that nominal white (L = 1.0)
          	 * matches the nominal SDR luminance. The HDR component of the signal is
          	 * represented as multiples of the SDR luminance (L > 1.0).
          	 *

zimg also pretty clearly assumes that ARIB B67 has a peak luminance of 1000 nits:

github.com

sekrit-twc/zimg/blob/master/src/zimg/colorspace/gamma.cpp#L336


      
          		break;
          	case TransferCharacteristics::REC_709:
          		func.to_linear = scene_referred ? rec_709_inverse_oetf : rec_1886_eotf;
          		func.to_gamma = scene_referred ? rec_709_oetf : rec_1886_inverse_eotf;
          		break;
          	case TransferCharacteristics::REC_470_M:
          		func.to_linear = rec_470m_oetf;
          		func.to_gamma = rec_470m_inverse_oetf;
          		break;
          	case TransferCharacteristics::REC_470_BG:
          		func.to_linear = rec_470bg_oetf;
          		func.to_gamma = rec_470bg_inverse_oetf;
          		break;
          	case TransferCharacteristics::SMPTE_240M:
          		func.to_linear = scene_referred ? smpte_240m_inverse_oetf : rec_1886_eotf;
          		func.to_gamma = scene_referred ? smpte_240m_oetf : rec_1886_inverse_eotf;
          		break;
          	case TransferCharacteristics::XVYCC:
          		func.to_linear = scene_referred ? xvycc_inverse_oetf : xvycc_eotf;
          		func.to_gamma = scene_referred ? xvycc_oetf : xvycc_inverse_eotf;
          		break;

st599 · February 11, 2021, 4:18pm

HLG is a relative system with black at 0 and peak at 1.0. For different screen brightnesses it has a transfer curve adjustment specified - see note 5f in ITU-R BT.2100.

The %age values for reference levels are constant as the signal doesn’t change, just the transfer curve in the monitor.

Note 5f – For displays with nominal peak luminance (LW) greater than 1000 cd/m2, or where the effective nominal peak luminance is reduced through the use of a contrast control, the system gamma value should be adjusted according to the formula below, and may be rounded to three significant digits:

γ(systemGamma) = 1.2 + 0.42 Log10 (Lw/1000)

where Lw is the nominal peak luminance

kmilos · February 12, 2021, 1:55pm

AFAIK the HLG adjustments only apply to the display (decode) side. Content should still be “mastered” and encoded for the reference 1000 nits, as one doesn’t know in advance what display will be used to view it.

st599 · February 12, 2021, 2:16pm

No, HLG is scene referred. The levels represent the illumination of the sensor not a master display.

You can master on any HLG display and it will appear perceptually similar on any other HLG display (provided that they correctly implement the system gamma listed above). So diffuse white appears at 75% signal level, which will be displayed at different brightnesses depending on the monitor’s peak brightness.

Entropy512 · February 12, 2021, 2:58pm

You can be pedantic all you want, but here’s the facts:
The standard specifies a reference peak level of 1000 nits for a typical/reference display
The standard specifies that it is the display’s job to alter its tone curve in a specific manner if it has a different peak
The standard specifies no absolute references for scene luminance, only relative luminance to an arbitrary number that has no units or any connection to reality

Claim it’s scene referred all you want - for any practical real-world purpose, it is not because your only real-world reference point to start from is an assumption of 1000 nits for a reference/standard/typical display. Myself, I live in the real world. If you have a problem with how zscale operates, raise an issue on its github project and take it up with sekrit-twc.

st599 · February 12, 2021, 3:23pm

The European spec for reference monitors has multiple minimum peak brightnesses listed for different locations and uses and only lists a minimum, not a fixed value. There’s no one fixed monitor brightness for HLG. https://tech.ebu.ch/docs/tech/tech3320.pdf