Hi,
I’ve noticed that when using ACES 2.0 to convert Rec2100 ST2084 (1000 nits) footage, black cracking artifacts appear in the red channel, whereas this does not occur with ACES 1.3.
After conducting some transcoding tests on the footage, I found that when ACES 2.0 processes video-level data, black cracking artifacts appear in red during the conversion of Rec2100 ST2084 (1000 nits), whereas no issues occur when transcoding to images (Full data level).
I would like to know if this is an issue with ACES 2.0 itself or with the DaVinci Resolve software integration, so I can decide whether to report it to BMD.
I’ll let Scott answer definitively. But! Within resolve itself the notion of legal vs full does not really apply as it’s floating point. The only point to where it applies is in your monitoring output and when you write to a codec. So the issue has probably more to do with your original file.
It looks like this is an issue with the ACES 2.0 integration in DaVinci Resolve.
I’ve also noticed that the conversion results from DaVinci Resolve’s built-in ACES 2.0 seem to differ from those of our official CTL version, as shown in the image below.
I’ll try to report this to BMD to see if they can fix these issues, though it seems like it might be quite challenging.
Pure guesswork, but if you are interpreting as video, and some pixels are below CV64, they will map to negative float values. Is the Resolve inverse Output Transform tolerant to negative input? Is the CTL? What if you apply a 0-1 clamp before the inverse OT?
You’re right; variables can indeed cause this issue. Currently, I can reproduce this problem on both Windows 11 and Ubuntu 24.04 (I don’t have a Mac).
The reason I say you’ve altered the data level is based on your screenshot: the colors in the TIFF and MOV frames are noticeably different, as shown in the image below. When I change the MOV setting to “Full,” my display matches yours.
Could you try converting to Rec709 using ACES to see if you can reproduce my results, as shown in Figure 2 below?
That’s beyond my area of expertise, but based on what I’ve seen so far, it appears to be an issue with the ACES 2.0 integration in DaVinci Resolve (specifically the use of ACES DCTL to convert CTL).
Although I’ve already reported this to BMD, I haven’t received any feedback yet. All we can do is wait for a fix, or perhaps they’ll integrate OpenColor IO V2.5 and Config-ACES2.0 V4 in the future.
In my mind, Resolve’s “Inverse Rec.2100 ST2084 (1000 nit)” > “Rec.2100 ST2084 (1000 nit)” is working exactly as expected: meaning scopes look identical with the node enabled or bypassed.
So it could be either CUDA related or maybe there’s an additional project setting affecting the behavior?
Can you post a screenshot of your project settings’ color management?
Welp, timeline/output colorspace is enough to make the preview look different: the default rec.709 (scene) which is what I had vs your Rec.2020 ST2084 1000 nits.
Even though it’s not (officially) color managed, the timeline (and/or output?) colorspace still has an impact on certain operations.
Resolve’s ACES node is behaving as I would expect: invert+forward = bypassed node.
It’s the ACES node in conjunction with the output colorspace of the project settings that is behaving strangely (not to mention the black artifacting that might be CUDA specific).
