ACES reached version 1.0 in December 2014

The image

There is no single frame here; the record is a document and a dated software release. On 20 December 2014, the version tag v1.0 was pushed to the source repository now at aces-aswf/aces-core, the codebase for the Academy Color Encoding System, originally published by the Academy of Motion Picture Arts and Sciences as aces-dev and now maintained under the Academy Software Foundation. Alongside it sits the current ACES documentation, describing the system as retrieved on 16 September 2026, not as it stood in 2014.

What the documents show

The documentation states plainly what ACES is for: an industry standard for managing color and digital files through a production's lifecycle. It lists a defined scope — camera matching, communication of image files between vendors, consistent viewing, multiple outputs, and an archival master meant to remain usable for future remastering. Nothing in the documentation claims ACES enforces a particular contrast curve, saturation level or overall look; it describes a coordinate system and a set of transforms, not an aesthetic. The dated release record establishes only that a version numbered 1.0 existed as a tagged, distributable codebase from December 2014 onward. It does not narrate the committee process behind that release, and no cited document here supplies studio adoption figures for that year.

Production context

This is an editorial read, extending past what either source states directly. A production that adopts ACES is choosing a common numerical space so that a camera department, a visual-effects vendor and a colorist in different applications can exchange image data without each step silently clipping or shifting color. The problem the documentation names — inconsistent communication of image files in multi-vendor workflows — is a pipeline problem, not a creative one. Solving it does not by itself produce any particular grade; it only removes one source of unwanted variation before the creative grading decisions are made.

Reference versus imitation

Because ACES is described here as a transport and interchange system rather than a style, citing an 'ACES workflow' as evidence for how a finished image looks would overstate the documentation. The record establishes a documented technical scope: a set of color encodings, transforms and file formats. Naming a production's use of ACES is worth doing when describing a pipeline, much as naming a camera or a stock is, but it does not describe the graded image itself.

• Is a cited ACES pipeline claim about interchange, or is it being used to explain a visual look that the documents do not describe?
• Does the source distinguish the aces-dev and aces-core codebase's release history from the Academy's broader Science and Technology Council programs?
• Has the reference material been retrieved at a date close to when it is cited, given that ACES documentation is revised on an ongoing basis?

The dated tag and the current documentation together support a narrow claim: a numbered, distributable version of a color-management system existed from December 2014, built to solve an interchange problem across a production pipeline. Anything beyond that, about how a particular film was made to look, belongs to other, more specific records.