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 22nd December 2022, 22:08   #21  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,258
Quote:
Originally Posted by kolak View Post
ProRes is always YUV based internally.
Perhaps it's stored that way, like other codecs that have YUV and RGB, but do you know of any implementation that handles Pr4444 with RGB options properly ?

The Apple Prores whitepaper claims that Pr4444: "also offers direct encoding of, and decoding to, both RGB and YCBCR pixel formats."


Quote:
Originally Posted by kolak View Post
ProRes444 out of Resolve will have min Y as 254 and max Y of 3765 for SMPTE bars. Both slightly off ideal values.
ProResHQ will have 63 and 941.
(at least those are reported by ffmpeg, which I don't trust 100% either).

I don't 100% trust them either, and I always try verify with other tools/workflows. You can export 12bit dpx out of Resolve, using various Resolve decoder(s) and measure that (if the import wasn't 12bit dpx, resolve 17 clips 4095 on windows according to the test above) also check export 16bit PNG/TIFF and downcovert to 12bit without dithering and measure

Quote:

DNxHR has 245 and 3777, but because ffmpeg decodes it to YUV (even if file is RGB). I requested YUV stats, so actually it has to convert.


Yes, reported before on ffmpeg trac for DNxHR 444 12bit RGB. The dev answer was: "This is because files use ACT, adaptive color transform, when some blocks are encoded in RGB instead of YUV and vice versa." - and it's not implemented in libavcodec for DNxHR decoding . If you take the test ramp posted above, and encode to DNxHR 444 12bit in resolve, you can see the errors in ffmpeg/libavcodec based decoders on the RGB blocks.
(e.g. vapoursynth/avisynth lsmash, ffmpeg/ffplay/mpv) . I also posted examples in other threads


Quote:
Some things never change- it's that much you can trust those pro tools
Certainly the lessons I've learned in the past are are don't blindly trust any tool (pro or opensource) . Version upgrades can break stuff previously working. Don't upgrade in the middle of projects. Verify your workflow before you commit to anything
poisondeathray is offline   Reply With Quote
Old 22nd December 2022, 22:29   #22  |  Link
groucho86
Registered User
 
Join Date: Apr 2016
Posts: 82
Quote:
Broadcast/ streaming services don't care about this stuff and will expect limited range anyways
There's one service that explicitly asks for full range and I've been academically debating it with them....

Quote:
This is just academic geeky testing
100%. And loving it


Quote:
Can you check on a mac if the 12bit DPX import/export clips 4095 ?
Confirmed still clipping.


Quote:
Originally Posted by kolak View Post
No one said YUV has to be legal. There is no such a hard requirement. It's just how it was used in the past, so it became a norm, but it's really obsolete "requirement". Today's digital world doesn't need it anymore. If not worse compression efficiency we could just stick to RGB snd don't even bother with YUV. YUV is for saving bandwidth (by 'cheating' on sampling) and also to get better compressibility.
When it comes to ProRes itself then things are bit different, because by official spec ProRes should always be legal. There is no way to flag range in ProRes private headers (nor in eg. MOV container), but there is in MXF. Saying this you can export full range ProRes, just be careful when importing as app has to be "somehow" aware it's full range. Resolve lets you interpret both ways, where eg. Premiere has (stupid) hard coded rules- 422 is always treated as limited where 444 as full!. ProRes is always YUV based internally.
In this aspect DNxHR is better as it has private headers range flag and 444 can also be YUV or RGB based, so it covers all cases (if I remember well Resolve uses RGB version).
I did not know Premiere assumed ProRes 4444 (MXF and MOV?) was full range. That is strange.

...

So I decided to take a break from pattern testing - clearly the SMPTE bars were giving me an incredibly incomplete picture of of RGB > ProRes 4444 > RGB.
I took 10min worth of 16bit DPX source of Rec2020 (P3 constrained) PQ 1000nit and used Colorfront Transkoder to render out ProRes 4444 legal and ProRes 44444 full and brought them back in to run PSNIR metrics against the original source. Results:

Code:
Legal ProRes 4444
min: 52.4257
max: 90.0
avg: 59.19808741851951

Full ProRes 4444
min: 53.2485
max: 162.556
avg: 59.91924627198857
As predicted by poisondeathray and others, full range provided a slightly better match. My SMPTE bars test was flawed.

In conclusion...?
Pros for full range ProRes 444 MOV
  • Higher fidelity
Cons for full range ProRes 444 MOV
  • No tag that specifies full range. Most softwares will misinterpret it as legal
Pros for legal range ProRes 444 MOV
  • Expected spec
  • Most softwares will correctly interpret it
Cons for legal range ProRes 444 MOV
  • Slightly lower fidelity
groucho86 is offline   Reply With Quote
Old 22nd December 2022, 22:42   #23  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,258
Quote:
Originally Posted by groucho86 View Post
There's one service that explicitly asks for full range and I've been academically debating it with them....
Not common at all...

Which service out of curiosity ? One would have to assume they were handling full range correctly

And did they ask for Pr4444 full range specifically ? or just full range in general ?
poisondeathray is offline   Reply With Quote
Old 22nd December 2022, 22:47   #24  |  Link
groucho86
Registered User
 
Join Date: Apr 2016
Posts: 82
Quote:
Originally Posted by poisondeathray View Post
Not common at all...

Which service out of curiosity ? One would have to assume they were handling full range correctly

