As I am working mostly in ACES, so I tried out this example in ACES as well and I got strange results.
But first, I started out in Affinity Photo 16-bit sRGB. I can replicate the result from the blog as expected.
The moment I convert the document to 32-bit float (sRGB linear), the problems go away.
But by assigning the ICC profile ACEScg to the document, so changing the working space to ACEScg, and having a red star with RGB 1/0/0 and the cyan background with RGB 0/1/1 with the view transform sRGB, this happens:
I am using the official OCIO/ACES 1.2 config.
Note: I am aware that Affinity Photo has a bug, where it cannot save an image properly with an ODT selected. I normally use it only with EXR files.
I am sure that I can “trust” Nuke more, so next, I moved over to Nuke 12.2v4 non-commercial with ACES 1.1.
I replicated the steps with only Nuke nodes and compared the Nuke-Default pipeline vs. the Nuke-OCIO pipeline side by side. For this I set the view transform to ACES (RAW), so that I can apply the view transform by myself with nodes. The tree looks like this:
And the results look like this: (left side Nuke-Default vs. right side ACES(sRGB)
I can fix the problem by using sRGB-linear primaries and convert these to ACEScg, hence lowering the values. The tree looks now the following:( I just added two OCIO color transforms from Lin_sRGB to ACEScg after each constant node)
Left is again Nuke-Default vs. right Nuke-ACES 1.1
I must say the first part of the tests in Affinity Photo I can kind of understand. Kind of.
But the Nuke tests show something different I think.
I guess it has to do with the ODT, but don’t really get why.
At last, I tried two more things. Replicate this test in Resolve. The result looks even more ugly with maximum ACEScg RGB values, because the blur of the image is applied in ACEScct instead of ACEScg. I checked this again in Nuke. This is now the left image of the side by side. And for the right side I forced the ACEScg comp first to linear-sRGB values (which doesn’t make any sense of course, because I start with values over 1 and some negative ones) and then simulated the Nuke-Default pipeline. Now I get on the right side again the same result as up with Affinity Photo in ACEScg (which doesnnot seems to work properly?)
I am confused.
I found out, the moment I choose a ODT with a bigger gamut, like P3 or Rec.2020, the problems seems to get “smaller”.
And I know that I am using a usually “display-referred” motion graphics example in a scene referred Nuke environment, which is not happen often I assume. But I guess in a rare case some of this problem could occur in a 3D rendering as well. I am using extreme values for sure, but they are “normal” ACEScg values.
I hope this is easy to follow. I can upload the files if needed.