I Have Published a HDR10 to HLG Converter

[wswartzendruber]

I used pg2hlg transcodes with different -r values and viewed them through MPV, comparing them to the same frames from the native BT.709 Blu-ray. Typically, I can adjust pq2hlg's -r value to get mostly consistent results between MPV's tonemapping and native BT.709. This was not the case with Interstellar. Not even close. Scenes on old earth consistently came in darker while everything aboard the Endurance looked blown out.

Artificially setting MaxCLL to 4,000 nits is an interesting approach.

EDIT: As for the credits MaxCLL, my workhorse PC is out of commission at least until a new motherboard arrives in the mail. I'm not really setup to do analysis on my backup ThinkPad.

[frank]

Good luck with your new board.

Here my script for getting MaxCLL (nvidia driver used):

ffmpeg64.exe -ss 2:44:00 ^
-c:v hevc_cuvid -crop 280x280x0x0 -resize 1920x800 -i Interstellar.UHD.rmx.mkv -vframes 24 ^
-pix_fmt rgb48le -f rawvideo - | ^
pqstat.exe -w 1920 -h 800 -

PAUSE

EDIT: hardware decoding has errors in this film! Invalid NAL units... results in wrong MaxCLL = 59.

Correct:

ffmpeg64.exe -ss 2:44:00 ^
-i interstellar.UHD.rmx.mkv -vframes 24 ^
-vf crop=3840:1600,scale=1920x800,format=rgb48le ^
-f rawvideo - | pqstat.exe -w 1920 -h 800 -

PAUSE

results in MaxCLL = 757 (bicubic).
Note: the value changes with the resizer (bilinear, bicubic, lanczos...)

Without resizing: MaxCLL = 753.

Mostly I use FHD because they do CGI and VFX in 2k and upscale the movie. Such movies compress very good. Interstellar FHD HLG with CRF 18 gets 5140 kbit/s video rate.
VMAF = 97.6, PSNR = 48.7 dB (first 10 min) show very good quality. You will see no difference to the original.

[wswartzendruber]

Every time I've run into invalid NAL units, it's been a Dolby Vision disc.

[wswartzendruber]

I have come to the conclusion that the SDR monitoring I've been getting from players has been completely inaccurate. There are a number of different ways to display HLG as SDR and none of them seem to be correct for monitoring. And then there is the issue of BT.2020->BT.709 color mapping. Hence, I cannot rely on players converting BT.2020 HLG into BT.709 SDR for determining brightness adjustments.

So I have built a new system into the latest pq2hlg in Git main. You can now pass in a --preview flag to generate a LUT that outputs black and white BT.709 (gamma 2.4) instead. After applying the specified linear brightness scaling and 1,000 nit tone mapping to the PQ signal, it is then monochromed using BT.2020's cofficients and then further tone mapped with a curve I developed just for this. In SDR space, we seem to set reference white to 80 nits and put max white at 100 nits. So PQ ranges from 0-203 nits linearly map to 0-80 nits. 203-1,000 nits then incur a logarithmic rolloff to 80-100 nits. After this, an inverse gamma of 2.4 is applied. This picture can then be compared to monochrome playback of the same movie's BT.709 Blu-ray, comparing the shadows and midtones of both. The linear scaling factor is then adjusted as necessary to make the preview picture match the standard Blu-ray monochrome picture while ignoring the highlights.

I have previewed the first ten minutes of Alita: Battle Angel with this new technique, and the HLG pictures in both VLC and MPV look quite good. I'll have screenshots of the full movie later.

[wswartzendruber]

Here are ten screenshots from Alita: Battle Angel using the latest approach.

Alita: Battle Angel (hlg-tools-5bad678)

Each image contains four screenshots, all of which are labeled.

VLC does much better with this approach, suggesting that the philosophy I've applied to brightness adjustment is quite compatible with VLC. Perhaps I have done things the universally "correct" way here. MPV, meanwhile, continues to look just a tad better, although not phenomenally better as before. VLC on Linux still has issues with mapping BT.2020 yellows to BT.709.

I would appreciate any feedback on this latest approach (described in the post above).

[wswartzendruber]

Originally Posted by frank

Good luck with your new board.

Here my script for getting MaxCLL (nvidia driver used):

ffmpeg64.exe -ss 2:44:00 ^
-c:v hevc_cuvid -crop 280x280x0x0 -resize 1920x800 -i Interstellar.UHD.rmx.mkv -vframes 24 ^
-pix_fmt rgb48le -f rawvideo - | ^
pqstat.exe -w 1920 -h 800 -

PAUSE

EDIT: hardware decoding has errors in this film! Invalid NAL units... results in wrong MaxCLL = 59.

Correct:

ffmpeg64.exe -ss 2:44:00 ^
-i interstellar.UHD.rmx.mkv -vframes 24 ^
-vf crop=3840:1600,scale=1920x800,format=rgb48le ^
-f rawvideo - | pqstat.exe -w 1920 -h 800 -

PAUSE

results in MaxCLL = 757 (bicubic).
Note: the value changes with the resizer (bilinear, bicubic, lanczos...)

