Marc Wielage wrote:The key (which I think I said a year or so ago in this thread) is to always export a few frames of color bars and other test signals, and check the render on a scope. If the other application is suddenly using Data levels when it should be Video levels (or vice-versa), or if something is changing drastically in the render, then you'll see it on the scopes.
+1, critical to establishing any workflow for any program, from open sourced to thousands of dollars, imho.
Thanks to everyone who clarified the problem with Data Levels vs Video Levels. I agree that when dealing with YCbCr, by definition, that is Video, and the luma channel, Y, maps to [64-940] and the chroma channels, Cr and Cb, both map to [64-960]. These values are the 10-bit equivalents of the more traditional 8-bit values that leave headroom and footroom. YCbCr outside these ranges have traditionally been referred to as superwhites and superblacks, and superwhites, in particular, are often encountered in consumer camcorder footage. But I digress.
Here is my question that may or may not be related to the problems others are experiencing. When I:
1. Import my SMPTE color bars that are 8-bit YCbCr 4:2:2 (UYVY)
2. Export the color bars (no effects) as either 8-bit or 10-bit Uncompressed YUV 422
3. Import the exported bars
4. Scope them up along with the original import
there is a slight shift in the scopes. It is probably not very obvious from the attached images. It is much easier to see when clicking between the clips within Resolve and studying the borders between the bars.
It appears that Resolve is resampling the chroma channels upon export because the edges of the bars are blurred in the export. My original bars have clean edges (if anyone is interested in how I generate them, I will be happy to share). The slight noise present on the scope of the original bars is undoubtedly the result of Resolve's resampling to RGB 444 for display on my computer monitor. Now, ordinarily I could live with this. However, what concerns me is that the exports appear to go through this YCbCr 422 -> RGB 444 -> YCbCr 422 pathway as well.
I am using the lite version, so there is no YUV444 option available. I am just spit balling here, but my guess is the only way to bypass the chroma resampling when exporting requires the use of YUV444. Lite users are out of luck. Can anyone please confirm my suspicion?
Thanks everyone.