I Have Published a HDR10 to HLG Converter

[wswartzendruber]

Sweet Fancy Moses.........

I just now realized that the "O" in EOTF and OETF don't refer to the same thing. For PQ and HLG, the EOTFs go to display-linear light and the OETFs go from scene-linear light.

I have to go back and verify everything now. All of it.

Also, I thought I would share a picture of myself:

[wswartzendruber]

I've published version 0.2.0 which seeks to correct tone mapping. It just uses MaxCLL now. This also eliminates the need to put the entire source stream through pqstat. This pre-release and its README are available via the links in the first post.

[frank]

The color parameters in your ffmpeg cmd are wrong. For HLG the right values must be (Mediainfo):

Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : HLG / BT.2020 (10-bit)
Matrix coefficients                      : BT.2020 non-constant

The second transfer value is a fall back for non-HLG displays.
There are issues in libx265 but here the correct part of ffmpeg command line for Windows:

ffmpeg64.exe ...
-color_primaries bt2020 -colorspace bt2020nc -color_trc bt2020-10 ^
-x265-params open-gop=0:atc-sei=18:pic_struct=0 ^
...

[wswartzendruber]

What is the reason for disabling open-GOP?

[frank]

Closed GOP is better for transmission errors, cutting, jumping. Open GOP is used for short GOPs (Blu-ray 24 frames) to prevent quality issues (by I frames) at the GOP borders.
I mostly use GOP length = 48 frames for my encodings, recommended by Nvidia, streaming my videos. So seeking in mpv is very fast.

For encoding HLG in containers (mkv, mp4) but also for .hevc set all color parameters in the x265 string, NOT DIRECTLY IN FFMPEG:

ffmpeg64.exe ...
-x265-params colorprim=bt2020:colormatrix=bt2020nc^
:transfer=bt2020-10:atc-sei=18:pic-struct=0 ^
...

The values are embedded in the stream. So TV like LG OLED CX will trigger HLG.

[wswartzendruber]

This command:

ffmpeg -i source.mkv \
    -vf crop=3840:1600,scale=1920:800,format=rgb48le,lut3d=alita-battle-angel.cube,format=yuv420p10le \
    -color_primaries bt2020 -color_trc bt2020-10 -colorspace bt2020nc \
    -c:v libx265 -crf 20 -preset slower -tune grain -x265-params atc-sei=18:pic_struct=0 \
    video.h265

Causes mediainfo to display this:

Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : HLG / BT.2020 (10-bit)
Matrix coefficients                      : BT.2020 non-constant

Why do I also need to pass these values in via -x265-params?

EDIT: To clarify, I originally had colors specified via -x265-params. However, after adding atc-sei and pic_struct as you suggested, this no longer seems to be necessary. It is as if FFmpeg originally filtered them out after detecting that I called for HLG without also setting the required atc-sei and pic_struct values.

[kolak]

-color_trc bt2020-10 is fine as long as you have atc-sei=18. This assumes SDR playback with standard BT.1886 gamma (2.4 based) unless device reporting HLG compatibility then atc-sei is used, so we have HLG signal.
If you don't use atc-sei=18 then -color_trc arib-std-b67.
First is more correct for broadcast, but for software world 2nd may be more robust.
Better to add flagging to x265, just to be sure. They need to be in x265 headers, not just container.

[wswartzendruber]

I did several encodes with hlg-tools-0.2.0 and tried them on two different Samsung sets. Both sets recognized the video gamma as HLG.

On one display, the video looked HDR, but was overall somewhat dim. This display had default settings. This was an enjoyable experience so long as ambient light was really low. Detail within specular highlights could easily be observed. These details are obscured when viewing through MPV.

The other set had what I consider to be outlandish settings, however, they were honored. It made the picture look more like really bright SDR, but the owner was quite pleased with the results and it was quite viewable with daytime light coming in through the windows.

I welcome anyone to point out any issues that are found. But unless someone does so, I don't see myself making any further changes.

[kolak]

Safest way of playback is through TVs own engine. Anything coming from Windows is big unknown
Other way is playing though some good player which can send HDR flagging on HDMI (and which is separated from Windows).
Not sure if I know anything like this, except some expensive ones.
3rd way is playing over dedicated card like BlackMagic through app like Resolve.

[wswartzendruber]

I just plopped the MKV on a USB stick and popped that into the TV's port. No other devices were involved. The TVs themselves recognized the gamma as HLG.

[FranceBB]

Originally Posted by wswartzendruber

I just plopped the MKV on a USB stick and popped that into the TV's port. No other devices were involved.

And that's a correct way to do it as the TV will use its own player and decoder to play the file, read the metadata etc.

