ACES 2.0 candidates tests in SDR and HDR


I am finally close to finish my tests with the three ODT candidates.
First of all one question. Is is okay that I get different results from Nuke and Resolve in HDR?
My test pipeline has many steps, I might made a mistake somewhere on the way.

Here is a brief explanation of the test image:
I created a very simple scene in Blender while the standard sRGB (EOTF) view transform.
In this way I can make sure that I can view a proper image without any special view transform, DRTs, ODT, etc.
More details and all the image results in SDR and HDR can be found on my website.
(3.5. One Scene – many images – Brylka – TooDee – PanicPost)

The Blender scene contains three spheres colored in red, green and blue with a very diffuse material (principled shader set to 0.8), a chrome ball, a bit of an environment and the scene is only lit by a HDRI that I created myself.

My expectation for all the different display rendering transforms is that the three spheres must keep their colours regardless which pipeline I use, especially because I should have a hard time to create out of gamut color values (I hope).

I did a whole series of tests including Blender standard sRGB, Blender Filmic, AgX, OpenDRT, Truelight (OCIO), ACES 1.2 and candidates A-C (Nuke OCIO) in SDR and another round of test in HDR.
The SDR images seem to look all plausible for me. Please check the website link above.

For HDR, I chose to render out the still images as ProRes 4444 files with Nuke. I always apply the ODT in the script and write out as “data”.
These ProRes files I load into FCPX (they are not properly tagged and look flat) and I set an color override to Rec.2020 PQ. Here I am not 100% sure if there could happen some mistakes. I also uses the FCPX color correction to level the exposure of the 18% patch at 10 nits. This makes it easier to compare the images in the clip.

Just to compare I rendered out the same image image file from Resolve 18 with the three ODT candidates. By default the ProRes files are also not properly tagged so FCPX “sees” them flat.

I found out that there is a difference between the Nuke and Resolve renders. Can this happen due to the baked LUTs that are used at the moment and the different implementations in Nuke over OCIO and Resolve via DCTL?

Maybe @nick or @alexfry have an idea?