I Have Published a HDR10 to HLG Converter [Archive]

wswartzendruber

7th March 2021, 10:28

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

7th March 2021, 14:43

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

9th March 2021, 15:12

SeeMoreDigital

9th March 2021, 16:52

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

wswartzendruber

9th March 2021, 17:53

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

9th March 2021, 18:22

wswartzendruber

9th March 2021, 18:45

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

9th March 2021, 21:27

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

10th March 2021, 01:21

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

10th March 2021, 17:17

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

10th March 2021, 19:24

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

10th March 2021, 21:28

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

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

wswartzendruber

11th March 2021, 01:32

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

11th March 2021, 11:50

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

11th March 2021, 15:11

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

11th March 2021, 21:45

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

12th March 2021, 11:08

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

12th March 2021, 16:26

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

12th March 2021, 18:05

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

12th March 2021, 19:34

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

16th March 2021, 16:13

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

20th March 2021, 04:13

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

20th March 2021, 12:53

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

20th March 2021, 22:39

What is the reason for disabling open-GOP?

frank

21st March 2021, 05:48

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

21st March 2021, 18:21

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

22nd March 2021, 11:24

-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

28th March 2021, 17:19

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

29th March 2021, 21:58

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

29th March 2021, 22:20

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

29th March 2021, 22:44

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

29th March 2021, 23:43

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

frank

31st March 2021, 16:49

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

31st March 2021, 23:48

frank

1st April 2021, 14:33

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

1st April 2021, 21:54

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

9th April 2021, 20:08

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

20th April 2021, 12:27

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

21st April 2021, 03:32

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

21st April 2021, 11:16

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

21st April 2021, 16:24

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

22nd April 2021, 09:52

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

22nd April 2021, 21:37

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

wswartzendruber

6th June 2021, 18:24

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

6th June 2021, 23:06

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

10th June 2021, 05:41

wswartzendruber

16th June 2021, 05:30

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

27th August 2021, 09:04

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

13th September 2021, 00:36

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

9th November 2021, 18:33

@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

9th November 2021, 19:58

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

9th November 2021, 20:49

FranceBB

