OCIO/ACES Color Management with Multilayer EXR

[HiFy]

The use of MultilayerEXR with OCIO/ACES Colormanagement is not working correctly. The Layer-Extraction with the EXtractoR is currently applied after the Input Transform to the ACEScg-Workingspace. The result looks slightly wrong compared to the same Image as Singlelayer EXR. If I disable colormanagement for the EXR-File and apply the Effects (OCIO and EXtractoR) manualy everything works correct. Would be cool if no manual Colormanagement would be needed. With Singlelayer EXRs there is no problem. 

After Effects Beta 23.2.0 Build 34

Windows 10

[Seb.James]

I use this set up, it seems to work most of the time for multi-layer V-Ray EXR files:

Project Settings Working Space set to sRGB or Rec.709 depending on your output. Linearize Working Space On. 32 Bit.

In your comp have your layers set up like so:

Any graphics sit at the top.

Adjustment Layer: Color Profile Converter effect. Input and Output set to sRGB. Tick on the Linearize Output Profile.

Adjustment Layer: OpenColorOI effect: Input Space: ACEScg. Output Space :sRGB.
Adjustment Layer(s): all of your colour correction effects sit here adjusting the layers in ACEScg colour.

Stack your Lighting, Reflection, Specular, Self Illumination etc, EXR passes here.

Please feel free to correct me though if the set up isn't totally correct, but it seems to work for me when I work with V-Ray passes and normal graphics from clients.

It looks like ACES colour is being fixed in the new beta versions of AE, lets just hope they've made it super simple to use as it is currently a right headache to get your head around it at first.

[HiFy]

Yes, that's the correct "old" way of using ACES in the release Version of AE. I'm talking about the integrated OCIO-color-management in the Beta Version. There you can enable OCIO/ACES in the Project Settings and it does all the conversions on import and export. You don't need all the Adjustment Layers with OCIO and Color Profile Converter to get rid of the double Gamma. In theory, AE manages this. In practice, the EXtractoR needs to happen before any color space transformation. To do this you have to set up the color management manually very similar to what you described. But that adds the complexity back that the Beta Version wants to get rid of with the new system.

[pat pro]

Do you render with Maya?  Try to use the OCIO config file from Maya in AE. 

[chrisbrearley]

I can confirm this is still a problem in 23.4 

Changing the input color space for a multilayerd exr has no effect on the image. Looks like extractor is reading the data before any transform is applied. Another minus in the incredibly flawed AE EXR workflow. Needs fix asap.

[Seb.James]

The process definitely needs fixing! It would really help if you could use a similar workflow for after effects and Photoshop too... I recently tried to work with aces renders in Photoshop but gave up, it was far too fiddly and the results weren't anywhere near matching what I saw in the Vray Viewport after I'd gone through the official guide on how to do it.

[Shebbe]

The issue is a bit more nuanced. Traditionally EXRs (from CG) were kind of assumed to be sRGB/Linear. You would work on them in sRGB/Linear and finish with a simple lin to 2.2 conversion.

Now we can run into the situation where we work in ACEScg with multi-pass renders in sRGB/Linear.

EXtractoR takes the data directly from the source file and thus bypasses it's conversion. In practice it doesn't matter whether it does it or not. Some passes in CG are actually intended to not be altered like UV/Position/Normal etc. If your EXR color space doesn't match your working space you want to convert your diffuse and other non data map but not the rest. You'd have to convert some data regardless of the order of operations.

Workaround:

The best way to go about it is to convert all your non data passes to ACEScg after the EXtractoR effect and leave all data passes as is. There is no need to revert back to manual color management.

Another alternative is to work in sRGB/Linear instead as the working space, if your pipeline/project/deliverable allow it.

Possible solution?:

I don't think there is a logical way to go about this.

In something like Nuke that is node based you could 'explode' your passes into separate Read nodes and assign the input space accordingly. Something similar in AE would be the ability to import multipass EXR into layers similar to a .psd file. Is that something we'd want though? Having only 1 file in the project bin definetly feels more clean.

Curious what you think.