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 > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 28th December 2020, 23:33   #61  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
I'm getting to the point where I'm happy with how this is working. Also, I'm turning it into a LUT generator. My vision is for HLG content to become more accessible, but converting HDR10 movies is rather difficult. This utility could be used to generate movie-specific LUTs that are tuned for the movies they will transcode. Anyone could then download the LUT for their movie (clarified by UPC code) and do the conversion themselves.

I have some more testing to do and some open source compliance issues to work out, then I'll post the 1.0.0 binary.
wswartzendruber is offline   Reply With Quote
Old 29th December 2020, 03:20   #62  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,869
Quote:
Originally Posted by wswartzendruber View Post
I'm getting to the point where I'm happy with how this is working. Also, I'm turning it into a LUT generator.
Great, the more the merrier.
And since we're here: Merry Christmas (late) and Happy New Year (soon).
FranceBB is offline   Reply With Quote
Old 29th December 2020, 04:48   #63  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
Quote:
Originally Posted by FranceBB View Post
Great, the more the merrier.
And since we're here: Merry Christmas (late) and Happy New Year (soon).
By the way, how long should a LUT be on each side? The current default for this thing is 32x32x32. Also, it generates .cube files. And do LUTs need titles?
wswartzendruber is offline   Reply With Quote
Old 29th December 2020, 21:07   #64  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,869
There are two kinds of LUTs, 1D and 3D.
The 1D ones are 1024, 4096 and 16384.
Now, in your case we're talking about 3D LUTs.
For 3D, sizes are 17x17x17 (this is just barely acceptable, but I would not recommend it), 33x33x33 (average quality, generally good and widely supported by lots of programs, even the home-user oriented ones). Lastly there's 65x65x65 which is broadcast quality and it's supported by programs like AVID Media Composer and surprisingly also by the Avisynth plugin "cube". As to FFMpeg, it didn't support them when I tried years ago, but users reported on my thread that it now does so it seems that they recently introduced support (where "recently" means 2 years ago) but I didn't have time to test them on FFMpeg yet. As to the title, I do put the title in my matrices and I also put a comment inside that states what it does and who made it (i.e me). As to the ".cube" extension, you're gonna be absolutely fine as it's the most widely supported one. There are also.ilut, .olut, .lut, .3dl, .spi3d, .3dl but again, I would go with a generic .cube as it's the most supported one.

Last edited by FranceBB; 29th December 2020 at 21:12.
FranceBB is offline   Reply With Quote
Old 30th December 2020, 02:42   #65  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
I've gotten FFMPEG to work with a 65x65x65 LUT, but setting the interpolation to "tetrahedral" results in everything having a really green tint.

The Cube specification from Adobe states that some software works faster with LUTs that are sized according to an even power of two. Would it be rational to host two sizes, then: 32x32x32 and 64x64x64?

Last edited by wswartzendruber; 30th December 2020 at 02:56.
wswartzendruber is offline   Reply With Quote
Old 30th December 2020, 02:53   #66  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,869
Well, since I use Avisynth and AVID most of the times, I didn't really test FFMpeg as I said. If you want, cross check the result in Avisynth to see whether it's FFMpeg misinterpreting the matrix or something wrong in the cube, but I bet it's FFMpeg.
FranceBB is offline   Reply With Quote
Old 30th December 2020, 05:41   #67  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
Aha! It's a bug with FFMPEG when dealing YUV444P10LE. When forcing the signal down to YUV420P10LE, it looks correct.
wswartzendruber is offline   Reply With Quote
Old 30th December 2020, 10:32   #68  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,869
Quote:
Originally Posted by wswartzendruber View Post
Aha! It's a bug with FFMPEG when dealing YUV444P10LE. When forcing the signal down to YUV420P10LE, it looks correct.
Ah...
Then it has to be reported in the bug tracker so they can fix it, I guess...
FranceBB is offline   Reply With Quote
Old 3rd January 2021, 20:03   #69  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
Quote:
Originally Posted by FranceBB View Post
Ah...
Then it has to be reported in the bug tracker so they can fix it, I guess...
I should. I'm just dragging my feet on it. I can't believe something like this doesn't have unit tests.
wswartzendruber is offline   Reply With Quote
Old 3rd January 2021, 20:32   #70  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,869
Pro and cons of open source, I guess... sometimes bug are there and nobody tested things
FranceBB is offline   Reply With Quote
Old 4th January 2021, 00:42   #71  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
Holy cow, Man of Steel drives one of the RGB channels all the way to the max. And reference white seems to be at 100 nits. Maybe because it's an early title?

