I know of a few film projects to have successfully used ACES-colorimetry footage in editorial/offline process with AVID Media Composer. I’m not sure timed-text or fades were involved or not, though.
You are correct in auspicing ACES is used for offline editorial, as that would be the perfect world.
However, not using ACES2065-1 encoded proxies during online does not necessarily break ACES ― as I will explain at the end of the post.
Not using ACES2065-1 during offline editorial is due to a couple of operational problems standing in today; if they ever cease to impede tomorrow, then rushes encoded in ACES2065-1 will be a reality on 100% of ACES projects:
- If, as it’s often the case, you have to transcode your rushes because, for one or several reasons, the online editorial process cannot directly work on camera-native files (so there’d be “time” for a simultaneous conversion to ACES colorimetry), current editing software may not likely support a standardized, yet practically workable file format that also encodes ACES2065-1 codevalues. In fact, the de-facto standard codecs for online, ―DNxHD/R and ProRes― currently do not.
- Even if you can “afford” online editing straight from camera-native footage, there are currently no cameras whose Raw format encodes ACES2065-1 codevalues. In that case you need an additional transcoding phase to switch to ACES colorimetry, which may not be ideal for timing/storage costs. For this reason ACES supports by design appliances working on camera-native files without mandatory, spearate step for transcoding to ACES.
However ―and this is the focal point, as anticipated at the begninning― the former situation of the two does not “break” ACES, because:
Separately-transcoded rushes used during online are considered to be “periferic files” in an ACES workflow; therefore their colorimetry may be correctly in an output-referred color-space. Specifically, it must be the color-space(s) used in the reference monitor(s) of online editor(s).
Even in the above color-pipeline, the correctness of the ACES workflow stands in as long as the transcoding of rushes to their output-referred color space always goes throughout a complete ACES pipeline, that is Input Transform (IDT), then an optional LMT, then Output Transform (RRT+ODT). Product Partners’ software allow the creation of such ACES-compliant rushes, usually in a completely transparent UX. This is the way color-critical information (like CDLs and show LUTs) can be passed to editorial in a consistent way with all other departments.
The rushes are “periferic” also because they are meant to be a visual reference/proxy to the original footage; no additional color-critical operations, not even any mastering, should come out of them. Ideally, rushes may even be erased after approving the final cut.
By the way, all the ACES film / TV productions that I supervised employed the above color-pipeline for the online. Paradigmatically for an SDR workflow, this means rushes transcoded ―with an ACES-compliant software and in one passage― into a proxy format (typically DNxHR or ProRes wrapped in MXF), color-encoded in Rec.709 or Rec.2020 ― cameras’ Input Transforms, then the show-LUT and/or on-set CDLs, then the Rec.709 Output Transform.
Needless to say that, were the editor to decide for additional color-grading on the rushes, those metadata carried over in the project’s “bin” or via additional CDLs would break the pipeline. This should really be avoided, both because of such a grade being applied in a (possibly SDR) output-referred color-space (Rec.709, Rec.2020, HDR10, …) rather than on top of an ACES color-space and, above all, because color-correction does not belong to the editorial department.
If, however, color-correction/pre-grading during offline is either desired or required, ACES workflow does not “impede” that. In this case rushes need to be in ACES2065-1 codevalues (as common everytime ACES content is stored, even temporarily). Color-grading will then take place, transparently to the editors, in either ACEScc or ACEScct color-space.
All in all, the common mistakes for on-location and offline departments, for any ACES projects, are:
- pre-viewing / checking camera footage using non-ACES conversion software to on-set / near-set monitors;
- transcoding the rushes using a color-pipeline that bypasses ACES completely (even using a Product Partner software, but not configuring it to internally pipe by ACES Input/Output Transforms, is wrong).
Any of the above will most likely end up with DI/post/VFX departments viewing something different than what was presented to DoP/editorial.