I Have Published a HDR10 to HLG Converter

[kolak]

Unless TVs does it dynamically in realtime ?

[wswartzendruber]

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

[FranceBB]

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]

@FranceBB: Do TVs really do this?

LG does it.

[kolak]

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]

PQ: Overcomplicating consumer video since 2016.

[rwill]

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]

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]

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]

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]

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]

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]

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]

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

[kolak]

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]

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]

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.
And it isn't annoying?

[kolak]

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

[wswartzendruber]

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.

[FranceBB]

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]

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]

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]

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]

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.

[rwill]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[wswartzendruber]

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

[kolak]

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

[wswartzendruber]

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]

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]

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

[kolak]

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

[wswartzendruber]

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]

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]

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

[kolak]

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

[kolak]

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]

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]

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]

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