This morning I was asked a couple of questions about switching a CG pipeline to ACES. and how difficult it was. Let see how to approach it.
First thing, why ACES? It seems to bring that nice “filmic” look that is so difficult to obtain while playing with rendering parameters. But it also comes with a lot of other things! It’s a bit like buying a luxury car just to have comfortable seating…
Setting up the driver’s seat
First thing first, you suffer back pain when driving your car. Maybe the seat is not good, maybe it’s not well set, maybe your position is not good. You may have tried different things for a while, but you may lack some of the knowledge to address the problem: ergonomics. For color management, it’s pretty much the same: you have a lot of check boxes in your software parameters, but taking a random approach won’t do much good, you need to understand a bit of color theory. Fortunately these days you have a lot of open knowledge available on the web, like the amazing Colour Science website, or ACES Central. Unfortunately it’s full of maths and physics, and except for a very few that are willing to dig into the theory, for most of the artists in a small post house or CG shop it feels like going back to Mr Sleezer’s infinite boredom classroom. It’s a bit like asking all the passengers in the car to graduate as ergotherapists, you will probably loose some people in the process.
Then you have the tutorials on Youtube and video classrooms. Lot of knowledge, lot of misinformation too, often examples that are difficult to translate (or copy and paste) into your pipeline, but the good thing is often after a little effort, you have the minimum to start, so let’s start.
Step-by-step approach
Let’s ask again, why ACES? ACES brings a lot of things, but maybe you don’t want to have them all at the same time. For example, that “nice filmic look” is just proper tone mapping, you can do that without ACES. What ACES brings that is important, but may be important to you later (or never):
- interoperability between softwares: all softwares should show the same picture
- interoperability between facilities: when sending files to another facility, they should see (if properly implmented) the same result
- No signal clipping
- same camera signal interpretation: when getting rushes, if processed through the correct IDT you should get the same image. Also pre-grading parameters done with ASC-CDL should process the image the same way
- Easy remapping for different deliverables
- A full set of color management tools to go to/from ACES
And much more… So the main thing is interoperability between software, and ultimately people. To get those people onboard, there must be a strong incentive, so first thing is to detect what problem ACES could fix into your pipeline. Usually problems come from misunderstandings, so semantically this is human interoperability, and we just saw that interoperability is what ACES is good at.
For example you can start by keeping your internal “secret sauce” color space and convert your exports to ACES so when you send files to another facility they see exactly the same thing. By implementing this you will learn a lot about your sauce, and may feel it’s time to have some work on it. Then you can test the different software packages in your pipeline on side projects to see how they react, and get the users to give their feelings about the reaction of the tools. That will help build knowledge about color and the words to describe it. Not all software design teams have great color scientists onboard, and you don’t want to force on artists a terrible user experience just for some geeky tech dogma. You may be able to fix some of the problems by yourself with some configuration or script, or you may help the developers bringing a better product to the market.
With HDR and all the excitement around it we have a lot of opportunities to rethink our color management and all the magic about colors… once you get there you never turn back to the darkness of color ignorance 🙂
Cedric
Thank you Maxime Caron for the inspiration for this article!
Originally published on Linkedin, April 2020