This was posted by Ray Feeney as a response to the original post on 3D-PRO. Re-posting here for convenience.
Thomas, Kevin, Sean (and the rest of the contributors),
First, I just want to express my sincere thanks for this paper. The amount of work, the clarity, and the usefulness of what you have created cannot be overstated. And I personally don’t disagree with anything raised as issues – they exist, they are real, and they need to be addressed.
And yes, ACES is an open source project so input (and participation) is actively encouraged. Hopefully your team (and others on this list) will take the time to go to community.acescentral.com and participate in a discussion around these topics. The paper is now posted in the discussion section under a new category titled: Feedback and Requests.
It’s pinned to the top of that category with instructions on how to join the conversation and launch discussion threads or topics.
It was just posted so there aren’t any conversations yet underway, so I think I will say a couple of things here to try and spur some thinking and inspire some participation on community.acescentral.com. And, of course, if anyone wishes to discuss anything offline, feel free to reach out to me.
As Thomas mentioned, the ACES leadership is changing. The Academy has some very good rules about term limits on committees and projects. Fresh voices are always encouraged. As ACES ramped up to a V1 official release, these term limits were waived in the interest of continuity. Now that conversations about post V1 steps are being discussed (including a ramp up to a V2 that can hopefully address the known issues), new project chairs will be selected. One has already been publicly announced – Annie Chang of Marvel/Disney.
So please take the below comments as my personal opinion – I am no longer speaking officially for ACES or for the Academy. But, obviously, I care a great deal about the next steps and I hope that I can inspire some of you to actively participate going forward.
The paper covers a lot of specifics, but here I think I will simplistically divide things into three primary categories – The processes of project participation and transparency, the gamut mapping issues of IDT input mapping and related artifacts around bright emissive sources (like colored lights, LEDs, or signs), and the general rendering transforms (in particular, the RRT). All three should inspire vigorous conversations on acescentral (and perhaps additional key topics in the paper will surface also).
When the ACES project started, there was no support for many of the underlying concepts in any of the typical commercial tools. Which meant that in order for anyone to actually see any ACES images in a properly vetted and controlled manner, people needed to come to the imaging lab at the Academy or presentations in the Dunn theater. Over fifty companies supported the efforts of their employees to participate in ACES development and to attend the monthly meetings in Hollywood. Companies like (for
example) Kodak, Fuji, and ARRI sent representatives thousands of miles each month to participate, but the natural fallout was a preponderance of local participation. Meaningful high speed internet remote participation was not an option a decade ago. The world is now a different place and I think this paper is an existence proof that important, useful, and influential ACES work can now take place anywhere on the globe. ACES development is primarily driven by volunteers who are facilitated with some amount of administrative and engineering help from the Academy. Rightly so, the paper calls for a reevaluation of how the broader community can participate in ACES development in a more traditional open source style model. How best to accomplish this transition is certainly worthy of conversation with the ideal goal of more directly empowering interested credible participants around the world. So please go to acescentral and discuss.
Second, the implications of an IDT type workflow seem to be completely validated by the industry. The concept of bringing all elements into a common working space seems to no longer be the least bit controversial.
Even systems that do not subscribe to the balance of the ACES components have adopted the idea of using an Input Device Transform into a common workspace of some form. Although many imaging devices and techniques work well for the vast amount of naturally occurring reflective colors, our world is everyday becoming more populated with active screens, brightly and highly saturated near monochromatic lights, and incredibly wide gamut signage. New techniques for gamut reduction into some form of working space (without the typical edge case artifacts) will need to be pioneered and evolved (with or without ACES). It is very valid work that needs to happen and it seems to be appropriate for a focused open source development effort. All ideas are welcome. Once again, please go to acescentral and discuss.
That brings us to the issues of the current rendering transforms. The vast majority of that discussion belongs on acescentral, but I will say a couple of things here. When ACES development started, the de facto workflow was 10 bit DPX log based. I know that it may come as a shock to many of you in the VFX part of the industry, but there was a great deal of resistance to a 16bit half float linear workflow as an underlying mechanism to bridge the silos of tasks in motion picture creation and post production. Granted that in the DI process, native camera data is still usually placed on the timeline and transformed on the fly through an IDT into a common working space, but in general, the world is no longer afraid of the linear light workflow concepts embodied in an OpenEXR workflow (even if parts of the industry are still resistant to storing the data in the OpenEXR container itself). ACES is responsible for socializing the vast majority of that change in thinking.
Prior to ACES V1, there was a great deal of discussion in the ACES working groups about what would be a “bridge too far” for ACES version one. There are two famous slides in the early ACES presentations that were created by Josh Pines. The first was “How you work today” and it had all the DPX terminology and transform boxes laid out in a diagram. The second was “How you work in ACES” and it was identical except that the boxes had different legends that corresponded to ACES terminology. There were three components in ACES that did not appear on that slide because there were no corresponding boxes. They were: Look Modification Transforms (LMT’s), the Common Lut Format (CLF) and ACESClip (the metadata container to specify the transform chain). All the other parts of ACES overlay on existing mechanisms so the effort for developers to add support for these overlay ACES components was deemed manageable. In fact, most ACES implementations support only those overlay functions and have missing (or incomplete) support for LMT’s, the CLF, or ACESClip. As a working group, we agonized over the RRT. As this paper points out, a serious discussion of the benefits of separating the basic rendering from the parts that might be characterized as “look components” (and breaking the RRT into a LMT and a simplified rendering that would be more easily dealt with for alternate looks), is a hugely appropriate conversation. Rightly or wrongly, there was a sizable contingent of the working group who felt that shipping a system that required valid LMT support in order to function at all, would have been a mistake. So we have the RRT as it stands in V1 – which allows for fairly simple modifications to tools and pipelines to support ACES and for many people it has been a success. Everything brought up in the paper about the RRT is correct and valid – but it is hard to break the RRT down into a LMT and a rendering if there is no support for LMT’s in the commercial tools.
We used to ask the community to ask vendors “When are you going to have ACES support in your tools?” Now we are asking the community to query vendors “When are you going to have meaningful support for LMT’s, CLF, and ACESClip in your tools”.
There is an interesting thing that has happened, though. Because we only had the option for one box in ACES V1 for the components that were rolled up into the RRT, there have been a significant number of high-end industry projects that have used all the ACES components but have used a custom rendering – their own “alternate RRT” that better addressed certain specific project requirements. So, in my mind, it is appropriate to separate the discussion of the architecture of the ACES system from the specifics of the actual rendering transforms. As is pointed out in the paper, a fairly large number of projects have used the ACES system components very successfully – but with a substitute rendering tailored for either a particular look or a style of working. I would claim that this level of use pretty dramatically demonstrates the robustness of the system architecture. I am sure that people are aware of the significant number of shows that have been supported by Bill Feightner at Colorfront or Josh Pines at Technicolor using ACES components along with some very interesting and robust rendering transforms.
Something like seven or eight of the top 10 grossing movies of the last couple of years have used ACES system components coupled with either a custom rendering or the RRT.
The paper calls for the splitting of the RRT into two parts (a LMT for the look modifiers and a simpler RRT). This implies a need for LMT support, the Common Lut Format to express the LMT transform, and ACESClip to carry the information as to what transforms have been cascaded together to form the actual total system rendering. There are a significant number of ACES development participants who agree with that recommendation. It isn’t accidental that these three necessary components are contemplated – and that they exist as draft proposals. It seems to me that it would be extremely valuable to have a conversation (on acescentral) around the questions of “Is this the correct thing to do? Are the draft specifications for the pieces needed to support this correct, sufficient, and implementable? And, will such a refactoring actually make ACES truly what it needs to be to fulfill on its potential?”.
As we contemplate an ACES2.0 (along with a cohesive roadmap for ACES system components), broader industry participation is invited and encouraged. It is open source – come help us flesh out the missing pieces and tune up the elements that need to be improved. As Annie Chang has said: “ACES is a thing now – not just a concept.” ACES is not going away. If there are parts that need work, then help us address those shortcomings.
Please help us understand how best to engage with with the production community to productively move ACES forward. I think this paper is an incredible first step – and one that has been very well received by the ACES leadership team. Again, thank you – I know how much work goes into such an endeavor.
I hope that this post is helpful. There are a lot of people on this list who are interested in ACES and I may pop back in few weeks with a status summary. Feel free to comment here, but please at least cross post your thoughts to acescentral (and hopefully ignite a sustainable conversation on “ACES next steps”).
Thanks,
Ray Feeney
