In an industry full of obscure acronyms, ACES probably ranks among the most obscure. The Academy Color Encoding System attempts to standardize how color is handled from acquisition through post and delivery.
ACES is not even that difficult to understand.
First of all ACES is a workflow, it’s a means of interpreting and processing image data in post in a scene referred linear color space with input and output transforms that relate to specific non-linear devices.
We’ll first take a look at how ACES handles color information, and why.
So what is a scene referred linear color space?
The essence of a scene referred linear color space is far simpler than you may imagine. It is a direct digital representation of linear luminance levels as they appear in front of a camera lens. Or, worded differently, it is a one to one relationship between real-world brightness and the data that represents it in an image file.
Why don’t we work this way?
Imaging sensors actually see light exactly this way; they have a linear response to light.
One reason we don’t record image data values linearly in camera but employ a curved or log gamma function (aka log, flat, film look) is that we can reduce the required color bit depth and file size by reassigning values to describe finer increments, or steps in luminance at the darker end of the luminance scale than the brighter end.
In other words, when we shoot “log” we are assigning a larger number of smaller “steps” to the shadow and mids, and fewer larger steps to the highlights.
This is a clever way to squeeze a higher total range of brightness (dynamic range) into a limited bit depth in a way that is visually unnoticeable. A non-linear gamma function allows for a more efficient assignment of the values in relation to the perception of human vision.
Log encoding also better suits some grading functions, which may not behave as expected with linear encoded files.
How ACES works
So if our camera files are not encoded as scene referred linear, but ACES works in a scene-referred linear space, then how does ACES handle camera files?
The answer is simple, the 10-bit, or 12-bit log encoded values in the camera files are transformed into scene-referred linear space using an IDT, or Input Device Transform. You can think of this almost as a type of LUT. When stored or rendered to file, these are 16-bit half-float EXR files.
Because every camera is different, each camera requires a specific and dedicated ACES IDT.
Once we are working with our images successfully transformed into the ACES space, we need to make sure we are seeing them correctly. This is where an ODT, or Output Display Transform comes in.
There is no such thing as a perfect, or completely unbiased monitoring device. You can’t monitor scene-referred linear image information. Every monitor display technology has limits and can only display a limited color gamut.
A display device expects to receive input data encoded with a non-linear gamma response according to a standard video color space and needs to be calibrated to either Rec709, DCI-P3.
Just as every camera needs a specific and dedicated IDT, the same is true for display devices and rendered file outputs from ACES into standard delivery color spaces.
Preserving your look
The last piece of the puzzle worth mentioning is a unified and platform independent method of retaining your intended look once graded. This is another transform called a RRT or Reference Render Transform. The RRT will ensure no matter what new output devices and color spaces come out in future, your intended grade will always be preserved.
As HDR and true Rec2020 UHDTV display technology becomes a consumer reality, demand will increase for content with full and rich colors, encoded in a color space with a far wider gamut than anything we are currently used to.
Although it is still early days and ACES does have some technical issues, many believe ACES is the future of digital color.