Best Practices for Exporting "Pre-Conformed" RAW Clips

Hi all,

On lower budget projects, a common request I get is to export out "pre-conformed" ProRes 4444 stringouts for color (for use in Baselight, let's say), rather than supplying the original camera media + XML (which would of course be my preference).

Typically, the way I would do this is simple - I'd remove all the effects, etc, and export out my sequence as a ProRes 4444, making sure that the timeline/output resolution reflect the resolution of the camera media. If there's multiple resolutions, they get a stringout with each resolution.

However, it occurred to me that a certain setting might have an impact on the preconformed ProRes - which is, the timeline + output color space, which is by default set to Rec 709 Gamma 2.4.

If I have a project with a Rec 709 Gamma 2.4 setting, and all my raw clips are in it (with "flat" settings), and I output that to ProRes 4444 for pre-conformed color - is that wrong? Should I actually be matching my timeline + output color space to the RAW clip settings? (Of course, if I do this and match the tags - the tags of the ProRes end up being undefined in an odd way).

Or - and this is what I have believed to be the case - does the project color space setting have no direct impact on the output file itself (if color has not been applied), but only matters for the Davinci Viewer??

Very confused!

EDIT: Color Science is set to DaVinci YRGB. Again, I am not coloring, just trying to output "flat" ProRes to color.

In non managed there is no color processing happening on the clips. The timeline space purpose is solely to define your working space for your color tools and node color space conversions to work as you want them to. So say you are grading in ARRI LogC3 and you're converting your camera footage to that space you can then use the tools with the proper "color space aware" properties as you would with a Color Managed project.

The output color space is intended for your file tags and your scopes. It will tell the scopes how to read your data for it's graphs.

When you export footage to ProRes as intermediate file with a log encoding ("flat" settings) you still need to encode it to Rec.709 Gamma 2.4 as this is by default how these files get interchanged typically. The data that is encoded onto it can be anything for that matter and the handling of it depends on the user. Just like you record to ProRes with a camera that shoots log. The file is still Rec.709.

So when you hand off these clips to a colorist you need to communicate what the actual data is so it gets treated properly.

If you shot raw, you'll want to make sure the clips are set in their camera native log encoding and not converted to Rec.709 or any other space intended for display.

Hope that makes sense.

Makes sense! Although I do receive files as 1-1-1 from color houses, often. So next question.

I've been running some tests on the effect of Color Space tags in a "preconform to ProRes" scenario, where I'm outputting and bringing the clips back into Resolve. My understanding is that, if I change only the color space tag in the delivery page and nothing else (again, working in YRGB), then two exports of the same exact thing that only have a difference in color space tag, should match when I bring them back into Resolve, if it's YRGB (unmanaged) and set to Rec 709, Gamma 2.4.

However, when I look at the scopes of an export with a Rec709A tag instead of a Gamma 2.4, there is a very subtle difference (look at the second to last peak of the blues in the provided histograms). This is not behavior I expect, especially since I am working in a non-color-managed workflow. I am simply on my Macbook, with "Use Mac display color profile for viewers" turned OFF.

I am applying 0 color correction or effects. Just placing the clips in a timeline of matching resolution.

Is this difference a result of the scopes looking for Rec709 Gamma 2.4, but seeing a Rec709A tagged clip?

And in further testing - if I uncheck "bypass re-encode when possible," I get the same result in both exports with different color tags, but the scopes are off from the original ProRes file they were exported from (with 1-1-1 tags), to the same degree as the provided screenshots. However, with "bypass re-encode" CHECKED, I get different results in both exports with different color tags, but the export with 1-1-1 tags matches the original ProRes perfectly.

Is this a bug? Any ideas?

Hard for me to tell seeing two seperate scopes. But from your explanation I can only think of the following scenario. One export gets re-encoded with the same data because they match and the other gets re-encoded meaning it gets compressed again. Even though it's ProRes 4444, it's still compression. Scopes may show a more distinct difference than you can tell by eye. Do you see a visual difference? If you overlay one over the other and set the blending to difference, then add gain, how much difference do you see? It should be fairly low.

Another test would be to encode to both tags with a file source that isn't ProRes to begin with so you can be sure they are always new encodings.

In theory you should even be able to encode to Rec.2100 HLG/PQ and Resolve should still see the footage as is. If not then maybe Resolve does do something...

The re-encode does make sense, for sure. I see no visual difference with my eyes (in Resolve's viewer).

I'm supposed to increase the gain by the same amount for each clip with difference mode, right? I don't see a difference in that scenario (the scopes show very little action riding the bottom of the histogram when playing, but nothing when paused - probably expected behavior with compression?).

So! I think I can let this one go? But it helps to know that a color space tag change, when the source is different, will force a re-encode.

Okay, final findings here:

When I exported the original ProRes 1-1-1 source file as 1-2-1 - for whatever reason - Resolve could not bypass the re-encode due to the difference in color tags. That's annoying, but it explains the slight difference I'm seeing in the scopes, because as you said, even though I'm going ProRes 4444 to 4444, it's actually getting re-compressed. I can confirm this, also, by checking the "writing library" in the source files and the exported files' mediainfo - the Rec709A export, from the 1-1-1 file, will always have the same exact writing library as the source file, while the 1-2-1 has a different writing library, which shows it was actually re-encoded.

If I uncheck "bypass re-encode," the exports with the different tags match each other perfectly, and they both have the same writing library.

I tested with a variety of different ProRes files from different sources, and was able to get the same results as each scenario laid out above. When going from a non-ProRes source, they matched all the time, because bypassing the re-encode was not possible.

TL;DR - A difference in only color tags on an export does not in and of itself produce a difference - but, Resolve forces a re-encode if the color tag in the delivery page does not match the source file (assuming they're the same codec), which results in a slight difference.

As I expected then
Very good observations. And nice to see you ran the tests thoroughly to confirm it!

As I expected then
Very good observations. And nice to see you ran the tests thoroughly to confirm it!

hello, Can I ask a question about "YRGB"? Because when I set the timeline colorspace, my android robot(wide gamut picture) be viewed correctly in view window, but in DAVINCI YRGB, the default profile is rec 709+gamma2.4, the robot shoudlen't be see in view window, what's happened?

DaVinci YRGB doesn't do any color management by itself. If you think about the image values as pure data, a fully saturated red would mean 1,0,0 in float values. If for this color gamut a second "full red" of a smaller gamut is stored, it can have a value of say 0.8, 0.1, 0. If you give these values directly to your display you will always see these differences no matter what your display is because it will show up on the monitor as maximum red and the less saturated red as the other value.

When you use color management and tell the system that the source gamut is P3 for example. It will convert all the values to Rec.709 if that's your target. There can be different ways in which this happens depending on the type of color management but it's very likely that pure R, G or B values end up very close or on the smaller display's primary values.

So if in your image the outside was P3 red and the inside Rec.709 red within that P3 image, they could end up on the same place in Rec.709 after conversion. The inside color doesn't change because it was already in Rec.709 1,0,0 position wise.

0.png (362.2 KiB) Viewed 861 times

Hope that makes sense.