The ACES Image Container File Layout format is a standardized format (SMPTE ST 2065-4), and it requires ACES2065-1, which is nominally "the" ACES color space for storage and interchange (see https://acescentral.com/t/acescc-vs-acescct/485/6). We chose to implement the standardized format first. This format places specific restrictions on the data (e.g. must be 16-bit EXR) in addition to the color space, and also adds additional metadata so a file can specify that it conforms to the standard. That's why the current option in OctaneRender is simply called "EXR (ACES)" and doesn't give you any choice about color space, bit depth, compression etc.jayroth wrote:This strikes me as odd, considering that ACEScg was designed specifically for computer rendered images, whereas all of the other specs were intended as a translation for live action footage. What drove that decision?karu wrote:The current experimental build contains support for exporting renders in "ACES Image Container File Layout" format, which is an uncompressed 16-bit EXR file in the ACES2065-1 color space with some additional metadata. There is currently no support for any other ACES color spaces such as ACEScg, or ACES textures, or ACES interactive preview. It is likely all of these will be made available as a result of further color management work coming in a future 2020.1 experimental build - watch this space.
It appears that the standardized format isn't actually used as widely as some alternatives such as using the ACEScg color space (if I wasn't very new to ACES myself, I might have known this at the time

My understanding is that ACEScg was designed to be used internally in RGB-based rendering/compositing to produce more reasonable results when multiplying RGB colors together. This is something OctaneRender doesn't do because it is a spectral renderer, but I can see that ACEScg export will be very useful for workflows that do this.