Without resizing: MaxCLL = 753.

Mostly I use FHD because they do CGI and VFX in 2k and upscale the movie. Such movies compress very good. Interstellar FHD HLG with CRF 18 gets 5140 kbit/s video rate.
VMAF = 97.6, PSNR = 48.7 dB (first 10 min) show very good quality. You will see no difference to the original.

Interstellar is trash. Not story-wise, but production-wise....ick.

And my new method above is no match for it. Artificially raising MaxCLL to 4,000 might be the only way to go.

And why are the edges of some frames so blurry?

This is probably going to be the only movie in my library where I prefer the BT.709 Blu-ray over HLG.

[wswartzendruber]

I'm happy with where things are at with my new approach, so I've published the 0.3.0 pre-release to GitHub.

I need to port the hlgprev.sh script to Windows.

[Balling]

MaxCLL is formally defined in (free) CTA 861-H. https://shop.cta.tech/products/a-dtv...aces-cta-861-h

[wswartzendruber]

Originally Posted by Balling

MaxCLL is formally defined in (free) CTA 861-H. https://shop.cta.tech/products/a-dtv...aces-cta-861-h

I knew it! That's not what everyone says MaxCLL is, but that's what it is. (The nit level of the brightest linear color channel without applying any of the RGB coefficients.)

[wswartzendruber]

@FranceBB

So in your LUT thread, you mentioned that you guys are putting reference white at 0.5 signal. This thing I've written tries to put it at 0.75. I did this because I had assumed that the industry would be adopting the updated values in BT.2408 instead of the older ones in ARIB STD-B67.

Does pq2hlg need to assume that reference white is at 0.5? Or should it support both modes? Or should I just call out in documentation that it uses BT.2408?

What a mess...

[FranceBB]

You should definitely support both, that would be ideal.
This problem arises from the fact that many broadcasters started producing contents early on and stick with BBC Specs.
We also have the official BBC paid LUTs over here which of course still follow the "old" BBC Specs.

[wswartzendruber]

This is comical, considering the BBC published a paper on PQ-to-HLG transcoding based on BT.2390, and BT.2390 blatantly states that SDR max white should be mapped to 75% HLG.

EDIT: It's the very first sentence on page 50.

EDIT: This paper does nothing to put reference white at 50% and several things to put it at 75%.

EDIT: This BBC presentation establishes 75% as reference white, beginning on slide 44.

[FranceBB]

Originally Posted by wswartzendruber

This is comical, considering the BBC published a paper on PQ-to-HLG transcoding based on BT.2390, and BT.2390 blatantly states that SDR max white should be mapped to 75% HLG.

EDIT: It's the very first sentence on page 50.

EDIT: This paper does nothing to put reference white at 50% and several things to put it at 75%.

EDIT: This BBC presentation establishes 75% as reference white, beginning on slide 44.

Ok, this is comical indeed to say the very least.
Let me send you colorbars made with the BBC Specs ARIB STD-B67 according to the very latest matrices they sent.
I somehow suspect that they actually changed it to 75% reference white underneath everyone's nose eheheheh

[FranceBB]

Actually, it's color bars, I don't care.

https://we.tl/t-gADbIgHTle

[wswartzendruber]

I'm going to laugh if you guys are the only ones in the region broadcasting reference white at 0.5.

EDIT: My emojis didn't go through. Does this site not do Unicode?

TEST: 美國人입니다.

EDIT: It does Unicode; I wonder what happened to my emoji.

[FranceBB]

You might laugh but I might cry xD

Did you check the colorbars?

[wswartzendruber]

I did. I can't be sure what VLC is doing with the gamma there, but when played back via Direct3D, the top-left bar is grey with 71.0% sRGB luminosity. The white box below is also grey at 93.7% luminosity.

[Balling]

Originally Posted by wswartzendruber

I did. I can't be sure what VLC is doing with the gamma there, but when played back via Direct3D, the top-left bar is grey with 71.0% sRGB luminosity. The white box below is also grey at 93.7% luminosity.

Use latest Stable Chrome, it supports scRGB for HDR. At least it works on images, like Display P3 ICC images. Latest mpv added support for hdr metadata finally. But only works if HDR in windows 11 activated desktop wide due to new WDDM 3.0 (in Chrome and in mpv). See for yourself: https://wsd.events/2019/07/13/pres/a...mut/index.html

[wswartzendruber]

Well in the course of studying this HLG reference white issue, I've discovered that I'm not scaling linear display brightness correctly. So I'm adding a gamma correction step as called for in BT.2446 section 4.1.2.

SIDE NOTE: Last March, a bunch of stuff seemingly moved out of BT.2390 and into BT.2408, including PQ->HLQ transcoding and PQ tone mapping.

[wswartzendruber]

I really just...



BT.2446 says to apply gamma correction. I ended up having to do the reciprocal of that to make the picture come out right.

The next version will also feature a spec-compliant (as best I can tell) SDR downconversion system (for previewing the result).

Tone mapping is now R'G'B' instead of YRGB.

I've got some more testing to do then I'll post a build of 0.4.0.