I Have Published a HDR10 to HLG Converter

[wswartzendruber]

Version 1.0.1 is out. Get it HERE (https://github.com/wswartzendruber/hlg-tools/releases/tag/release/1.0.1).

Hello everyone:

The hour is late here in Idaho, but I have finally published something I've been working on for over a year now. It started when I decided to rip my Blu-ray library for personal use. This would allow me complete control over the copies and I could then freely put them on any of my devices. I ran into trouble when I went to consider how to handle my 4K discs. These use entirely different gamma and color from what my PC and laptop use. Effectively, I would have to rip both the 4K and standard Blu-ray discs to keep both my current SDR devices happy along with my future HDR ones. After thinking about this prospect of ripping both discs for 3/4 of a second, I decided to look into making these 4K discs viewable on existing devices. Enter HLG. What followed was studying piles of ITU-R printouts, experimenting, more studying, more experimenting, running around in some circles, and finally a (tentatively) complete product.

Anyway, enough of all this rambling. I need to get to bed, so here you go:

You can download current packages here: https://github.com/wswartzendruber/hlg-tools/releases
You can check out the top-level README for the project here: https://github.com/wswartzendruber/hlg-tools/blob/main/README.md. It contains the conversion guide.

I should probably disclose that I have not yet gotten my hands on a good HLG display, only a Samsung that left a lot to be desired. In fact, the SDR downconversion via MPV looked leaps and bounds better than that display's interesting interpretation of things. I did briefly get to evaluate a transcode on a much more expensive Samsung set, and that looked much better. In both cases, the TV recognized the signal as HLG. -- Things are looking much better on the set that looked bad.

All right, it's 2:30 AM. I'm off to bed!

EDIT: Hold on just a minute! I forgot to credit FranceBB with helping me here and there along the way.

EDIT: And kolak, and SeeMoreDigital, and frank...

[FranceBB]

It's been a long way, but wswartzendruber you finally made it to the end. :D
I'm glad you were finally able to publish everything, it took a lot of effort and research on your side but I'm sure the results are now accurate, so well done. :)
I'm sure this will help many people who want to convert their disks and other sources to HLG correctly, so well done for this and for making everything open source, that's the right way. :)

[kolak]

Do you use any low pass filtering when calculating your max values?
Any encode will introduce overshoots and your max points can be very high, but somehow unreal due to compression.

Also maybe ffmpeg scaling should use nearest neighbour method instead of default bicubic.

[SeeMoreDigital]

This is why this forum could do with a 'thumbs up' button ;)

[wswartzendruber]

Do you use any low pass filtering when calculating your max values?
Any encode will introduce overshoots and your max points can be very high, but somehow unreal due to compression.

Also maybe ffmpeg scaling should use nearest neighbour method instead of default bicubic.
I'm not lowpass filtering anything. If you're worried about going through the ceiling because of MDCT's inherent imprecision, you could always give yourself some headroom when feeding max-channel into pq2hlg. Or you could have ffmpeg do the filtering before passing it to pq2hlg.

[kolak]

Seen so different results for HDR analysis mainly because compression overshoots. It all works fine as long as you stay with eg. 16bit TIFF, but once you touch ProRes etc. (not even talking about h265) then 1000nits max becomes eg. 2000, which can be just a single pixels overshoot in the whole movie. Very fake value.

[wswartzendruber]

Seen so different results for HDR analysis mainly because compression overshoots. It all works fine as long as you stay with eg. 16bit TIFF, but once you touch ProRes etc. (not even talking about h265) then 1000nits max becomes eg. 2000, which can be just a single pixels overshoot in the whole movie. Very fake value.

Well I can add a note to README.md telling the user they may wish to filter before sending to pq2hlg. What filter and settings would you recommend?

[kolak]

No idea about specifics. I think some specs may mention it.
I know some tools do use it, eg. Cortex when analysing HDR, but I think values are own MTI Film calculated.

[wswartzendruber]

No idea about specifics. I think some specs may mention it.
I know some tools do use it, eg. Cortex when analysing HDR, but I think values are own MTI Film calculated.

