Background
ACES 2 was “locked” and released to developers in its current form in September. Vendors were then asked to implement the transforms as their product development pipeline allowed - but basically “as soon as possible”. The ACES 2 code jumped from an “architecture” phase directly into an “implementation” phase, without any time for optimizations once design of the algorithm had been locked. There were “beta” release candidates which would have been the ideal time to identify optimizations, but most vendors (understandably) would not even look at the code unless it was no longer a “release candidiate”.
Thus, the developer release labeled as “2.0” was intended to be “final” (or as final as possible). It was still expected that vendors might identify potential optimizations in their work to translate from the reference CTL into coding languages used in their products. And now, the process of adapting the reference code into implementations has identified that simplifications would be desirable for speed reasons. In particular, OCIO and a few other implementers have expressed concerns about the increased compute budget it demands as compared to ACES 1.
In an ideal world we would not need to make changes, but OCIO is a product very important to ACES’s success. The OCIO team has voiced concerns about ACES 2 being (anywhere from 3x to 8x) slower when compared to ACES 1. It is important to note that ACES 2 can be applied to high-res images and played back at normal frame rates in real-time, but the increased percentage hogging of resources compared to ACES 1 is unfavorable.
OCIO 2.4.0 contained a “preview release” of ACES 2.0, and was considered a work-in-progress since it was anticipated that the processing results might change somewhat as a result of optimizations. OCIO 2.4.1 was intended to include the final ACES implementation but not enough progress had been made on suggested optimizations by the Output Transform Working Group before the time 2.4.1 was scheduled to ship. Therefore, a new OCIO 2.4.2 release has now been made the target to support adding a shader-based update to the ACES implementation, but hopefully after some optimizations have been made to make it as performant as possible.
Any changes being explored by this group are not expected to visually change results. The default “look” determined by the architecture group is set. Unfortunately though, changes will change the pixel output enough from the 2.0 code that objective differences will show from the reference test images produced by the 2.0 version of the code. If and when changes are made to the reference code, we only want to do that one time and in a way that is clear and agreed to by all implementers who may have already invested time and resources into an implementation based on the 2.0 code.
It is important to note that at this point no changes have been identified as “worth making”. However, there are a few proposals on the table that a small group of us will be evaluating to see if they might offer performance improvements.
The group will need to identify test image(s) and a metric to quantify any improvements. These can later be repurposed to help implementors objectively quantify how close they are to the reference.
The key individuals driving this work might not be privy to how far along you may be on your implementations, but do we are aware of a few companies that have already released preview versions of their apps with 2.0 support, which is an effort we want to respect. We need buy-in that compatibility is important, but so is an implementation that is as light weight as possible.
Group Goals
- Optimizations - Identify then enact and test possible optimizations to the 2.0 core algorithm
- Rollout - If any optimizations from above are determined to offer a substantial improvement, consider how to best roll these changes into the reference code in a manner agreeable to ACES stakeholders
- Tests - Establish objective tests and metric with thresholds to help implementers independently verify their implementation
Timeline
- Any changes to the code must be identified and enacted by February 2025, as March is the extended deadline to meet the VFX Reference Platform.
- Time is short, and the upcoming holidays are an impediment. Work in the New Year must be swift and results oriented.
- To further complicate things, @sdyer will be on medical leave after January 17, with his availability unknown after that date.
Some key points already idenitified
- Optimizations do not necessarily need to achieve a “match” to ACES 1’s speed in order to be successful. Any decrease in frame processing time toward the level of ACES 1 would be considered an improvement. Faster is better.
- Rather than everyone developing different optimizations independently, it seems wise to coordinate efforts and then have one party implement the obvious optimizations.
- OCIO is pretty much the reference used in VFX, and it would be more important for implementations to match OCIO than the CTL. Therefore, it makes sense for OCIO to heavily support this effort, with any changes to be rolled back into the reference code in a future update.
Process Details
Meeting notes, general notes and progress will be posted here on ACESCentral after each meeting so that those that could not attend can stay updated with the ongoing work. Conversation between meetings can occur here on ACESCentral. More ephemeral chat might occur in other places, such as the OCIO Slack, but I will do my best to pull any key points made in other places to to be posted here for the record.
If you are interested in joining the Slack discussion, I am sure Carol or Doug can facilitate that.
EDIT: Updated incorrect information about what was included in OCIO 2.4.0 and 2.4.1.
EDIT 2: Removed dates for future meetings.