And did they ask for Pr4444 full range specifically ? or just full range in general ?
I'd rather not say on a public forum. But yes, we need to assume they're handling it correctly...

UHD deliverables (SDR and HDR) are to be ProRes 4444(XQ) full range

HD SDR deliverables are to be ProRes 422 HQ legal.
groucho86 is offline   Reply With Quote
Old 22nd December 2022, 22:50   #25  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,258
Quote:
Originally Posted by groucho86 View Post
UHD deliverables (SDR and HDR) are to be ProRes 4444(XQ) full range
Interesting, full range unexpected for SDR in this scenario
poisondeathray is offline   Reply With Quote
Old 22nd December 2022, 23:05   #26  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,834
Dolby created mess saying DV has to be full range. It all went bad as most people use ProRes for DV mastering (one level down from 16bit TIFF masters) without knowing that there is nothing describing range in ProRes MOVs.
Now it's all been recalled You can and maybe should use limited range for DV ProRes masters. It's practically harmless (lost precision is meaningless), where full range will in 50% cases handled badly!

If delivery place says full range ProRes I would assume they know what they are saying and will handle it properly. 99% is limited range and better stay this way until specifically requested otherwise.
kolak is offline   Reply With Quote
Old 22nd December 2022, 23:10   #27  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,834
Quote:
Originally Posted by poisondeathray View Post
Perhaps it's stored that way, like other codecs that have YUV and RGB, but do you know of any implementation that handles Pr4444 with RGB options properly ?

The Apple Prores whitepaper claims that Pr4444: "also offers direct encoding of, and decoding to, both RGB and YCBCR pixel formats."
This is confirmed now by many different sources including a guy who can write bit-perfect to Apple ProRes encoder.

Apple paper says encoder/decoder can take RGB data directly (it does internal conversion). Basically that's all what it says in this magic line. Internal data is always YUV (probably for efficiency).

There is no ProRes which stores data as RGB as this is not in Apple spec.
If you want that use DNxHR (just make sure app uses RGB variant for 444) or Cineform.
kolak is offline   Reply With Quote
Old 23rd December 2022, 00:04   #28  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,258
Quote:
Originally Posted by kolak View Post
There is no ProRes which stores data as RGB as this is not in Apple spec.
I was asking about output from the decoder (less interested in how it's stored; but YCgCo would technically be better) - Are you aware of any Pr4444 implementation that has YCbCr vs. RGB output options or controls? Whitepaper implies 2 decoding cases, RGB and YCbCr. For example, you feed RGB in , you get RGB out. Or you feed YCbCr in you get YCbCr out . It seems to be YCbCr in most cases, and the host application possibly converts to RGB .
poisondeathray is offline   Reply With Quote
Old 23rd December 2022, 00:38   #29  |  Link
groucho86
Registered User
 
Join Date: Apr 2016
Posts: 82
Quote:
Originally Posted by poisondeathray View Post
Are you aware of any Pr4444 implementation that has YCbCr vs. RGB output options or controls?.
Nope, always been under the hood.
groucho86 is offline   Reply With Quote
Old 23rd December 2022, 01:00   #30  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,834
Quote:
Originally Posted by poisondeathray View Post
I was asking about output from the decoder (less interested in how it's stored; but YCgCo would technically be better) - Are you aware of any Pr4444 implementation that has YCbCr vs. RGB output options or controls? Whitepaper implies 2 decoding cases, RGB and YCbCr. For example, you feed RGB in , you get RGB out. Or you feed YCbCr in you get YCbCr out . It seems to be YCbCr in most cases, and the host application possibly converts to RGB .
As far as I understand official decoder provides many pixel formats on output (you can feed many on input as well).
It' up to the app to call what it needs/wants. I think Resolve in most cases uses b64a (16bit RGBA), FCPX 32bit float YUV4444 (r4fl). If app is good it writes properly which pixel format was used on input and you can check it with advanced view in mediainfo. Some apps may "lie" though
So basically it all depends how app is written. Good ones try "most direct" pixel format between input/output, eg. if you converting ProResHQ to Cineform it will most likely go over v210. If there is no need you should avoid going to RGB.
RGB in, RGB out would make sense if encoder had native support for YUV and RGB (DNxHR, Cineform). If it does conversion then it's already "less perfect", but you may still avoid double conversion.

Nuke may let you choose requested pixel format. Use to have this.

You have list of supported formats here:
https://wiki.multimedia.cx/index.php/Apple_ProRes

Last edited by kolak; 23rd December 2022 at 01:29.
kolak is offline   Reply With Quote
Old 23rd December 2022, 01:08   #31  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,834
Quote:
Originally Posted by groucho86 View Post

I did not know Premiere assumed ProRes 4444 (MXF and MOV?) was full range. That is strange.
I think last version I tested was 2020. It's was hard coded and Premiere has no "easy" way to overwrite range (like eg. Resolve does). It's very dangerous behaviour.
MOV, no idea about MXF.
Try it. You will see bad levels straight away if you feed limited ProRes444. Then do full and it should be fine.
Resolve (and many tools) always (for 422 and 444) uses limited by default (this is more per Apple spec I think).

Last edited by kolak; 23rd December 2022 at 12:28.
kolak is offline   Reply With Quote
Reply

Tags
full range, limited range, prores, ycbcr

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 05:03.


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