Hi guys. I often listen to people comparing ACES to just being a colour space.
Well. Apart from the fact that ACES specifications span a total of 5 colour-space definitions, it’s important to stress the fact 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 workpractices where they are needed the most. And that involves colour spaces as well.
The reason why these spaces are 5 is that real-world implementations of a complete colour pipeline rely on steps where there are systemic architectural differences like, for example, the capability of internally handling floating-point colour codevalues instead of purely integer maths.
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 colour spaces, whitepoint chromaticity is (x, y ) = (0.32168, 0.33767) and two different gamut are alternatively used: either AP0 or AP1.
This is just a review of the colour spaces and common situations where they should be used in an ACES pipeline.
-
ACES2065-1 ― (what may 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 floating-point digital mesh, e.g. in 16-bit/channel codevalues).
By design, this is the only ACES colour space which all short-/long-term storage and archival of footage should be encoded as. It’s currently the most colorimetric, yet RGB-model based, colour space existing in the industry.
The use of AP0 gamut, that is wider than Rec.2020, DCI P3 and many “wide-gamut” colour-spaces is, in practice, the reason why ACES2065-1 is the ideal setting for professional imaging. Theoretically, this justifies the AP0 triangle gamut enclosing the whole CIE1976 chromaticity diagram: to represent every colour stimuli percievable by the standard observer, thus future-proofing any images that were and will be archived using it. -
ACEScc ― (which is sometimes referred to with wordings such as “Log ACES” or “ACESlog”). It uses AP1 wide-gamut set of primaries and a logarithmic transfer characteristics, which means the codevalues representation is proportional to how visual perception —and thus traditional colour-correction operators— behave. This encoding can be internally used for color grading/correction (sometimes even transparently to the user).
The parameters of Color Decision Lists (CDLs) implemented in ACES workflows
are meaningful when generated and/or interpreted on top of ACEScc codevalues. -
ACEScct ― It is a variant of ACEScc color space (AP1 gamut), just with a higher toe in its logarithmic transfer characteristic to generate a distinct “mikling” 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 alike traditional DI theatre’s.
Extra care is required for using CDLs on top of ACEScct codevalues (which is not compatible with ACESproxy arithmetics ― read below). -
ACEScg ― It uses AP1 wide-gamut primaries, is photometrically linear (gamma-1.0) and 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, but without losing any information to colours that may not be representable for different reasons (including out-of-gamut’s). For example, codvalues <0.0 and >1.0 are expected to represent colours outside the AP1 gamut (yet within AP0’s).
-
ACESproxy ― Simply put, ACESproxy is ACEScc encoded with integer codevalues (rather than with ‘floats’, AP1 gamut). It is another encoding related to design constrains by certain video transport systems, like the SDI infrastructure, that are used for either real-time and color-grading operations. Codevalues employ integer arithmetics (either 10- or 12-bits/channel), but with the same logarithmic transfer characteristics as ACEScc ― but not that of ACEScct.
Always remember that ACESproxy is a video-legal signal (while ACEScc is not) in order to be correctly dislayed (and not deemed “illegal”) by compliant broadcast equipment.
No storage of ACES footage is intended with this encoding — that is just for transports like (as one example) camera feeds on reference monitors, LUT boxes, and other on-set equipment for real-time colour evaluation.
The parameters of Color Decision Lists (CDLs) implemented in ACES workflows
may be generated on top of ACESproxy codevalues, to be later (re-)interpreted on top of ACEScc.