-
YUV > RGB > YUV codec question
OK, first, I know YUV is ‘wrong’, it’s YCbCr, but just for sake of rhetoric allow me to use the YUV term.
I’ve been asked to solve what appears to be a color/luma shift problem from having rendered from DVCProHD to Animation in a 400 x 300 QT format via AE. But I want to get my facts and language straight so that I can not only solve the problem but explain it correctly.
I understand that FCP is a YUV application, and that AE is RGB. However, I believe there is more to it than that. So straighten me out. Here is how I understand it:
If you digitize via SDI from a DBeta source using a “YUV aware” codec, such as Apple 8-bit or 10-bit, or one of the AJA codecs such as v210, the SDI signal is converted to a QT file whose codec is YUV, and therefore the content has NOT been transcoded into RGB. If you then export in the native codec to AE and composite graphics or whatever, then render in the SAME YUV-aware codec, the render should match the color/luma qualities of the original video. this will work despite the fact that AE is an RGB application because the rendering codec is re-converting AE’s RGB interpretation back into YUV [or the RGB aspect is defeated altogether?].
In other words:
DBeta>SDI>YUV codec>AE via same codec=no change in characteristics
If you do all of the above, but render in AE in Animation [an RGB codec], the YUV attributes will be mapped and stretched to the RGB spectrum and will shift the color/luma. This is so because YUV black is 16 on the RGB scale, and white is 235 on the RGB scale, but is being stretched to Zero and 255.
Now here is what is confusing to me: I have read/heard that the NLE process, be it FCP, AVID, Pinnacle [except Cinewave?], Premiere, involves digitizing a YUV source, working INTERNALLY in RGB [meaning, processing fx, rendering], but then converts back to YUV for display and SDI output to tape. Is this true? And if so, does the workflow I just described above mean that I am essentially doing:
DBeta>SDI>YUV-aware codec [internal YUV-RGB-YUV]>AE [RGB>YUV via same codec]>FCP [internal YUV-RGB-YUV]
And if there are High Precision FX renders:
DBeta>SDI>’YUV aware’ codec’ [YUV-RGB-YUV 4:4:4-YUV]>AE [RGB>YUV via same codec]>FCP [YUV-RGB-YUV 4:4:4-YUV]
Maybe eliminate the last [YUV-RGB-YUV 4:4:4-YUV]since it is an import not an SDI digital capture.
So what’s the deal? is it simpler than this?
I am advising that the DVCProHD master material be rendered down to an AJA YUV aware codec in QT by using Compressor, and setting a custom preset for the scaling and pixel cropping rather than going into AE. the client will be given the link to the AJA windows codec download, and they can take the delivery assured that it will not shift on them.
steve covello
-
3 Replies
-
[weevie833] “If you then export in the native codec to AE and composite graphics or whatever, then render in the SAME YUV-aware codec, the render should match the color/luma qualities of the original video.”
This is the root of the problem. Once you’re in AE, everything is processed in RGB[A] at 4:4:4[:4]. Keep in mind that native video files have characteristics such as super-white. Super-white is impossible to process in RGB since there is no white level above 255 (or 1024 for 10-bit). Once you hit 255, there’s no ceiling above that, even if you render in 32-bit float. RGB is RGB. No more, sometimes less.
So even though AE may render back to a native Y’CrCb, it may not hold some of the original values that the raw video file had in the beginning if the color-space values are beyond what RGB can process.
Marco Solorio
-
AE CS3 also has new color management tools to help with these types of anomalies.
Jeremy
-
‘So even though AE may render back to a native Y’CrCb, it may not hold some of the original values that the raw video file had in the beginning if the color-space values are beyond what RGB can process.’
As I understand it, the values in a wide gamut RGB colorspace are from 0 to 255 for R, G & B. In a legal 709 YUV signal the values go from 16 to 235 for the Y, Cb & Cr channels, everything above and below is super, but can still be mapped to RGB values. RGB and YUV just describe the channels present in the colorspace and will both handle the same values at the same bit depth.
The problem is how you ‘stretch’ the black values from 16 to zero, and from 235 to 255 on the whites – this is the shift that weevie is seeing in RGB I believe. Most software has parameters for mapping the values correctly. Question is if it was done right or wrong in the first place.‘Once you hit 255, there’s no ceiling above that, even if you render in 32-bit float. RGB is RGB. No more, sometimes less.’
You can have RGB 10bit log files, which give you the possibility in 10 bits for 1024 logarithmic values – way over what 8 or 10bit linear formats can handle that have just 1024 values.
If you go from 8bit YUV to AE RGB, what you want to do is raise the bit depth of the project in AE to 16 or 32bit floating and then render out into a 10 bit YUV codec. As far as I understand this is the best way to keep super info, & in 32bit floating you can pull the values where you want.
Reply to this Discussion! Login or Sign Up