This will be an interesting stress test for the tone mapping system. It's going to be doubling linear luminosity to bring reference white up to 203 nits. That's going to put MaxCLL over 10,000 (which, as float-64 is used internally, won't cause clipping).
wswartzendruber is offline   Reply With Quote
Old 4th January 2021, 07:47   #72  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,869
Considering that it has been released in 2013, it can be.
I don't have the m2ts of that title, but what did they write in the metadata? Besides, how come it maxes out RGB? I mean, reference white at 100 nits and RGB maxed out makes me lean towards BT2020 SDR.
FranceBB is offline   Reply With Quote
Old 4th January 2021, 23:25   #73  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
I'll get the metadata and parsed stats when I'm off work. In the meantime, here's what MPV shows for BT.709. Putting reference white all the way down to 100 nits still makes it seem a bit dark.

https://imgur.com/gallery/KRSkpFj
wswartzendruber is offline   Reply With Quote
Old 5th January 2021, 02:37   #74  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
Here's what mediainfo says:

Code:
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : PQ
Matrix coefficients                      : BT.2020 non-constant
Mastering display color primaries        : Display P3
Mastering display luminance              : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level              : 7770 cd/m2
Maximum Frame-Average Light Level        : 1468 cd/m2
Original source medium                   : Blu-ray
The main thing that stands out to me is that MaxCLL actually exceeds the Mastering Display Luminance. In other words, they graded it higher than their reference monitor could show them?

Manually parsing every pixel in the stream with a utility I wrote reveals a maximum luminance of 5,560. This is calculated by first applying the PQ EOTF to each color channel (R', G', B') and then multiplying each one by its appropriate BT.2020 coefficient, and then adding the three channels together.

EDIT: Why is color range limited? I thought a bit value of 0 represents 0 nits, while a bit value of 1023 represents 10,000 nits.

Last edited by wswartzendruber; 5th January 2021 at 02:42.
wswartzendruber is offline   Reply With Quote
Old 9th January 2021, 10:12   #75  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,869
Quote:
Originally Posted by wswartzendruber View Post
Why is color range limited? I thought a bit value of 0 represents 0 nits, while a bit value of 1023 represents 10,000 nits.
Color range limited is perfectly valid and covers the 64-940 range of values in which the color curve spreads, so you just have to re-scale the calculations. For instance, on HDR Monitors, when you turn on the waveform in the settings, it lets you choose Full or Limited, along with the curve. From my experience, PQ and HLG target end users, so they're always limited tv range, while Slog, Clog, LogC, Zlog, Flog etc target studios, so they're almost always full pc range.

Quote:
Originally Posted by wswartzendruber View Post
The main thing that stands out to me is that MaxCLL actually exceeds the Mastering Display Luminance. In other words, they graded it higher than their reference monitor could show them?
Possibly, but since it's a movie about GFX, they probably pushed things high with spikes on graphic effects as they're fake anyway. Heck, it's hard to believe that there is a camera with enough stops to be able to go to 7770 nits now, let alone in 2013, so it's definitely about graphic effects that have been pushed high beyond their limits. I think it's pretty lame to grade something like this. Sure, the standard was just taking shape and it was very new and they probably wanted to make it future-proof, but honestly they made it look impossible to reproduce for any TV at the time as every single TV had to apply an highlights roll off and/or re-scale everything to its maximum displayable amount of nits. For me it's a "no". The HDR Documentary I made in 2019 had 400 nits 'cause it was the maximum I could go with the Canon C300 from CLog3 to HLG without "inventing" anything. For them, just because they have computer-made graphic effects doesn't mean they can go as high as they want, 'cause there are still gonna be real scenes captured with a real camera and if you push things higher than they should, not only you're literally inventing things, but you "stretch" the values so much that you end up getting lots of noise in the dark scenes, so much so that you're forced to "crush" the blacks to make it look ok and average out all the other values. For me, they got cocky with the GFX and ended up getting it wrong...

Last edited by FranceBB; 9th January 2021 at 10:14.
FranceBB is offline   Reply With Quote
Old 9th January 2021, 10:55   #76  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,869
I actually checked what they used. They claim they recorded with Arri cameras in Log-C with 14 stops. If you compare it with PQ, you can easily see how the first (Log-C) is similar, although it starts slightly higher in the blacks and then it goes all the way up to exhaust itself at 14 stops, while PQ still has lots to give as it goes up way slower (and therefore it takes longer to get to the maximum value, so it has more stops, hence more nits). So, in a nutshell, they recorded in Log-C, they were able to go all the way up to 2000 nits from Log-C to PQ and then they used graphic effects to get to the "fake" 7770 nits on a 4000 nits monitor:



(this is plotted with x representing stops and y representing 10bit values scaled to 100%)
FranceBB is offline   Reply With Quote
Old 9th January 2021, 16:50   #77  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
Hold on a sec, I need to go back and redo the LUT generator to put minimum luminance at 64 and maximum luminance at 940, for each curve?
wswartzendruber is offline   Reply With Quote
Old 10th January 2021, 09:30   #78  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,869
Quote:
Originally Posted by wswartzendruber View Post
Hold on a sec, I need to go back and redo the LUT generator to put minimum luminance at 64 and maximum luminance at 940, for each curve?
I'm afraid so, but don't delete the ones you've already made, rather offer the option to the users to choose whether it's Full or Limited range.
FranceBB is offline   Reply With Quote
Old 15th January 2021, 00:10   #79  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
Blargh.

It looks like "legal" range RGB uses 64-940 (as you said) while "extended" range uses 4-1019.

Why is this even a thing? Who said, "Oh, you know, we have a completely defined signal space with definite boundaries, but we're going to artificially not use all of it."

EDIT: I wonder if I'm ever truly going to finish this thing, or if I'm going to take another left hook.

EDIT: I'm tempted to just have this thing document that you need to expand any limited RGB range before using it.

EDIT: I think I got it. I'll follow up with unit tests tomorrow.

Last edited by wswartzendruber; 15th January 2021 at 06:18.
wswartzendruber is offline   Reply With Quote
Old 16th January 2021, 05:16   #80  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 410
When converting to RGB48LE, FFMPEG expands limited Y values into full ones. At least, according to this hex editor I'm looking at. I see Y vales of 64 (little-endian) for the raw YUV420P10LE stream. But when I convert to RGB48LE, they become 0. Converting back to YUV420P10LE from RGB48LE brings it back to limited range.

Where's that bottle of sake... I need to drink... I'll try to wrap my head around this in the morning. Or maybe use it to drive nails into the siding of my house.

Last edited by wswartzendruber; 16th January 2021 at 05:20.
wswartzendruber is offline   Reply With Quote
Reply

Tags
hdr, hlg, pq2hlg

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 12:51.


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