10th November 2021, 10:38

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 (http://downloads.bbc.co.uk/rd/pubs/papers/HDR/BBC_HDRTV_HLG_LUT_Production_Guide.pdf) does nothing to put reference white at 50% and several things to put it at 75%.

EDIT: This BBC presentation (https://www.dutchguild.nl/31jan2017/HLG%20Overview%20-%20Dutch%20Guild%20published.pdf) 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

10th November 2021, 10:46

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

https://we.tl/t-gADbIgHTle

wswartzendruber

10th November 2021, 23:02

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

11th November 2021, 07:51

You might laugh but I might cry xD

Did you check the colorbars?

wswartzendruber

11th November 2021, 16:20

Balling

12th November 2021, 15:51

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/all-the-colors/samples/media-color-gamut/index.html

wswartzendruber

13th November 2021, 02:59

wswartzendruber

16th November 2021, 05:32

I really just...

http://littlefun.org/uploads/52309db3e691b236df7d6b76_736.jpg

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.

wswartzendruber

20th December 2021, 04:02

Nope. Nevermind. It turns out:

1. Scaling linear RGB luminosity is a pretty good way to go for increasing brightness.
2. Color does not need to be converted to yxY before doing so (RGB0->yxY, scaling Y, and then yxY->RGB yields identical results to simply scaling RGB).

This effectively means that 0.3.0 was doing the right thing all along.

I have updated the tone mapper to work against R'G'B' instead of Y, however, as Y can produce out-of-gamut results. This should be rare, however.

ErazorTT

3rd January 2022, 10:42

For anybody reading this thread, I am pretty sure that this conversion I'm quoting here is wrong. In that it introduces a colorshift, which is especially visible in the yellows. This can be seen by just leaving out the cube statement, then this script shouldn't do anything to the colors, however it does.

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)

The proper conversion is reached when the colorspace change in the back-conversion is written out as well, emphasized in bold. So the correct script would be:

# 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="YUV420P16",colorspace_op="rgb:std-b67:2020:f=>2020ncl:std-b67:2020:l",dither_type="error_diffusion")

# Enable MT
Prefetch(2)

This does however also mean that DGPQtoHLG does something funny with colors! As DGPQtoHLG produces an output which is virtually identical in colors as the script I quoted using with the wrong colospace converison! :confused:

ErazorTT

3rd January 2022, 18:45

Oh and have you guys (FranceBB and wswartzendruber) settled on a value for the reference white? Is it 50% or 75%?

wswartzendruber

3rd January 2022, 22:12

I'm firmly settled that it should be 75%. FranceBB is the one in the broadcast industry, though.

FranceBB

4th January 2022, 10:28

Oh and have you guys (FranceBB and wswartzendruber) settled on a value for the reference white? Is it 50% or 75%?

Yes.
75% for anything "recently" done and anything you will ever do in the future (current BBC standard), 50% on old legacy stuff done at the very beginning of HDR (old NHK proposal).

I'm firmly settled that it should be 75%.

So am I now. Anything done nowadays should be 75%, no one should really be use the old NHK proposal. Not even the BBC uses it any longer and following their own specs with their own LUTs the output is always 75%, which checks out.

FranceBB is the one in the broadcast industry, though.

for now, dunno what the future holds in those perilous times ehehehehe
(actually there's little to laugh about, the economic situation around the globe is tragic and there are cuts everywhere, but so far I've been one of the lucky ones who is still here and hasn't been fired)

ErazorTT

4th January 2022, 12:07

Yes.
75% for anything "recently" done and anything you will ever do in the future (current BBC standard), 50% on old legacy stuff done at the very beginning of HDR (old NHK proposal).

So is this then reflected by the LUT's of your LinearTransformaion package? I'm asking because I'm having a hard time matching the LUT's of you two guys.

FranceBB

4th January 2022, 15:46

So is this then reflected by the LUT's of your LinearTransformaion package? I'm asking because I'm having a hard time matching the LUT's of you two guys.

Yes, at least in the latest version it should be correct.
Please also note that my LUTs all work in RGB Full Range, so if you have a YUV Limited TV Range input you have to convert to Full Range RGB first, apply the lut and then convert back to Limited TV Range YUV. By default, the Avisynth built-in converters do this. My LUTs have also been implemented in the automation software we use at work and we're developing together with other TVs across the world here at Sky, namely FFAStrans https://ffastrans.com/wp/ - https://forum.doom9.org/showthread.php?t=176655

wswartzendruber

4th January 2022, 17:05

I'm having a hard time matching the LUT's of you two guys.
What version of pq2hlg are you using, and what does your command line look like?

ErazorTT

5th January 2022, 03:02

Please also note that my LUTs all work in RGB Full Range, so if you have a YUV Limited TV Range input you have to convert to Full Range RGB first, apply the lut and then convert back to Limited TV Range YUV.

Yes, sure.

What version of pq2hlg are you using, and what does your command line look like?

I'm using version 0.3.0 this way:

# generate lut file by: .\pq2hlg.exe lut.cube --size 128 --max-cll 1000 --ref-white 203
ConvertBits(16).ConvertToPlanarRGB(matrix="2020ncl")
Cube("lut.cube",fullrange=true)
ConvertToYUV420(matrix="2020ncl")

I tried some combinations of max-cll and ref-white but I cannot match any of them to FranceBB's outcome. And I'm comparing against PQ_to_HLG_Nspec.cube from LinearTransformation 1.8.
Using FranceBB's LUT also appears to look great on my calibrated BT.1886 displays (which is weird since I would have expected that the deep blacks get slightly crushed there), but on my calibrated HDR display it appears that the blacks are too bright. I have a perfectly calibrated computer display which I set to BT.1886 and an LG OLED tv where I calibrated 1886, PQ and HLG separately. I'm calibrating using a spectrometer and a colorimeter.
Its already very late, so I will produce test clips tomorrow.

wswartzendruber

5th January 2022, 04:40

I think FranceBB custom-tuned his LUTs.

Those parameters into pq2hlg will produce a stock conversion LUT according to BT.2408.

What are your calibration parameters? A HLG display in a reference environment should output reference white at 203 nits and max white at 1,000 nits.

FranceBB

5th January 2022, 05:23

Oh no no no, don't use NSpec, that stands for NHK 50% reference white specification, no wonder the result is different. Use the other one, PQ_to_HLG.cube, which follows the BBC 75% standard.

ErazorTT

5th January 2022, 10:54

Those parameters into pq2hlg will produce a stock conversion LUT according to BT.2408.
Yes, exactly. And my first supposition was that this should roughly match FranceBB's LUT.

What are your calibration parameters? A HLG display in a reference environment should output reference white at 203 nits and max white at 1,000 nits.

Unfortunately my LG can only output 720nits peak in a 10% window. So I'm trying to calibrate it to a reference white of 159nits and a gamma of 1.14. (my calculation of these should be fine, since it exactly reproduces all the right values of tables 3 and 4 of the BT.2408-4 paper)
But I don't think that the perfromance on the peak white (or even reference white) matters at all since what I'm concerned about are the blacks.

Oh no no no, don't use NSpec, that stands for NHK 50% reference white specification, no wonder the result is different. Use the other one, PQ_to_HLG.cube, which follows the BBC 75% standard.
Hm, ok. But that one behaves even more different, since now the whites are also different from wswartzendruber. With the Nspec LUT, at least the whites were equal.

I should be able to produce a half minute clip in the next hours, to which I will send you two a link via PM (because of DRM and such I will not be able to post it here, so sorry for anybody else who might be reading).

ErazorTT

5th January 2022, 15:04

Here are screenshot of the files being played in the mpv player which is running with the icc-profile parameter set to an exact profile of my pc display.

Original PQ:
PQ.jpg (https://drive.google.com/file/d/1BwSjLdhQCNlvYSl-6U_sCWeL2oEKQjsX/view?usp=sharing)

hlg-tools LUT with max-cll of 10000 and a ref-white of 203:
HLG_hlgtools_10000_203.jpg (https://drive.google.com/file/d/1q3EO6VLYQm50jVytWdaPEGhF3lDyXNXh/view?usp=sharing)

FranceBB's PQ_to_HLG LUT:
PQ_to_HLG.jpg (https://drive.google.com/file/d/1pGFhBLk5fTuIhB_jC6JXwyHQ8iVD8LLq/view?usp=sharing)

The blacks on the last screenshot are very much brighter and the whites are slightly darker than in the original PQ clip. So that clip has less contrast than it should have.

FYI: By comparison with with my well calibrated OLED tv I found that mpv does an extraordinary good job of tonemapping PQ and HLG clips on well calibrated computer displays with whatever gamma curve, as long as it is given the display profile and as long as the clip does not use too much of the very high brightnesses possible in HDR. It is helpfull if the computer display has a wide gammut of P3 so that at least the colors do not need to be tonemapped too much.

FranceBB

5th January 2022, 15:34

I'm preparing a new version for you to check.
I'll send it over to you via PM for legal reasons.

ErazorTT

5th January 2022, 18:25

Out of interest, what size would you guys think is enough for the LUT for converisons from PQ to HLG?

FranceBB

5th January 2022, 18:31

Out of interest, what size would you guys think is enough for the LUT for converisons from PQ to HLG?

33x33x33 is the minimum required to be considered broadcast quality, 65x65x65 is recommended.

I would never use anything like 17x17x17.

wswartzendruber

5th January 2022, 20:17

Unrelated

I put some numbers into a spreadsheet and effectively demonstrated a theorem: Multiplying gamma-corrected values by a smaller amount produces the same result as multiplying linear values by a larger amount.

This makes me wonder if multiplying PQ values by a smaller amount isn't what I'm supposed to be doing to adjust an image's brightness.

ErazorTT

6th January 2022, 00:42

well no, actually not.
Let's say z is the linear signal, n the factor on that linear signal, and Z is the non-linear signal with N is the factor on that non-linear signal then what you mean is:

N*Z = OETF(n*z) with N=f(n) for all z

That is not generally the case. Actually that is only the case if we're talking about a pure gamma curve where OETF(x)=x^k.
But not even BT.709 is a pure gamma curve, it has the linear part in the blacks. PQ is full of additive constants and HLG does not even remotely try to be a gamma curve. So you will never have a single pair (n,N) which statisfies the above equation for all z over the whole range. Thus a multiplication on the linear side is not equal to a multiplication on the non-linear side.

So if you want to change brightness via multiplication you must do this on the linear signal and not on the non-linear signal.

wswartzendruber

6th January 2022, 01:31

ErazorTT

6th January 2022, 01:53

I am very pleased but the performance of your LUT generator. That first comparison I saw with the official LUTs showed me that what you implemented is actually spot on! You did a great job!
And actually some of the other conversion methods currenlty compatible to avisynth should really not be used, I'm talking about DGPQtoHLG or HDRTools. These absolutely do not do the right thing! (I have some awefull examples if there are any doubts about that statement)

What you should do is to add a reference to your software here: http://avisynth.nl/index.php/External_filters
(I can help there, if help is needed)

And we somehow need to get rid of the ones which do not do the converison properly. Because I lost at least a couple of days looking into these two.

wswartzendruber

6th January 2022, 01:56

Thank you!

I'd like to wait until 0.4.0 for listing it. That's going to have arguably better tone mapping. (It will map the RGB channels independently, which doesn't allow out-of-gamut results.)

I need to get some scripts ported to Windows (PowerShell?) and then that can happen.

ErazorTT

6th January 2022, 02:14

No need to port scripts to windows. Just install the bash shell on windows, its in the package of git for windows:
https://gitforwindows.org/

Just install this, and you have a fully functional bash shell in windows.

wswartzendruber

6th January 2022, 07:09

Here's 0.4.0:

https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F0.4.0

I ported the BASH scripts over to PowerShell (for the Windows zip) so people could use them more easily.

FranceBB

6th January 2022, 08:58

That first comparison I saw with the official LUTs showed me that what wswartzendruber implemented is actually spot on! He did a great job!

Yep. @wswartzendruber you should have got the file I sent which has been encoded using the official BBC LUT through Avisynth, namely:

video=FFVideoSource("\\mibctvan000\Ingest\MEDIA\temp\PQ2HLG-20220105T125539Z-001\PQ2HLG\PQ.mkv")
audio=BlankClip(length=607, fps=24000, fps_denominator=1001, channels=1)
AudioDub(video, audio)

#From 4:2:2 16bit planar Narrow Range to RGB Planar 16bit Full Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:full", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\1a_PQ1000_HLG_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=true)

#From RGB 16bit planar Full Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P10", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

and the result is close.

@ErazorTT I'm now encoding the test patters you sent me with the official BBC LUT and I'll post the 7 days link to the result here if you don't mind, so that everyone else can take a look at it too.

The idea, after that, would be to try to recreate a LUT as close as possible to the official one, so I'll send you back a new LUT file as well later in the afternoon.

ErazorTT

6th January 2022, 10:10

Here's 0.4.0
Awesome! I will test!

@ErazorTT I'm now encoding the test patters you sent me with the official BBC LUT and I'll post the 7 days link to the result here if you don't mind, so that everyone else can take a look at it too.

Sure, I have created those patterns with my own avisynth scripts, which are part of my calibration pattern suite. So I could actually also post those, if anybody needs PQ or HLG test patterns.

FranceBB

6th January 2022, 11:56

There we go:

Color Saturation Steps: https://we.tl/t-gwqgHChcyZ
Gray Steps: https://we.tl/t-q8f4O5AGpt

(link valid for 7 days, so hurry up eheheheh)

This should produce really really similar results to the official BBC LUT: https://github.com/FranceBB/LinearTransformation/blob/master/PQ_to_HLG.cube

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

BBC LUT (left) - My LUT, new Implementation (right)

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

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

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

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

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

ErazorTT

6th January 2022, 15:38

There we go:

Awesome! After looking closely into the results I must again complement you guys!

So FranceBB's v1.9 PQ_to_HLG.cube LUT is alomst identical as the results with wswartzendruber's hlg-tools v0.3.0 and 0.4.0 with the settings of max-cll 1000 and ref-white 203. The differences are only single 8bit values apart, and that only in very view of all the test squares of the patterns.
And the best is that both are extremely simular to the output using the official LUT! So a big thumbs up there!

The big advantage of the hlg-tools generator is that the LUT can be adjusted to whatever max limunosity is needed, while in contrast the fixed LUT's all will cut abruptly at 1000nits, which might be undesirable. And if more tuning is needed, there is also the possibility of changing the ref-white (or the brightness factor).

I have to ask though, was that expected that 0.3.0 and 0.4.0 return exaclty identical results? Perhaps however the differences are below the 8bit threshold for which I tested.

wswartzendruber

6th January 2022, 16:43

I have to ask though, was that expected that 0.3.0 and 0.4.0 return exaclty identical results? Perhaps however the differences are below the 8bit threshold for which I tested.
For a reference white of 203 nits and a MaxCLL of 1,000 nits, they should produce identical results.

Functionally, 0.4.0 does tone mapping a bit differently, but that only matters for MaxCLL values above 1,000 nits (or if you boost the brightness so that MaxCLL gets pushed up above that internally).

Internally, there was a lot of code refactoring that went into 0.4.0 to better organize things.

EDIT: I kind of want to get a wiki going of different 4K UltraHD discs and the pq2hlg settings that should be put into it for each movie.

FranceBB

6th January 2022, 17:28

Awesome! After looking closely into the results I must again complement you guys!

So FranceBB's v1.9 PQ_to_HLG.cube LUT is alomst identical as the results with wswartzendruber's hlg-tools v0.3.0 and 0.4.0 with the settings of max-cll 1000 and ref-white 203. The differences are only single 8bit values apart, and that only in very view of all the test squares of the patterns.
And the best is that both are extremely simular to the output using the official LUT! So a big thumbs up there!

Nice! :D
Thank you for testing and making me work on this once more, I'm always happy to improve things. :)

The big advantage of the hlg-tools generator is that the LUT can be adjusted to whatever max limunosity is needed, while in contrast the fixed LUT's all will cut abruptly at 1000nits, which might be undesirable.

Yes, in particular, professionally wise, at Sky we have 3000 LUTs (I'm not joking) one for each nit, from 1000 nits to 4000 nits and we receive a masterfile like an Apple ProRes 4:4:4 10bit or 12bit or a Motion JPEG2000 4:4:4 12bit or a DNXHQX 4:2:2 12bit and an xml file in which the MaxCLL value is stored and from that we have a workflow that picks up that value and generates an Avisynth Script with the right LUT. Anything lower than 1000 nits uses the 1000 nits LUT, anything higher than 4000 nits uses the 4000 nits LUT 'cause we haven't got anything higher than that so far. Unfortunately I can't share those 'cause they're for internal use only (just like the BBC LUTs, they are licensed by the BBC to the individual broadcasters).
Still I gotta say, @wswartzendruber, impressive work, looks like you finally got it right this time! :D
Amazingly enough, something that you started as a hobby-like project, turned out to be so reliable that is able to produce professional-like results. Well done! ;)
I don't know why many people over the past months didn't bother to reply or help you, but I knew you would have got this on your own eventually. :D

wswartzendruber

6th January 2022, 17:44

I'm curious as to how pq2hlg's generated LUTs compete with the licensed ones you have.

Do you have the means+time+patience to compare pq2hlg at 4,000 nits MaxCLL to one of your licensed LUTs?

FranceBB

6th January 2022, 20:50

Do you have the means+time+patience to compare pq2hlg at 4,000 nits MaxCLL to one of your licensed LUTs?

Absolutely.
I think it's gonna be a useful exercise for us all. I stand on the free and open source software side, so the more open source softwares improve, the better.
Tomorrow I'm gonna be back at work and I'm gonna be busy hardsubbing the UHD HDR HLG Italian dubbed version of The Town with the Italian typesetting and it will take me a while 'cause it's always a bit of a pain in the... *Beep* to work with typesetting in HLG, especially given that Aegisub is stuck in the stone age (2014) and has no idea whatsoever of any colour curve and I have to use the colour picker to get exactly the same levels of the HLG video and then use a separate waveform monitor to cross check everything...

(You may think that official studios and professional use fancy paid HDR aware subtitling/typesetting software, but no, we're in the same tedious painful mess as the rest of the world eheheheh).

Anyway, I'm digressing, long story short, if I'm gonna have time tomorrow, I'll repeat the tests with the official 4000 nits LUT and see what happens. :)

FranceBB

7th January 2022, 11:46

p.s "What's the most common thing you do at work?"

Me: Wait for indexing

LMAO

https://i.imgur.com/5QTbeCy.png

(456 GB worth of mezzanine file, it's gonna take forever ehehehehe)

wswartzendruber

10th January 2022, 20:15

Of course, if this turns out too well, I'll probably have the BBC pissed off at me for taking away a source of revenue.

wswartzendruber

14th January 2022, 02:33

I've just now realized that GitHub has wikis!

https://github.com/wswartzendruber/hlg-tools/wiki/Movies-Database

I'll be filling this out as I work through my Marvel collection (really mad at DC right now).

ErazorTT

15th January 2022, 17:38

Anyway, I'm digressing, long story short, if I'm gonna have time tomorrow, I'll repeat the tests with the official 4000 nits LUT and see what happens. :)

Any news on that front? I'm still holding my breath :P

FranceBB

15th January 2022, 18:16

Any news on that front? I'm still holding my breath :P

Unfortunately I've had a bit of a rough series of days, as I've been busy with several issues (XDCAM frame properties and indexers reporting the wrong chroma location value, which screwed up some workflows I had. You can see the whole story on Avisynth Development, Avisynth+. As soon as that thing is solved/fixed, I'll spend time on the LUTs again, I promise).

ErazorTT

17th January 2022, 13:25

I ran tests with different lum-scales and I think there is something I do not understand.

Let's say I have a PQ clip with a maxcll of 1000, then I'm first going to try out a LUT setting maxcll of 1000 and a scale of 1.0.

Now lets say I find that a scale 2.0 would be more fitting. What happens is that everything is brightened, including the whites.
My tests showed that the whites are all pushed to the max brightness bin (1023 or 940 whatever you prefer)! So now there is loss of information since all whites are pushed together into the max brighteness.
Shouldn't maxcll be thus increased according to the scale? Thus when the scale is increased to 2 the maxcll should also be increased to 2000, to leave place for all the whites?
2000 is perhaps too much, but I'm pretty sure it should be increased to something above 1000.

Or is all that not the case and I somehow mess up the processing?

wswartzendruber

17th January 2022, 17:13

FranceBB

17th January 2022, 17:18

Ok, so, the issue doesn't seem to be closed and it's making us all talk a lot here: https://forum.doom9.org/showthread.php?t=181351 and yet the FFMpeg developers don't seem to care: https://trac.ffmpeg.org/ticket/9598 which is actually annoying me as this is a problem which affects our production environment.
That being said, I've actually temporarily worked around the thing by pretending to be using Avisynth 3.7.0 instead of 3.7.1 or 3.7.2 by using propClearAll() after every file I index, which is far from being perfect, but still...

Anyway, here are the samples encoded with the official BBC LUT 4000 nits

ColorSaturationSteps BT.2100 PQ - ColorSaturationSteps BT.2100 PQ_BBC_LUT_4000_nits: https://we.tl/t-KLyDHIyaeq

GraySteps All - GraySteps All_BBC_LUT_4000_nits: https://we.tl/t-dqPcNT4B3y

(Link valid for 7 days)

ErazorTT

17th January 2022, 19:06

Hm that is weird. The BBC lut produces two steps at almost exactly the same non-white brightness (red arrows in the grayBBC.png picture). These steps are apart 5% of the signal, which for PQ is really a lot in absolute terms. So that must be wrong!

Addionally, I took out my colorspace calculation sheet and found that a 4000nits white is at a 8bit value of 198 for a limited range signal. So actually in the picture the step with an orange arrow should already have been completly white, since that is at a value of 202. (Always assuming that I implemented my calcualtion sheet correctly which is quite a big if.)

The lut generator however produces anything as I expected. See picture gray_4000_1.0.png.

I also added the original grayPQ.png but with the signal values written as text so that anybody knows which step is which.

https://drive.google.com/drive/folders/1oDy8Z9iQ3fre14HLHfyNcGKpFVtHVYQT?usp=sharing

FranceBB

17th January 2022, 19:15

Well, left you have 4000 nits, right you have 1000 nits:

https://i.imgur.com/8rvqGyi.png

The script is:

video=FFVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\GraySteps All.mkv")
audio=BlankClip(length=719, fps=24000, fps_denominator=1001, audio_rate=48000, channels=1)
AudioDub(video, audio)

propClearAll()

z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:full", resample_filter_uv="spline64", dither_type="error_diffusion")

bbc4000=Cube("C:\Program Files (x86)\AviSynth+\LUTs\2a_PQ4000_HLG_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=true)
bbc1000=Cube("C:\Program Files (x86)\AviSynth+\LUTs\1a_PQ1000_HLG_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=true)

StackHorizontal(bbc4000, bbc1000)

z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

and indeed you can see more steps in the 4000 nits one, just take a look at the whites.

wswartzendruber

17th January 2022, 19:19

I'll mess with all this once I get off work.

ErazorTT

17th January 2022, 19:29

and indeed you can see more steps in the 4000 nits one, just take a look at the whites.

Yes there are more steps in the 4000nits. But actually its too many steps. The BBC lut looks to be wrong, as I wrote in my previous post:

Hm that is weird. The BBC lut produces two steps at almost exactly the same non-white brightness (red arrows in the grayBBC.png picture). These steps are apart 5% of the signal, which for PQ is really a lot in absolute terms. So that must be wrong!

Addionally, I took out my colorspace calculation sheet and found that a 4000nits white is at a 8bit value of 198 for a limited range signal. So actually in the picture the step with an orange arrow should already have been completly white, since that is at a value of 202.

Also look at the files I posted there.

ErazorTT

17th January 2022, 19:32

I'll mess with all this once I get off work.

Currently I don't think you should do any changes to your code. Your result appears to be on point for me. (In contrast to the BBC lut, which appears to be somehow messed up)
At least for a luma-scale of 1.0. For Factors above I'm not so sure, I still think there is something fishy.

wswartzendruber

17th January 2022, 20:27

At least for a luma-scale of 1.0. For Factors above I'm not so sure, I still think there is something fishy.
From a theoretical standpoint, the PQ to HLG conversion process fundamentally has one parameter: Lw. This controls the reference peak luminance.

Now, I could have pq2hlg alter this value according to MaxCLL after any --lum-scale adjustment, but as BT.2408-4 page 23 explains, "the signal level for diffuse white will vary." I made a decision early on that Lw would always be fixed to 1,000 nits, which is what BT.2408 calls for.

Ergo, the pq2hlg process consists of three fundamental steps:

1. Scale luminosity to get reference white where it should be (if specified).
2. Tone map everything from the working maximum down to 1,000 nits.
3. Perform the PQ-to-HLG conversion process.

FranceBB

17th January 2022, 22:59

Tomorrow I'll repeat the test with the Warner Bros approved one and I'll compare it to the BBC one and we're gonna see the differences. Ironically, Warner didn't approve the BBC one, which probably means that there must be something odd indeed.

ErazorTT

18th January 2022, 00:20

@wswartzendruber: I rechecked what I was doing in 16bits, and as it appears everything is fine just as you said. It's doing exactly the right thing for lum-scale!
Doing things in 10bits made it appear that the "point of max whiteness" was moving to the dark side on a greyscale ramp when lum-scale was increased. But that was only due to rounding errors on 10 bits. Interesting, I would have thought that 10bits would be enough precision for anything I'm doing.

@FranceBB: yes, that would be interesting as well

wswartzendruber

18th January 2022, 04:12

Looks like I'm at odds with the BBC on what a 4,000 nit LUT should do:

http://wswartzendruber.net/images/bbc-vs-pq2hlg-4000-nits.png

Telling pq2hlg that the MaxCLL is 10,000 nits produces a much closer result to the BBC's LUT:

http://wswartzendruber.net/images/bbc-vs-pq2hlg-10000-nits.png

FranceBB

18th January 2022, 09:31

Ok, looks like the BBC 4000 nits LUT is doing something particular indeed, but if anything the WB approved one is even... more peculiar, let's put it this way.
This is the Warner 4000 nits LUT:

video=FFVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\GraySteps All.mkv")
audio=BlankClip(length=719, fps=24000, fps_denominator=1001, audio_rate=48000, channels=1)
AudioDub(video, audio)

propClearAll()

#From 4:2:2 16bit planar Narrow Range to RGB Planar 16bit Narrow Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\WarnerBros_PQToHLG_MaxCLL_4000.cube", fullrange=true)

#From RGB 16bit planar Narrow Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:limited=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

Warner 4000 nits left, BBC 4000 nits right:

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

Color Saturation Steps Warner Bros approved LUT 4000 nits encode: https://we.tl/t-JezXgoCRzm

Grey Steps All Warner Bros approved LUT 4000 nits encode: https://we.tl/t-QZ5iX3gvOI

@wswartzendruber... can you check if this one checks out with your output?

ErazorTT

18th January 2022, 13:47

z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\WarnerBros_PQToHLG_MaxCLL_4000.cube", fullrange=true)

#From RGB 16bit planar Narrow Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:limited=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

Why the heck are you converting to limied range rgb and then have the lut run on full range?

FranceBB

18th January 2022, 14:19

Why the heck are you converting to limied range rgb and then have the lut run on full range?

the full range thick there doesn't matter, that particular LUT is Narrow Range in - Narrow Range Out, so basically Limited TV Range in, Limited TV Range Out.

If you set it to false, it's not gonna work correctly, 'cause every time you convert to RGB with something like Convertto etc it will expand levels to Full Range and at that point it's too late.

FranceBB

18th January 2022, 14:34

This is a 1000 nits movie.

FFVideoSource("\\Mibcpmcs011.avid.mi.bc.sky.it\raid0\MASTERFILES\Godzilla vs Kong H.265 UHD HDR PQ BT2020 YUV422 23,976p 10bit.ts")

propClearAll()

#From 4:2:2 16bit planar Narrow Range to RGB Planar 16bit Narrow Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

#From PQ to HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\WarnerBros_PQToHLG_MaxCLL_1000.cube", fullrange=true)

#From RGB 16bit planar Narrow Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:limited=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

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

As you can see black sits perfectly at 4096 ('cause we're working in 16bits) and everything is nice and dandy.
Same goes for frame 1382:

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

Now, here's what happens with this other script:

FFVideoSource("\\Mibcpmcs011.avid.mi.bc.sky.it\raid0\MASTERFILES\Godzilla vs Kong H.265 UHD HDR PQ BT2020 YUV422 23,976p 10bit.ts")

propClearAll()

ConvertBits(16)
ConvertToPlanarRGB()
Cube("C:\Program Files (x86)\AviSynth+\LUTs\WarnerBros_PQToHLG_MaxCLL_1000.cube", fullrange=false)
ConverttoYUV422()

The result is CLEARLY wrong:

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

and indeed you can see the black sitting far too high:

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

and this is ALSO WRONG:

FFVideoSource("\\Mibcpmcs011.avid.mi.bc.sky.it\raid0\MASTERFILES\Godzilla vs Kong H.265 UHD HDR PQ BT2020 YUV422 23,976p 10bit.ts")

propClearAll()

z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

Cube("C:\Program Files (x86)\AviSynth+\LUTs\WarnerBros_PQToHLG_MaxCLL_1000.cube", fullrange=false)

z_ConvertFormat(pixel_type="YUV422P16", colorspace_op="rgb:std-b67:2020:limited=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

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

as you can clearly see that the black is far too high.

So, in a nutshell, to recap the officially used LUTs:

-> The BBC one works in Full PC Range RGB
-> The WB approved one works in Studio RGB (i.e Limited TV Range)

therefore, for the Warner Bros approved one, you need to first bring everything to Studio RGB 16bit planar and THEN apply the LUT, then go back to Limited TV Range YUV without touching the levels. This is pretty common in the industry and honestly the only reason why the BBC one works in full range is that they made two version of the same LUT one that works in Full Range RGB and the other that works in Limited TV Range RGB.
I've been encoding plenty of movies this way and never had any problems as they all passed QC before going on air, so no worries, I know what I'm doing ehehehehehe
Besides, this is the main reason why I've been using avsresize in all my workflows here at work.

ErazorTT

18th January 2022, 15:56

that particular LUT is Narrow Range in - Narrow Range Out

ok that's the answer. So in contrast to the lut generator these are for the narrow range. I wasn't aware of that.

SeeMoreDigital

18th January 2022, 16:38

Color Saturation Steps Warner Bros approved LUT 4000 nits encode: https://we.tl/t-JezXgoCRzm

Grey Steps All Warner Bros approved LUT 4000 nits encode: https://we.tl/t-QZ5iX3gvOI

Newbie question...

Is there any particular reason why these samples have been encoded in 10-bit AVC instead of 10-bit HEVC?

There's very little hardware SoC playback support for 10-bit AVC.

Cheers

wswartzendruber

18th January 2022, 17:17

Is anyone using SoC devices to compare these clips?

SeeMoreDigital

18th January 2022, 17:47

Is anyone using SoC devices to compare these clips?
The media players on loads of 'smart' televisions support HLG HDR encoded using HEVC in either .mkv, .mp4 or .m2ts...

ErazorTT

18th January 2022, 19:17

I wasn't even aware that these were AVC's that FranceBB was sharing. I would think that for actual encoding HEVC would be his prefered format as well, but here we're just sharing test clips for quick assessment.

Me at least, I'm encoding anyhting 8bits in AVC and anything 10bits in HEVC.

FranceBB

18th January 2022, 19:19

Newbie question...

Is there any particular reason why these samples have been encoded in 10-bit AVC instead of 10-bit HEVC?

There's very little hardware SoC playback support for 10-bit AVC.

Every file I encode is not intended for consumers SoC but for professional SoC.

What professional SoC like Versio want is an XAVC Intra Class 300 with PCM audio muxed in MXF.

In a nutshell, it's a file in which all frames are intra and their weight is exactly the same, it's level 5.2, 4:2:2, 10bit H.264.

http://www.avsol.net/images/stories/virtuemart/product/Versio.png

Just FYI if you're a consumer, those kind of files are the ones which are re-encoded live in H.265 4:2:0 25Mbit/s 10bit with AC3 audio, muxed in .TS ;)

SeeMoreDigital

18th January 2022, 19:31

Every file I encode is not intended for consumers SoC but for professional SoC.

What professional SoC like Versio want is an XAVC Intra Class 300 with PCM audio muxed in MXF.

I don't think the 'professional' end of the market was the spec wswartzendruber was originally aiming for...

wswartzendruber

18th January 2022, 19:48

I don't think the 'professional' end of the market was the spec wswartzendruber was originally aiming for...
They're just expendable test clips that show us output signal level for a given signal input and LUT transform. They're not at all intended for end user viewing.

My personal HLG library is encoded as 10-bit HEVC.

What these test clips are encoded as is irrelevent so long as they convey the information correctly and thread participants can see them. These aren't meant for viewing, but for study with dedicated equipment.

FranceBB

18th January 2022, 19:50

I don't think the 'professional' end of the market was the spec wswartzendruber was originally aiming for...

Sure, but those are just samples, it doesn't really matter how I deliver them. Why would I change a BAT that I know works for something that I have to create from scratch?
I'm at work, I don't have any consumer BAT files, I encoded what was more convenient for me eheheheh

What these test clips are encoded as is irrelevent so long as they convey the information correctly and thread participants can see them. These aren't meant for viewing, but for study with dedicated equipment.

Exactly. :)

SeeMoreDigital

18th January 2022, 19:57

Thanks guys,

Needless to say, I'd be most interested in seeing some of 'before' (HEVC HDR10) and 'after' (HEVC HDR10 HLG) HEVC encoded samples, to see how well my TV and OPPO handles them ;)

FranceBB

18th January 2022, 20:07

Thanks guys,

Needless to say, I'd be most interested in seeing some of 'before' (HEVC HDR10) and 'after' (HEVC HDR10 HLG) HEVC encoded samples, to see how well my TV and OPPO handles them ;)

Fine.
I'm a consumer myself, by the way, regardless of my job I watch TV series too, so my library is made of consumer BD eheheheh
I can share a sample, I should have something somewhere, but it's gonna be short. Perhaps Gemini Man could be a good fit. I'll do that tomorrow, though, right now I'm at dinner and later I'm gonna watch Brighton Vs Chelsea ;)

wswartzendruber

18th January 2022, 20:23

FranceBB

18th January 2022, 20:47

EDIT: What is "HDR10 HLG?"

Nothing, he probably means H.265 10bit HLG eheheheh

frank

19th January 2022, 20:18

The LG TV displays the HLG HDR logo for 5 seconds at the top right when you play an HLG video.

ErazorTT

20th January 2022, 16:48

wswartzendruber

20th January 2022, 21:48

There is something that I still cannot wrap my head around. The PQ standard is very obvious and strict in that it's actualy a standard of absolute luminosity. Why do the movies then need such a wide range of lum-scale to equalize them?
SMPTE says reference white goes at 100 nits. The ITU says that value should be 203 nits.

Alita: Battle Angel puts it around 47 nits (the darkest I've encountered). Shazam's is something stupid like 500+ (the brightest I've encountered).

I have no idea why studios are all over the place with it.

EDIT: I've noticed something somewhat common. Once you adjust the luminosity, the internal MaxCLL value ends up being very close to 1,000 nits. Sometimes I wonder if these movies aren't graded to 1,000 nits with reference white at 203 nits, and then scaled down so that TVs that can't reach 1,000 nits can still display more of the originally intended changes in brightness.

EDIT: And I was wrong about Shazam. It's reference white level is only 369 nits or thereabouts.

ErazorTT

21st January 2022, 10:05

EDIT: I've noticed something somewhat common. Once you adjust the luminosity, the internal MaxCLL value ends up being very close to 1,000 nits. Sometimes I wonder if these movies aren't graded to 1,000 nits with reference white at 203 nits, and then scaled down so that TVs that can't reach 1,000 nits can still display more of the originally intended changes in brightness.

How do I get a hold on the internal MaxCLL?

wswartzendruber

21st January 2022, 17:11

(internal MaxCLL) = --max-cll * --lum-scale

or

(internal MaxCLL) = --max-cll * (203 / --ref-white)

It's not something you really need to take into consideration, however. pq2hlg determines this value for you. If it exceeds 1,000 nits, then pq2hlg will generate a tone map curve specific to the internal MaxCLL value.

FranceBB

21st January 2022, 19:19

Little update: I'll delay the encode and share of a real life sample a bit 'cause FFMpeg 5.0 introduced IMF decoding and it's something I've been waiting since April 2016 (when no one really knew anything about it and there was no way to work with it) (https://forum.doom9.org/showthread.php?t=173372) so I'm as happy as Larry :D

frank

22nd January 2022, 11:38

Alita has 5 different cll metadata:
LIGHT 285 63
LIGHT 737 130
LIGHT 1000 18
LIGHT 257 1
LIGHT 505 13

The core movie at 737 130.
Includes HDR10, DoVi, and HDR10+
That is the culprit. Someone played with parameters without changing the content.

The mastering display has 1000 nit / 0.0001 nit.
So stay on the standard with the PQ_to_HLG matrix (1000nit), and you will get a perfect HLG conversion.
Testet on LG OLED48CX.

frank

22nd January 2022, 12:24

Content light metadata are only used if the display has not the desired luminosity. HDR10 strictly follows smpte2084. The TV scales itself brightness and contrast.
HLG arib-std-b67 is based on max 1000nit. The TV knows that and scales brightness automatically without HDR metadata.
repeat-headers for HLG is not necessary.

wswartzendruber

22nd January 2022, 18:36

frank

22nd January 2022, 22:23

Oh, I still have to test on SDR...

wswartzendruber

23rd January 2022, 01:24

Oh, I still have to test on SDR...
pq2hlg -m 737 -l 4.75 -s 65 pq2hlg-alita.cube

frank

24th January 2022, 19:42

Thanks.
I tested -m 1000 -r173
because of 130 x 4/3 = 173
Is better but I am not satified.

Let's go with your findings.

frank

24th January 2022, 19:57

Please change back the status lines like

# Generated by PQ2HLG 0.4.0
# ref-white: 203
# max-cll: 1000
...

in pq2hlg.
It is better for later doc of the cube.

wswartzendruber

25th January 2022, 04:20

Please change back the status lines like

# Generated by PQ2HLG 0.4.0
# ref-white: 203
# max-cll: 1000
...

in pq2hlg.
It is better for later doc of the cube.
Fresh out of the oven: PQ2HLG 0.4.1 (https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F0.4.1)

frank

27th January 2022, 22:02

Thank you! :)

On my Alita tests I saw a big issue. VLC and mpv have different display outputs. mpv goes much earlier into level saturation!
I only can go until -l 2.5...3.0 for HLG. Otherwise you will be dazzled by white.

Which prog does it right? Different specs? max cll 100 vs 203?

I'll make further tests with the built-in player of LG TV.

--------------
System: Win 10 Pro on Dell XPS 15 9510

wswartzendruber

27th January 2022, 22:07

Do not use MPV for critical monitoring. It adjusts gain as the video plays back.

wswartzendruber

31st January 2022, 17:59

@FranceBB: What's the latest here? Surely you can understand why I would want someone with access to professional equipment assessing my work against industry assets.

FranceBB

1st February 2022, 18:46

@FranceBB: What's the latest here? Surely you can understand why I would want someone with access to professional equipment assessing my work against industry assets.

I'm busy with IMF guys... :(

wswartzendruber

3rd February 2022, 17:13

Whos parliament do I have to contact to get you out of this? :)

FranceBB

3rd February 2022, 17:35

Whos parliament do I have to contact to get you out of this? :)

Send an email to my boss saying: Hey, Doom9/Avisynth/LUTs are part of Frank's job, he's not doing those for fun.

(The fact that I have fun with this is different eheheheh)

Jokes aside, I have an idea. I sent you a PM.

wswartzendruber

5th February 2022, 05:45

Send an email to my boss saying: Hey, Doom9/Avisynth/LUTs are part of Frank's job, he's not doing those for fun.

(The fact that I have fun with this is different eheheheh)

Jokes aside, I have an idea. I sent you a PM.
Lemme get this together. I've had other crap going on.

Balling

8th February 2022, 06:21

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.

BT.2408 is only supported in --vo=gpu-next, not --vo=gpu

Untill like 10 days ago gpu-next was not even decoding YCbCr correctly (like gray was not even equal in all 3 channels after to R'G'B'), so be more careful with it. We are still testing it. See https://github.com/haasn/libplacebo/commit/953dcdb3806d1df47b6a560bd3b699d698241a68

wswartzendruber

8th February 2022, 17:27

BT.2408 is only supported in --vo=gpu-next, not --vo=gpu

Untill like 10 days ago gpu-next was not even decoding YCbCr correctly (like gray was not even equal in all 3 channels after to R'G'B'), so be more careful with it. We are still testing it. See https://github.com/haasn/libplacebo/commit/953dcdb3806d1df47b6a560bd3b699d698241a68
That original post turned out to not be true. I was scaling luminosity correctly.

Now what's this about BT.2408 not being supported. What part of BT.2408? It's gotten rather comprehensive.

Balling

11th February 2022, 13:20

That original post turned out to not be true. I was scaling luminosity correctly.

Now what's this about BT.2408 not being supported. What part of BT.2408? It's gotten rather comprehensive.

It is not supported in stable --vo gpu. Only in --vo gpu-next.

wswartzendruber

25th February 2022, 21:13

There are some comparisons I am going to soon be doing to compare pq2hlg against commercial variants. Before that, there is a rare case I would like to be able to handle. HLG limits the maximum level any color channel can reach by itself.

Red, by itself, maxes out at 201.1 nits instead of 262.7.
Green, by itself, maxes out at 627.3 nits instead of 678.0.
Blue, by itself, maxes out at 33.7 nits instead of 59.3.

Now I could just hard-clip a channel that violates this. But what I'm considering is elevating the other channels to reach the same luminance that the single color channel calls for. This will produce the same level of brightness, but slightly desaturate those pixels.

I'll listen to any remarks on this approach before proceeding to implement it.

wswartzendruber

23rd March 2022, 05:17

I've just pushed some updates to Git that change the default tone mapping approach from R'G'B' to maxRGB.

ErazorTT

26th March 2022, 13:09

... change the default tone mapping approach from R'G'B' to maxRGB.

I have no idea what any of that means but I guess you know what you're doing..
BTW, I'm still using your tool all the time now for all my encodings.

wswartzendruber

27th March 2022, 23:28

I have no idea what any of that means but I guess you know what you're doing..
BTW, I'm still using your tool all the time now for all my encodings.
Are you encoding UHD discs, or some other source?

Has the documentation been helpful?

Are you aware that documentation exists?

ErazorTT

29th March 2022, 00:00

Are you encoding UHD discs, or some other source?

Has the documentation been helpful?

Are you aware that documentation exists?

only UHD discs. I have read the github documentation. And yes it was helpful.

For other people to find this software, I would really think you should add a link also to the list of avisynth filters: http://avisynth.nl/index.php/External_filters

Reel.Deel

29th March 2022, 00:07

For other people to find this software, I would really think you should add a link also to the list of avisynth filters: http://avisynth.nl/index.php/External_filters

Although technically is not an AviSynth plugin. However, I did added to the external links section of the AVSCube (http://avisynth.nl/index.php/AVSCube#External_Links) plugin a while back.

wswartzendruber

14th April 2022, 03:02

https://github.com/wswartzendruber/hlg-tools/releases/tag/release/1.0.0

This concludes active development. Any new releases from here will be in response to community feedback.

wswartzendruber

12th May 2022, 03:06

Special thanks to ErazorTT for reporting the bug that lead to this release:

https://github.com/wswartzendruber/hlg-tools/releases/tag/release/1.0.1

ErazorTT

17th May 2022, 14:17

I'm currently trying to find a rigorous way to determine the luma scale. Trying to come up with somthing I found this discrepancy and I cannot wrap my head around it.

Here I am plotting the display brightness of the HLG curve and the SDR curve with 100%=203nits.
Since the HLG specifications say that 100% signal value on the SDR picture should represend 75% signal value on the HLG picture, and 75% of the HLG signal are 203nits, I am using these 203nits as maximum for the SDR curve.

https://i.postimg.cc/NLpgjN61/SDR100eq-HLG75.png (https://postimg.cc/NLpgjN61)

But as can be seen, the two curves never match! So I am currently questioning your recommendation to "use a frame with a caucasian face in a well-lit environment, comparing the brightness of that face".

The curves would be matching in the lower half if one would be using the definition of 89%SDR=75%HLG. Since then the curve look like that:

https://i.postimg.cc/Jt1rmwkr/SDR89eq-HLG75.png (https://postimg.cc/Jt1rmwkr)

So in the case of 89%SDR=75%HLG one can directly comare the brightnesses of the darks and the midtones. But this does not follow the assumption that 100%SDR=75%HLG.

In order to be able to compare the brightness using the 100%SDR=75%HLG definition, one needs to first scale the values of the HLG stream before one can compare them to the SDR stream. The factor to increase signal values of the HLG stream would be 1.123. This would produce the following curves:
https://i.postimg.cc/7CGVfQJb/SDR100eq-HLG75-1-123.png (https://postimg.cc/7CGVfQJb)

wswartzendruber

17th May 2022, 15:59

This is quite intentional.

BT.2408-4 section 5.1.2.1 does state that SDR displayed within HLG should have 100% SDR mapped to 75% HLG. This is effectively mapping SDR maximum white to HDR reference white.

Elsewhere, BT.2390-9 section 1.3 states the following:

In video, the system white is often referred to as reference white, and is neither the maximum white level of the signal nor that of the display.

And continues on with:

In traditional imaging, the range allocated to these highlights was fairly low and the majority of the image range was allocated to the diffuse reflective regions of objects. For example, in hardcopy print the highlights would be 1.1x higher luminance than the diffuse white maximum. In traditional video, the highlights were generally set to be no higher than 1.25x the diffuse white. Of the various display applications, cinema allocated the highest range to the highlights, up to 2.7x the diffuse white.

(Note that these are display linear values.)

This is why the preview LUTs generated by pq2hlg behave the way they do. We are not trying to map SDR within HLG, we are trying to find the SDR representation of a HLG image. As such, pq2hlg's preview mode linearly maps 0%-75% HLG to 0%-90% SDR, and it compresses 75%-100% HLG within 90%-100% SDR.

SDR does have a small amount of dynamic range for specular detail, just nowhere near as much as HLG.

ErazorTT

17th May 2022, 16:16

So then you say that 90% of the SDR signal should map to 75% of the HLG signal?

wswartzendruber

17th May 2022, 16:19

So then you say that 90% of the SDR signal should map to 75% of the HLG signal?

That is my present philosophy until someone can argue why it shouldn't be.

ErazorTT

17th May 2022, 23:33

That is my present philosophy until someone can argue why it shouldn't be.

I found a sentence in 2408-5 supporting your view. In section 7.7:
The difference in perceived mid-tone contrast arises because of the difference in the diffuse white level of an SDR image (~100 cd/m2) and that of an HDR image (~200 cd/m2).
Thus in order to compare the pixel signal values of SDR and HLG, we have to carry out the comparison under the assumption that SDR and HLG have the same diffuse white level of ~200. Making the 100% signal of SDR going above 200 in that comparison.

PS: i found an even better quote from 2408-5. Table A8.2 states the following numbers:
90%SDR = 75%HLG = 203nits
100%SDR = 79%HLG = 260nits

wswartzendruber

18th May 2022, 02:58

Uh, wow. Appendix 8 is new for the fifth revision. And it's all about how the PRC does HDR/SDR simulcasting.

And...we independently came to similar conclusions about mapping HLG to SDR.

ErazorTT

18th May 2022, 09:23

You know, I had the impression that HLG not only has more headroom in the highlights but also in blacks ("bottomroom"..? :p). At least when reading through the BBC documentations.
But now our HLG streams have basically the exact same pixel signal values in the darks and midtones as SDR. So how to reconcile this with the BBC statement?

wswartzendruber

18th May 2022, 21:57

Wait, what does the BBC say that counters this?

ErazorTT

19th May 2022, 01:25

this here for example at around minute 8:
https://www.smpte.org/webcast/dr-pq-and-hlg-presented-bbc
Granted, at this stage he talks about the camera curve (OETF) and not the display curve (EOTF), but I would have thought that there should have been also some repercussions in the display curve if the camera curve is different.

here are the slides for that talk:
https://www.dutchguild.nl/31jan2017/HLG%20Overview%20-%20Dutch%20Guild%20published.pdf
Especially slide 14, where it zooms into the curve, and one sees that the SDR curve does actually not match the HLG curve.

And then there is Figure 18 in 2390-10, again the OETF, the red HLG line is not exactly on top of the blue SDR line in the lower half, but slightly above it. Thus bringing home the same message as the plot on slide 14.

Or to put it differently: Section 5.1 and section 5.2 of 2408-5 do the SDR to HLG conversion differently. 5.1 produces an HLG signal that follows the same curve as SDR and can be matched exactly like we're doing, and 5.2 generates a HLG signal which looks more like the OETF plots I mention above.
:confused:

I am aware however that the PQ to HLG conversion does not have any of these ambiguities and has only the luma-scale as a free parameter. So all this does not contradict your LUT generator, it's a question about the expectation of what curve the birghtness of the resulting HLG will follow. And this is not clear to me. Should I expect to get basically an SDR curve in the lower half, which would match the section 5.1 SDR to HLG conversion, or should I expect to get something looking like the OETF which does not match the SDR curve and would reproduce the section 5.2 SDR to HLG conversion.

wswartzendruber

19th May 2022, 22:35

The shape of the HLG curve isn't something I considered at all. Fundamentally, I view PQ with a reference white of 203 nits and MaxCLL of 1,000 nits as being logically equivalent to HLG. Once I realized that, I came to see most of the conversion process in the context of linear display light.

In any event, the HLG curve doesn't mean what it used to. Back when HLG was going to put reference white at 50%, the shadows and midtones were going be on a SDR response curve, while the specular detail above that would be on something closer to PQ. But now, reference white is at 75%. So 1/3 of the shadows+midtones are in the PQ-area of the curve.

wswartzendruber

10th June 2022, 16:54

I didn't realize I could upload copyrighted HLG material to YouTube, but WB will apparently let me as long as I don't monetize it.

https://www.youtube.com/watch?v=D-F82b9m3Qo

Can anyone see this in HLG?

FranceBB

10th June 2022, 19:39

Can anyone see this in HLG?

Yes I can:
when people are watching with SDR BT709 capable devices, it shows 1080p and google converts the colormatrix only from BT2020 to BT709, so the reference white will still be 75%.
When people are watching with SDR BT2020, google will serve the BT2020 HLG stream (although the monitor will ignore the transfer) and the reference white will still be 75%.
In my case, I'm watching this with an HDR HLG BT2020 capable device (and a 799 nits monitor) and it offers me the right HLG stream: Settings Image (https://i.imgur.com/mNekeoD.png)

I tried to make a few screenshots while the monitor and the OS are in HDR Mode, so hopefully they're gonna give you an idea of how it looks like in HDR HLG:

Img 1 (https://i.imgur.com/neG8RKV.png) - Img 2 (https://i.imgur.com/fkVKuNs.png) - Img 3 (https://i.imgur.com/zRJLTpj.png) - Img 4 (https://i.imgur.com/xj8rD6P.png) - Img 5 (https://i.imgur.com/iK1N3JR.png) - Img 6 (https://i.imgur.com/blGF1Rd.png) - Img 7 (https://i.imgur.com/qmANPsb.png)

On a real monitor it looked really good, though... except for the fact that YouTube bit-starved everything, but that ain't HLG Tools fault.

wswartzendruber

10th June 2022, 23:27

Yeah the compression they applied is horrendous. I'm guess my small-time channel doesn't warrant any more bits than that. I would have paid them to do a better job.

wswartzendruber

11th June 2022, 03:10

I wonder if Disney will let me get away with the same thing...

FranceBB

11th June 2022, 09:05

I wonder if Disney will let me get away with the same thing...

I guess there's only a way to find out xD
Jokes aside, I wouldn't risk it.
When I upload samples they're generally stuff I recorded with my camera myself.

wswartzendruber

11th June 2022, 17:39

I've also uploaded an Alita clip.

https://www.youtube.com/watch?v=XMdFweclflY

The BT.709 presentation here looks...kind of red...

https://wswartzendruber.net/images/alita-yt709-vs-sdr.jpg

YouTube's BT.709 mapping is on the left. Native BT.709 is on the right.

kolak

16th June 2022, 21:22

Yep, looks quite saturated, but when I play YT and compare this to your grab then they don't match (maybe it's due my screen been P3 gamut and tags accuracy). YT is less saturated, but still more than the one on the right. It's hard to say which one is correct. Update: seeing HLG in native format actually one on the left looks more correct.
There can be HDR version and SDR version and HDR mapped to SDR doesn't really have to look as native SDR version.
If you want to compare you conversion to something else use Resolve which has Dolby mapping built in.
Dolby tools do best SDR from all tools I've seen. Maybe because they work per shot, so each seen is analysed for min/avg/max brightness and then mapped to SDR. This is way more optimal than global conversion.
From my tests Dolby tools preserve saturation better than eg Resolve's internal mapping filter. Overall they tend to create rather more saturated look.

I think YT now puts HDR over Dolby tools for SDR conversion, so it should be quite good. But not sure if they convert HLG to HDR10 and then use Dolby to map to SDR or do some direct HLG to SDR mappings.

FranceBB

16th June 2022, 23:03

But not sure if they convert HLG to HDR10 and then use Dolby to map to SDR or do some direct HLG to SDR mappings.

They don't for HLG, no worries about that.

The BT.709 presentation here looks...kind of red...

Speaking of the sample, I see it red-ish in HLG as well to be fair.

Those are the screenshots I grabbed while playing YouTube in HLG and with the OS being HLG aware and outputting in HLG BT 2020 like I did for Aquaman:

Img1 (https://i.imgur.com/o26N2Bt.png) - Img2 (https://i.imgur.com/bXFD2ft.png) - Img3 (https://i.imgur.com/UCFCIx7.png) - Img4 (https://i.imgur.com/OQrpJjd.png) - Img5 (https://i.imgur.com/nbh3m89.png) - Img6 (https://i.imgur.com/z4BfdYr.png)

kolak

16th June 2022, 23:13

They don't for HLG, no worries about that.

Speaking of the sample, I see it red-ish in HLG as well to be fair.

Those are the screenshots I grabbed while playing YouTube in HLG and with the OS being HLG aware and outputting in HLG BT 2020 like I did for Aquaman:

Img1 (https://i.imgur.com/o26N2Bt.png) - Img2 (https://i.imgur.com/bXFD2ft.png) - Img3 (https://i.imgur.com/UCFCIx7.png) - Img4 (https://i.imgur.com/OQrpJjd.png) - Img5 (https://i.imgur.com/nbh3m89.png) - Img6 (https://i.imgur.com/z4BfdYr.png)

It can be tested if they use Dolby mapping for HLG input or not.

Your grabs are P3 gamut with sRGB gamma.
Are they really HLG just with sRGB tag or gamma is sRGB (then it's a conversion)?

wswartzendruber

17th June 2022, 18:47

I don't know if they're gamma mapping or not...

However, I can generate a test signal for upload this weekend to find out.

wswartzendruber

17th June 2022, 19:23

They're not mapping brightness. They're just interpreting HLG as BT.709.

https://www.youtube.com/watch?v=8g0NRk1afYk

Balling

17th June 2022, 20:39

Alita is fake HDR, 203 nits everywhere. which is SDR level in 1000 nits. I would say any test with it is invalid. https://www.youtube.com/watch?v=JLmkRyhjzQ8

It mostly does not even exceed 709 primaries, which is ridiculous.

Of course it is still a cool example of blu-ray with both Dolby Vison MEL and HDR10+.

wswartzendruber

17th June 2022, 20:40

Alita is fake HDR. I would say any test with it is invalid. https://www.youtube.com/watch?v=JLmkRyhjzQ8
It's not fake HDR, it's cinematic XYZ.

And the test in this case is in color gamut and how YouTube is mapping BT.2020 to BT.709.

kolak

17th June 2022, 20:40

Hmmm- this sounds as "easy" way, but far from optimal.
Also YT requires HLG HDR been sent as Rec.2020, so you can't use P3 primaries (has to be P3 within Rec.2020).

wswartzendruber

17th June 2022, 21:55

What's a better way to upload HDR to YouTube?

kolak

17th June 2022, 21:59

Rec.2020 PQ with proper headers.

https://support.google.com/youtube/answer/7126552?hl=en#zippy=%2Chdr-video-file-encoding%2Chdr-metadata

If encoder doesn't set proper headers then use MOV container and then this tool to inject proper HDR metadata (of course video has to be Rec.2020 with PQ):

http://mogurenko.com/2021/01/29/amcdx-video-patcher-v0-6-7/

If you have small sample I can make you DV SDR mapping.

wswartzendruber

17th June 2022, 22:15

Balling

17th June 2022, 23:24

Hmmm- this sounds as "easy" way, but far from optimal.
Also YT requires HLG HDR been sent as Rec.2020, so you can't use P3 primaries (has to be P3 within Rec.2020).

Only Netflix masters use pure P3-D65 with PQ. In fact windows does not even support HLG.

>EDIT: Alternatively, I'm willing to hear arguments on why viewers need more dynamic range than what HLG offers.

Black level? 0.0001 is simply achievable and is much more important than difference between 750 nits LG C9 and 1700 nits Galaxy S22 Ultra.

>No offense, but I really wish PQ would just die when it comes to content distribution.

Yes, without 12 bit PQ in Main12 or VP9.2 12 bit it is not perfect.

kolak

17th June 2022, 23:26

kolak

17th June 2022, 23:31

No offense, but I really wish PQ would just die when it comes to content distribution.

Its proper place is in the studio.

EDIT: Alternatively, I'm willing to hear arguments on why viewers need more dynamic range than what HLG offers.

Not my decision :)
You should be happy that at least happy we've passed ancient Rec.709 and 100nits :)

Balling

17th June 2022, 23:32

You can use which you prefer until it hits some delivery spec and then you have to use what is required. All "transmission" needs Rec.2020 as this is in UHD standard.
Netflix delivery spec doesn't mandate P3, it can be Rec.2020 as well. It mandates DV though.

Last time I checked DV still mandates P3, which is less than what samsung QD-OLED support, I suppose to preserve some bitrate. Are you sure JPEG 2000 masters do not mandate P3-D65 with PQ?

kolak

17th June 2022, 23:39

Balling

17th June 2022, 23:53

I've also uploaded an Alita clip.

https://www.youtube.com/watch?v=XMdFweclflY

YouTube's BT.709 mapping is on the left. Native BT.709 is on the right.

Yes, I do not know what you did but this is absolutely wrong with blu-ray 00688.m2ts, Blu-ray is much darker.
mpv.com --target-colorspace-hint=yes -hwdec=nvdec --gpu-api=vulkan -vo=gpu-next BDMV\STREAM\00688.m2ts

mpv.com --target-colorspace-hint=yes -hwdec=nvdec --gpu-api=vulkan -vo=gpu-next --ytdl-format=335 https://www.youtube.com/watch?v=XMdFweclflY

LG C9 also agrees with the first command if not even slightly darker. Oh and changing vulkan to d3d11 MAKES NO difference at all. It is bitperfect looking.

Balling

18th June 2022, 00:04

It's always P3 gamut. No one commercially grades to Rec.2020 as nothing (realistic) can display it.
Just in case of Rec.2020 delivery it's P3 within Rec.2020 container (same a many cinema masters are just Rec.709 within P3).
Netflix delivery spec is public:
https://drive.google.com/file/d/0B9DJydDVOVKKLVdCdlF2cFVDVEE/view?resourcekey=0-GRqfy963JM9jcd-MQcaoBw

Spears & Munsil UHD HDR Benchmark was specifically graded on Laser BT.2020 projector (red tulips scene), even on FEL. Lego Batman and some others were test graded on Blu-ray as BT.2020. Matrix was graded in 2020. Latest Star wars is mostly outside P3...

QD-OLED can go into Bt.2020 no problem. Self-emissive QD will even surpass that.

In fact Ted has a giant list of movies outside P3. Oh, and there is also SDR 10 bit HEVC blu-ray tagged as Bt.2020.

Balling

18th June 2022, 00:15

Looks like it is new stuff in Netflix spec.

>Updated colorimetry to include support for ITU-R BT.2020 Dolby VisionTM HDR IMF packages

kolak

18th June 2022, 00:45

Spears & Munsil UHD HDR Benchmark was specifically graded on Laser BT.2020 projector (red tulips scene), even on FEL. Lego Batman and some others were test graded on Blu-ray as BT.2020. Matrix was graded in 2020. Latest Star wars is mostly outside P3...

QD-OLED can go into Bt.2020 no problem. Self-emissive QD will even surpass that.

In fact Ted has a giant list of movies outside P3. Oh, and there is also SDR 10 bit HEVC blu-ray tagged as Bt.2020.

As you said- all rather test titles.
If you have Rec.2020 titles then they will look different depending how much of Rec.2020 your TV can cover. Not a desired thing :) Tech has to be there in order to make a use of Rec.2020.
Do you know how much those laser projectors cost?
Also- projection gives totally different viewing experience compared to TVs as it's reflective, not emissive. These projectors are also not very bright as they are for dark rooms. There is still a lot to do.

I just watched some info abut QD and it's more like shy of 90% of Rec.2020, so still not there. We need 95%+ to start doing Rec.2020 grades. Problem is that industry still has no screen for this as pro market is dead and no one is really doing special panels for reference screens.
No idea where you read that QD-OLED can go to Rec.2020 (easily)?

kolak

18th June 2022, 00:57

Is there Lego Batman Blu-ray which is Rec.2020 (for sure) or they kept it just for cinema master?
Fact that it was graded to Rec.2020 is 0 guarantee what is on Blu-ray as you create many versions for different releases.
Not that sure big studio would be keen to release Rec.2020 grade when tech is not there ( I worked at those places).
Show me grab from this disc saying Mastering display color primaries = Rec.2020.
Not that it matters much but it is not even a native UHD tile, but 2K upscale.

Almost sure Rec.2020 grade was just for Dolby Cinemas:
https://www.avsforum.com/threads/the-lego-batman-movie-in-dolby-vision-hdr-and-atmos-sound.2747881/page-2

Balling

18th June 2022, 02:04

Not that it matters much but it is not even a native UHD tile, but 2K upscale.

Their upscale is many times better than what LG or Nvidia can give, it is not real time. Also, this is animation. And yes, Lego Batman has a lot of colors outside P3. https://www.avsforum.com/threads/christie-eclipse-projector.3018138/page-82#post-59680204

Anyway, latest Star Wars and remaster of Matrix are not P3, they were by design mastered for Bt.2020, even if tagged in MDCV as Display P3. Matrix is tagged 2020 though.
https://mobile.twitter.com/NanosysInc/status/1290434026994577408
>No idea where you read that QD-OLED can go to Rec.2020 (easily)?

This is just first gen of it. I mean it is kinda obvious.

>Also- projection gives totally different viewing experience compared to TVs as it's reflective, not emissive.

They are certainly very different SPD, so are captured on cemaras differently than TVs.

wswartzendruber

18th June 2022, 06:10

Yes, I do not know what you did but this is absolutely wrong with blu-ray 00688.m2ts, Blu-ray is much darker.
mpv.com --target-colorspace-hint=yes -hwdec=nvdec --gpu-api=vulkan -vo=gpu-next BDMV\STREAM\00688.m2ts

mpv.com --target-colorspace-hint=yes -hwdec=nvdec --gpu-api=vulkan -vo=gpu-next --ytdl-format=335 https://www.youtube.com/watch?v=XMdFweclflY

LG C9 also agrees with the first command if not even slightly darker. Oh and changing vulkan to d3d11 MAKES NO difference at all. It is bitperfect looking.
pq2hlg takes the input's reference white level into account when performing the conversion.

Alita is a cinematic XYZ transfer. So reference white is going to be 48 nits and MaxCLL is going to be 130 nits. You feed these values into pq2hlg so it can factor them into the LUT it generates. Then you'll get reference white put at 203 nits and MaxCLL tonemapped down to 1,000 nits.

EDIT: Although, since Alita doesn't use all of HLG's dynamic range, no tone mapping will take place.

kolak

18th June 2022, 10:53

Their upscale is many times better than what LG or Nvidia can give, it is not real time. Also, this is animation. And yes, Lego Batman has a lot of colors outside P3. https://www.avsforum.com/threads/christie-eclipse-projector.3018138/page-82#post-59680204

Anyway, latest Star Wars and remaster of Matrix are not P3, they were by design mastered for Bt.2020, even if tagged in MDCV as Display P3. Matrix is tagged 2020 though.
.

When you grade you have two ways: P3 settings or you grade in Rec.2020 and then you have gamut limiter. Typically this limiter is set to P3. When you export you get P3 within Rec.2020. If you grade in P3 you then export as Rec.2020 and get same end result.
Blu-ray is always Rec.2020 as there is no such a thing like P3 defined 'transmission' format. Your players sends 2020 to TV.

If you now go to 1st grading method you turn off P3 limiter and grade in full Rec.2020. Here most important is monitor. If you do so but your monitor is capable of about P3 anyway it's all good. Colorist wil see only P3 colors, but master will contain also colors up to Rec.2020 gamut. Colorist doesn't know how exactly scene is going to look with Rec.2020 capable display though as he simply can't see it. This is why standard approach is to limit gamut to P3 today.
If you grade on something close to Rec.2020 then when watched on P3 monitor you will get 'unknown preview'. You won't see what colorist did as your monitor can't display all Rec.2020 colors, so your experience is affected. I’m not sure how 'bad' or not it will manifest as I have not seen monitor which goes much outside of P3. Industry is struggling with any decent HDR screen as Sony stopped making pro OLED panels and Panasonic trashed their dual layer tech as well.
When you watch Rec.709 on poor laptop screen (still probably 50% laptop screen are <Rec.709) you get not a nice experience, so P3 vs Rec.2020 is similar but may be less drastic as P3 is already a 'lot' of colors. I assume if you have properly mastered Rec.2020 disc (so player is aware of it and does proper conversion) then it's not really destructive and you see just P3 without those 'extra' colors. In this case Rec.2020 disc are fine.
Another reason is hidden in $. Now you have P3 experience, but when tech evolves then they will sell you same content again graded to Rec.2020 :p

Matrix may be true Rec.2020 title, but was probably still graded on monitor which doesn't go much beyond that. If it was graded in Rec.2020 on laser projector then home users will not necessarily see good representation (as cinema is very different experience) of director/colorist idea, so it's not all that obvious that having out of P3 colors is a good thing today (this is why Rec.709 is/was used for so long even if studios had P3 monitors for quite a time). We need to wait for tech to catch up to use Rec.2020.

The whole idea in standard is that things are clearly defined and you grade to achievable parameters. There is no place for any mapping, approximation etc. Monitors are calibrated and follow precise math. Once you leave studio it's crazy world with TVs set all over the place, but this is another story :)

Also- any analysis like in case of Sony monitor should not be done with compressed master (or Blu-ray) as you get plenty codec overshoots so if monitor's check is "bit perfect" then many pixels will be outside of 100% P3, but only because they are overshoot. If you could set gamut to eg. 103-105% P3 (or low pass filter signal first) then results would be different. Most discs out there are P3 limited.

kolak

18th June 2022, 10:55

pq2hlg takes the input's reference white level into account when performing the conversion.

Alita is a cinematic XYZ transfer. So reference white is going to be 48 nits and MaxCLL is going to be 130 nits. You feed these values into pq2hlg so it can factor them into the LUT it generates. Then you'll get reference white put at 203 nits and MaxCLL tonemapped down to 1,000 nits.

EDIT: Although, since Alita doesn't use all of HLG's dynamic range, no tone mapping will take place.

Yes as HDR in cinema is just bit more than 100nits ( 108 nit is used by Dolby HDR cinema if I remember well). It’s still way superior experience compared to any TV.

FranceBB

18th June 2022, 13:25

Yep, exactly, the overwhelming majority is still limited to P3 and grades contents this way and then exports as BT2020. Even our Eizo, Kodac and Sony expensive studio equipment which we've been using to grade HDR stuff from Log since 2018 can't do much better and I can totally relate with what Kolak said: it wouldn't make sense to go beyond Display P3 'cause no one would be able to see and benefit from it anyway (especially users won't be able to see those anyway as far as consumer TVs are concerned), so yeah. About the different TV sets, aside from the different technologies they use, I also noticed that the overwhelming majority of users (excluding the Doom9 population) just puts very exaggerated settings, throwing any creative intent down the drain (I'm talking about stuff like putting contrast up high, colors up high, sharpness 100% etc all together with linear interpolation / optical flow artifacts) which make the final result completely different from what we saw in the studio, but hey, c'est la vie. About the last thing, overshooting, you're absolutely right again: final distribution codecs have overshoots occurring occasionally on different scenes and the more bit-starved the files are, the worse they get. People might think that masterfiles are safe from those, but believe it or not, I saw those occurring in *some* high bitrate ProRes files as well (and I'm sure you saw them too), but anyway that's another story.

:goodpost: Kolak, I'm glad that you're here. :)

Balling

18th June 2022, 18:43

Well, all USA based on snapdragon Galaxy devices have natural profile which is color accurate.

So this whole
>excluding the Doom9 population

Is misleading. Of course until device manufactures will not force color accurate profiles... Oh and also Dolby Vision profiles are accurate by default I think. Not that they also do not have Vivid mode.

>Your players sends 2020 to TV.

I am not sure this is the case with MacOS, BTW. It is certianly not the case with some Mastering monitors with P3-D65 modes (ONLY mode sometimes). Atomos Ninja...

>any analysis like in case of Sony monitor should not be done with compressed master (or Blu-ray) as you get plenty codec overshoots

Some of those are 420 overshoots. Thay is why you do not use mastering monitor. You use davinci resolve or ff software. See for example, this uses ff: https://youtu.be/DtyDmnoPVRs

kolak

18th June 2022, 20:44

UHD uses Rec.2020 when transmitted between devices. There is no such a thing like P3 in HDMI spec. This is why all BD UHD discs use 2020 primaries (and every TV station requires 2020 primaries for UHD) and any connection between 2 UHD devices over HDMI must be done with Rec.2020 (optionally Rec.709 is allowed if I'm correct).
Gamut is one thing and transmission standard another. Atomos is not an exception when it comes to HDMI in/out.

Resolve won't protect you against overshoots by default. FF has/will have some filtering built in (like many other pro tools). Its author meant o publish some technical doc about it.
There are tools which measure actual P3 gamut cover, but those are quite expensive.
Don't trust internet so much.

Balling

18th June 2022, 23:02

BTW, specifically for you red tulips from BT.2020 mdcv blu-ray of spears and munsil and if limited to P3 in color limiter of Davinci.

https://imgur.com/a/iHcmWdf

And of course AVIF tagged as Bt.2020/bt.2020nc/PQ with all those pixels. Open in chome, not in buggy mozilla. lossless avif with avif samples 420 lossless md5 with original and also not tagged as top left chroma siting, a bug in ffmpeg! Hope will be fixed!

So who is a genious! I am! Hah! (Rename to AVIF, can see it natively here: https://github.com/mpv-player/mpv/issues/10247) https://user-images.githubusercontent.com/104958042/174458649-ccff6eb4-0d6c-449c-a60a-7c0c8c817779.jpeg

>Don't trust internet so much.

Sigh. I do not need to. I generate most of this out of P3 comments on the internet under many different names.

kolak

18th June 2022, 23:47

Not sure what are you trying to prove?
That this disc has colors out of P3?
Very possible, you already mentioned it.

Balling

19th June 2022, 00:43

>Not sure what are you trying to prove?

Trying to? I proved it.

wswartzendruber

19th June 2022, 01:07

Balling

19th June 2022, 01:09

> Every 4K disc I have reads "Display P3."

Spears and Munsil has BT.2020

Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color pri : BT.2020
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light : 400 cd/m2

What it was mastered upon has no impact what can be inside though.

wswartzendruber

19th June 2022, 01:10

Yeah, I just caught that. See my edit. All three Matrix movies are BT.2020-graded.

Balling

19th June 2022, 01:16

Spiderhead on Netflix has a lot of colors outside P3, so Netflix started using BT.2020 masters. Rescued by Ruby also has some scenes, but mostly inside 709. Planet Earth 2 has sometimes all the colors of Bt.2020 uniformely, which is nuts.

FranceBB

19th June 2022, 02:09

Planet Earth 2 has sometimes all the colors of Bt.2020 uniformly, which is nuts.

That's the BBC at work. ;)
I look forward to the day they'll upgrade the BBC iPlayer to have HDR on my Google Pixel 6 Pro too!

kolak

19th June 2022, 10:35

I'm not quite sure I'm following the scuffle you two have gotten yourselves into, but HEVC seems to allow a content author to record the "Mastering display color primaries."

Every 4K disc I have reads "Display P3."

In all cases, though, the color primaries signaled are BT.2020.

EDIT: Scratch that! The Matrix trilogy appears to have been graded natively in BT.2020.

Exactly what we said. Most discs are P3 limited or at least P3 graded ( so give correct preview on P3 screen, but have colors outside P3). All use 2020 as primaries as there is no such a thing like P3 transmission format. Single discs may be 2020 graded/tagged, so you are confirming yours and our claims.

Those HDR tags always been there and some TVs use them some not. Regardless, they should be accurate, not some random or max values as you will find on some discs ( like 10K MaxCCL). Early disc are not done 100% properly as industry was struggling with tools. It’s way better now, but exceptions still happen.
Btw. when you see 1000/400 for MaxCLL/MaxFALL then it's likely to be a false value as this is some default used by Resolve.

kolak

19th June 2022, 10:48

>Not sure what are you trying to prove?

Trying to? I proved it.

I already believed you that some discs may have colors outside P3 ( where some may be just falsely reported as such). I said that standard practice is to limit gamut to P3 (for broadcast it’s in many cases a hard rule, not just a recommendation).
It’s down to studio practice- if they turn on P3 limiter or not.
Content which is graded to full Rec.2020 on Rec.2020 capable device is very rare.
As I said- disc which is graded on P3 screen but kept as 2020 may actually be "problematic" when watched on 2020 capable display. You may find that some lights etc. are annoyingly saturated etc. as they were not seen by anyone to judge.
You can't just assume that that portion of the colors which you don't see during grading with P3 display will look perfectly (without seen it).
It's like if you were grading to P3 on Rec.709 display. I'm not a colorist, but I know no one does it.

rwill

19th June 2022, 16:25

I have seen my fair share of content and almost never have encountered content that was graded in P3D65 and delivered in BT.2020 that had problems. One just has to be somewhat careful.

I have seen problems with P3D65 being clipped to BT.2020 though.

wswartzendruber

19th June 2022, 19:07

I have seen problems with P3D65 being clipped to BT.2020 though.
What?

rwill

19th June 2022, 19:37

What?

P3D65 does not completely fit into the BT.2020 gamut. Its somewhat academical though.

If I remember correctly I only ever investigated things flagged by automated QC tools and nothing found by actual human guided QC.

huhn

20th June 2022, 06:56

well just compare them p3d65 just have a very tiny be of red that bt 2020 can't do.
compared to bt 2020 that red is more green.
it is so little it is kinda irrelevant.

Balling

21st June 2022, 18:37

well just compare them p3d65 just have a very tiny be of red that bt 2020 can't do.
compared to bt 2020 that red is more green.
it is so little it is kinda irrelevant.

I checked with 3D, it does not appear to be the case (in-gamut, liminance is not HDR) https://www.colour-science.org:8020/

(select as primary colorspace BT.2020 and as secondary P3-D65).

kolak

21st June 2022, 20:53

huhn

21st June 2022, 22:04

I checked with 3D, it does not appear to be the case (in-gamut, liminance is not HDR) https://www.colour-science.org:8020/

(select as primary colorspace BT.2020 and as secondary P3-D65).
please just move on it's very easy to prove.
https://abload.de/img/dcip3redisnotpartofbt6nku5.png

wswartzendruber

21st June 2022, 23:37

Looks like industry is changing.
In one of the reference tools used in post MaxCLL is now calculated for compressed formats based on luminance (ITU-R BT.2020-2 Table 4). This is opposite to the max R, G or B component.
Using Y for MaxCLL is outright irrational. Let's say the value is signaled at 593 nits. That can mean anything from 6% equal intensity across all three channels to 100% intensity on just blue.

wswartzendruber

22nd June 2022, 04:56

Since I don't have a BT.2020 display at my house, I'll have to ask everyone (subjectively) how good Yavin IV looks here:

https://www.youtube.com/watch?v=oMHK7IbpI_I

kolak

22nd June 2022, 11:50

Using Y for MaxCLL is outright irrational. Let's say the value is signaled at 593 nits. That can mean anything from 6% equal intensity across all three channels to 100% intensity on just blue.

No idea. I just read it in tool release notes.
6% on R,G,B gives bright white? I thought it's about black and Y will be low (at eg. 70 and 70 is not 593 nits for sure)?

wswartzendruber

22nd June 2022, 13:10

Y(r = 0.06, g = 0.06, b = 0.06) = 593
y(r = 0.00, g = 0.00, b = 1.00) = 593

kolak

22nd June 2022, 13:15

https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-2-201510-I!!PDF-E.pdf

table 4 has this:

Y'=0.2627R' + 0.6780G' + 0.0593B'

are they referring to it?

wswartzendruber

22nd June 2022, 15:14

https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-2-201510-I!!PDF-E.pdf

table 4 has this:

Y'=0.2627R' + 0.6780G' + 0.0593B'

are they referring to it?
Those are the BT.2020 coefficients, so yes. But you can apply them to display light as well.

kolak

22nd June 2022, 15:16

So how do they count light then if they refer to this table?

wswartzendruber

22nd June 2022, 15:58

So how do they count light then if they refer to this table?
I have no idea. MaxCLL is specific to PQ, so how it's taken should reference BT.2100.

kolak

22nd June 2022, 18:27

Have you implemented any filtering for compressed formats?
Like skip 1% of brightest pixels, low pass filter?
If you take properly 1K nit mastered master what MaxCLL is your tool reporting?

wswartzendruber

22nd June 2022, 18:41

Have you implemented any filtering for compressed formats?
Like skip 1% of brightest pixels, low pass filter?
If you take properly 1K nit mastered master what MaxCLL is your tool reporting?
I haven't done any filtering. hlg-tools includes a utility called pqstat, but it doesn't filter. You'd need to do that via FFmpeg or somesuch.

I have heard rumor that there are defined specifics on how this is to be done, but I don't know what they are.

kolak

22nd June 2022, 18:56

There are none.
Each company does own based on tests.
Paper math is not designed for compressed sources.

Quick test v210 vs ProRes gives on some random short file max Y as 922 vs 926, so it would translate to few nits, but not that bad actually.

wswartzendruber

22nd June 2022, 19:08

kolak

22nd June 2022, 19:17

Well this was ProResHQ. Now do the same with 30mbit h265 4:2:0 and things most likely will look way worse.
Maybe good solution is something which would average pixels so smallest one is made of 4 original. Who cares about place in the frame which is 1 pixel big? Maybe 4 is also too small?
Half size resize with area filter seems to give quite good (923) results on this sample :)
This is 30 seconds test, so don't rely on it :)

wswartzendruber

22nd June 2022, 19:45

kolak

22nd June 2022, 19:49

Half size seems to work :)
Not sure if blur is a good way.

Interesting fact. h265 performs better than ProRes. Maybe it's not a surprise actually as it's way more complex codec and handles contrast much better. 924 max value, so not that big deal. Looks too good actually :)
Maybe 20Mbit is a lot for HD.

wswartzendruber

22nd June 2022, 20:03

kolak

22nd June 2022, 21:35

Yep, quarter size may be even better and faster to process (tried on HD as well and it was good). How much would it affect MaxFALL calculation?
Maybe I'm over-exaggerating it.
ProRes will do few levels overshoot, around 4-8 max (so far I've seen by simulating very high contrast edges), so it's not that much. How many nits is this in worse case?

5mbit h265 for HD is doing up to 20 Y levels, so this is bit high.
Wavelet based codecs (Cineform, Jpeg2000) behave bit better. DCT based always go up, where wavelet ones also bit down.

wswartzendruber

23rd June 2022, 16:38

I just got from pqstat that Iron Man has a MaxCLL of 2,682 when metadata declares 826.

I'm going to try omitting the first and last several seconds in case there's some frame decoding error and artifacts are getting rendered.

kolak

23rd June 2022, 20:44

Hmm...2,682 sounds bad. No one would master it to such a value. It doesn't sound 2K with overshoots, just random value, so something must be not right. Try some 20 min. portion- should be representative and give max as well (no guarantee of course).
Studios master mainly to 1K, 2K and 4K nits and typically grading software will clip max to this values (+- few nits). This is why value like 2682 is strange.
How old is this title? Try something from last 6 months.

Why can't we measure it this way.
All delivery codecs are YUV based, so just find max Y value and then count light by comparing it to PQ curve. Eg. I know that 769 (for 10bit) is 1000nits (this also perfectly agrees with Resolve when grading).
This sounds simple and should be correct (overshoots problems still apply though).
Why do we need some convoluted way to recreate RGB when original grading decision is bound to Y value inside your file?

wswartzendruber

24th June 2022, 04:18

Because MaxCLL is not properly calculated using Y values. It is properly calculated with max(R,G,B).

FranceBB

24th June 2022, 07:21

To be fair, I have a few ProRes HQ over here and I was checking the MaxCLL value by comparing it with the one sent via xml by the official provider.
For Harry Potter and the Chamber of Secrets, the official value provided via xml is 2856 Nits, however the one calculated by PQStats is 3204 which means that it's off by 348 nits due to compression overshooting (yes even if it's 900 GB worth of ProRes).

Hmm...2,682 sounds bad. No one would master it to such a value.

For that particular title, sure, but I've seen movies mastered at really arbitrary nits depending on which studio did it.
For instance, this is a series of titles we received over the years along with an xml depicting the MaxCLL:

Goodfellas 247 Nits
The Dark Knight Returns 1399 Nits
The Good Liar 244 Nits
Richard Jewell 1213 Nits
Harry Potter and the Half-Blood Prince 1915 Nits
The Dark Knight 1002 Nits
Harry Potter and the Order of the Phoenix 1135 Nits
Harry Potter and the Deathly Hallows: Part I 2632 Nits
Harry Potter and the Deathly Hallows: Part II 2811 Nits
Zack Snyder's Justice League 835 Nits
Batman Begins 992 Nits
Harry Potter and the Philosopher's Stone 552 Nits
Harry Potter and the Goblet of Fire 2848 Nits
Harry Potter and the Prisoner of Azkaban 1838 Nits
The Lego Movie 1687 Nits
Godzilla 561 Nits
The Town 1339 Nits
Just Mercy 1017 Nits
Birds Of Prey 4616 Nits
Harry Potter and the Chamber of Secrets 2856 Nits
Dune 945 Nits

so as you can see, it looks like the MaxCLL can be as arbitrary as people like, so beware of what the distributor puts on the BD 'cause it might differ from the actual value of the master.

kolak

24th June 2022, 08:46

Sorry, but MaxFALL is something totally different than I thought.
Not sure why it’s defined this way, but it has not much to do with fact that you graded to eg. 1K nits. Grading can be 1K where MaxFALL 1.5K ( I assume). Is it true MaxFALL will be always bigger ( or at least equal ) than max brightness coming from Y?
What I see in Resolve and on any other scopes etc. is a separate thing to MaxFALL. Titles are graded to rather round values and it’s 1,2,4K etc. but MaxFALL is totally separate thing. Why, no idea.

kolak

25th June 2022, 20:06

Regardless how "strange" MaxCLL and MaxFALL are there is this as an alternative measure (taking into account overshoots problem:

https://postimg.cc/YvJVJCfW

kolak

25th June 2022, 20:42

Top and bottom bars (as separate files) give similar MaxCLL (just bit above 1000nits).
In the same time max Y is 475 vs 705, so very different and not really appropriate for MaxCLL calculation.

https://i.postimg.cc/GmPcRHzN/cc.png

Grab is form QTX, so tone mapped to 500 nits Mac screen (irrelevant here).
Top row is just blue channel of the bottom bars.

This makes those metadata values defined in very confusing way, but I assume there is some idea behind them.
I've just learnt they are very different things than what I thought (even if I remembered them been defined in some specific way).

In the same time in Resolve scopes both peak at around 1000nits, so show up correctly. This means when I grade in Resolve (by scopes to 1000nits) MaxCLL should be 1000nits not more.
So I'm confused by numbers from those titles from the other thread. They should not be so "strange" and random. Very possible most of them have simply wrong values as metadata. Some do look fine though.

wswartzendruber

26th June 2022, 06:35

Regardless how "strange" MaxCLL and MaxFALL are there is this as an alternative measure (taking into account overshoots problem:

https://postimg.cc/YvJVJCfW
Well hello there...

quietvoid

26th June 2022, 16:15

The whole article (image based): https://0x0.st/oSpl.pdf

kolak

26th June 2022, 21:10

Hmm...looks like original recommendation wasn't really well thought out. I'm still not very convinced with current formula either.

wswartzendruber

26th June 2022, 22:52

Hmm...looks like original recommendation wasn't really well thought out. I'm still not very convinced with current formula either.
It's a bit late to be having this conversation, isn't it?

kolak

26th June 2022, 23:18

Why too late?
You can always change a formula :)
MaxCLL may stay as is, but I can see that companies started counting "titles' max brightness" in own ways- more intuitive/representative.
Also for your needs MaxCLL may be simply not the best measure.

wswartzendruber

26th June 2022, 23:30

If MaxCLL is retroactively reinterpreted to mean Y instead of maxRGB, television sets are going to suck at tome mapping.

kolak

27th June 2022, 09:48

They unlikely to change this, but you can ( if old way is not really representative).
Do TVs actually use it? Apparently many TVs don’t.

wswartzendruber

27th June 2022, 16:12

They unlikely to change this, but you can ( if old way is not really representative).
Do TVs actually use it? Apparently many TVs don’t.
MaxCLL tells you how aggressively you need to tone map.

kolak

27th June 2022, 20:03

Unless TVs does it dynamically in realtime ?

wswartzendruber

27th June 2022, 20:50

Unless TVs does it dynamically in realtime ?
@FranceBB: Do TVs really do this?

FranceBB

27th June 2022, 23:53

Yes, but only some brands and it really depends.
The idea was to cope with missing mandatory info.
Although those values are mandatory for PQ streams, a relatively high number of files spreading all over internet didn't have those and Samsung saw that coming.
To put this into context: I gave to the TV a PQ without metadata other than the fact that it was PQ BT2100 and the TV worked that one out surprisingly well.
When it comes to metadata actually being there, though, it's a different story and I found out that some manufacturers respect them and some other don't and do their thing anyway.
Again this is due to the fact that some of them are just wrong.
On the other hand, I did make a test by giving Samsung a PQ file that was artificially stretched to occupy all the available values from top to bottom and then I told the TV that it was 1000 nits (it wasn't). The result wasn't completely wrong in the sense that the TV did adjust something and recognised that something was wrong, but it still did a fairly poor job cause while some scenes were looking good, some others almost made me blind, especially when red was involved.
Still I'm pretty sure that some TVs do something to correct the result, but can still get it pretty wrong if the value is wrong.

And of course you'll never have any of those issues with HLG, which is also an added benefit of using it.

Balling

2nd July 2022, 20:06

@FranceBB: Do TVs really do this?

LG does it.

kolak

2nd July 2022, 21:25

Looks like MaxCLL is big problem.
Some HDR ProRes444 master.
Supplied value (from master done in Flame)=997, measured in Resolve around 2800 :)
MaxFALL is 172 vs. 171, so looks fine.

wswartzendruber

3rd July 2022, 16:30

PQ: Overcomplicating consumer video since 2016.

rwill

3rd July 2022, 17:53

PQ: Overcomplicating consumer video since 2016.

PQ is good if its done right.

Not that CLL Info and Mastering Display is needed, but I wonder how people manage to continuously screw them up. And the idea that one can represent the characteristics of a whole sequence in just a couple of values also does not fit into my head.

rwill

3rd July 2022, 17:58

On the other hand, I did make a test by giving Samsung a PQ file that was artificially stretched to occupy all the available values from top to bottom and then I told the TV that it was 1000 nits (it wasn't).

PQ is an absolute range. You cannot re-scale it. You cannot just say that a 10k nits pixel is 1k nits. How would this even work anyway ?

FranceBB

3rd July 2022, 17:59

And the idea that one can represent the characteristics of a whole sequence in just a couple of values also does not fit into my head.

It doesn't, in HDR10+ you have it dynamically changing on a scene-per-scene basis and then of course you have all the crazy stuff with Dolby Vision dual layer 10bit layer 1 + layer 2 to create a dynamically changing 12bit HDR PQ video.

PQ is good if its done right.

Sure, although it's gonna take a long time before people (I mean consumers) will be able to enjoy stuff over 1000 nits and as far as the argument of "added nits in the blacks as it's a totally logarithmic curve while HLG isn't", that's true, but only those who have OLED (or similarly capable screens) are able to notice the difference in the blacks and those who do have those are also limited to around 900 nits anyway due to the way those LED work, so...

rwill

3rd July 2022, 18:53

It doesn't, in HDR10+ you have it dynamically changing on a scene-per-scene basis and then of course you have all the crazy stuff with Dolby Vision dual layer 10bit layer 1 + layer 2 to create a dynamically changing 12bit HDR PQ video.

Yeah but no one was talking about HDR10+ or Dolby Vision. People talked about Content Light Level Information and how it affects HDR10 in televisions. My guess is that the HDR10 metadata is not needed at all for a television to be able to display PQ/2020 content 'correctly'. I only know of some use in Power Management where it can have benefits.

Sure, although it's gonna take a long time before people (I mean consumers) will be able to enjoy stuff over 1000 nits and as far as the argument of "added nits in the blacks as it's a totally logarithmic curve while HLG isn't", that's true, but only those who have OLED (or similarly capable screens) are able to notice the difference in the blacks and those who do have those are also limited to around 900 nits anyway due to the way those LED work, so...

So its somewhat future proof instead of being a stop gap solution like HLG ?

kolak

3rd July 2022, 21:15

PQ: Overcomplicating consumer video since 2016.

Not sure if it's really that complicated. Idea behind it is good.

I don't know where this big difference is coming from though. I don't believe it's due to compression overshoots (it's jus too much), but this may be more clear when I use few tools to measure MaxCLL. Resolve is not the best way when you have finished (compressed) master.
MaxFALL aligns, which is somehow good news. Supplied DV metadata is also aligned with master and matches one generated in Resolve. It's just MaxCLL.

FranceBB

3rd July 2022, 22:08

So its somewhat future proof instead of being a stop gap solution like HLG ?

Sure, I very much believe that the future is gonna be some sort of 12bit PQ with high enough nits and dynamically changing metadata. The biggest limit to achieve all this right now is consumer's hardware, but yeah I do believe that the future is gonna be PQ and one day, long long into the distant future, even newer better logarithmic curves as I think they're gonna be kept updated, a bit like Sony does for Slog, Canon does for Clog etc. The only difference is that when PQ was created, they made it so that it had so much room for manoeuvre that it was going to take years to fill the gap. Even nowadays, 6 years later, there aren't cameras with enough stops to be able to record as many frequencies as the ones needed to cover the whole PQ spectrum. There are movies that have been graded as high as 5000 nits, but that's not because the camera captured all of that but rather because it had special effects and the creator decided that it was worth making them that high. For instance, the old Harry Potter movies were shot in LogC and had just a bunch of nits, but due to the special effects and all the magic things they've been able to master them at over 2000 nits.

Anyway, in a nutshell: is PQ future proof?
Probably yes.

kolak

3rd July 2022, 22:52

As for today cameras are not the main limitation, but way more displays. 10K nits will need some time and development for sure and probably we don't even need more for the eye, so PQ should be quite future proof.
Eye can see around 20 stops if I remember well, but not at the same time (only after some adaptation time).

wswartzendruber

4th July 2022, 01:10

Given a reference viewing environment (5 nits ambient lighting), does exceeding 1,000 nits have any real use?

kolak

4th July 2022, 10:25

Even in dark room more than 1K nits still makes difference.
I've only seen 2K masters on Dolby monitor, but those who saw 4K nits say it still makes difference compared to 1K. Not sure about 10K though.

Balling

4th July 2022, 10:27

PQ is an absolute range. You cannot re-scale it. You cannot just say that a 10k nits pixel is 1k nits. How would this even work anyway ?

That is the whole point of the word perceptual in PQ, our eye does not see the difference between 10000 nits of display and 1 billion nits of the sun, it is the range of light that makes a difference (unless you put two TVs side by side thus breaking your brain's adaptation).

>Sure, I very much believe that the future is gonna be some sort of 12bit PQ with high enough nits and dynamically changing metadata.

It is already the future. IPTPQc2 is 11.5 bits PQ. FEL is 12 bit. And no, you do need 12 bit Dolby Pulsar to present this. 12 bit is BT.2020 10000 nits, display is only 700 nits P3, so 10 bit is for smaller image. There is also RGB vs YCbCr and of course 4 subpixels. So more or less all I watch is 12 bit PQ.

wswartzendruber

4th July 2022, 16:23

kolak

4th July 2022, 22:25

What do you mean ?
4K nits strikes with another level of visual impact (apparently).

wswartzendruber

5th July 2022, 06:17

FranceBB

5th July 2022, 10:50

Essentially, I am attempting to figure out why everyone is not simply migrating distributed content over to HLG.

Probably because of the fact that HLG is hybrid so people with OLED won't be able to appreciate any added details on the blacks as the lower part of the curve is essentially SDR BT2020.

kolak

5th July 2022, 16:10

As does looking directly into the sun, but that's uncomfortable to say the least.

So given a reference environment of 5 nits, does exceeding 1,000 nits serve any artistic purpose that anyone will appreciate? Or...does it just serve to have a larger number that marketing tells us is automatically better?

I mention a reference viewing environment combined with a max brightness value of 1,000 nits because that's HLG's baseline. If you have more ambient light, you can simply turn up the brightness, and the EOTF will perform the necessary adjustments to preserve artistic intent.

Essentially, I am attempting to figure out why everyone is not simply migrating distributed content over to HLG. Surely there must be artistic merit in exceeding 1,000 nits in a reference environment? Because that's the one thing it can't do.

Then again, it did take UTF-8 two decades to become the predominant encoding on the World Wide Web. See, UTF-16 was declared the future and that's what sophisticated people used. Except that...UTF-8 turned out to be so much easier to deal with.

It's not just about brightness itself. It's about color volume, which makes huge impact on your brain.
I'm not going to argue with you as I don't have enough expertise. I can only pass what Dolby people said. They done a lot of study including many tests on random people (not just engineers). 4K nits is apparently not "burning" your eyes at all.
Atm. color volume is an issue even for 1K content as OLEDs due to technology limitations makes signal pure what above some nits (if I remember well they fall apart already at 200 or so), which is not how it should be.
Sony reference OLED monitor was RGB based and it behaved much better. There is video on YT (from Vincent) where it can be seen compared to Apple HDR screen.

wswartzendruber

5th July 2022, 16:13

Probably because of the fact that HLG is hybrid so people with OLED won't be able to appreciate any added details on the blacks as the lower part of the curve is essentially SDR BT2020.
What you're saying implies that HLG has banding issues in dark regions on devices that can display absolute black.

FranceBB

5th July 2022, 17:27

What you're saying implies that HLG has banding issues in dark regions on devices that can display absolute black.

Nope, not banding, it's still 10bit and it works just fine.
The only thing I'm saying is: suppose you shoot a scene in LogC and it's in a relatively dark environment.
When you convert to PQ, you're gonna be able to preserve every stop recorded by the camera, while when you convert to HLG only the ones in the middle and high levels are gonna be preserved. In other words, if you have like a dark environment, in HLG it will be averaged out to black 64 while in PQ and LogC you're gonna be able to see different shades of black. Of course this isn't generally an issue and this is why: those details or rather values are artificially removed anyway during the grading even in PQ 'cause they're almost always full of noise.

If I wasn't on paid leave with my phone in my hand and no PC in sight I would have shown you.

wswartzendruber

5th July 2022, 17:43

rwill

5th July 2022, 19:25

Remember that I am arguing for HLG for consumer distribution only. It's certainly not anything you would ever want to capture or grade in.

So...is all that detail in the blacks useful for consumer viewing? I do not know the answer.

Is a Dolby Atmos Mix useful if most consumers use the built in TV speaker ? Yet there are people with really expensive audio setups for whom it is additional value.

wswartzendruber

5th July 2022, 19:55

Dolby Atmos is backwards compatible with both TrueHD and AC-3. And because of that, it's backwards compatible with simple stereo. And as Dolby controls all of this, there is no disagreement on what different things (MaxCLL) mean.

If video were to have Atmos' level of compatibility, we would be looking at something like HLG with a PQ enhancement layer and metadata.

Now that might actually be cool...

EDIT: Okay now I'm really thinking about this...

nevcairiel

5th July 2022, 23:26

If video were to have Atmos' level of compatibility, we would be looking at something like HLG with a PQ enhancement layer and metadata.

Now that might actually be cool...

Its called Dolby Vision Profile 8.4.

iPhones record in that format in HDR mode. HLG base layer with enhancement metadata that turns it into PQ (plus the typical other metadata Dolby Vision includes to assist tonemapping etc).

FranceBB

6th July 2022, 00:17

Its called Dolby Vision Profile 8.4.

iPhones record in that format in HDR mode. HLG base layer with enhancement metadata that turns it into PQ (plus the typical other metadata Dolby Vision includes to assist tonemapping etc).

Yes and if you display it on an HLG only capable display or a BT2020 SDR only capable display or anything that doesn't read Dolby metadata (and even if you try to apply normal tonemapping algorithms that generally work on standard HLG, ignoring the Dolby metadata) it will look like crap, thus defeating its original purpose.
I know 'cause I stumbled on this early last year:

https://forum.doom9.org/showpost.php?p=1934075&postcount=94

wswartzendruber

6th July 2022, 00:33

Did Profile 8.4 not exist when the UHD Blu-ray spec was being done? Because it seems obvious that it should have used that.

EDIT: That was a stupid question. HLG didn't exist when that spec was being drafted.

nevcairiel

6th July 2022, 01:23

Did Profile 8.4 not exist when the UHD Blu-ray spec was being done? Because it seems obvious that it should have used that.

Dolby Vision is by far not open enough to be the sole way to do a high quality HDR representation on Blu-ray.

PQ is a good choice as it gives you high quality throughout the entire spectrum, and a lot of extra brightness for future-proofing.

HLG is a "compromise" format, not a high-quality format.

Yes and if you display it on an HLG only capable display or a BT2020 SDR only capable display or anything that doesn't read Dolby metadata (and even if you try to apply normal tonemapping algorithms that generally work on standard HLG, ignoring the Dolby metadata) it will look like crap, thus defeating its original purpose.

Thats quite likely just Apples implementation of it, there is nothing that makes it inherently worse then eg. normal HLG.

wswartzendruber

6th July 2022, 03:19

EDIT: Redid the whole post.

@FranceBB

I punched in the HLG EOTF into Groovy and ran it.

https://pastebin.com/uBSvprpG

That produced these results, measured in nits:

https://wswartzendruber.net/uploads/hlg-values.txt

So for a 1,000 nits reference display, those are the values of the 64-940 range (as my script calculates them).

Here's an except from the 64-96 range:

64: 0
65: 0.00002319768460764913344820080387531646692877984605729579925537109375
66: 0.0001224381134056305307951373340102918518823571503162384033203125
67: 0.0003239930176511829373366124773525598357082344591617584228515625
68: 0.00064623223687535293925654489299859051243402063846588134765625
69: 0.0011040090918109997548957057489360522595234215259552001953125
70: 0.00171004539930367138907130186709082408924587070941925048828125
71: 0.0024755969306660928486163442130418843589723110198974609375
72: 0.0034108341950139643532213806764730179565958678722381591796875
73: 0.004525084173793222398762825520179831073619425296783447265625
74: 0.005826994920839249740562859614101398619823157787322998046875
75: 0.00732465348536010495139603193592847674153745174407958984375
76: 0.0090256737286479489512647234050746192224323749542236328125
77: 0.01093726374751113027128379684427272877655923366546630859375
78: 0.0130662789355960214099372507234875229187309741973876953125
79: 0.01541926460420294138498054081765076261945068836212158203125
80: 0.0180024908106224922066385119023834704421460628509521484375
81: 0.0208219812393356483448680904757566167972981929779052734375
82: 0.0238835374569335394390190430158327217213809490203857421875
83: 0.027192759508206452989664825281579396687448024749755859375
84: 0.030755063576323460328154624221497215330600738525390625
85: 0.03457569725687363593191747668242896907031536102294921875
86: 0.038659752870411644154469144041286199353635311126708984375
87: 0.043012179146079208835740104177602916024625301361083984375
88: 0.04763779154002421856173299374859197996556758880615234375
89: 0.052541281400103730103712251775505137629806995391845703125
90: 0.057727224148202117837147540058140293695032596588134765625
91: 0.063200086620259110503639021771959960460662841796875
92: 0.06896423367953674610220105023472569882869720458984375
93: 0.0750239341991425501277035436942242085933685302734375
94: 0.081383366494185038764186401749611832201480865478515625
95: 0.08804662327129329779662469945833436213433742523193359375
96: 0.09501771615293085060383049267329624854028224945068359375

Those are all below 1/10 of a nit. Can the human eye even perceive more than that?

kolak

7th July 2022, 00:09

Not sure if it's really that complicated. Idea behind it is good.

I don't know where this big difference is coming from though. I don't believe it's due to compression overshoots (it's jus too much), but this may be more clear when I use few tools to measure MaxCLL..

These are overshoots, which get boosted due to strong PQ curve, so suddenly 1K nits becomes 2K nits. Even quite strong low pass filtering doesn't help- looks like best way is to skip some % of top values.

wswartzendruber

7th July 2022, 05:09

That's a good point. Going from 100 nits to 200 nits sounds crazy, but it's a mere 8% difference as far as Y goes.

A 25% increase from 1,000 nits is 10,000 nits.

EDIT: I guess this weekend I should modify pqstat to use that algorithm you posted earlier.

kolak

7th July 2022, 08:31

Because of the way how MaxCLL is calculated it’s not just about Y overshoots, no?
If it was just about Y we would not have as big differences as Y doesn’t deviate that much.
In my case problematic scene has some blue lights, it makes sense as blue adds only small % of Y.
What % is between 1K nits and 2K nits in PQ curve?

kolak

7th July 2022, 09:01

It’s 769 vs 847 so about 10%. 2x more nits and just 10% change in coded values.

If we take my example which provided MaxCLL as 979 ( from grading stage) it suggest that using current formula for compressed data is totally flawed ( 2278 calculated from ProRes444).
In the same time most Blu-rays will also have questionable MaxCLL, so I would not relay on them either ( in most cases they are also calculated from compressed masters).

kolak

7th July 2022, 16:21

Been wasting a lot of time around it and have new findings.
Details to come.

wswartzendruber

7th July 2022, 16:24

Determine a better way of doing this, and I can get it into pqstat for everyone to use.

kolak

7th July 2022, 16:28

It's not about better way (not directly), but to understand what affects MaxCLL calculation the most.

wswartzendruber

7th July 2022, 16:31

Have we established what MaxCLL even is? My current interpretation is max(R, G, B) across a presentation. That signal level is then put through PQ's EOTF and declared to be the presentation's MaxCLL value in nits.

kolak

7th July 2022, 17:21

Yes, this is an official way.

Intermediate codecs should not be a huge problem. They are going to introduce some overshoots and errors (compared to uncompressed source), but this should be within few coded levels (maybe 10 max, so let's say 100nits max, but typically less).
What do make a huge difference is any scaling and chroma subsampling.
I've created test project in Resolve. Exported to 10bit RGB uncompressed, XQ, 444 and 422 HQ ProRes. First 3 had similar MaxCLL (Resolve reports 944, measured from file XQ=1001, 444=973). ProRes HQ 422 had MaxCLL=2046!
Similar story happens when you try to scale eg. UHD to HD (or other way around). It massively affects MaxCLL (also about 2x!).

wswartzendruber

7th July 2022, 18:43

I hadn't thought about how badly 4:2:0 subsampling could murder the calculated result.

kolak

7th July 2022, 20:34

Even 4:2:2 kills it, so 4:2:0 not going to be better.

wswartzendruber

11th July 2022, 15:31

Well we can suppress the effects of subsampling by downscaling before parsing.

What about quatering the size on each axis and then taking the brightest between R,G,B of the 99% brightest pixels?

kolak

11th July 2022, 15:58

No idea :)
I can tell that I had CGI title as ProResXQ which was showing 1600 MaxCLL. ProRes HQ 422 version of it above 4K its :)

Try following this new proposed formula:
https://0x0.st/oSpl.pdf

Is scaling down itself not going to create new blended "bad" pixels?
Looks like even math precision itself can generate errors, so best to use float.

wswartzendruber

11th July 2022, 16:19

I'll study this PDF once I'm off work.

kolak

11th July 2022, 21:30

Maybe scaling is good, but with method which doesn't touch chroma, so you get 444 HD?

kolak

12th July 2022, 11:48

Another example.
Netflix Sol Levante which is extreme example as it's so colourful and dynamic.
TIFF MaxCLL = 998
ProResXQ = 1260
ProResHQ = 6083!!

Yet again- 422 subsampling messes MaxCLL totally.

Rule seems to be quite simple (as I expected from the start).
If title is graded properly to 1K, 2K , 4K nits then MaxCLL should be around those values as well (unless it's very conservative grade which doesn't really use HDR properly).
All those random values are rather simply wrong and useless (or even more- may give negative impact on actual viewing experience).
I wonder if very latest BD titles have MaxCLL "better" or is it still a mess?

kolak

12th July 2022, 12:28

Resolve scopes.
Yellow line are extents, which are before low pass filtering.

ProResXQ vs ProResHQ:

https://i.postimg.cc/D09ysHC8/hdr.png

Of course TIFF sequence has nothing above 1K nits line.

wswartzendruber

12th July 2022, 16:27

Resolve scopes.
Yellow line are extents, which are before low pass filtering.

ProResXQ vs ProResHQ:

https://i.postimg.cc/D09ysHC8/hdr.png

Of course TIFF sequence has nothing above 1K nits line.
I collected the declared MaxCLL values for every one of my discs.

Here are my top five:

1. Man of Steel (7,770 nits)
2. Batman v Superman: Dawn of Justice (4,000 nits)
3. Wonder Woman (1,721 nits)
4. Aquaman (1,501 nits)
5. Shazam! (1,351 nits)

Those are insterestingly all DC movies from the same continuity.

What's odd is Zack Snyder's Justice League at 597 nits.

kolak

12th July 2022, 17:03

7.7K- not a chance it's correct.
4K- may be fine if it was graded to 4K nits.
Rest sounds like 1K grades with MaxCLL measured on compressed masters.

I've read in different places that some HDR discs are disappointing, so 597 nits sounds like one of them (may be just such a grade).

wswartzendruber

12th July 2022, 17:08

FranceBB

12th July 2022, 20:06

ProResXQ vs ProResHQ:

https://i.postimg.cc/D09ysHC8/hdr.png

:eek:
Ouch. And that's just from going from 4:4:4 to 4:2:2?! O_O
No wonder studios are sending IMF packages with MJPEG2000 in RGB or YUV 4:4:4 12bit...

kolak

12th July 2022, 20:11

Even lossless Jpeg2000 4:2:2 shows same problems.
It may also depend how tool handles chroma down and upsampling, but errors are rather unavoidable.

wswartzendruber

12th July 2022, 20:48

So should we not be using 4:2:0 to measure this? That's what the TV itself has to work with...

kolak

12th July 2022, 21:05

And have eg. 5K nits value for title which was graded to 1K nits only because we have chroma subsampling messing with pixels ?
I don't think so. If anything I would say this is very wrong approach- way better to clip those "bad pixels", by using original MaxCLL value from uncompressed master.
I think industry needs to re-think whole MaxCLL value.

For your tool it's definitely pointless to use this bad MaxCLL in my opinion.

wswartzendruber

12th July 2022, 21:30

Right, but if we filter the 1% extremes, will it not be more reasonable?

kolak

12th July 2022, 22:07

Definitely more than using unfiltered.
I see it way simpler- if you know title was graded to (1K or 2K or 4K), you just use those values :)

kolak

13th July 2022, 00:31

wswartzendruber

18th July 2022, 15:35

There must be also more precise math which would let you eliminate those "bad pixels".
How big is area in UHD which is visible from closer than typical viewing distance- 16 pixels, 36, 64? It's definitely not a single pixel or even 4.
I would think that would be a function of how bright the disparity between that pixel and surrounding pixels is.

A solid white, 10,000 nit pixel will stick out against a black background.

wswartzendruber

18th July 2022, 15:40

kolak

19th July 2022, 14:14

Lossless 4:2:2 creates 4K MaxCLL instead of 1K, so heavily compressed 4:2:0 not going to be better I would think.

wswartzendruber

19th July 2022, 15:54

nevcairiel

19th July 2022, 16:20

For such a jump to happen, whatever scaling algorithm you use to scale the chroma, its flawed (in either direction, up or down, since you can't directly measure it for the subsampled signal). Maybe its treating the image like gamma light for the process of scaling and thus this happens?

kolak

19th July 2022, 17:29

Here's the same thing I did for HLG values, except now with PQ values:

https://wswartzendruber.net/uploads/pq-values.txt

1,000 nits sits at 723.
4,000 nits sits at 855.

That's a 15% jump. For chroma subsampling to do that seems...excessive.

Not sure what exactly this is? Coded values to nits?
1K nits should be at 769 coded value, but for full range.
1K nits for limited is 723 as you said.
Should you not scale everything to full as whole HDR/DV is "designed" rather with full range in mind (I assume makes no real difference)?

This is nice calc for quick reference:
https://apps.apple.com/us/app/pq-calc/id1541419476

ErazorTT

19th July 2022, 19:03

In case it is of use to anybody, I have written an avisynth plugin which takes the HDR10 Base Layer and the DolbyVision RPU data together with the DolbyVision Enhancement Layer producing the result clip prior to the dynamic tonemapping. This clip could thus be used as input to the HLG conversion.

Not yet implemented is my idea to use the dynamic tonemapping data from the DolbyVision RPU data to steer the HLG conversion. I have yet to make up my mind how to actually do that.

>>Link (https://github.com/erazortt/DoViBaker)<<

kolak

19th July 2022, 19:15

Idea sounds good and could work not only with RPU, but xml DV metadata which is equivalent of RPU, just in different format as far as I understand.

Other thing- do you know how to apply RPU on top of the main video, to get eg. SDR trim?

ErazorTT

25th July 2022, 20:55

Ok so now I implemented the dynamic tonemapping as well. This makes it possible to convert Dolby Vision clips to HLG and dynamically change the LUT based on the signaled tonemapping from the Dolby Vision metadata.

Current releases are here:
https://github.com/erazortt/DoViBaker/releases

ErazorTT

25th July 2022, 21:03

Idea sounds good and could work not only with RPU, but xml DV metadata which is equivalent of RPU, just in different format as far as I understand.
I just know the bin files, and I have only used theses until now.

Other thing- do you know how to apply RPU on top of the main video, to get eg. SDR trim?

Well, I wished I knew how to perform the trim pass based on the signaled values, but I have not found any source which describes this technically. Does anybody have any idea how I could put my hands on that?

wswartzendruber

25th July 2022, 21:16

Can Dolby Vision be used to determine reference white adjustment?

kolak

26th July 2022, 10:25

Well, I wished I knew how to perform the trim pass based on the signaled values, but I have not found any source which describes this technically. Does anybody have any idea how I could put my hands on that?

This is Dolby secret I assume. Nothing public. Every tool does it using Dolby SDK.

ErazorTT

26th July 2022, 11:09

Can Dolby Vision be used to determine reference white adjustment?

Not that I know of.

ErazorTT

26th July 2022, 11:13

This is Dolby secret I assume. Nothing public. Every tool does it using Dolby SDK.

On the creation side yes, I would assume that anything uses the SDK. But on the presentation side, like Software players, these must somehow implement that. I looked into the source codes of VLC / FFMPEG and mpv but have not found anything. So my current assumption is that these also don't actually apply any of the processes of the dynamic tonemapping.

kolak

26th July 2022, 11:28

quietvoid

26th July 2022, 15:00

mpv doesn't do the whole dynamic tone map processing, only the initial colourspace (polynomial and chroma MMR mapping).
It's based on some RE efforts and "ETSI GS CCM 001", nothing related to Dolby licensing.

The first step would be to parse the display management metadata in FFmpeg, to make the shot-by-shot tone map metadata available.

kolak

26th July 2022, 16:19

I'm sure it's nothing to do with licensing :)
Point is - there is no official Dolby processing without licensing.

FranceBB

26th July 2022, 22:28

It's all licensed and proprietary. So they may know it, but it's protected by licensing agreement. Dolby is always done same way and that's the whole idea of it.

Dolby stuff have always been a pain to handle and after creating proprietary stuff with audio, now they're fiddling with video too. (T_T)

It took ages for the open source community to decode proprietary audio codecs like DolbyE (and the current ffmpeg implementation is far from ideal and only works with the u8 workaround which made me write several lines of code cross-checking with mediainfo given that ffprobe cannot even recognize DolbyE in an mxf container) and now they're back with DolbyED2 Atmos (currently impossible to decode) and DolbyVision profiles (also currently impossible to decode).
Best case scenario, they're just using the 12bit dual layer profile so that it's H.265 10bit PQ + metadata layer to create the 12bit and we can still watch the content by ignoring the proprietary Dolby Vision metadata layer. Worse case scenario: they're using the Dolby Vision Proprietary colorspace like dvhe0509 (https://camo.githubusercontent.com/a025ee8566be5ea3f9d1d985dde2fa557f266adf9862acdf0b6bc5d59f54c837/68747470733a2f2f692e696d6775722e636f6d2f5a525a46674c342e706e67) and we won't be able to see the content correctly (although there's been a recent attempt with libplacebo in VLC, MPV and Avisynth to tackle it).

wswartzendruber

27th July 2022, 06:36

I'm just going to continue to appreciate HLG for its abundant simplicity.

ErazorTT

29th July 2022, 15:22

There is something wrong with v1.0.1 and v1.0.0 which was ok for 0.4.1. Using a perfect 16bits grayscale (this is just a 8bits jpeg of it (https://postimg.cc/qz8vvXtV)) and applying the luts with a lum-scaling factor of more than 1 I'm getting the following picture:
https://i.postimg.cc/GH0pRSmx/1000-3-0.png (https://postimg.cc/GH0pRSmx)

While with v0.4.1 I was getting this:
https://i.postimg.cc/SnkN228X/v0-4-1-1000-3-0.png (https://postimg.cc/SnkN228X)

Please look at the enlarged picture and not at the thumbnail. In the area where it should have been perfect white there is a wave structure. Lum-scale factor was 3.0 in this case, but other factors above 1 will produce the same structures. I used a 65x65x65 lut.

This is the script how I generated that:

ImageReader("GreyRamp16bits.png",use_devil=true,pixel_type="RGB48").ConvertToPlanarRGB()
Cube("z:\lut_3.0_1000.cube",fullrange=true)

wswartzendruber

29th July 2022, 16:33

I also need to know what you're passing for MaxCLL.

ErazorTT

31st July 2022, 21:17

I also need to know what you're passing for MaxCLL.

I was using 1000 nits, thus the filename lut_3.0_1000.cube.

But that issue is independent of the maxcll. I just tested it also with 4000 and 10000.

wswartzendruber

31st July 2022, 22:44

If --max-cll * --lum-scale <= 1,000...no tone mapping will be performed.

That is why I wanted to know.

wswartzendruber

3rd August 2022, 04:17

I'm not getting this at all. Can you send over the LUT that's been generated with your 1.0.1 binary?

wswartzendruber

4th August 2022, 19:37

There's nothing wrong with your build of pq2hlg, is there? You did some kind of image processing (scaling?) on the output that put that banding in, didn't you?

:-)

ErazorTT

4th August 2022, 21:58

Its more prominent with smaller LUTs, try size 33. Here is an archive containing anything, even a cmd to create the LUT: hlg_test.7z (https://cloud.rascanu.de/index.php/s/FyjJ5SkkBora3zd)

wswartzendruber

4th August 2022, 23:31

https://wswartzendruber.net/uploads/GreyRamp16bits_converted.png

When sampling pixels, the brightness always increases as I progress rightward. I cannot find any row of pixels that's brighter on the left side than the right.

ffmpeg -i GreyRamp16bits.png -vf lut3d=lut_4000_3.0.cube -pix_fmt rgb48be GreyRamp16bits_converted.png

I did recompress with The GIMP. It has preserved the 16-bit sampling precision.

EDIT: This is with the same LUT you provided.

ErazorTT

7th August 2022, 19:12

So you are not using avisyth and the Cube function from here: http://rationalqm.us/hdr/avscube_1.3.zip?

Thus I guess, this means that there is a bug in the avscube library.

Balling

8th August 2022, 00:40

It's not just about brightness itself. It's about color volume, which makes huge impact on your brain.
I'm not going to argue with you as I don't have enough expertise. I can only pass what Dolby people said. They done a lot of study including many tests on random people (not just engineers). 4K nits is apparently not "burning" your eyes at all.
Atm. color volume is an issue even for 1K content as OLEDs due to technology limitations makes signal pure what above some nits (if I remember well they fall apart already at 200 or so), which is not how it should be.
Sony reference OLED monitor was RGB based and it behaved much better. There is video on YT (from Vincent) where it can be seen compared to Apple HDR screen.

They do not fall apart, you are talking about this dumb display that was just a bug in power adapter (more accurately USB-C plug, LOL). LG C9 does not have such problems, in fact they can be calibrated to reference (even if Sony is slighly better it does not really matter, since both are under JND, though slightly bigger than a JND if Delta IPT is used). Some colors can be 0.0001 Delta E 2000 (not that 2000 standard is that accurate for HDR). Asus monitor though: https://youtu.be/vYWDsJGVYWY?t=565

Balling

8th August 2022, 00:50

Balling

8th August 2022, 01:17

I just know the bin files, and I have only used theses until now.

Well, I wished I knew how to perform the trim pass based on the signaled values, but I have not found any source which describes this technically. Does anybody have any idea how I could put my hands on that?

Trims as in for different displays should be described in the standards of SMPTE. Artistic meta maybe too. https://libgen.li/index.php?req=+Dynamic+Metadata+for+Color+Volume+Transform

Or artistic meta can be reverse ingeenered by getting root on Android OS of LG C9 or Movies & TV plugins. In fact I pasted SDR screenshots in russian ixbt of the sample where the metadata changes but the base layer is same encoded image. Oh, Nvidia's windows driver also support their NVAPI for this, it is very buggy though (and I think it is TV led only, so no support for Low Latency player led DV). https://forums.developer.nvidia.com/t/cannot-turn-off-dolby-vision-hdr-mode-after-calling-nvapi-disp-hdrcolorcontrol-with-nv-hdr-mode-dolby-vision/199530/2

Balling

8th August 2022, 01:23

Can Dolby Vision be used to determine reference white adjustment?

You are talking about true RAW (not partially debayered like in BRAW), like N-RAW? Well, Red is suing Nikon for it, LOL, Nikon Z9 can lose pretty quick, after all it is hilariuous every thing above 24 fps debayered is patented by Red (and Canon, but those are just sublicensing it).

Balling

8th August 2022, 01:26

On the creation side yes, I would assume that anything uses the SDK. But on the presentation side, like Software players, these must somehow implement that. I looked into the source codes of VLC / FFMPEG and mpv but have not found anything. So my current assumption is that these also don't actually apply any of the processes of the dynamic tonemapping.

libplacebo you mean, GOD, VLC does not even support Dolby vision profile 5. Also, no, libplacebo does not support dynamic metadata, good news it is applied in the very end and everything else (EL can be done too with a plugin) is done.

Balling

8th August 2022, 01:28

It's all licensed and proprietary. So they may know it, but it's protected by licensing agreement. Dolby is always done same way and that's the whole idea of it.
Look at mpv - they may have it:
https://emby.media/community/index.php?/topic/107829-dolby-vision-in-mpv/

Actually this may only work if your display is DV capable and certified. Idea is simple- someone has to pay Dolby licensing fees :)

No need for display to be certified, facepalm. Movies & TV play without an issue.

Patents you mean, ffmpeg does not care about patents and VLC is in France, where those patents cannot be used.

Balling

8th August 2022, 01:30

I'm sure it's nothing to do with licensing :)
Point is - there is no official Dolby processing without licensing.

And in some cases like in all Blu-ray players (all of them have broken low latency Dolby vision, but standard dolby vision is good) at all.

Balling

8th August 2022, 01:31

Dolby stuff have always been a pain to handle and after creating proprietary stuff with audio, now they're fiddling with video too. (T_T)

It took ages for the open source community to decode proprietary audio codecs like DolbyE (and the current ffmpeg implementation is far from ideal and only works with the u8 workaround which made me write several lines of code cross-checking with mediainfo given that ffprobe cannot even recognize DolbyE in an mxf container) and now they're back with DolbyED2 Atmos (currently impossible to decode) and DolbyVision profiles (also currently impossible to decode).
Best case scenario, they're just using the 12bit dual layer profile so that it's H.265 10bit PQ + metadata layer to create the 12bit and we can still watch the content by ignoring the proprietary Dolby Vision metadata layer. Worse case scenario: they're using the Dolby Vision Proprietary colorspace like dvhe0509 (https://camo.githubusercontent.com/a025ee8566be5ea3f9d1d985dde2fa557f266adf9862acdf0b6bc5d59f54c837/68747470733a2f2f692e696d6775722e636f6d2f5a525a46674c342e706e67) and we won't be able to see the content correctly (although there's been a recent attempt with libplacebo in VLC, MPV and Avisynth to tackle it).

Dolby e-destribution v2 Atmos samples welcome on ffmpeg bug tracker.

"they're using the Dolby Vision Proprietary colorspace like dvhe0509 and"

That was implemented in full. PQ 12 bit mapping would be good though.

FranceBB

8th August 2022, 05:45

Dolby e-destribution v2 Atmos samples welcome on ffmpeg bug tracker.

Do you already have a ticket I can upload them to or do I have to open a new one?

Balling

8th August 2022, 09:27

Do you already have a ticket I can upload them to or do I have to open a new one?

A new one of course. :)

FranceBB

8th August 2022, 10:40

A new one of course. :)

https://trac.ffmpeg.org/ticket/9864

Balling

6th September 2022, 14:26

It looks like after lastest commit that finally fixed top-left chroma siting of EL, we can now safely merge FEL and BL. Nice. https://github.com/erazortt/DoViBaker/commit/0ca321bba290dee7dec96a654d1775d0ffa03528

How would you even check FEL yourself?? I have ABSOLUTELY no idea, root access to my C9 may allow that, but I am not quite sure.

I am certainly not checking FEL by just eyeballing it...

No Dolby tools I know of will allow to merge FEL just like that.

frank

28th September 2022, 12:32

wswartzendruber

28th September 2022, 15:27

There is a new challenge for correct conversion: the movie Heat (1995), released in August on UHD disk. But the movie is too dark, they totally screwed up reference white.

I have measured max.cll =130, and someone 80,20,
Web source 167,57.

Then I have generated a lut3d with -m 130 -l 5.66 for HLG conversion. 5.66 means 2.5 stops more brightness. Results are good but I'm not sure.

Any experience or ideas?
Going by your command line there, the movie grading is a disaster.

I might pick it up just to see how bad it really is. So far, Alita: Battle Angel is the worst I've run into simply because it's a direct cinema XYZ transfer to PQ with botched metadata.

EDIT: Wait a sec...130 for MaxCLL? This movie is also a naïve XYZ transfer. Here's your command line:

pq2hlg -s 65 -r 48 -m 130 heat.cube

frank

28th September 2022, 20:36

Then -l = 203/48 = 4.23 equals -r 48
right?
Thanks, I'll test again.

wswartzendruber

29th September 2022, 15:28

Yes. --ref-white and --lum-scale are mutually exclusive and end up setting the same internal value.

-r 48 and -l 4.23 are principally the same.

frank

30th September 2022, 08:54

Great, William, that's it, it worked with -r 48! :thanks:
Now the movie looks fine.
And that morons still sell the messed up uhd for 30 Eur. :devil:

frank

30th September 2022, 09:24

I'm using mpv on my notebook (500nit FHD+ display) to watch the conversion. It has excellent tone mapping but you have to set it yourself for best colors.
For portable using create the folder mpv/portable_config/ and copy the files:input.conf, mpv.conf
Edit mpv.conf:vo=gpu-next
hwdec=auto-safe
tone-mapping=bt.2390
hdr-compute-peak=no You'll get excellent HLG/HDR tone mapping. No brightness flickering at start-stop.
For more settings see the manual in /mpv/doc/.
vlc is also good but doesn't have that many options.
___________________
Dell XPS 15 9510, Win10 Pro

FranceBB

30th September 2022, 13:04

Alita: Battle Angel is the worst I've run into simply because it's a direct cinema XYZ transfer to PQ with botched metadata.

Wait a sec...130 for MaxCLL? This movie is also a naïve XYZ transfer.

Yep. Looks like is more common than it seems

And that morons still sell the messed up uhd for 30 Eur. :devil:

The thing is that there's nothing wrong in using the DCP transfer to create the UHD-BD version, but metadata MUST be right and that's unfortunately something they got wrong... :(

vlc is also good but doesn't have that many options.

Yeah, I use MPV as well, it's the best.
The only time I use VLC is when my poor computer struggles with decoding and I'm willing to accept a quality reduction as long as I can still watch it in real time...
But yeah, if I had infinite computational power, I would totally use MPV for everything.

wswartzendruber

11th October 2022, 00:46

I have begun to experiment with using skin tones to set reference white. I'm going to throw a few Zack Snyder movies at this technique to see how robust it really is.

frank

5th November 2022, 16:37

Next example of wrong UHD mastering.

Top Gun: Maverick UHD 2022
max-cll 617,496
Release is too dark. Again they mismatched the white level.
I found that -r 100 for HLG is comparable to the BD bt709.

So it is created for DCP 100 nits, EOTF PQ, P3.
What do you think?

wswartzendruber

6th November 2022, 16:53

I don't have Maverick yet, but if they put reference white at 100 nits, that is actually correct. Well, depending on your point of view.

HDR10 is static metadata around either ST.2084 or ST.2086. And it's one of those that says reference white should be at 100 nits in a reference environment.

Well, the ITU came in later and did their own tests and determined that reference white should be at 200 nits in a reference environment. So their BT.2408 paper says to put it at 203 nits, as this corresponds to 75% HLG, which is where reference white is at that format.

frank

7th November 2022, 14:12

wswartzendruber

7th November 2022, 18:50

I think 90% of viewers don't sit in the dark to watch a movie on tv. UHD publishers don't get it.
This is half the reason HLG was created to begin with.

FranceBB

11th November 2022, 15:35

Well, I sent you a present, William. ;)
It's my Christmas gift. :)

https://cdns-images.dzcdn.net/images/cover/f852c18fcb3f41987b0de1f905b38ade/264x264.jpg

Balling

12th December 2022, 14:34

OK.
My "reference environment" is the living room and tv, not a dark basement. I think 90% of viewers don't sit in the dark to watch a movie on tv. UHD publishers don't get it.
That's why I convert to HLG.
And 200nits look better on my notebook too.

I do. Many people do, cause why BT.709 was for a dark room, end to end gamma 1.2.

While sRGB was for office environement.

kolak

13th December 2022, 00:26

OK.
My "reference environment" is the living room and tv, not a dark basement. I think 90% of viewers don't sit in the dark to watch a movie on tv. UHD publishers don't get it.

Maybe Dolby did:
https://professionalsupport.dolby.com/s/article/Dolby-Vision-IQ-Content-Type-Metadata-L11?language=en_US

I wonder how well it works in real life.
Actually system may be bit limited in functionality atm.

Balling

23rd December 2022, 08:21

Maybe Dolby did:
https://professionalsupport.dolby.com/s/article/Dolby-Vision-IQ-Content-Type-Metadata-L11?language=en_US

I wonder how well it works in real life.
Actually system may be bit limited in functionality atm.

And BTW, it is not dark basement. That would require 2.6 gamma for SDR. It is just dark room with 5 nits of D65 lamps. So 5 candles not in front of the TV.

Dolby IQ works great, just as D93 light color managment. The patent on Dolby IQ is solid. Just like for TrueTone though.

See IQ patent. It is fuxxing nuts. https://patents.google.com/patent/WO2018119161A1/en

wswartzendruber

27th December 2022, 04:03

Jack Daniel's thoughts follow:

The HLG EOTF doesn't scale the display outlet linearly. As it increases brightness, the gamma value changes. If the HLG EOTF is doing this, then I should have pq2hlg do this when --lum-scale is applied.

I need to do the math (I suck at math) abstract the HLG parts out of a working model.

wswartzendruber

30th December 2022, 17:40

The Lord of the Rings appears to have reference white at 100 nits. This is with linear brightness scaling.

The Argonath (https://www.youtube.com/watch?v=1Yn12ELtE5Q)
Isildur's Account (https://www.youtube.com/watch?v=nUGePo_boeU)
A Wizard Is Never Late... (https://www.youtube.com/watch?v=6o7zCsl1rys)

Balling

12th January 2023, 00:07

Ambient environment SEI is now apparently used by iPhone, so they can reproduce D65 or D93 illuminants, or ony color as white point. Nice. https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230111185707.22132-4-jeebjp@gmail.com/

Applied!! https://github.com/FFmpeg/FFmpeg/commit/5de565107a32414aec9f079940c76812265157c5

ffprobe -select_streams v:0 -show_frames -i "iPhone11_4K-recorder_59.940DV+HLG.mov"

side_data_type=Ambient viewing environment
ambient_illuminance=3140000/10000
ambient_light_x=15635/50000
ambient_light_y=16450/50000

side_data_type=Dolby Vision RPU Data

[SIDE_DATA]
side_data_type=Dolby Vision Metadata
rpu_type=2
rpu_format=18
vdr_rpu_profile=1
vdr_rpu_level=0
chroma_resampling_explicit_filter_flag=0
coef_data_type=0
coef_log2_denom=23
vdr_rpu_normalized_idc=1
bl_video_full_range_flag=0
bl_bit_depth=10
el_bit_depth=10
vdr_bit_depth=12
spatial_resampling_filter_flag=0
el_spatial_resampling_filter_flag=0
disable_residual_flag=1
vdr_rpu_id=0
mapping_color_space=0
mapping_chroma_format_idc=0
nlq_method_idc=-1
nlq_method_idc_name=none
num_x_partitions=1
num_y_partitions=1

pivots=63 132 362 618 874 911 927 935 942

mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=-409680 16721463 -20276640

mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=-119056 13575212 -12867889

mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=1317527 5338528 -948122

mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=2119979 2065496 2288524

mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=7982780 -11367226 9973944

mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=53792084 -114243184 67724328

mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=112973872 -244837568 139764480

mapping_idc=0
mapping_idc_name=polynomial
poly_order=2
poly_coef=236828416 -518849056 291306944

pivots=0 1023

mapping_idc=1
mapping_idc_name=mmr
mmr_order=3
mmr_constant=-4200453
mmr_coef=9094176 31944476 739652 -27103344 -3431599 -11015088 22758042 -2028643 -30021218 -906885 26272992 7291404 16488745 -78087176 -1487777 12496543 762460 -4281948 -5768035 -7843163 103636960

kolak

17th February 2023, 22:24

Some document which may have useful info:

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-7-2019-PDF-E.pdf

wswartzendruber

22nd February 2023, 00:17

It looks like we only need to mess with gamma when increasing brightness due to the ambient environment providing distractions?

kolak

23rd February 2023, 17:09

No idea. I just shared doc thinking it may be useful.

Balling

4th March 2023, 06:37

Is Ultraviolet/infrared light as ambient white allowed? Interesting.

Balling

4th March 2023, 06:41

It looks like we only need to mess with gamma when increasing brightness due to the ambient environment providing distractions?

It is not only gamma, it is primaries too. Anyway. E.g., imagine you have Ledvance, former OSRAM, halogen lamps. Twelve of 12 V 300 lumen, so 12 V can be direct current too, so no pulses from alternating current. On the newer 2021 generation there is QR code into EU database EPREL (European Product Registry for Energy Labelling), this is mine https://eprel.ec.europa.eu/screen/product/lightsources/714468?navigatingfrom=qr

As you can see it has Correlated colour temperature 2 800K and Chromaticity coordinate
x: 0,452 y: 0,409, that is far from D65 6504 K x: 0.31271 and y: 0.32902. Lol.

wswartzendruber

13th April 2023, 02:10

Version 1.1.0 is out.

Included in this release are:

1. The new hlg2pq utility, which allows for conversion to PQ at arbitrary display levels up to 10,000 nits.

2. Adding --hlg-compensate (-c) to pq2hlg, which addresses excessive saturation in a single channel by diverting to the other two channels.

3. The pqprev.sh / pqprev.ps1 script, which will grayscale a PQ frame and output it as an sRGB image without adjustment.

https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F1.1.0

wswartzendruber

19th August 2023, 01:42

I'm starting to learn about how to run a YouTube channel. I've started a playlist that features various commercial HDR10 demos converted into HLG.

https://www.youtube.com/playlist?list=PLkO9wxRVnt-Q6XnwaAeHKMsJiYkzYRm1e

wswartzendruber

26th November 2023, 06:19

I've been doing reading on how to best increase image exposure. Because when we're adjusting reference white, that's really what we're doing. I've posted two test clips onto YouTube. The first increases exposure by multiplying the linear RGB values by a factor. The second increases exposure by converting to Oklab and multiplying those components by a factor.

RGB: https://youtu.be/XMdFweclflY
Oklab: https://youtu.be/9hqkMBvwqSc

I'm interested in what others think of the results, as there doesn't seem to be an objectively correct way of doing this.

EDIT: Here are some screenshot comparisons for BT.709 playback via YouTube:

https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-1.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-2.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-3.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-4.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-5.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-6.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-7.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-8.jpg
https://wswartzendruber.net/uploads/alita-rgb-vs-oklab-9.jpg

wswartzendruber

1st December 2023, 07:36

Here's 2.0.0-beta1. (https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F2.0.0-beta1)

All brightness scaling is now based on Oklab (https://bottosson.github.io/posts/oklab/). In other words, for all the pictures in the preceding post, 1.x (linear RGB scaling) is shown on the left while 2.0.0-beta1 (Oklab scaling) is shown on the right.

To this end, the --lum-scale (-l) flags are gone and replaced with --exposure (-e).

wswartzendruber

3rd December 2023, 05:40

Here's 2.0.0-beta2. (https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F2.0.0-beta2)

This features newly-derived RGB<->XYZ matrices using the constants defined in BT.2020 as a starting point at 64-bit float precision.

These new matrices allow for a RGB<->Oklab roundtrip with accuracy to 0.0000000001 nits across all brightness levels.

ErazorTT

3rd December 2023, 11:46

I'm interested in what others think of the results, as there doesn't seem to be an objectively correct way of doing this.

Don't you have the SDR BluRay to compare against? There you should be able to see how deep the blacks are.

The point is, that of course the one with deeper black seems to look better, subjectively. However, I would be afraid that this might drown all blacks to black.

kolak

3rd December 2023, 13:55

SDR will be most likely grading trim from HDR, so it's creative step (not some fixed math). It's not that easy to say which one is correct as there is no such a thing like "one correct SDR version". Typically official directors grade is reference and in case of HDR/SDR one can be sometimes quite different than other.

wswartzendruber

3rd December 2023, 16:27

ErazorTT

3rd December 2023, 16:39

The objective with incorporating Oklab is to say: "The HDR10 grading represents some artistic intent. That intent should be preserved as the exposure is adjusted to increase reference white."

RGB is not perceptually uniform.

Yes, but you're increasing the brightness for the reason to match the total brightness of the HLG stream to that of the SDR stream.

So I think it would be best if you compared these with the SDR stream to see which of these better match the blacks.
RGB: https://youtu.be/XMdFweclflY
Oklab: https://youtu.be/9hqkMBvwqSc

ErazorTT

3rd December 2023, 18:53

I tested the v2.0.0.b2 against the v1.1.0, and I am seeing exactly no differences, apart from rounding to +/-1 at 10 bits. And I scrolled through the whole movie. What am I missing?
Here is my script:

LoadPlugin("C:\...\dgindexnv\DGDecodeNV.dll")
pq=DGSource("C:\...\pq.dgi")

pq=pq.z_ConvertFormat(chromaloc_op="top_left=>center",width=pq.Width()/2,height=pq.Height()/2,pixel_type="RGBP16",colorspace_op="2020ncl:st2084:2020:limited=>rgb:st2084:2020:full",dither_type="none",resample_filter="spline36",resample_filter_uv="spline36")
hlg1=pq.Cube("C:\...\1.1.0\lut_2.75_1000.cube")
hlg1=hlg1.z_ConvertFormat(chromaloc_op="center=>top_left",pixel_type="YUV420P16",colorspace_op="rgb:std-b67:2020:full=>2020ncl:std-b67:2020:limited",dither_type="none",resample_filter="spline36",resample_filter_uv="spline36")
hlg2=pq.Cube("C:\...\2.0.0.b2\lut_1.4_1000.cube")
hlg2=hlg2.z_ConvertFormat(chromaloc_op="center=>top_left",pixel_type="YUV420P16",colorspace_op="rgb:std-b67:2020:full=>2020ncl:std-b67:2020:limited",dither_type="none",resample_filter="spline36",resample_filter_uv="spline36")

StackVertical(hlg1,hlg2,Subtract(hlg1,hlg2))
ConvertBits(10,dither=0)

The v1.1.0 lut was created with that command:
./pq2hlg.exe lut_2.75_1000.cube --max-cll 1000 --lum-scale 2.75 --size 65 -c

The v2.0.0.b2 lut was created with that command:
./pq2hlg.exe lut_1.4_1000.cube --max-cll 1000 --exposure 1.4 --size 65

I came to the lum-scale and exposure by comparision to my SDR source.
Please create lut files using the parameters above with 1.1.0 and compare them yourself against 2.0.0.b2.

wswartzendruber

4th December 2023, 06:11

Here's a screenshot comparison. The bottom two are done with 2.0.0-beta2.

https://wswartzendruber.net/images/alita-comparison-1.png

https://wswartzendruber.net/images/alita-comparison-2.png

https://wswartzendruber.net/images/alita-comparison-3.png

https://wswartzendruber.net/images/alita-comparison-4.png

https://wswartzendruber.net/images/alita-comparison-5.png

Regarding LUT comparison between 1.1.0 and 2.0.0-beta2, if your source was monochrome, there might not be a difference at all. If Oklab is to be believed, scaling linear brightness by a fixed factor is perceptually uniform, so long as no color (non-D65) is involved. This, at least, is what I found when I experimented with it.

But when color is involved, things change. Here's line 168,269 from each one:

1 1 0.9537389

1 1 0.94303465

Or line 39,788:

0.008232022 0.66472024 0.10244914

0.01649015 0.6643379 0.102354646

ErazorTT

6th December 2023, 02:04

if your source was monochrome, there might not be a difference at all.

Crap, yeah it was monochrome, because I was interested in the brightness side of things. Ok so I will retry with color.

wswartzendruber

7th December 2023, 04:06

Awesome, that probably explains things, then.

Remember that if no reference white adjustment is needed, both versions should generate identical LUTs.

wswartzendruber

10th December 2023, 05:24

Here's 2.0.0-beta3. (https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F2.0.0-beta3)

This corrects SDR black and white previews. Those were using BT.2020 coefficients earlier in beta2.

EDIT: That is, taking a black and white preview shot of a BT.709 Blu-ray now uses the BT.709 conversion matrix to go to Oklab for better brightness assessment.

wswartzendruber

22nd December 2023, 03:39

In today's segment of Useless Trivia™, The Fifth Element declares a MaxCLL of 10,000 nits. These levels can be seen on the tiny lights highlighting the aliens's armor at the beginning of the movie.

FranceBB

22nd December 2023, 11:51

In today's segment of Useless Trivia™, The Fifth Element declares a MaxCLL of 10,000 nits. These levels can be seen on the tiny lights highlighting the aliens's armor at the beginning of the movie.

LOL making something no one can see, including the ones who actually created it, cool xD
I guess this is their way of saying that their Pogo Stick is bigger than everyone else's... but it's not.

(it's a Modern Family reference, go look it up if you didn't get it).

wswartzendruber

22nd December 2023, 22:26

I used Oklab to push the peak brightness down from 10,000 nits to 100 nits, but otherwise did no tone mapping:

https://wswartzendruber.net/images/excessive-maxcll.png

ErazorTT

23rd December 2023, 19:56

Another question converning v2. How come that the -c parameter is not needed anymore? Is this due to the oklab processing?

wswartzendruber

23rd December 2023, 20:38

Another question converning v2. How come that the -c parameter is not needed anymore? Is this due to the oklab processing?
No. It's that I decided it was dumb.

-c was in 1.x because HLG has limits on how much value a single color channel can have when the other two channels aren't present. Ergo, the maximum value a single color channel can have increases as the other two channels accompany it. The only time R, G, and B can be at their max is when all three are at their max.

-c worked by saying, "I've got a red channel by its self calling for 262 nits, but I can only take this to 201 nits with HLG. I'm going to divert some of the overall signal strength from this red channel to the other two. Saturation will be lost but overall brightness will be preserved."

Except that not even that is true, because linear RGB is a terrible predictor for perceptual brightness.

Note that HLG allows isolated channels to go high enough that this shouldn't even be something anyone runs into.

EDIT: This is discussed in BT.2408-4 page 25, in section 6.5

ErazorTT

24th December 2023, 13:09

Ok I see. Since you mention BT.2408-4, please be also aware that the current release is now already at BT.2408-7.

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-7-2023-PDF-E.pdf

wswartzendruber

24th December 2023, 19:01

Ok I see. Since you mention BT.2408-4, please be also aware that the current release is now already at BT.2408-7.

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-7-2023-PDF-E.pdf
Oh for crying out loud. I wanted to release 2.0.0 on New Year's Day.

But I should examine this first.

EDIT: Okay so they have made an attempt to address the issue of linear RGB scaling. They're clarifying how two separate adjustments can be made, one to RGB and then the other to Y. And they're attempting to get more perceptually accurate color modeling using data from BBC and ARIB surveys. Converting from RGB to Oklab, scaling, and then converting back to RGB is going to be more expensive, but the LUT only needs to be generated once. And whereas BT.2408-7 only covers scaling from SDR to HDR, Oklab can (theoretically) scale to and from any brightness. Oklab has been modeled using an extensive data set from color perception surveys.

So I'm currently planning to leave Oklab in place for 2.0.0. I would need someone to tell me that Oklab scaling looks bad on a high-end grading monitor (which I don't have).

I need to just shell out the money on an Asus ProArt monitor.

ErazorTT

24th December 2023, 23:37

I would need someone to tell me that Oklab scaling looks bad on a high-end grading monitor (which I don't have).

Anything specific to look out for? What would be the critical places in the LUT? I have a LG EP950, which has 33 point 3D hardware calibration and has the same JOLED display as the OLED ProArt.

wswartzendruber

25th December 2023, 06:13

Anything specific to look out for? What would be the critical places in the LUT? I have a LG EP950, which has 33 point 3D hardware calibration and has the same JOLED display as the OLED ProArt.
Find something that needs a lot of correction (stress test). Some of the 20th Century Fox stuff is graded really dark placing reference white at 48 nits. Alita is one such movie. If you find a movie like that, try this command with both 1.x and 2.0.0-beta3:

pq2hlg -m 162 -r 48 -s 128 pq2hlg.cube

The 2.x LUT should look a lot more like an exposed representation of the original than the 1.x. You may specifically find that hue changes with 1.x and the midtones might be overexposed.

Basically, 2.x should just look like a brighter take on the original while 1.x looks off.

ErazorTT

25th December 2023, 21:01

I really don't understand why you see differences between the new and the old LUTs. I don't see any.

Please take a look at the script here. It generates a calibration pattern, then transforms it using the old and the new LUT, and then compares the outputs. There arn't any differences. Looking at the calibration pattern, I would have thought that there should be differences.

Thats the script:
https://drive.google.com/file/d/1dSvGPK02ybH2rurAov7Bpt9tM_B1rGfT/view?usp=drive_link

Thats the calibration pattern the script generates which then gets transfomed by the LUTs:
https://i.postimg.cc/DJtCdJ7h/Color-Brightness-Steps-All000089.png (https://postimg.cc/DJtCdJ7h)

To use the scirpt you need to generate the LUT files and adapt the paths to the LUT files at the very bottom of the script.

wswartzendruber

26th December 2023, 03:44

Sweet Fancy Moses. You're right. I have no idea how or why, but 1.1.0 and 2.0.0-beta3 produce visually identical results despite the large differences seen in the previous page.

I'm investigating...

EDIT: So far, scaling linear RGB by a factor, and scaling Oklab by a much smaller factor.............produce the same results. This shouldn't be the case at all. Not even close... This also doesn't explain the differences on the previous page.

EDIT: Increasing image exposure via linear RGB appears to be "correct" for now anyway. Oklab does return different brightness levels when monochroming an image (like in preview mode).

EDIT: Okay, so...

1. Linear RGB may not be perceptually uniform, but it still suffices for increasing image exposure.
2. 2.0.0 should simply revert to using linear RGB for exposure (reference white) adjustments.
3. Oklab still has a place in black-and-white preview mode (which can be used to determine exposure).
4. YouTube has likely changed the way BT.709 is generated from HLG uploads, explaining the differences on the preview page (uploaded a year apart).
5. Be more thorough in monitoring differences (this has bitten me in the ass before).

EDIT: I grabbed a HDR Windows machine and screenshot the two YouTube clips with HLG playback. They appear to have identical levels.

wswartzendruber

28th December 2023, 22:24

Titanic (which just came out on 4K) declares a MaxCLL of 283 nits.

FranceBB

29th December 2023, 09:18

Well, that's in line with other UHD re-scanned movies like Goodfellas which declares 247 Nits.
To think that it was only a few years ago, in 2016, when I've got the Apple ProRes FULL HD re-scan and encoded an XDCAM-85 out of it (back when the "XDCAM SHD - aka Super HD" slogan was still a thing 'cause Sony didn't know how to cope with newer and better 10bit standards so they just reckoned they could push more bitrate into a dying MPEG-2 8bit standard to go from 50 Mbit/s (XDCAM-50) to 85 Mbit/s (XDCAM-85) totally missing the point about the issues MPEG-2 had and its problems with banding etc.
Anyway, I remember that day as if it was today, it was a weekend, Sunday morning, in 2016, I was at work and given that the last time I watched Titanic was back when DVD were a thing, I re-watched the entire movie in XDCAM-85.
I went into one of the QC rooms at Sky, the QC Room 3, at the third floor, 'cause we had one and only one Harmonic Omneon playback port capable of playing XDCAM-85 files (all the other VS7 ports were only capable of up to XDCAM-50) and watched it.
Aside from a few places in which the film was clearly ruined, the overall picture was rather sharp but it had plenty of grain.
Back then I thought "this is amazing" 'cause I could see way more details than the ones I remembered on the DVD, although there were a few scenes with water that presented banding anyway (despite all the grain) and I clearly thought "why is the world sticking with MPEG-2 8bit? why?!".

Well, fast forward to 2023, 7 years later, and we have the 4K Remaster where they probably re-scanned the old film once again.
At this point I'm curious to see that one as well and see whether there are effectively more details compared to the FULL HD scan or if it's just more grain like in Goodfellas.
If I get my hands on it, I'll be back with a few screenshots.
The only thing I don't understand about those Remasters, though, is the fake PQ 'cause no matter how much you play around with it, the source will always be SDR (and in some case, even worse than 100 nits SDR, depending on the condition of the film). I mean, sure, you can bring some highlights up, mask some reflections and treat them differently etc but why?

wswartzendruber

29th December 2023, 18:15

FranceBB

31st December 2023, 01:54

Thank you for the sample!
Well, as I said with Goodfellas before, we're really getting closer and closer to the limit of what was actually on the physical film with these 4K scans.
Still, the fact that there are still details coming out of it compared to the FULL HD version is astonishing (I'm currently back to my parents' house for the holidays so I don't have the FHD version handy for a quick comparison).

If you take a look at this, it may not look like much:
https://i.imgur.com/grf9hoF.png

until you realize it actually comes out of this:
https://i.imgur.com/ZWOumgu.png

(pictures in BT709 SDR only for reference)

Every time I think about the amount of info the physical film reel used to hold back in the days and how much that was squeezed into 480i / 576i CRT at the time, it's just incredible.
Here are we are, 26 years after the movie was shot, finally seeing the details the original reel had on consumer hardware. Amazing.
By the way, this film is actually better preserved than others I've seen in the past, which is something to keep into consideration.
Who knows if we'll talk about this again when 8K will finally be a thing... ehehehehe

If you want something up in the original PQ, I can do that too so long as it's kept under two minutes.

Nah, I'm fine with HLG. :)
This scene here was probably 287 nits in PQ because of the clipped out sky and I can see that it's well below 0.52V in HLG which is fine as it won't burn the eyes of the viewer this way (just like it wouldn't in PQ). :)

https://i.imgur.com/qWuATtI.png
https://i.imgur.com/DRDA4i6.png

in BT709 SDR as a reference:

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

wswartzendruber

31st December 2023, 21:57

Surely something there is above 0.52V... That should be like 83 nits in a reference environment.

EDIT: I'm tempted to generate a custom LUT that converts this to BT.2020 SDR, because that's more or less what it is.

FranceBB

2nd January 2024, 10:15

Surely something there is above 0.52V...

Is there? XD

I'm tempted to generate a custom LUT that converts this to BT.2020 SDR, because that's more or less what it is.

Yeah that would actually make a lot of sense.
I mean, fake 283 nits aside, it does come from an SDR source in the first place anyway, so...

wswartzendruber

3rd January 2024, 03:52

If that's my HLG YouTube clip, the sky in that frame should be right at 75% HLG.

EDIT: Time to get work on this custom LUT!

EDIT: It's a smidge above SDR. This has peak white at 1.6X reference white, roughly. SDR is typically graded to put peak white at 1.25X reference white.

EDIT: Okay, clip is uploading.

wswartzendruber

3rd January 2024, 08:34

Titanic: Rose Arrives in Southampton [SDR-WCG] (https://www.youtube.com/watch?v=eFEyHcWAmDw)

Does this even play as BT.2020 SDR? It didn't on the HDR-equipped laptop I have, but I also know that YouTube encodes BT.709 first and then goes on to BT.2020/2100.

FranceBB

3rd January 2024, 10:09

Arg, nope, it reports BT709 SDR from the internal YouTube conversion...
Looks like it's internally converting to BT709 8bit... :(

wswartzendruber

3rd January 2024, 15:16

Bah. Fine.

https://wswartzendruber.net/uploads/titanic-rose-arrives-in-southampton-bt2020sdr.mkv

FranceBB

4th January 2024, 10:49

Looks good now and even in SDR there's still headroom. :)

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

BT2020 SDR

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

BT709 SDR (as reference)

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

It's also nice to see the grain in the shot now that I have a sample encoded from you and not one murdered by YouTube's VP9:

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

wswartzendruber

4th January 2024, 15:43

Well I'm glad it came out good. Here's the LUT if you want it:

https://wswartzendruber.net/uploads/titanic-bt2020-sdr.cube

ErazorTT

10th January 2024, 11:52

EDIT: Increasing image exposure via linear RGB appears to be "correct" for now anyway. Oklab does return different brightness levels when monochroming an image (like in preview mode).

Actually I think this detour was at least a nice double check that things work correctly. Concerning the monochroming, well yes, I always thought there is something wrong the way it is usually done. Looking at monochrome from BT709 and comparing it to monochrome from BT2020 was way too different in the reds.

wswartzendruber

12th January 2024, 23:42

Actually I think this detour was at least a nice double check that things work correctly. Concerning the monochroming, well yes, I always thought there is something wrong the way it is usually done. Looking at monochrome from BT709 and comparing it to monochrome from BT2020 was way too different in the reds.
I guess it's time to get 2.0.0 released and then move the documentation over to the wiki.

ErazorTT

23rd January 2024, 18:51

So apparently you have released with the oklab conversion, meaning that its now using exposure instand of lumscale.

For reference, this is how exposure and lumsacle relate to eachother:
lumscale = exposure^3
exposure = lumscale^(1/3)

I actually prefered the old linear behaviour of lumsacle since its interplay with max-cll was much easier to understand. lumscale*max-cll was meaningful value which the whole tonemapping depended on.
So I would suggest to add the above scaling to your application and let the user insert lumscale as before, you can then calculate exposure internally.

Independently of that and independently of the version used (1.0, 1.1 or 2.0) by coincidence I ran into the following issue:
Here you see a ramp of red to blue. When iterpreded as a PQ source and applying a lut with max-cll=2000 and lum-scale=4 (or exposure=1.587) I get an unexpected output.

source:
https://i.postimg.cc/JGknbb2t/red-blue-PQ-small.png (https://postimg.cc/JGknbb2t)

HLG:
https://i.postimg.cc/Xr6vxpRL/red-blue-HLG-small.png (https://postimg.cc/Xr6vxpRL)

Click and open the bigger images, I added two green arrows to show where the issue is. For me this appears to be something related to one of the e1, e2, e3 or e4 of the EETF, you probably know what I mean.

wswartzendruber

23rd January 2024, 20:23

EDIT: Disregard everything before this.

You're driving max red on the left and max blue on the right. Because you're maxing out a color channel (regardless of which one), that's going to push your effective MaxCLL up to 10,000 nits. Remember that MaxCLL isn't just how bright the overall pixel is, it's how bright that pixel would be if all of its color channels were aligned with its highest one.

With that said, I've found a bug in the "rgb" tone mapping mode. I need to investigate that. There's some weird fuchsia banding going on... This, fortunately, is not the default tone mapping mode.

Also, I can add --lum-scale back in.

EDIT: My good friend "NaN" is back in the generated LUT for the "rgb" tone mapping method...

* Loads lever-action rifle. *

I'm going to put this pain-in-the-ass down once and for all...

wswartzendruber

24th January 2024, 01:52

* BANG!!! *

Anyway, here's 2.1.0: https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F2.1.0

I've added a battalion of unit tests to ensure that NaN, Inf, or anything outside the range of 0.0...1.0 never shows up in a LUT ever again.

Oh and --lum-scale is back. :-)

ErazorTT

24th January 2024, 16:23

* BANG!!! *

Anyway, here's 2.1.0: https://github.com/wswartzendruber/hlg-tools/releases/tag/release%2F2.1.0

Awesome!

Going back to my issue of the color ramp. Yes, the colors are driven to the max, yes. So this shows what happens when the values overshoot the range set via max-cll. I think that overshooting should still not lead to the hue and brightness changes seen. The rgb tonemapping LUT does not show this behaviour.

wswartzendruber

24th January 2024, 17:09

Awesome!

Going back to my issue of the color ramp. Yes, the colors are driven to the max, yes. So this shows what happens when the values overshoot the range set via max-cll. I think that overshooting should still not lead to the hue and brightness changes seen. The rgb tonemapping LUT does not show this behaviour.
Well, there's no single best way to do tone mapping. The MaxRGB method is a somewhat recent addition to BT.2408. It typically provides the best results for commercial productions, but not always. You may very well conclude that it's objectively inferior to RGB and that's fine. That's why I didn't remove RGB when adding MaxRGB.

ErazorTT

26th January 2024, 18:41

I just have made another test with the following script:

BlankClip(color=$000000,length=30*24,pixel_type="RGBP16",width=960,height=540,fps=24000,fps_denominator=1001).RGBAdjust(rb=49271,gb=49271,bb=49271)
Cube("lut_1.0_1000.cube",interp=1)

The script creates a uniform gray at RGB value (49271,49271,49271) which is exactly at 1000nits in PQ terms (in 10 bit YUV this would be 723,512,512).
With LUTs of increasing size the output value is getting nearer to the max of 65535 but is never really getting there. With a LUT of size 65 I'm getting 65387, and even with a LUT of size 126 I'm getting 65526.
While at the first glance this does not sould very surprising, of course bigger LUTs give better results, for me it was unexpected because I would have thought to be at the very max of the LUT, where I would have not expected any interpolation anymore and would have thought to always get 65535 independently of the LUT size.
(Why does my expectaion not hold that at these input levels we should be at the max of the LUT, where there would be no interpolation? Why is that not the case?) => See next post!

As settings for the LUTs I used a max-cll of 1000 and a lum-scale of 1.0. RGB or MaxRGB does have no influence. And the same findings also apply to FranceBBs PQ_to_HLG LUT.

I know it nitpicking, but 65387 is 985 nits and not 1000 nits.

ErazorTT

26th January 2024, 19:30

Ok I found out what what my misconception was. The LUT has as input the whole range, not just the relevant part of 0-49271. Since the points are placed evenly on the whole range one can find out which LUT would have a point nearest to the desired value of 75.18%. I made that very simple calculation and it turns out that the LUT with a point nearest to that is of size 138. And that one indeed has the expected max value of 65535 for an input of 49271. However, a LUT of that size is rather impractical, since it does not fit in almost any CPU cache (except of the L3 of modern CPUs).

The LUTs of the following sizes are optimal in the sense, that they provide the highest output at an input of 1000nits PQ (=49271=75.18%) compared to the LUTs of the sizes inbetween them:
5,9,13,17,21,25,29,33,37,41,45,49,53,57,61,65,69,70,74,78,82,86,90,94,98,102,106,110,114,118,122,126,130,134,138
(While the absolute best is 138 since it's the only one actually delivering the max out channels at the given max input.)

So if you choose a LUT size for PQ to HLG conversions, be sure that it has one of these sizes.

ErazorTT

28th January 2024, 19:15

Ok, so I'm now about to finish my monologue :D
To sum up what I figuered out: Depeding on the settings to pq2hlg it is possible to cut down the LUT to remove unnecessary values as long as the LUT does not have the whole PQ range as input. For a LUT with max-cll of 1000 and a lum-scale of 1.0 this means that all input values above 75.18% can be removed from the LUT. This makes the LUT less then half as big (0.7518^3=0.425). For this it is necessary to use the DOMAIN_MAX attribute inside the LUT, setting it to the input level of the highest available point in the trimmed LUT, which is going to be something slightly higher then 0.7518. This DOMAIN_MAX attribute is suppored by both VSCube and DGCube.
If anybody is interested in this, I have written a small application which does this trimming. And if wswartzendruber thinks it's worth to halve the sizes of the LUTs created by his pq2hlg, he could implement this trimming into it.

wswartzendruber

1st February 2024, 21:18

In one post you're talking about overdriving MaxCLL and now you're talking about limiting the input domain. ��

EDIT: We can't put emojis in text?

ErazorTT

19th February 2024, 20:44

@wswartzendruber, yeah sorry I was all over the place with my thoughts.

In the meantime I have sorted my thoughts and came to the following conclusion: Having one LUT for the process of tonemapping the PQ down to 1000 nits AND converting to HLG is proably not the most optimal way of doing it.
The main argument here is that all the different maxcll and lumascales are part of the tonemapping, which can be done with a 1D-LUT (one for each combination of maxcll and lumascale) while the conversion to HLG can be done with a static 3D-LUT, which absolutely never changes.
Since that 1D-LUT can be generated extremenly fast for each combination of maxcll and lumascale, this opens the possibility for dynamic tonemapping.

So I went and implemented exactly that in DoViBaker. It now provides the possibility to have dynamic tonemapping, based on a 1D-LUT generated in memory on the fly. And then on top of that the user can apply the conversion to HLG with a static 3D-LUT. Of course there is also the possibility to have static tonemapping in case the input is just PQ without DolbyVision.

I think that this is an impoved workflow since on top of the addition of dynamic tonemapping, I can also circument the issue with the maximal output brightness of the HLG conversion, by allowing the intermediate output after the tonemapping to be scaled such that it fills the whole singal range. The then adjusted HLG conversion 3D-LUT uses the whole input range, which solves that problem. And also that adjusted 3D-LUT can be much smaller since now all LUT-points are used, and not only those below maxcll.
So instead of having a 65x65x65 LUT where only the lower 50x50x50 points are used, I can now directly use an adjusted 50x50x50 LUT, which has the same fidelity as the usual 65x65x65 LUT but now also hits the absolute max output brightness perfectly, while being less than half the file size (and CPU cache size).

wswartzendruber

20th February 2024, 00:25

hlg-tools inherently can't handle dynamic metedata because it generates static LUTs. If something else comes along and is a better way to do things, that won't bother me none.

kolak

20th February 2024, 15:27

wswartzendruber

27th February 2024, 22:47

I actually don't know that I'm as done with this as I thought I was...

If can I figure out how to efficiently calculate a device-dependent color space's maximum C value in OKLCH, I can quickly do gamut reduction without impacting perceptual brightness. This would let me efficiently:

1. Perform Y-based tonemapping which is not commonly done as it can produce out-of-gamut results.
2. Deal with maximum saturation on a single color channel which causes HLG to clip on that channel.

ErazorTT

28th February 2024, 11:35

This is an idea behind Dolby tone mapping. It's done per shot or even per frame (eg. for live content) with some 'smoothing'.
2 pass mapping sounds like most optimal.

This is exactly what DoViBaker does. If a DolbyVision substream is available it reads it and steers the tonemapping accordingly. And if no DolbyVision substream is available, the stream can be scanned which creates the necessary information which is then again used for the tonemapping.

ErazorTT

28th February 2024, 11:40

I actually don't know that I'm as done with this as I thought I was...

If can I figure out how to efficiently calculate a device-dependent color space's maximum C value in OKLCH, I can quickly do gamut reduction without impacting perceptual brightness.

That sound interesting, however looking at https://oklch.com/ it appears to me that the numerical range of the C varialbe has a complicated functional form depeding on the other two variables (this "mountain range" on the top right of the page). How do you plan to use this for gamut reduction?

wswartzendruber

28th February 2024, 17:31

That sound interesting, however looking at https://oklch.com/ it appears to me that the numerical range of the C varialbe has a complicated functional form depeding on the other two variables (this "mountain range" on the top right of the page). How do you plan to use this for gamut reduction?
Right now, I am using brute force to reduce C by an incredibly small amount until converting to RGB has everything in the 0.0-1.0 range. I have generated an experimental BT.2020-to-BT.709 LUT with this method and sent that off to FranceBB for evaluation.

Example Screenshot of Joker HLG (https://wswartzendruber.net/images/bt2020to709-1/bt2020to709-joker-hlg.png)

The OKLAB author mentions elsewhere a far more efficient method that I may implement. It relies on color gamut being the shape of a triangle.

FranceBB

29th February 2024, 16:00

Right now, I am using brute force to reduce C by an incredibly small amount until converting to RGB has everything in the 0.0-1.0 range. I have generated an experimental BT.2020-to-BT.709 LUT with this method and sent that off to FranceBB for evaluation.

Yes and I'm really really really sorry, but I'm still "having fun" with generating DolbyE 5.1 20bit big endian muxed in aiff...
Once that one is sorted, I'll take a very close look at it.
Apologies for the delay... :(

wswartzendruber

29th February 2024, 18:29

Well, I threw the LUT your direction without speaking to you about it prior. You have every right to simply ignore it.

With that said, I am quite thankful that you are willing to review it.

FranceBB

29th February 2024, 22:37

I would never do that, I consider you my friend, we even did a video call together, I would never ignore you. :)
Unfortunately spare time project thingies are piling up. I also still have to review a pull request by frank for videotek which is still there pending... :(
It's not easy when you clock in at 08.30AM and you leave your desk at 09.37PM... :(

wswartzendruber

1st March 2024, 03:32

FranceBB

15th March 2024, 21:28

Ok, I finally had time to review the LUT.
The LUT has been tested against BT2020 SDR 100 nits contents.
Those contents were way more common in early 2013-2015 when the very first UHD H.265 50p 10bit broadcasting began and streams were just WCG (i.e Wide Color Gamut) but there was no standardization around using actual different logarithmic transfer characteristics.
It goes without saying that the world in 2013 was a very different place. Back then, we didn't expect things to end up the way they are now with logarithmic transfers, because the change in standard was already pretty massive without it!
We were effectively moving from H.264 FULL HD 25i TFF BT709 8bit to H.265 UHD 50p BT2020 10bit, so aside from the resolution and the codec, the very big swing was finally going progressive by saying goodbye to interlacing and finally going to 10bit.
As to the BT2020, given that the overwhelming majority of native BT2020 SDR 100 nits contents were coming from sport events (especially football), everything else was mostly still BT709 SDR 100 nits.
This meant that back then the supply chains around the BT2020/BT709 conversions were made to provide an easy roundtrip by effectively allowing to map BT709 points to BT2020 and remap those down to BT709 almost perfectly in a similar way of what was done for BT709/BT601. This meant it was possible to convert a native BT709 content without "inventing" anything but rather by just remapping the points to the right BT2020 coefficients so that those could then be mapped back (eventually) to BT709 if it was needed.
Back then little did we know that we would end up broadcasting different transfer characteristics, in fact working with logarithmic curves was common but not standardized and it was only an intermediate step in the production process and given that there was no standard everyone came up with its own implementation, the likes of Sony with Slog, Canon with Clog, Arri with LogC, ImagineVision with ZLog for their ZCam etc. What was worse was that each manufacturer included this info either as proprietary metadata in the file (Sony) or by writing the metadata as additional info, so in the "wrong" place in the file (Arri, ImagineVision) or even by blatantly lying and saying BT709 and then including the actual info in a sidecar XML (Canon).
This is still relevant today 'cause if we have HLG is thanks to the development and efforts done in those early days to standardize the whole thing and with the concept that people who still own a BT2020 SDR TV can still watch the stream.
As for the BT709 SDR -> BT2020 SDR -> BT709 SDR roundtrip, it was due to the fact that it was commonly thought back then that we would have been having a single master for everything in BT2020 SDR from which everything else needed to be obtained, a bit like what happened for BT709 (in fact I'd say that 100% of the BT601 SDR versions in 2013 were obtained automatically from the BT709 master). I made several tests with Jean Philippe Scotto di Rinaldi back then and in fact it's possible to apply a perfectly valid roundtrip in his HDR Tools like so:

#BT709 to BT2020
ConvertYUVtoXYZ()
ConvertXYZtoYUV(Color=1, pColor=2)

#BT2020 to BT709
ConvertYUVtoXYZ(Color=1)
ConvertXYZtoYUV(pColor=1)

This can be shown as follows (roundtrip BT709-2020-709):

BT709
BT2020
BT709

https://i.imgur.com/63OSOf5.png
https://i.imgur.com/9WBuF92.png
https://i.imgur.com/5IJBU5f.png

As you can see, the roundtrip is performed correctly.
Now, enough of that, on with the tests:

https://i.imgur.com/NBM2np9.png
https://i.imgur.com/ug7mAcd.png
https://i.imgur.com/kqQxUHK.png
https://i.imgur.com/1XspL7P.png
https://i.imgur.com/PnhNxdt.png
https://i.imgur.com/smNdknQ.png
https://i.imgur.com/b9wI0hq.png
https://i.imgur.com/th6qiYy.png

Note that I've just labelled the results obtained with William's LUT "HLG Tools" although he said that it's still experimental and he hasn't included it yet.
Here we can see that OKLAB (the algorithm he based his LUT on) seems to be producing a darker output, thus producing a slight shift in chroma. In some scenes it's much more noticeable, while in some others it's harder to spot. For instance, in the blue of the ambulance it's pretty noticeable. The overall result, however, is not bad and if someone didn't have something to compare it against, he would never be able to notice the difference.

If I have time, I'll try with some sport footage next time.

wswartzendruber

16th March 2024, 00:07

EDIT: Whoops, nevermind.

FranceBB

18th March 2024, 10:15

New test, this time on Sports, which is actually a true representation of BT2020 SDR 100 nits and I have to say that the results are actually pretty good there.
Both HDR Tools and William's new LUT achieve a very good result. The game was totally watchable and the results were incredibly close. I guess William's new idea of reducing the chroma to make it fall within valid BT709 SDR values works, so... well done. :)

https://i.imgur.com/fe9wwg5.png
https://i.imgur.com/ZjxmWA5.png
https://i.imgur.com/F9u9Boz.png
https://i.imgur.com/yl3TLTZ.png
https://i.imgur.com/OMuCUEM.png
https://i.imgur.com/qnu75xy.png
https://i.imgur.com/FahY82i.png
https://i.imgur.com/VnhnJiw.png
https://i.imgur.com/YBpSoPL.png
https://i.imgur.com/W3weWZF.png
https://i.imgur.com/1FSC00Y.png

wswartzendruber

19th March 2024, 05:53

Yeah so it really does just hard-clip the color gamut. This is typically hard to do because finding a LAB/LCH-based color model than can do this can be a bit difficult. If a color model doesn't cause perceived brightness changes from lowering the chroma, then it will probably cause a hue shift from doing so.

Anyway, here's the OKLAB/OKLCH-based LUT:

https://wswartzendruber.net/uploads/bt2020to709.cube

I find this also works quite well for watching my HLG conversions on my 709 devices:

https://wswartzendruber.net/images/bt2020to709-1

ErazorTT

20th March 2024, 16:46

Since my last replay in here, I also have been working on a LUT generator from PQ down to HLG, 2020 SDR and 709 SDR (DoViLutGen which is now part of DoViBaker (https://github.com/erazortt/DoViBaker)). Including a LAB based mapping to prevent hard clipping for 2020 to 709. And there, what transfere function would you guys think is the proper one to take for going to and from linear, the one from BT709 (scene-referred) or the one from BT1886 (display-referred)? wswartzendruber has apparently used BT1886, which after some back and forth I now also think it probably the right one. But what do you think FranceBB?

FranceBB

20th March 2024, 21:18

And there, what transfer function would you guys think is the proper one to take for going to and from linear, the one from BT709 (scene-referred) or the one from BT1886 (display-referred)?

I'm using display-referred.

wswartzendruber

20th March 2024, 23:18

I've had good results using the same LUT to convert both BT.2100 HLG and BT.2020 SDR into BT.709 SDR.

FranceBB

21st March 2024, 07:32

I've had good results using the same LUT to convert both BT.2100 HLG and BT.2020 SDR into BT.709 SDR.

Yes of course, that's the whole point about HLG.
On a BT709 classic monitor by just converting the matrix/primaries and leaving the transfer alone, you're essentially seeing the same results a person with a BT2020 SDR TV would see when its TV doesn't interpret the transfer. And with HLG the idea is that you're still gonna be able to enjoy a valid result, albeit dimmer.

In the future, hopefully, SD and FULL HD channels will be tossed in favour of one single UHD BT2020 HLG stream per channel, but that future ain't here yet and we still have SD channels... :(

FranceBB

26th March 2024, 13:40

Same test but this time with an HDR HLG source.
The same concept applies, but this time round I included the waveform to make things more clear.
Effectively, by just converting the matrix and primaries the luma is left untouched, which means that the result will be dimmer compared to tonemapping, but it will be very close to what someone with a BT2020 SDR TV would see.
In this example we have the BT2020 HLG source on the left, Reinhard tonemapping to BT709 SDR (HDR Tools) in the middle and then a simple colormatrix and primaries conversion with William's LUT (HLG Tools) on the right:

https://i.imgur.com/alDi2y7.png
https://i.imgur.com/LXwpnFK.png
https://i.imgur.com/nqa2cw6.png
https://i.imgur.com/FkEJ23a.png
https://i.imgur.com/WQ7XxwB.png

as we can see from the luma, this is left untouched by William's LUT and therefore it will peak at the same level as the original HLG source, thus making the white look a bit dimmer. This is exactly what HLG was created for and it's basically the same result someone with a BT2020 SDR TV at home would see. The idea behind HLG is to make it watchable without having to convert the transfer for the BT2020 SDR TVs, so the very same concept can be applied to convert from WCG BT2020 to BT709 leaving the original transfer alone. :)

wswartzendruber

26th March 2024, 17:20

I was thinking about something several days ago and had a realization. With SDR, indoor and outdoor scenes tend to have small variance in where reference white would be. But with HDR, there is a lot more variance between these scenes. With the BBC putting reference white at 75% HLG, and then by viewing this on a SDR display, we effectively have these dimmer indoor scenes "pushed up" towards 75% and the brighter outdoor scenes "pushed down" towards the same level. This seems to go a long way in making HLG look "like it should" despite the greater variance in HDR's levels of indoor vs. outdoor scenes.

As best I can tell, the 75% HLG level for reference white was a BBC innovation, as NHK's original specification called for 50%. Another way to put this is that the NHK seems to have viewed HLG as a hack to have basic monitoring work on existing 10-bit equipment while the BBC wanted HLG to "just work" on existing 10-bit consumer devices.

wswartzendruber

3rd April 2024, 20:37

I've got Planet Earth II showing up on 4K Blu-ray today. :D

For those who don't know, this is what was used to show the world HLG for the first time in 2017 using the BBC's iPlayer app.

As I understand it, the content was natively graded in HLG and then for this disc, converted directly to PQ. So hopefully, reference white is parked neatly at 203 nits and MaxCLL is right at 1,000 nits.

FranceBB

3rd April 2024, 21:51

I've got Planet Earth II showing up on 4K Blu-ray today. :D

uuuuuh David Attenborough, a national legend!
I love the BBC documentaries in HLG, they're always perfect and his voice is so calm.

For those who don't know, this is what was used to show the world HLG for the first time in 2017 using the BBC's iPlayer app.

Yep, the only things I still don't like about the BBC iPlayer are:

A) No 5.1 support
B) No HLG support on the web version

The first one is a bit sad 'cause lots of programs are actually made in 5.1 and yet they're just sent out as stereo (as a long-time subwoofer owner, I care about this).
The second is really sad 'cause you can see the glorious UHD HLG contents if and only if you're using the BBC iPlayer App AND your Smart TV is supported. On one side, I understand that this means that they rigorously test each and every device the app works on (and I'm not joking here, when I met Andrew, one of the guys from the BBC, he said that they absolutely positively test them all to make sure they perform correctly), but on the other side it's a bit sad 'cause it means that whenever it comes to generic things they can't test like the web version they limit the features to the very bare minimum set of what they know is gonna work... :(

FranceBB

2nd May 2024, 11:16

Currently, I'm employing brute force to minutely decrease C until the conversion to RGB falls within the 0.0-1.0 range. Using this approach, I've produced an experimental BT.2020-to-BT.709 LUT, which I've forwarded to FranceBB for assessment.

No, you did no, you useless AI powered bot.
William did, William created it.
Man, I'm starting to miss the old spammers that used to register, post a link and get banned. With AI it's now harder to spot those stuff...

Anyway, I've reported the account, it will be banned soon.

wswartzendruber

2nd May 2024, 21:22

If I respond to the bot, does that count as talking to myself like a crazy person? ��

wswartzendruber

21st May 2024, 04:52

Here's a comparison between the OKLCH LUT and VLC on Windows:

https://wswartzendruber.net/images/oklch-lut-vs-vlc-windows/ospray-interior.png

https://wswartzendruber.net/images/oklch-lut-vs-vlc-windows/analysts.png

https://wswartzendruber.net/images/oklch-lut-vs-vlc-windows/used-car-lot.png

https://wswartzendruber.net/images/oklch-lut-vs-vlc-windows/mikayla.png

https://wswartzendruber.net/images/oklch-lut-vs-vlc-windows/pursuit.png

https://wswartzendruber.net/images/oklch-lut-vs-vlc-windows/optimus-prime.png

https://wswartzendruber.net/images/oklch-lut-vs-vlc-windows/glenn.png

https://wswartzendruber.net/images/oklch-lut-vs-vlc-windows/autobots-en-route.png

tormento

10th March 2025, 19:46

Version 1.0.1 is out.
I have a strange issue with the anime The Castle of Cagliostro.

The mediainfo reports:

Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Le : 159 cd/m2

Being so dark, I wanted to try your utility, after checking the true values for both of them. I have a MaxCLL of about 450 (with a peak of 2200, probably an artifact) and a Reference white of 160.

I have created two luts: one peaking at 500 and one peaking ad 2200. The very strange part is that, even if they are different, I can see no difference at all in the output, even using the Tektronik plugin by FranceBB. The nit graphics are really identical.

Any idea?

This is the distribution:

https://i.ibb.co/VcKds82n/Cagliostro-UHD-HDR-plot.png (https://ibb.co/VcKds82n)

This is the output with BBC lut for 1000 cd/m2

https://i.ibb.co/ZpWFNxhD/image.png (https://ibb.co/ZpWFNxhD)

This is the output with generated lut for 500 cd/m2

https://i.ibb.co/twHHNLmJ/image.png (https://ibb.co/twHHNLmJ)

This is the output with generated lut for 2200 cd/m2

https://i.ibb.co/nMWQYzKh/image.png (https://ibb.co/nMWQYzKh)

I can see no difference between the last two. Why?

The script is (obv changing the lut):

LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
LoadPlugin("D:\Eseguibili\Media\DGCube\DGCube.dll")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\DehaloAlpha\Dehalo_alpha.avsi")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\Dither\mt_xxpand_multi.avsi")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\FineDehalo\FineDehalo.avsi")
DGSource("M:\In\Cagliostro UHD\Cagliostro_UHD.dgi",ct=44,cb=44,cl=0,cr=0)
Y = ConvertToY(matrix="rec2020").DeBilinearResizeMT(1920, 1036, threads=1, prefetch=2, accuracy=2)
U = UToY()
V = VToY()
YToUV(U, V, Y)
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="2020:st2084:2020:limited=>rgb:st2084:2020:full", resample_filter_uv="Spline64", dither_type="error_diffusion", use_props=0)
DGCube("D:\Programmi\Media\AviSynth+\cube\BBC LUT 1.7\1a65_PQ1000_HLG_Type1_Transcode_nocomp-v1_7-cicp.cube", in="full", lut="full", out="full")
z_ConvertFormat(pixel_type="YUV420P16"", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="Spline64", dither_type="error_diffusion", use_props=0)
fmtc_bitdepth (bits=10,dmode=8)
VideoTek(Mode="HLG", Type="nits")
Prefetch(2,6)

wswartzendruber

12th March 2025, 02:38

That looks right to me. Let's start off with establishing some things about how pq2hlg behaves:

Reference White Scaling

If you enter a reference white value (in this case 160 nits), then the linear RGB values will be proportionally scaled to bring that level up to 203 nits. This makes the effective MaxCLL values 571 nits and 2,791 nits, respectively.

Tone Mapping

The effective MaxCLL value (after reference white scaling) is how pq2hlg determines when to apply tone mapping. Simply put, if the effective MaxCLL value is 1,000 nits or less, the process is skipped altogether because it simply isn't needed. So this means that for the first LUT, no tone mapping is done at all, and for the second LUT, tone mapping is calculated based on a MaxCLL of 2,791 nits. So how does this end up working out?

Well, in the case of 2,791 nits, tone mapping doesn't really begin to set in until around the 700 nit mark. Meaning, pq2hlg won't be doing much brightness adjustment on anything dimmer than that. And from what I'm seeing here, the maximum brightness on anything visible is only 400 nits. So...there won't be any visible tone mapping applied.