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. |
28th December 2020, 23:33 | #61 | Link |
hlg-tools Maintainer
Join Date: Feb 2008
Posts: 413
|
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. |
29th December 2020, 03:20 | #62 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
Quote:
And since we're here: Merry Christmas (late) and Happy New Year (soon). |
|
29th December 2020, 21:07 | #64 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
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. |
30th December 2020, 02:42 | #65 | Link |
hlg-tools Maintainer
Join Date: Feb 2008
Posts: 413
|
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. |
30th December 2020, 02:53 | #66 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
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.
|
30th December 2020, 10:32 | #68 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
Quote:
Then it has to be reported in the bug tracker so they can fix it, I guess... |
|
4th January 2021, 00:42 | #71 | Link |
hlg-tools Maintainer
Join Date: Feb 2008
Posts: 413
|
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). |
4th January 2021, 07:47 | #72 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
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. |
4th January 2021, 23:25 | #73 | Link |
hlg-tools Maintainer
Join Date: Feb 2008
Posts: 413
|
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 |
5th January 2021, 02:37 | #74 | Link |
hlg-tools Maintainer
Join Date: Feb 2008
Posts: 413
|
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 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. |
9th January 2021, 10:12 | #75 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
Quote:
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. |
|
9th January 2021, 10:55 | #76 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
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%) |
15th January 2021, 00:10 | #79 | Link |
hlg-tools Maintainer
Join Date: Feb 2008
Posts: 413
|
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. |
16th January 2021, 05:16 | #80 | Link |
hlg-tools Maintainer
Join Date: Feb 2008
Posts: 413
|
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. |
Tags |
hdr, hlg, pq2hlg |
|
|