To help map out exactly where the pipeline is breaking, could you clarify a few details?
Just to confirm the baseline: what is the exact Output Transform you have selected in your project settings for the 1.3 vs 2.0 setups? (e.g., Rec.709, P3-D65, etc.)
Perhaps I’m confused about your workflow here, but why are you turning off the output transform to create the DCP? The Output Transform is part of what shapes your graded data into display-referred space. If you bypass it, well, I’m not exactly sure what that would give you, but it doesn’t seem right to me.
In the case of this example, Rec709. But it’s actually indifferent. It could be P3D65 or any other, if everything else is coherent. The principle of the resulting DCP being identical to the control file is what matters.
If the output transform is turned off, ACES AP0 Linear is converted to the DCP’s XYZ. But again, that’s not the real point here.
The point is in 1.3 the control file matches the DCP, i.e. the DCP faithfully represents the grade.
In 2.0, it doesn’t. In other words, a DCP created from a 2.0 project/timeline has a shift from the final grade, no matter the output transform.
@Rui_B sorry, right now I don’t have time to test it any further
That said, I’m still not sure why you would disable the Output Transform when creating a DCP. DCP creation from an ACES output isn’t fundamentally different from creating one from any other color workflow, so my expectation would be that the process remains the same. However, I also don’t regularly create DCPs, so I’ll defer to those who use those tools more often and have a better understanding of their intended usage.
One thing that stands out is that if you’re indeed doing exactly the same thing as you’ve done previously and the only variable you’ve changed is using ACES 2 instead of ACES 1, then the difference in behavior may point to a change outside of ACES itself. The core fundamentals of ACES didn’t change between versions 1 and 2. The primary change in ACES 2 is the appearance of the default rendering transform, but that is not the same magnitude of difference that is seen in your provided stills.
Please hand this over to whoever may be able to test this pipeline and get back with the results. As you say, I did nothing different but to change from 1.3 to 2.0. All the operations inside Resolve were the same. Furthermore, I’ve even tested the same workflow in Resolve 21, with the same results.
The only clue I can think of is the implementation of ACES 2.0 within Resolve. But that’s something beyond my knowledge.
Looking forward to learning your team’s conclusions on this. Thank you.
Just to manage your expectations, any “team” I might have is the community here, so the best I can do is to hope that there is someone lingering on this forum that might have their own experience writing DCPs directly from Resolve when using ACES who can assist you.
I might be wrong. When you mean that you export a ProRes444 control file, do you mean a Log file? or already encoded for display?
The difference between the images that you sent seems to be more or less the difference between the rendering between ACES 1.3 and ACES 2.0. So maybe in Resolve you are using one rendering , and for the DCP is using a different version of ACES?
You might need to share a drop file with your node tree, and more information about your set up,
Encoded for display, representing the final grade, to be compared with the DCP.
It seems my first post was not very clear. I apologize for that.
But, in the end, it all comes down to this:
A DCP exported from an ACES 1.3 project represents faithfully the final grade, i.e. when compared to the control file, exported in the color space of the project, both files are identical.
A DCP exported from an ACES 2.0 project has a shift in color and contrast from the final grade, as you can see in the stills I uploaded.
You’re right. Visually it’s what it seems. That’s why I tend to believe there are problems in the ACES 2.0 implementation in Resolve, both in 20.3.3 and 21 versions. I’ve tested this problem on both. So, if you’re able to do a quick test, it’s as simple as exporting to DCP whatever footage you may have at hand, both in a 1.3 and a 2.0 projects, and compare the results with the grade of each project.
It seems I’m not making any progress in explaining this issue… Let’s try again!
The point here is comparing a DCP made from a 1.3 project to its respective grade (no issues, DCP = grade), and a DCP made from a 2.0 project to its respective grade (color and contrast shift, DCP ≠ grade). I’m not comparing grades between different versions of ACES, which will obviously be different.
This is a pain point in Resolve. You think you’re working non color managed, and yet Resolve is color managing the DCP. How and to what colorspace? Unclear, but changing Timeline/Output colorspace (despite being non color managed!) affects how it looks.
As far as I know, Resolve does this exclusively with DCPs (I don’t know about IMFs).
I can’t explain why the two used to match with 1.3 and now they don’t in 2.0, but trying to QC/validate a DCP this way is not ideal.
The way I see it, when you import a DCP to a non-color managed project in Resolve, it will adapt to the project/timeline color space, i.e. XYZ to Rec709, P3D65, etc.
I don’t think this is “wrong”. It’s a way of displaying the agnostic XYZ in the color space of your choice, according to the way you’re viewing it.
This is my point from the beginning. I thought it could be something more widely known but apparently it isn’t.
I may have missed this info but are you color managing using RCM or the ACEStransform nodes? Feels to me you should be discussing this with BMD as the problem lies there most likely.
Now, you mentioned this in the beginning but technically speaking to create a DCP you should have first a DCDM. From that DCDM you should produce your DCP.
My use case and issue, however, is an ACES 2.0 project, color managed, with the respective IDT’s assigned to the clips → export DCP and control file (ProRes444 Rec709 Gamma 2.4):
To compare the DCP with the control file, new project, non-color managed → import both files, they should match, but they don’t. There’s a shift, visible in the stills uploaded previously.
You might need to upload a video with every detail for your set up. Node tree and export settings at least.
I tried with the settings you have and the exported file re-imported and looks the same brought back in. Even matches manually converted using nodes instead of auto color managed with manual IDT tagging.
