Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Announcements and Chat > General Discussion

Reply
 
Thread Tools Search this Thread Display Modes
Old 31st December 2023, 01:54   #401  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,915
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:


until you realize it actually comes out of this:


(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

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




in BT709 SDR as a reference:


Last edited by FranceBB; 2nd January 2024 at 09:07.
FranceBB is offline   Reply With Quote
Old 31st December 2023, 21:57   #402  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 414
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.

Last edited by wswartzendruber; 1st January 2024 at 02:12.
wswartzendruber is offline   Reply With Quote
Old 2nd January 2024, 10:15   #403  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,915
Quote:
Originally Posted by wswartzendruber View Post
Surely something there is above 0.52V...
Is there? XD

Quote:
Originally Posted by wswartzendruber View Post
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...
FranceBB is offline   Reply With Quote
Old 3rd January 2024, 03:52   #404  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 414
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.

Last edited by wswartzendruber; 3rd January 2024 at 04:34.
wswartzendruber is offline   Reply With Quote
Old 3rd January 2024, 08:34   #405  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 414
Titanic: Rose Arrives in Southampton [SDR-WCG]

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.
wswartzendruber is offline   Reply With Quote
Old 3rd January 2024, 10:09   #406  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,915
Arg, nope, it reports BT709 SDR from the internal YouTube conversion...
Looks like it's internally converting to BT709 8bit...
FranceBB is offline   Reply With Quote
Old 3rd January 2024, 15:16   #407  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 414
Bah. Fine.

https://wswartzendruber.net/uploads/...-bt2020sdr.mkv
wswartzendruber is offline   Reply With Quote
Old 4th January 2024, 10:49   #408  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,915
Looks good now and even in SDR there's still headroom.



BT2020 SDR



BT709 SDR (as reference)




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:

FranceBB is offline   Reply With Quote
Old 4th January 2024, 15:43   #409  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 414
Well I'm glad it came out good. Here's the LUT if you want it:

https://wswartzendruber.net/uploads/...t2020-sdr.cube
wswartzendruber is offline   Reply With Quote
Old 10th January 2024, 11:52   #410  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
Quote:
Originally Posted by wswartzendruber View Post

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.
ErazorTT is offline   Reply With Quote
Old 12th January 2024, 23:42   #411  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 414
Quote:
Originally Posted by ErazorTT View Post
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.
wswartzendruber is offline   Reply With Quote
Old 23rd January 2024, 18:51   #412  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
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:


HLG:


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.

Last edited by ErazorTT; 23rd January 2024 at 19:13.
ErazorTT is offline   Reply With Quote
Old 23rd January 2024, 20:23   #413  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 414
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...

Last edited by wswartzendruber; 23rd January 2024 at 21:13.
wswartzendruber is offline   Reply With Quote
Old 24th January 2024, 01:52   #414  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 414
* BANG!!! *

Anyway, here's 2.1.0: https://github.com/wswartzendruber/h...elease%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. :-)

Last edited by wswartzendruber; 24th January 2024 at 06:12.
wswartzendruber is offline   Reply With Quote
Old 24th January 2024, 16:23   #415  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
Quote:
Originally Posted by wswartzendruber View Post
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.

Last edited by ErazorTT; 24th January 2024 at 16:25.
ErazorTT is offline   Reply With Quote
Old 24th January 2024, 17:09   #416  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 414
Quote:
Originally Posted by ErazorTT View Post
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.
wswartzendruber is offline   Reply With Quote
Old 26th January 2024, 18:41   #417  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
I just have made another test with the following script:
Code:
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.

Last edited by ErazorTT; 28th January 2024 at 19:19.
ErazorTT is offline   Reply With Quote
Old 26th January 2024, 19:30   #418  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
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.

Last edited by ErazorTT; 28th January 2024 at 19:23.
ErazorTT is offline   Reply With Quote
Old 28th January 2024, 19:15   #419  |  Link
ErazorTT
Registered User
 
Join Date: Mar 2003
Location: Germany
Posts: 215
Ok, so I'm now about to finish my monologue
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.

Last edited by ErazorTT; 28th January 2024 at 19:25.
ErazorTT is offline   Reply With Quote
Old 1st February 2024, 21:18   #420  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 414
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?
wswartzendruber is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:44.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.