ACES rec.2020 ST2084 - Resolve export color shift

Hi All,

I’m facing a color shift problem on exports from my ACES PQ Resolve 16.2.3 project.
It happens on compressed formats eg. ProRes 444, Sony XAVC Intra CBG 480 which is supposed to be my delivery.
There is no such a problem with rgb files, EXR, DPX.
It affects reds mainly in my case. Hues are shifting clockwise on the vectorscope and luminance in parts of red and green channel is going down.
How can deal with this?

my setup

sony raw file, no grading

exr file imported with proper idt

ProRes 444



ProRes 444

Welcome and thanks for your first post!
Steve T
ACESCentral Admin

Hi Jamihaukowalski,

can you show your export settings window for the ProRes export?
Mine are set to Auto-Levels.

I tried this as well in Resolve with an ACES 2065-1 EXR file, exported a ProRes 4444 ST2084 and loaded it back into Nuke. In Nuke I took the same EXR files, and applied and inverted the same steps with to OCIO colorspace nodes. With this method the color stay the same.
I recorded quickly my screen:

Might be a bug in Resolve? I am using the latest version 16.2.5 Studio

Best regards


Here you are!

1 Like

Ironically, if there is a match in Nuke, that may mean that they do not match!

Nuke (on Mac at least) only offers Rec.601 and Rec.709 matrices for decoding ProRes files. When Resolve writes a ST.2084/Rec.2020 ProRes file, it tags it as such in the metadata (you can check with ffprobe). On Mac at least, opening a movie tagged as being ST.2084 and using a Rec.2020 R’G’B’ to Y’CbCr matrix crashes Nuke instantly.

If you are able to read the ProRes in Nuke on your system, it may be decoding it incorrectly using a Rec.709 matrix. If you get a match with that decode, it suggests that the image data in the file is not correct. Can you see what matrix is being used?

The matrix to compensate R’G’B’ data which has been incorrectly decoded with a Rec.709 matrix, and produce the values which would have been produced by a Rec.2020 matrix is:

set cut_paste_input [stack 0]
push $cut_paste_input
ColorMatrix {
 matrix {
     {0.9499 0.04550612 0.00459388}
     {-0.05422337 1.03810505 0.01611832}
     {-0.00295596 -0.00994404 1.0129}
1 Like

Followup. If I bring a ProRes 444 rendered with the ACES ST.2084 Rec.2020 1000 nits Output Transform back into a non ACES Resolve project with the timeline colour space set to Rec.2100 ST.2084, I see the same slight vectorscope rotation as shown in the original post.

If I use DCTL to apply the inverse of the matrix I gave above, it corrects it to match the original. So it seems there may be some kind of double compensation happening when Resolve writes the file.

1 Like

Hi Nick,

thanks for pointing this out about the Nuke Read Node and ProRes files. I was not aware of if, but I wonder now what happens if I read in an Alexa LogC ProRes file? I was never thinking about the primaries in the decoder settings.

The match that I got in Nuke (visible in my screen recording) was: EXR–>OCIOColorspace ACEScg–>ST2084 and then a second node reversing that afterwards.

But I can actually write out in OSX-Nuke 12.2v1 the EXR image sequence as as ProRes ST-2084 and read it into nuke again and it is actually automatically tagged as ST-2084 and there is no difference between the files (apart from the compression of course and some rounding errors)

I will try the matrix that you provided though.

Best regards


I’m not talking about the primaries, but the R’G’B’ to Y’CbCr matrix (ProRes files are always Y’CbCr internally). ALEXA LogC ProRes files still use the Rec.709 matrix, so it isn’t an issue.

Check a ProRes file with ffprobe and you will see three attributes – primaries, Y’CbCr matrix and transfer function.

It predates Rec2020, but read for more detail.

1 Like

Thank you guys for your interest!

Nick, what couses this shift? Is it Resolve problem, rec 2100 or Aces?
I am more of an artist than a color sientist…
l’ve never used dctl before. Should I use your code in text file with .dctl extention and apply it with the ofx pluggin?
I need to apply shift compensation on raw graded footage before exporting it to Y’Cb Cr file.
How should a matrix look like in this case?

The code I showed is in fact for a Nuke Matrix node, not DCTL.

It would not be possible to add a compensating DCTL in Resolve in ACES mode, as this would need to happen after the Output Transform, and there is no option to do that. You could potentially do it in DaVinci RGB mode, if you built your own ACES pipeline using the ACES Transform OFX. But that is complicating things significantly.

The best thing is to report the issue to Blackmagic, so if it is a bug they can fix it.

Thank you Nick.

Could anybody of you guys test this export behavior?
Somebody has reported to me, it works as it should…

I certainly see the same behaviour that you do. I’m testing on Resolve 16.2.5 (and previously replicated it on 16.2.3) under MacOS 12.13.6 (High Sierra). Perhaps the behaviour varies between platforms?

Incidentally the Nuke 12.2v1 release appears to have fixed the crashing issue with ST.2084 / Rec.2020 QuickTime Movies for me. But it still only offers the choice of Rec.709 or Rec.601 Y’CbCr matrices, and choosing between them has no effect, which is odd.

1 Like