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?
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: https://my.hidrive.com/lnk/yADURoOv
Might be a bug in Resolve? I am using the latest version 16.2.5 Studio
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:
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.
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’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.
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.
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.
