Hello,
I did some testing based on all of this and it may be helpful-
I built an OCIO config based on the rev060 LUTs that Nick shared, and confirmed that it matched the Blinkscript implementation (as a note, in my config I’m using the BT.1886 rec.709 rev060 LUT but converting from BT.1886 to sRGB for my display) .
Using my rev060 config and Nuke, I tried to recreate Christophe’s results-
First, I worked as explicitly as possible where I knew for certain what colorspace the image was in at every step-
In my config, the scene_linear role is ACEScg, matching a “regular” ACES config.
I read in the image as AP0 (thus transforming from AP0 to AP1), then matching Christophe’s desire to perform this operation in linear sRGB, I converted from ACEScg to linear sRGB. I created a primary blue image with a constant, but since my Nuke working space is ACEScg, I converted from ACEScg to Linear sRGB, and multiplied that
linear sRGB blue primary (EDIT: Mistake here, this is the ACEScg primary in linear sRGB) with the linear sRGB image. I then converted back to ACEScg for the DRT, which resulted in this image, which does not have the artifacts that Christophe experienced-
I then did the exact same thing, except instead of multiplying by the linear sRGB blue primary, I multiplied by the ACEScg primary blue instead by bypassing the colorspace transform:
Which resulted in this image, which does have the artifacts Chris mentioned-
As I mentioned, I first wanted to do this test when my Nuke working space was set to ACEScg, because I have not experimented with changing the Nuke working space away from the scene_linear role, so I wanted to first perform testing in an environment when I knew exactly what was going on.
My final test was to actually change the Nuke working space in the settings, though:
And then read in the image with the AP0 transform, multiply the image by 0,0,1, and then view the image under the DRT where the Display Transform is expecting a linear sRGB input rather than the scene_linear role ACEScg input.
This workflow resulted in an image matching the artifacts as well-
In both cases, multiplying by the “working space primary” with values of 0 in the red and green channel resulted in the artifacting, which frankly is not something I am surprised by. I’m a CG artist and have read Christophe’s CG cinematography book (Thank you for that resource Christophe, by the way), which is where I originally learned about avoiding pure primary values with zeroed out channels in lighting, which resulted in artifacts with ACES 1.3 and other color management workflows that this instance reminds me of.
In the first test that I did that did not result in these artifacts, I believe that I followed Christophe’s desired workflow (bringing the image into linear sRGB, multiplying by the linear sRGB blue primary, and viewing with the ACES 2 rev060 DRT), but I did it within the context of the ACEScg working space which prevented any 0 values in the multiplication.
Another factor that may be important here is just that – the working space in Nuke. My standard workflow with OCIO configs is to define my working space with the scene_linear role, and when you load a config into Nuke that is the colorspace chosen as the working space by default, and when you create OCIO nodes in Nuke the colorspace that role is set to is the default for many of the options. I am unsure that it is a good idea to change the working space away from this role in the project settings – firstly because defaults in nodes will not match your newly set working space, and secondly because I’m not sure how much of Nuke actually adapts to that working space change – for example, when using the Nuke viewport View Transform (in the top left of the view panel), if you are looking through only a single read node with a properly set IDT, the visual result in the viewport will change, which suggests to me that either the IDT transformation from encoded → working space or the view transform from working space → display is not properly reflecting the user change in the project settings. This introduces unknowns into the equation in multiple ways – since I’m not able to explicitly know what Nuke operations are properly reflecting this change, I would rather not change my working space there.
Hopefully some of this is helpful–
Conlen
, so that we can try the DRT ourselves.
