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 16th January 2021, 14:26   #81  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 1,283
Quote:
Originally Posted by wswartzendruber View Post
Where's that bottle of sake... I need to drink...
Kanpai!! xD

Quote:
Originally Posted by wswartzendruber View Post
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.
Right... So, you've been doing this correctly all the time as you made calculations and analysis in RGB and also applied the LUTs in RGB before converting back to YUV, so, even if you assumed that it was full range, since FFMpeg scaled to full range while bringing things to RGB, the stats were correct. I think that's because there isn't anything such as Limited Range RGB per se (I mean, by definition) outside intermediate broadcast use, so, while it would be logical to assume that a simple "regular mapping" of values would occur when going from YUV to RGB (so 64 to 64 etc) to get a "Limited" range RGB, the FFMpeg devs probably thought that, since there's no such a thing as a flag to display Limited RGB properly, it was a sensible thing to scale those values going from limited to full and then back from full to limited.
When I was making SafeColorLimiter this discussion popped up:

Quote:
Originally Posted by feisty2 View Post
there's no limited range RGB.
and

Quote:
Originally Posted by poisondeathray View Post
There is such a thing as "limited range RGB" . It's also known as "studio range RGB" . In 8bit RGB , 16-235 is black to white (sRGB or "computer RGB" is 0-255 black to white in 8bit, it's far more common) . Limited range RGB is used in r103 compliance checks for broadcast, and some NLE's like vegas use studio range RGB .
but also

Quote:
Originally Posted by feisty2 View Post
a) no television system transmits video in RGB space, so it makes no sense to preserve some "headroom" from the 8-bit range for some metadata that does not exist in the first place.
b) YUV<->RGB conversions are ALWAYS defined on full range RGB, this limited range RGB could not be properly displayed (without some non-standard scaling applied first), or properly converted to YUV by any standard.
and

Quote:
Originally Posted by poisondeathray View Post
these standards exist, you should be aware of them, and we have to live with it because it's still used today.



So, in a nutshell, this is what I think led to the misunderstanding.

1) End users receive a Limited TV Range 10bit 64-940 file with a color curve applied, either HLG or PQ

2) Broadcast studios can also use Full PC Range YUV values for those curves, however it's much more likely to have Full Range only for curves like Slog, Clog, LogC, etc

3) You're checking values and doing your calculations in RGB (assuming that the content is in Full Range) as LUTs must be applied in RGB

but here's the thing: when you have a Limited TV Range YUV file that is delivered to a TV, the TV can read the flag and convert to RGB correctly (since the display is always in RGB), but if you try to deliver an RGB whose black start at 64 and white peaks at 940, there's no way to flag it as "Limited", therefore it would almost definitely be displayed incorrectly unless a YUV conversion is applied or there's some system that is aware of this. This is probably the reason why the FFMpeg guys thought that, when you convert a Limited TV Range content to RGB, you don't want to "work with it", but you want to "deliver it" and, since it wouldn't be displayed correctly if it's linearly mapped, it will expand it! So, in the end, you were doing all correctly in the first place as your calculations assumed Full PC Range, the content was in Limited, but FFMpeg took care of it during the YUV to RGB conversion!

So... I think I may have made you lose time on something that has already been addressed by a conversion you were doing, but hey, we both learned something new today, which is that FFMpeg expands Limited to Full in YUV -> RGB. Who would have thought that...

I'll leave you to the Sakč:



(fun fact I: the first time I tried sakč was in 2009 with my friends in an allegedly Japanese restaurant which was probably run by Chinese pretending to be Japanese; anyway I didn't like it that much.)

(fun fact II: there are three glass in the picture I grabbed from a website 'cause one is for you, one is for me and the other is from whoever wants to grab it. I think StainlessS is more of a Beer guy, so let's see... xD)

Last edited by FranceBB; 16th January 2021 at 14:32.
FranceBB is offline   Reply With Quote
Old 16th January 2021, 22:21   #82  |  Link
wswartzendruber
Registered User
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 103
I just learned how to revert a range of commits in Git.

Since you're handing out drinks, I'll let it go.

Hell, I have a Ryzen 3950X. I can do two movies at a time and make up for lost time.

Last edited by wswartzendruber; 16th January 2021 at 22:36.
wswartzendruber is offline   Reply With Quote
Old 24th January 2021, 06:57   #83  |  Link
wswartzendruber
Registered User
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 103
I believe that as of this very moment, my tooling is complete. This includes a pgsmod utility I have written to crop and tonemap SUP subtitles.

The one thing I don't understand is why my pqstat utility returns higher MaxCLL values than what's in the metadata. Usually it's marginally higher.
wswartzendruber is offline   Reply With Quote
Old Today, 07:05   #84  |  Link
wswartzendruber
Registered User
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 103
pq2hlg and pqstat have now been consolidated under this single repository: https://github.com/wswartzendruber/hlg-tools. The original pq2hlg and pqstat repositories have been archived.

There will soon be a comprehensive HOWTO regarding converting 4K UltraHD Blu-rays to HLG for universal viewing.
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 23:26.


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