ACES “working” Spaces

Official Academy documentation on the Encodings and Metrics of all of the ACES working spaces can be found here.

While ACES is commonly associated with color spaces and other specific aspects, it is important to recall that ACES is actually a framework, or a series of guidelines, that promotes an as-much-as vendor-neutral as possible interoperability, by defining common work practices where they are needed the most. ACES specifications span a total of 5 color-space definitions to achieve this framework.

It may seem like the logical method for creating such a uniform framework would be to have one single color space that every input device transforms to and every output device transforms from. The reason why there are 5 spaces is that real-world implementations of a complete color pipeline rely on steps where there are systemic architectural differences like, for example, the capability of internally handling floating-point color code values instead of purely integer maths. These color spaces were designed to be interoperable to maintain ACES’s consistent color appearance while making it easier to perform transformations and operations on the encoded color of images.

The ACES colorimetry (e.g… after any mapping by Input Transforms) is always scene-referred. It only becomes output-referred after mapping by an Output Transform (actually just after the “RRT part” of it).
For ACES color spaces, whitepoint chromaticity is (x, y) = (0.32168, 0.33767) and two different gamuts are alternatively used: determined by the primaries AP0 or AP1.

Primaries are used to define the extent of colors in an x,y space utilizing metamerism. AP0 was designed to encompass the entire visible spectral locus and AP1 is much more akin to rec. 2020.

This is just a review of the color spaces and common situations where they should be used in an ACES pipeline.

ACES2065-1 

The core ACES colorspace, also be referred to as “Linear ACES”, “SMPTE2065-1” or just “ACES colorspace”. It uses the AP0 set of primaries; it is photometrically linear (i.e. gamma-1.0). It is implemented in a 16-bit floating-point digital mesh. By design, this ACES color space is for short/long-term storage and archival of footage. In theory and most practices, the use of a massive, all-encompassing gamut like AP0 gamut is the reason why ACES2065-1 is the ideal setting for professional imaging. ACES2065-1 is also the only interchange format, which means that any ACES content should be converted to ACES2065-1 before being sent to another facility for example.

ACEScc 

Also known as “Log ACES”, ACEScc uses AP1 wide-gamut set of primaries and a logarithmic transfer characteristics, which means the control representation is more proportional to visual perception —a desire of traditional color-correction operators. This encoding can be internally used for color grading/correction. Many colorists have preferences to use log color spaces for how the controls of color correction boards operate. The parameters of Color Decision Lists (CDLs) implemented in ACES workflows are meaningful when generated and/or interpreted on top of ACEScc code values.

ACEScct

A variant of ACEScc color space, except that it adds a “toe” to make it more akin to traditional “log” curves to generate a distinct “milking” or “fogging” of shadows under lift operations, which is typical of some film looks. This comes from requests to provide colorists with a grading environment more similar to that of traditional legacy log film scan encodings when grading using a working space from the “ACES” family of color spaces.

ACEScg

ACEScg uses AP1 wide-gamut primaries, is photometrically linear (gamma-1.0) and utilizes floating-point arithmetics. This exists to allow artists to visually process any pixel of an ACES-encoded image during compositing, painting and other CG-related processes,. It uses a smaller set of primaries , AP1, because tools used to synthetically render imagery (CGI) have long used certain optimizations that are different than in typical color management scenarios and sometimes do not work well with very wide-gamut primaries such as those defined in ACES2065-1.

ACESproxy 

Simply put, ACESproxy is ACEScc encoded with integer code values in the AP1 gamut. It is another encoding related to design constraints by certain video transport systems, like the SDI infrastructure, that are used for either real-time and color-grading operations. Code values employ integer arithmetics (either 10- or 12-bits/channel), but with the same logarithmic transfer characteristics as ACEScc.

ACESproxy has been designed to place scene details into the SMPTE “legal range” of video systems. Scene detail from about 7 stops under mid-gray to 10 stops over mid-gray should be visible within normal legal-range monitor setups. No rescaling of the device output signal should be needed for direct viewing, but is required before applying color grading transforms

*Always remember that ACESproxy is a video-legal signal in order to be correctly displayed by compliant broadcast equipment. ACESproxy is a temporary colorspace, and is just for transports like camera feeds and LUTs on reference monitors for real-time colour evaluation. The parameters of CDLs implemented in ACES workflows may be generated on top of ACESproxy code values, to be later (re-)interpreted on top of ACEScc.

This knowledge base article was created by Simon Yahn largely with the help of Walter Arrighetti and Scott Dyer’s previous forum posts on ACES spaces and the Academy Documentation linked at the beginning of the article.