The likely most used ACES ODT, ODT.Academy.Rec709_100nits_dim.a1.0.3, has not a Rec.709 0.45-based OETF, but an Inverse BT.1886, 1/2.4, OETF - that is good.
(Ideally, I believe, should the ODT-naming indicate the “BT.1886 fixed g2.4” calibrated target device).
I happened to try the “aces_1.2 OCIO Config” in the “OCIO plug-in for Adobe After Effects” and sadly believe that “Output - Rec.709” and “Output - Rec.709 (D60 sim.)” are, in an ACES compatibility context, wrong - i.e., wrongly using the Rec.709 0.45-based OETF.
(A Nuke artist friend confirmed the issue, when testing the same Config. It causes viewing/rendering-issues between DaVinci Resolve and Nuke/AE and baked-in issues in the DNxHR LB encoded VFX-results back to the Avid Media Composers).
Am I right that the specific AE plug-in above cannot access any newer/modern ACES 1.3-based OCIO Config including the Reference Gamut Compression?
If I am right, could AMPAS please standardise an additional ODT, i.e., a completely equal copy of the Academy.Rec709_100nits_dim.a1.0.3 code, but giving it a new unique name (see proposal above) with a new unique ACEStransformID?
After that, could then OCIO simply add (not replace) the new correct unique ODT to the existing “aces_1.2 OCIO Config” without hurting that Config’s backwards compatibility regarding archived VFX projects?
I have not tested specifically, but since the ACES OCIO configs are generated using the CTL in the aces-dev repo, it seems unlikely that it does not use the correct 2.4 gamma curve.
The Fnordware OCIO plugin for After Effect has been updated to OCIOv2, so can certainly read v2 configs. But I have not yet tested any configs which include the ACES 1.3 RGC.
OCIO in Nuke can read v2 configs, but not, I believe, v2.1. So it cannot support the RGC.
I just did a very quick test, and I get a perfect match between the ACES Rec.709 output of Nuke, Resolve and After Effects using either the standard ACES 1.2 config, or my own OCIOv2 config.
It’s probably also worth noting that my v2 config (like the Reference Config it is based on) explicitly uses the name “BT.1886”.
You are right that the three grey-scale test-patterns in the draft document “TB_2018_002_v0.2” works, hence indicating correct 1/2.4 behaviour, but when measuring the Magenta pattern, the green component is confusingly off?
I.e. Wrongly 0,12 via the ACES 1.2 config, but close to the correct 0,15 in Resolve - please, why?
That’s an example of where OCIOv1’s LUT implementation shows its limitations.
OCIOv2 (with a v2 config) uses the actual maths of the transforms, as does Resolve. So those will match.
Okay Nick, thanks.
Very last question, please: Is the general recommendation that an Adobe After Effects user should use OCIOv2 (with a v2 config)? If so, via which weblink can one find that appropriate Config?
What you use is dependent on what is supported by the various apps in your pipeline. You can’t move on to the “latest and greatest” if you can’t use that same config everywhere (or at least if you do you need to be aware and find workarounds for unsupported apps).
You can get the latest reference and cg v2 configs here, but as always with OCIO, those are intended as start points for you to customise a config to your own requirements. OCIOv2 is backwards compatible with v1 configs if you prefer to use those.
VFX Platform 2022 lists OCIOv2.1, whereas 2021 only lists v2.0, which does not yet include the RGC. I am not fully up to speed with this, but I believe applications stay on the same version of VFX Platform during each major release cycle. So some apps are unlikely to get OCIOv2.1 until their next major release.
FWIW, If you are interested in playing with it, I have an OCIO v2.0 config with a LUT implementation of the RGC. In the config the RGC is applied in the view transforms using 3D LUTs. This is accomplished with a 1D shaper function (courtesy of @matthias.scharfenber) that transforms both negative and positive input value ranges into the 0.0→1.0 domain, essentially the ACEScct function mirrored at the Y-axis.