Maybe I should be paying attention to the metadata's MaxCLL.

Question: Is it a safe assumption that the brightest pixel is always white?

EDIT: I'm asking because pqstat just told me that Aquaman clocks in with a MaxCLL of 3,190, yet the metadata puts it at 1,506. I've never seen that kind of disparity before.

[kolak]

This is exactly what can happen with compression overshoots. You get very misleading results.

MaxCLL quite often come form the top of the production chain, where people work with EXRs or TIFF, so those should be more accurate than ones calculated form h265 compressed files.
I would still blindly not rely on MaxCLL.

There should be free EBU etc. doc about calculating MaxCLL.
There is this:
http://avisynth.nl/index.php/MaxCLLFind

Some paper:

https://i.postimg.cc/44h62X92/Screenshot-2021-03-10-at-17-32-20.png

None of it mentions low pass filtering, but this also (quietly I think ) assumes that measurements are done on uncompressed assets.

[wswartzendruber]

From that little snippet alone it would appear that I have been calculating MaxCLL incorrectly anyway. Is there any way I can get my hands on ST.2086?

EDIT: Part of the reason I want to calculate MaxCLL manually is that Alita: Battle Angel changes after the 20th Century Fox logo. It goes from 233 nits to 737 nits.

[kolak]

2nd page is for MaxFALL (in case this is confusing).

this ZIP has random info regarding HDR:
https://spaces.hightail.com/space/nEaXy

[wswartzendruber]

So MaxCLL really is assumed to be white, and furthermore, no single color channel for any pixel can exceed what it would be to produce white at that brightness...

If that's how this really works, I'm going to completely redo tonemapping in pq2hlg. I won't have everyone waste their time with running the whole thing through pqstat. I'll just have them feed MaxCLL into pq2hlg instead.

-- EDIT --

Where on GOD'S GREEN EARTH is MaxCLL formally defined?! It's not a part of BT.2100, BT.2408, or BT.2390. It's also not a part of ST.2086. Is it a part of the HDR10 specification? Because I can't find that, either! All I can find is that it (HDR10) is controlled by the CTA.

What SMPTE publication is that above? Or is MaxCLL a part of that document dump?

[SeeMoreDigital]

EDIT: Part of the reason I want to calculate MaxCLL manually is that Alita: Battle Angel changes after the 20th Century Fox logo. It goes from 233 nits to 737 nits.Apart from HDR10, that particular 4K UHD disc has also been encoded with/contains HDR10+ and (MEL) Dolby Vision...

[kolak]

Where on GOD'S GREEN EARTH is MaxCLL formally defined?! It's not a part of BT.2100, BT.2408, or BT.2390. It's also not a part of ST.2086. Is it a part of the HDR10 specification? Because I can't find that, either! All I can find is that it (HDR10) is controlled by the CTA.

What SMPTE publication is that above? Or is MaxCLL a part of that document dump?

No idea. Grabs are from SMPTE document.

[wswartzendruber]

I found where the two SMPTE snippets above come from:

https://www.murideo.com/uploads/5/2/9/0/52903137/study_group_on_high-dynamic-range-hdr-ecosystem.pdf

This includes the algorithm for calculating MaxCLL. It demonstrates that MaxCLL is not necessarily the Y value of the brightest pixel in the stream as many sites suggest. Instead, MaxCLL tells the display what magnitude each color channel can reach, but all three don't have to reach this level, only one does. In practice, though, if the brightest pixel is truly white, then all color channels will reach this level.

EDIT: Working on hlg-tools-0.2.0 now... Version 0.1.0 is not even remotely correct.

[FranceBB]

Any encode will introduce overshoots and your max points can be very high, but somehow unreal due to compression

Of course... Why didn't I think about that? He's not analyzing .tiff, he's analyzing the final compressed file for users... Crap... I got so used to do things here at work that I forgot he was actually doing things from the prospect of an home user...