Originally Posted by kolak

3rd way is playing over dedicated card like BlackMagic through app like Resolve.

BlackMagic Decklink cards are my favorite, I use them to playback things all the time and that's also how I test the LUTs, but they're definitely more professional/broadcast oriented rather than user-oriented. Still, if anyone was interested, I would definitely recommend them

[kolak]

I would recommend AJA (way more reliable than BM), but these are quite expensive

[frank]

I tested hlg-tools-0.2.0 and compared it to dgPQ2HLG_1.0.

Result: colors are the same, so it works.

On a TV that decodes HLG right you'll get almost the same picture as HDR10. Contrast and brightness are good.
I use a LG OLED48CX with normal calibration and it's own player.
But setting the TV to normal colors (neutral whitepoint) was a nightmare. Don't use display modes like sports, games, enhanced colors etc.
Only Movie or Standard.

[wswartzendruber]

Originally Posted by frank

I tested hlg-tools-0.2.0 and compared it to dgPQ2HLG_1.0.

Result: colors are the same, so it works.

On a TV that decodes HLG right you'll get almost the same picture as HDR10. Contrast and brightness are good.
I use a LG OLED48CX with normal calibration and it's own player.
But setting the TV to normal colors (neutral whitepoint) was a nightmare. Don't use display modes like sports, games, enhanced colors etc.
Only Movie or Standard.

I'm not at all familiar with dgPQ2HLG, but I thank you for testing my solution out.

[frank]

Fast script using dgPQ2HLG:

# Avisynth+

LWLibavVideoSource("video.uhd.mkv",cachefile="video.lwi",format="YUV420P16",decoder="",prefer_hw=1) # NVIDIA hw

# (avsresize.dll)
z_Spline36Resize(1920,1080) # FHD

# Converting HDR PQ to HDR HLG (dgPQ2HLG.dll)
dgPQtoHLG(impl="255",light=1000.0) # nVidia cuda

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="YUV420P10",dither_type="error_diffusion")

# Enable MT
Prefetch(2)

And fast script using hlg-tools:

# Avisynth+

LWLibavVideoSource("video.uhd.rmx.mkv",cachefile="video.lwi",format="YUV420P16",decoder="hevc_qsv",prefer_hw=2) # hw

# (avsresize.dll)
z_Spline36Resize(1920,1080) # FHD

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="RGBP16",colorspace_op="2020:st2084:2020:l=>rgb:st2084:2020:f",dither_type="none")

# Apply LUT (vscube.dll)  input full / output full  HLG
Cube("hlg-tools65.cube",fullrange=true) # max-cll 1000

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="YUV420P10",dither_type="error_diffusion")

# Enable MT
Prefetch(2)

[wswartzendruber]

Wow, cool! Be sure to mess with --ref-white if you find the result looks unsatisfactory on SDR. Too dark means --ref-white needs to be lowered. Too bright means --ref-white needs to be increased. MaxCLL will be adjusted for you and tone mapped (BT.2390) accordingly.

[wswartzendruber]

Shazam! and Insterstellar are mastered really bright. The first has reference white at like 350 nits, and the second seems to be at 400 nits.

[frank]

Interstellar with max-cll=1242,436 is a really hard thing. Contrast settings using a 4000 nit mastering display are too high. If you use 400 as the reference white, you'll get a mid-tone that is too dark.
With reference white=170 LUT generated by

pq2hlg -m 4000 -r 170 -s 65 4000nit.cube

you'll get good results.

[wswartzendruber]

I'm curious about something. Do you have an HLG test signal that highlights:

1. SDR range vs HDR range (the border at 75% signal)
2. BT.709 color vs BT.2020 color (the border between them)

Does something like that exist?

[frank]

I did a lot of tests with hlg-tools-0.2.0. I have no test signal.
I compare videos:
1. on TV LG OLED48CX in HLG HDR
2. on notebook Dell XPS 9500 with mpv (Windows HD color enabled) max = 500nit
mpv has an outstanding tonemapper.

In the credits of Interstellar 2:44:00 you get maxCLL = 59 (??) EDIT: hw decoder error!
How did you get the 400 nit for reference white?

Interstellar has such a hard contrast so the TV has to compress to a knee (on OLED 600nit), and dark details disappear. In the cinema such contrast would blind you. The colorist has done his work badly for home users.
On bluray (bt709) the color grading of Interstellar is good.

Most UHD videos look fine with -r 203 in HLG.
-r 170 with Interstellar gives you more details in dark scenes.
-m 4000 supports the knee to prevent blinding. Details are retained.

This is my result.