Tags: #Modo nuke #ACES_1_0_3 (keyword field won’t take these)
Hi, hopefully someone here has a better idea than I got. After I finally got my head around the sRGB issues I had, I wanted to get my entire pipeline ACES based.
Now I’m stuck at Modo. What I got so far.
- Manually added ACES 1.0.3 luts and config.ocio to Modo’s file bundle, replacing their incomplete and outdated one (Modo 902 s3).
- Setup
- 8-Bit: Output - sRGB (my legacy 8-Bit assets have gamma baked in)
- 16-Bit: Output - sRGB (same)
- Float : ACES - ACEScg
- View: Utility - Rec.709 - Display
- Files saved as ACEScg
And that’s where the problems begin. If I set the viewer to Output - sRGB as it should be, it’s coming out way too dark and saturated (gamma on top of gamma?).
In order for the Modo preview renderer (and final render) to look right, so I can still use the standard materials I can’t set it to sRGB. In its default non ACES setting, the viewer is set to what’s called sRGB. In ACES the closest I can get to the original it is Utility - Rec.709 - Display.
So in Nuke I have to do a weird dance to get it to look exactly like in Modo.
- Set the viewer to ACES RAW
- Read node set to ACEScg
- Followed by: OCIOColorSpace node set to: ACEScg to Utility - Rec.709 - Display
The only upside of this, it looks exactly like in Modo and I get the same exact look across all three/four apps (Modo, Nuke, Affinity).
What I’m looking for is a setup where I can just use it and have no extra colour transformations just so the Modo image fits. Normally the ODT should be Output - sRGB.
By starting with a RAW viewer, I’ll have to pollute the node graph with an extra transform for every other asset I bring in, slowing down the render as a result. That usually indicates an error.
Someone got an idea?