I Have Published a HDR10 to HLG Converter

[wswartzendruber]

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).
Yeah, FranceBB threw the BS flag on Man of Steel last year.

[FranceBB]

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]

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]

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

[kolak]

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]

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

[kolak]

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]

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.

[wswartzendruber]

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]

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.
Wait a sec, how is even 4:2:0 going to throw off MaxCLL by 4,000 nits?

[kolak]

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]

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.

[nevcairiel]

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]

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]

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]

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]

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]

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]

Can Dolby Vision be used to determine reference white adjustment?

[kolak]

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]

Can Dolby Vision be used to determine reference white adjustment?

Not that I know of.

[ErazorTT]

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]

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

[quietvoid]

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]

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

[FranceBB]

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]

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

[ErazorTT]

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]

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

[ErazorTT]

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]

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

That is why I wanted to know.

[wswartzendruber]

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

[wswartzendruber]

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]

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]

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]

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]

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]

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

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

Are you kidding me? Human vision can persieve (LG C9 is 0.00006 nits, PQ is minimal 0.0001) 0.000003 (after some adaptation, I personally tried, I can see after 68 (not 65, 66, (64 is black, it does not flicker)) in PQ after 10 minutes of dark room). https://www.mkrgeo-blog.com/the-role-of-contrast-in-ability-of-human-vision/

[Balling]

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]

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]

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]

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]

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]

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]

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]

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]

A new one of course. :)

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

[Balling]

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]

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?

[wswartzendruber]

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