View Single Post
Old 23rd December 2022, 01:00   #30  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
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