Hello Brian and welcome,
I have been pretty vocal on this forum about ACES and some limitations, for example in this post.
Just like you, back in 2017, I had no clue about colour as you can tell in my first post. And it is partly thanks to this community that I started and still continue this amazing journey through colour. To answer your question shortly, I would say that yes, these complaints have practical validity. Let me give a few examples :
- Image a system that clips shadow values in SDR at 0.002.
- Imagine a full CG character such as a red plumber lit by the sun… And his hat goes “Dorito” orange.
- Imagine a full CG light saber where the colour is an ACEScg primary and the character looks flat.
- Imagine a blue rabbit or sphere that goes purple when lit.
I think it goes back to Vlad’ s point : there is a lack of overall color science knowledge in the CG industry. Learning about colour science has made me a better lighting artist and now that I have seen and experienced first hand the “notorious 6”, I cannot go back to ACES 1.X. I have setup some trainings at the studio, so every artist knows what the “notorious 6” are and how to identify them.
It took me 15 years of experience to learn about “display transforms” and in my quest about colour, I have talked to many Lighting/Compositing/CG/VFX Supervisors and realized that most of them do not have a good understanding of what happens when the “image data” is rendered for a display device. So I agree with Joseph when he says that “color management in motion pictures is still in its infancy”.
I would say that the hue shifts/skews themselves are “not necessarily” the issue (as Alex explained). The issue is that with ACES, you will always get the same ones. So, maybe your different projects have different artistic needs but ACES will prevent you from having different behaviours. Your orange tones will always become “rat piss yellow” with values above 1 for instance.
As Derek and Thomas have explained, part of the issue comes from per-channel. We could add that ARRI K1S1 is a per-channel display transform that has been used massively and with great success. So, in reality, the issue is not per-channel itself but how it is implemented (as explained brilliantly in this post by Jed). You can also have a look at this cool post about per-channel by Alex Tardif.
As always, devil is in the details. I don’ t know what is the scope of your projects, if you display in SDR or HDR and what are your requirements. Many artists who just want an “automatic tone mapper” use ACES because it has been implemented in most DCC softwares (ACES being like the lowest common denominator here) and they got used over the years to the “notorious 6 aesthetics”. But once you have seen differently, there is no going back.
About ACES productions, I would be very careful because it has been said by different people in several meetings that the ACES Output Transforms were inverted most/all of the time. So I will stick to what I know : ACES is mostly used for exchanging files and archival (unless proven otherwise).
Finally, about openness and transparency, I wish the TAC would have let Daniele speak a year ago to present the Meta framework idea. And I also wish the TAC had discussed in their latest meeting the loss of their main contributor. I think that is a big deal. Sure, this community has a voice here on this forum and this is great. But is this voice being heard ? I am not sure.
I hope my criticism is constructive. As Vlad explains, part of the issue is the “ACES evangelist” (I used to be one of them) and as a community, we need to dig deeper and expand the knowledge. So artists can take better decisions and not just follow a trend.