ACES/Color Space Transform to sRGB or whatever...

Working on some stuff and was thinking about linearizing footage or graphics.

I'm working on some Red footage that will ultimately go back out as Red but wanted to add a viewing LUT to make some graphics judgement calls. Lately, the process I've been using goes like this.

Make an OCIO Colorspace. Set it up from incoming footage type to sRGB and throw in at the end of my flow or do the same in a Viewer LUT depending on the circumstances.

Then, if I get some graphics, I'll use an OCIO Colorspace to go from Output - sRGB to "Whatever the Footage Is". Add it to the flow and use any Color Correctors or Solids or whatever and just deal with the color differences between what I get and what it looks like in the inspector. BUT I wanted to see what the linearized process might work like so I set this image up.

Screenshot-2022-11-29-160559.jpg (333.55 KiB) Viewed 541 times

My issue/question is between picture 2 and 3 from left to right. Picture 2 is linearized and then changed to sRGB with OCIO. Picture 3 is linearized with OCIO and sRGB with a Gamut. I would think that the two would result in the same picture but it's not. Any idea what's happening? I thought once it was linearized all the math would be 0.0-1.0 so an sRGB conversion would be the same regardless of a Gamut Node or OCIO.

The Output sRGB view transform from ACES 1.2 has a tonemap built in. Try using OCIO to convert to Utility - Texture - sRGB instead of Display - sRGB, or whatever the name of that transform is. That will probably match what that Gamut node does.

So in fact, the typical ACES transform is incorrect, even though it looks more pleasing. Try roundtripping an sRGB image into and out of linear using that workflow, and you'll see what I mean. If you use the display out, the result won't match the original image.

There's a recently-released ACES update that has a config compatible with OCIO 2.0. It separates the tonemap from the ODT, but I haven't yet experimented with it in Fusion. I'm also not sure where to download it directly; last I checked a couple of weeks ago it wasn't in the OCIO github repository, and the ACES page hadn't yet updated to point to it.

That's what I thought too but tests are showing the opposite.
Here's a comparison between Utility-Texture-sRGB and Gamut. Check out the Waveform.

ACES to Gamut Match 2.jpeg (316.62 KiB) Viewed 491 times

Here's Output-sRGB and Gamut. Waveforms match.

ACES to Gamut Match 1.jpeg (316.21 KiB) Viewed 491 times

As a BONUS "What the Hell?"... Here's a CC node on each with the gain cranked down. Look how it pulls the OCIO Linear vs. Gamut.

ACES to Gamut Match 3.jpeg (308.25 KiB) Viewed 491 times

Within an ACES pipeline you never want to deviate from the viewing standard so in your first comparison setup 3 and 4 are incorrect. You also probably want to work in the ACES linear color space ACEScg instead of Linear sRGB. You should always monitor through the ACES ODT as that is the same everyone else in the pipe will view through. The display transform just like REDs IPP2 mapping or ARRI's rec.709 LUT apply display rendering and tone mapping to the image. Using it as an inverse to convert graphics into scene referred is an option if the desire is to null the display transform for data that should remain the same in appearance when viewed through the ODT. However, the result of this is that display white will map to around 16 in linear. This can also be useful for emissive objects like compositing neon signs or fire but less effective for normal surface colors. This is where Utility sRGB Texture is more suitable. You'll have to choose one of them depending on your needs.
The view LUT should always be Output - sRGB.

When handing of the renders the official way is to export ACES 2065-1 EXR but back to camera log space 12bit integer files could also work.

This ^

For int storage ACEScc/cct in 12bit container is also fine, there is no practical difference from lets say AWG/LogC