Photoshop now includes the option to enable OpenColorIO and utilize ACES workflows. The end goal in this test is to take a raw DNG image and export it as an EXR from Photoshop to be used in an an ACES workflow inside of Nuke.
Below I’m going to test the workflow to take a Raw image file(.DNG from the Sigma fp) and convert it to .exr exported with the Utility Raw transform in ACES, and read it into Nuke. I shot these files in DNG format with AdobeRGB as the encoded colorspace for viewing in Adobe Camera Raw.
This will allow us to treat a standard camera Raw file as an .exr in Nuke alongside cg renders. The goal is to ensure consistent display in Photoshop, Adobe Camera Raw, and Nuke and apply consistent color transforms with cg renders. To do this we need to setup Photoshop to utilize OpenColorIO.
Opening a Raw and exporting to EXR
When opening an incoming .dng image, Adobe Camera Raw will launch. The default for the profile and working color space is generally Adobe Color, which is already applying a color transform. We need to switch this to Adaptive Color, which is designed to handle incoming HDR images and Raw data. This will ensure that there’s no color transform applied to the Raw file before we export to a Raw EXR file, where the EXR is a new container for our Raw data that’s able to be opened in Nue.
Here I set working space to AdobeRGB(16 bit) with the Profile as Adaptive Color, which will avoid applying profiles to the raw image.
Opening from Adobe Camera Raw may prompt you for an input color space, shown below. Note that the working colorspace should be set to Raw. We haven’t converted our image to ACES yet. We should also set the incoming color profile to the color profile used by our camera when the Raw image was recorded. In this case, I set my camera to encode the image in AdobeRGB colorspace.
To correctly utilize ACES we also need to make sure our working bit depth is correct. We should set to a minimum of 16 bit, or 32 bit. 16 bit is adequate and is the standard for ACES workflows, however to expose OpenEXR export in Photoshop we need to be in 32 bit working space. Go to Image > Mode and set to 32 bit.
Go to File > Save a Copy and select OpenEXR as the output. For now I’m opting to not use any compression to eliminate any variables in the image export.
Working in Nuke
In Nuke, hit S to go to Project Settings. We need to match the ACES transforms available in Photoshop, based on ACES 1.3 currently at the time of this post.
Go to Color and set Color Management to OCIO and OCIO Config to fn-nukestudio-config-v1.0.0aces-v1.3ocio-v2.1. Working space should be scene_linear(ACEScg) with Raw(sRGB - Display) as the default monitor out.
Reading the .exr into Nuke, we need to set the Input Transform to Utility(Raw) on our Read node. This will match our view transform in Photoshop, where we’re manipulating Raw data but viewing it on an sRGB output device.
Comparing the EXR in Nuke with Raw(sRGB Display) transform applied. This matches what we see in Photoshop. The EXR is only acting as a container for the Raw data, not applying any transform.
To write this file back out into ACES space we need to set the Output Transform on our Write node to compositing_linear(ACEScg). I’m choosing to output as ACEScg in order to standardize the colorspace with our output from cg renderers like VRay and Unreal. The goal is to be able to grade raw footage or stills in tandem with our cg renders. If I write out the EXR in ACEScg space and read it back in, and change the Viewer transform to ACES 1.0 SDR Video like in VRay, this is the result:
Here I’m reading in my ACEScg EXR. Input Transform is set to scene_linear(ACEScg), with the Viewer transform set to ACES 1.0 SDR Video. The image doesn’t look ‘broken’ but is washed out, and doesn’t match the view that we saw previously in Photoshop.
The image doesn’t look ‘broken’ but is unexpectedly washed out. Ideally the end result would be in ACEScg, and when applying the ACES SDR viewing LUT it should look fairly similar to our preview image in Adobe Camera Raw.
Setting the Viewer transform in Nuke to Raw(sRGB - Display) appears to fix this, where it looks more correct. Changing the Viewer transform to Raw(sRGB - Display) results in the Raw file looking much closer to sRGB preview of the Raw file in Adobe Camera Raw. But the ACES files appears to have shifted colors - more saturated orange values in particular. Things are mostly right, but my CG renders now appear to be broken - as though they’ve been gamma corrected, shown below.
Setting to Raw(sRGB - Display) makes the images look roughly correct, but the CG is broken.
My workflow here is as follows, from left to right in ACES 1.3:
Read in the Raw image, with data(Raw) as the Input Transform. This was an EXR written from Photoshop after Opening in Adobe Camera Raw
Use an OCIOColorSpace node to go from Raw to ACES 2065-1(ACES Interchange)
Use an OCIOColorSpace node to go from ACES2065-1 to scene_linear(ACEScg)
Use an OCIODisplay node with the incoming Read and outgoing Write set to Raw to not apply further transforms, and applying an ACES 1.0 SDR View Transform
If I change the Viewer transform to ACES SDR 1.0 Video, the result is fairly washed out, but looks correct for my incoming CG render test image from VRay below. This matches what’s happening in the VRay framebuffer, where the rendering is done in ACEScg and a tonemapping transform is applied so that we can view the ACEScg color values on our sRGB display. In the image below the CG renders are correct, in that they match the output in my VRay framebuffer. When writing out the image to an sRGB jpg, I can bake in the tonemapping using Color Picking(sRGB) on the Write node in Nuke and the output matches and will look correct regardless of where it’s viewed. So the final .jpg matches the .exr from VRay and the image I saw in the framebuffer.
Meanwhile, my ACES images are looking washed out. What did I do wrong?
Back to ACES 1.2/OCIOv1
Comparing to the old style ACES 1.2 / OCIO v1 workflow below, where you just set the Input color space to scene_linear(ACEScg) and the Viewer in Nuke to sRGB(ACES). The ACES images match the sRGB view of the Raw file in Adobe Camera Raw. The Raw file on the left looks washed out.
Here the ACES images are in sync, but the Raw is washed out, as though an inversion is happening when we view it through the ACES 1.0 SDR Video viewing transform.
In this comparison, the Raw image is washed out when viewing with the sRGB(ACES) viewing transform in ACES 1.2/OCIOv1, while the other images look correct, including my CG renders which match my VRay framebuffer.
Viewing the Raw with Raw(ACES), it appears to match the ACES images viewed with the sRGB(ACES) transform viewing lut. So there’s an inversion happening here we need to account for.
In the above image, I’m viewing Raw image with a Raw view transform in ACES, meaning no view transform is applied, and it looks correct. But my ACES images are now broken without the tonemapping, as though they’ve had a gamma of 0.454 applied, which is typically done when going from Linear to sRGB. I think what’s effectively happening is the Raw view transform is applying this gamma correction so that the Raw looks consistent on our sRGB display.
I’m using a similar workflow inside of ACES 1.2, the only change being I’m swapping the color profiles as needed to fit the old definitions in the Read and Write nodes.
Read in the Raw image, with data(Raw) as the Input Transform. This was an EXR written from Photoshop after Opening in Adobe Camera Raw
Use an OCIOColorSpace node to go from Raw to ACES 2065-1(ACES Interchange)
Use an OCIOColorSpace node to go from ACES2065-1 to scene_linear(ACEScg)
Use an OCIODisplay node with the incoming Read and outgoing Write set to Raw to not apply further transforms, and applying an ACES 1.0 SDR View Transform designed for sRGB Display
What did I do wrong? How can we fix this for ACES 1.3/OCIOv2?
The problem in all cases is related: there’s a transform applied incorrectly, and the image is basically inverted. The expectation is that I can apply the same ACES 1.0 SDR Video transform to my converted Raw to ACEScg photos, and to my VRay cg renders, and everything will look more in sync.
Lets go back to the ACES 1.3 / OCIO v2 setup. In theory we should use the following settings in the OCIODisplay node:
Now when I compare and view my ACEScg VRay render and my Raw to ACES converted image, they look correct. Compare the original washed out image on the left below, vs the output on the right with the correct OCIODisplay transform applied to view on an sRGB monitor:
Slap comping the CG render over the original DNG now in ACES, viewing with an ACES SDR transform things look as I would expect. The ACES plate is now very close to what I would see when viewing the Raw in Adobe Camera Raw.
Baking in the tonemapping is correct, but it’s affecting our final output due to incorrect values.
Normally at this point, I would write out a .jpg or .png with color_picking(sRGB - Texture) applied to view the image on any device. However, this appears to break my incoming ACES backplate I converted from my Raw/DNG. The highlights are clipped and red values are totally ruined.
Exporting DNG from Resolve to ACES
A workaround is to rely on Davinci Resolve, which supports DNG and CinemaDNG natively along with other Raw formats, as well as OpenColorIO. I loaded the DNG still image from the Sigma fp and wrote out a 16 bit exr with ACEScg transform applied. Using this method I was able to read the image into Nuke with an ACES 1.0 SDR transform lut applied to display the image on an sRGB monitor, much like my ACEScg renders from VRay.
I was also able to bring the image into Photoshop using Open as Open Color IO and set the incoming working space to ACEScg. Viewing the image in Photoshop, the end result matches the image seen in the Viewer in Nuke with the view transform applied.
Comparing the EXR loaded in Photoshop with Open as OpenColorIO vs Nuke. In Nuke I’m reading in the image as ACEScg with the ACES SDR Video transform LUT applied.
The settings I used with Open as OpenColorIO in Photoshop.
Once I write out an EXR from Resolve in ACEScg and use the ACES 1.0 SDR Video transform, it essentially matches the output we see when opening a .DNG or other Raw file in Adobe Camera Raw. Note though that the Monitor transform in Resolve appears to be incorrect below.
In the next part I want to follow up on how we can do this directly in Photoshop, by opening a Raw file as an OpenColorIO object and working with it to export an ACEScg EXR which can then be used in Nuke and Maya interchangeably as a background plate. There are also some changes under the hood in ACES 1.3 and OpenColorIO v2.1 that affect how we apply a viewing transform.