Previously I was in Nuke 15 with ACES 1.2, and Maya 2024.2 which used ACES 1.2 as well. In this setup my standard practice was to render ACEScg, bring exrs into Nuke with the ACES 1.0 SDR Video transform on in the viewer, and write out sRGB png images using Color Picking(sRGB) on the write node. I could then bring these pngs back into Nuke for review, and leave the viewing transform on in the Viewer.
I’ve now migrated to Maya 2026.3.2, VRay 7, and Nuke 17.0v2.
What I’ve observed now is Color Picking now clamps the output, rather than tonemapping the values into the 0-1 range for sRGB.
The only solution I’ve found so far is to set my write node to Transform Type > Display, and display to sRGB_Display, and disable the tonemapping by setting the viewer to Untonemapped. This is basically a 1:1 match for my raw ACES comp(slight saturation difference I think, but the dynamic range and detail is there).
All my 8 bit png images are read in with color_picking(sRGB) applied.
If I write a standard color_picking(sRGB) output it looks correct with the viewer transform on(ACES 2.0 SDR 100nit - sRGB) in terms of the gamma and shadows. But I lose dynamic range and detail in the image whereas previously I didn’t(notably the cheek on the attached image where the highlights are clamped).
If I write a Transform Type > Display, and display to sRGB_Display, and disable the tonemapping by setting the viewer to Untonemapped it matches my comp.
Can I just edit Nuke’s config so that when it reads in a color_picking(sRGB) image it bypasses the viewer tonemapping? That seems to be the behavior that was happening in ACES 1.2, but there’s also something missing in the output.
Or is there another output setting that’s preferable in ACES 2.0 in Nuke? I’m not totally clear.
I tried using the studio_config ocio file in Maya but didn’t really notice any output difference in terms of how it renders. I don’t think there’s any issue with ACEScg exr renders.
I attached 3 output images here. I guess technically color_picking is correct in that it looks like what could be shown on an SDR 8 bit display - you would need HDR to fully represent ACES? But I’m used to a what you see is what you get workflow from ACES 1.2.
Meant to attach this as well. These are my 2 Write node outputs in Nuke. Color Picking causes the clamping issues shown above, where highlights look a bit ‘burnt’. Setting output to display sRGB and disabling viewer tonemapping while setting the output view transform to ACES 2.0 SDR Video appears to match my raw comp view perfectly. The difference is subtle, but I’m concerned I’m making a mistake with color_picking. The clamped highlights leave a lot less room for further grading in editing.
I’m not entirely sure what your intent is with the 8bit png output images. But if they are for final output intent for sRGB displays, that is what you should write out for it.
ACES 1.2 uses the ‘tone mapped’ display out Output - sRGB as color picking role where the ACES 2.0 config uses sRGB Encoded Rec.709 (sRGB)which is only the gamut and gamma without the tone mapping.
I don’t know exactly why this change was made but I’d keep color picking as role separate from your other intents. So for a write node use transform type Display → sRGB - Display because that is what you intend to encode into the file, which is the equivalent of ACES 1.2’s Output-sRGB.
When verifying the written file inside Nuke, the read node color space should also be set to sRGB - Display.
Thanks. My intent is to bring them into an editor and deliver an SDR h264 output. So no real need to write out full exrs, png is fine.
Previously I could bring in a color_picking png with color_picking on the Read and leave on the ACES SDR 1.0 display transform in the Nuke Viewer.
I’m glad Display > sRGB - Display is correct on the output.
I often read in these pngs for reference and final review back into Nuke or to compare comp versions, etc. I’ll try setting the read to sRGB - Display. But you’re saying the Nuke Viewer has to be switched to sRGB - Display from the ACES 1.0 SDR tonemapping? Previously I could just bring in a color_picking image and I think it would bypass the viewer transform.
The structure of OCIOv2 ACES 2.0 config is a little different. ACES 1.2’s OCIO config was based on LUTs and all the color spaces including view transforms into display spaces were defined as such. Because the color_picking role was also assigned to the view transform/display “Output - sRGB” this worked if you read the exported file as that.
ACES 2.0 OCIOv2 uses separate display definitions and color spaces which is much more practical and organized especially when dealing with multiple view transforms (SDR/HDR etc).
What happens when you pick a tone mapped display space as read in, it does an inverse of the SDR sRGB view transform to the working space (ACEScg) then the comp viewer does the forward transform again. So not a bypass but a ‘nullification’ in a sense apart from some inaccuracies. But these inaccuracies are severely diminished with ACES 2.0 compared to ACES 1.2.
Your comp viewer should always be set to what your display is calibrated to so sRGB - Display / ACES 2.0 -SDR 100nits would be correct if using sRGB. I believe Nuke displays the view transform and display in a single list just like AE.
(These examples use ACES 1.3 config which was also upgraded to OCIOv2.x utilizing the displays category.)
But the OCIODisplay and Write nodes neatly separate the two which removes the redundancy making it a much shorter and more readable compact list. The possible view transform option adapt to the display choice.
If for some reason you want to keep using color_picking to read the file, you can change it’s role to sRGB - Display and it should match how you used ACES 1.2 but like I explained I wouldn’t really recommend using it for purposes other than color picking. If you happen to have reason to pick a color in a different space, you would have to change it back to write your exports correctly. Potential user errors there.