@wswartzendruber... so what Kolak means is that in the final encode you're gonna have things that are not there in the original source in which the measurements should have been done. I actually have never done a measurement on a final compressed encode for consumers, but I tried and indeed things are different.
Take a look at this waveform coming directly from a synthetic 16bit .tiff sequence:

https://i.imgur.com/riZZ9JK.png

and this is what happened after the H.265 10bit planar compression:

https://i.imgur.com/E4VMYaY.png


Now, leaving aside the fact that the scope is "wrong" in the sense that it's not HDR Aware etc and it's not good to check those things, what you see is essentially what happens when you compress something with a consumer-tier bitrate most of the time. I've run the analysis and indeed I've got two very different results from the .tiff sequence compared to the final encoded version, sadly, which is expected, but still...

How could have I missed that... :(
Only humble pie for me today...

[wswartzendruber]

How could have I missed that... :(
Only humble pie for me today...

That really won't be necessary. We seem to be in something of uncharted territory here as far as consumer utilities go. I did, after all, decide to create this because I couldn't find a FOSS (free, open source software) utility that could handle any arbitrary 4K disc thrown at it. So to that end, we're probably leaving the realm of established practice.

hlg-tools-0.2.0 will simply use whatever the movie has for MaxCLL, although I'm telling users in the latest README to skip around to make sure the indicated value doesn't change (looking at you, Alita). And now that I know what MaxCLL really is (which should have been easier to find), pq2hlg just uses that and the indicated reference white value to generate the LUT. The end result is that the stream won't be over-compressed (tone mapped) and the source also doesn't have to do a separate pass through pqstat.

All in all, I'm quite happy with the remedy to this latest complication.

As a side note, I've noticed that the ITU doesn't want anything to do with HDR10 or any of the other metadata schemes. They'll redefine PQ (and even change its reference white level), but they won't touch PQ metadata. In fact, the word "metadata" appears just twice in BT.2390:


"The signal characteristic is similar to that of a traditional standard dynamic range camera with a knee and requires no production metadata."
"No use of metadata is shown or required."


The word does not appear in BT.2100 or BT.2408.

[kolak]

Not sure if I understand whole conversion correctly but...

MaxCLL can be misleading anyway even if value is correct.
MaxCLL is based on single frame. Whole movie can be relatively dark and have one scene with 1000nits peak.

If we use this 1000nits as max value won't we end up with not optimal HLG result? Would it not be better to have that one scene nod ideal (clipping?) then rest of the movie dull?

Is this the case with your tool?
I assume maybe not as we are converting to HLG which is also HDR.
This is the problem when converting to SDR and this is why all good tools work "locally" not globally.

[wswartzendruber]

The two main requirements for a good PQ-to-HLG conversion are:

1. Reference white needs to be at 203 nits.
2. MaxCLL needs to be at 1,000 nits.

So here's an overview of how pq2hlg does things:

1. What is the reference white level? Adjust the linear brightness to bring whatever that is to 203 nits.
2. What is MaxCLL now that that's happened? Adjust MaxCLL by the same ratio to reflect the reference white adjustment.
3. Tone map MaxCLL down to 1,000 nits.
4. Run the HLG iOOTF.

I've watched a few movies that I've done with this converter on MPV. The SDR range (everything below reference white) has looked good for a while now. But the utility has never really tone mapped the HDR range correctly. I intend to have that corrected by Monday.

You can find SDR screenshots at the bottom of the Git repo's README. These still use the incorrect method of tone mapping, but it's not so obvious when MPV is downconverting to SDR.

[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:

https://infantcpr.com/wp-content/uploads/2020/09/baby-with-pacifier.png

[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]

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. :)


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 :D

[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]

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.cubeyou'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.

[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 -

PAUSEEDIT: 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 -

PAUSEresults 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) (https://imgur.com/a/tbVbB6j)

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]

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 -

PAUSEEDIT: 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 -

PAUSEresults 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-profile-for-uncompressed-high-speed-digital-interfaces-cta-861-h

[wswartzendruber]

MaxCLL is formally defined in (free) CTA 861-H. https://shop.cta.tech/products/a-dtv-profile-for-uncompressed-high-speed-digital-interfaces-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...