ACES Color Management Explained: Keeping Color Consistent from Workstation to Render Farm

Introduction

If you searched for "ACES color" or "Academy Color Encoding System", the short answer is this: ACES is a free, open framework that gives every image in a production, whether it came from a camera, a 3D renderer or a compositing package, one shared reference for what its colors mean. The Academy of Motion Picture Arts and Sciences developed and maintained it for more than a decade, and in August 2025 it moved to the Academy Software Foundation (ASWF) under an open technical steering committee (Academy press release, read 13 October 2026).

This guide explains ACES in plain language without getting it wrong: the main color spaces, input and output transforms, what changed in ACES 2.0, and how OpenColorIO (OCIO) delivers it inside your 3D software. Then it covers the part most explainers skip: what happens to color when a scene leaves your workstation and renders on other machines, with a checklist to run before you submit a job. For what rendering itself is, see our rendering fundamentals guide.

What ACES Is, and the Problem It Solves

The Academy describes ACES as an open source framework for color management and image interchange across the whole motion picture production life cycle. It has three kinds of parts: encodings (the color spaces), transforms (the math that moves an image into ACES and from ACES onto a display), and specifications such as the ACES Metadata File (AMF) and Transform IDs. ACES2065-1 is standardized as SMPTE ST 2065-1:2021, and the ACES documentation notes that dozens of companies have built ACES components into their tools (ACES documentation, read 13 October 2026).

The problem is simple. Every device has its own idea of what a pixel value means: a camera records in a manufacturer's encoding, a texture arrives in sRGB, a renderer calculates in its working space, and every monitor has a slightly different gamut. Without a shared reference, the same numbers mean different colors in different places. ACES acts as a contract: each source is converted once, through a known transform, into a common reference; work happens there; a known transform maps the result to each display. It is not a filter that makes renders look better. Its value is consistency, which is exactly what is at stake when a scene moves between machines.

The Core Color Spaces: ACES2065-1, ACEScg and ACEScct

Sources: the ACES2065-1, ACEScg and ACEScct pages, read 13 October 2026.

• ACEScg is linear and scene-referred. Its values directly encode relative exposure. Negative values are valid and should ideally be kept, and values well above 1.0 are expected and should not be clamped except during deliberate color correction.
• ACEScg exists because of CG math. The documentation explains that CGI calculations often treat RGB as reflectance, which behaves poorly with the very wide AP0 primaries. ACEScg uses the smaller AP1 primaries (red 0.713, 0.293; green 0.165, 0.830; blue 0.128, 0.044) and the same white point (CIE xy 0.32168, 0.33767). Converting between the two is a fixed matrix.
• ACEScct is not a rendering space. The documentation calls it transient and internal to software or hardware. A renderer works in ACEScg; a grading tool may switch to ACEScct.

The practical rule: render and composite in ACEScg, and treat ACES2065-1 as the interchange form when a facility asks for it.

Input and Output Transforms: The Two Ends of the Pipe

Between the outside world and your ACEScg working space sit two kinds of transform.

• Input transforms convert a source into the working space. A texture needs one that matches how it was saved, usually sRGB for color images. In 3D software this is the input color space field on each image node.
• Output transforms take scene-linear ACES data and prepare it for a display, applying tone mapping and gamut mapping on the way (About rendering, read 13 October 2026). In 3D software this is the view transform or display setting in the viewport and render window.

The point that matters most for farm rendering: the view transform is for looking at the image. The image itself should stay scene-linear.

ACES pipeline: textures and camera footage pass through input transforms into ACEScg for rendering, linear EXR is stored, and an output transform maps the image to the display

What Changed in ACES 2.0

The project changelog dates ACES 2.0 to 4 April 2025 (aces-core CHANGELOG, read 13 October 2026). The ACES documentation puts a redesigned suite of rendering transforms at the center of the release (About ACES 2, read 13 October 2026):

• New Output Transforms with a less aggressive tone scale, reduced mid-tone contrast and a gentler highlight rolloff than ACES 1.x.
• More robust gamut mapping, with fewer clipping artifacts.
• More intuitive parameters for unusual displays, display presets, and optimized inverse transforms.

What does this change for CG? The pages we read locate the change at the display end of the pipe, and we found no statement that the ACEScg encoding itself changed. In practice, the same scene-linear EXR can look different on screen depending on whether it is viewed through an ACES 1.x or an ACES 2.0 output transform. If your workstation previews with one and a farm node with the other, you are comparing two looks of the same data.

A note on version labels. OpenColorIO's documentation now lists built-in configs labeled aces-v2.1 for OCIO 2.6 and newer, and OCIO 2.6.0 was published on 1 October 2026 (OCIO Studio config and OCIO releases, read 13 October 2026). The ACES sources we read do not list a 2.1 entry, so we treat 2.0 as the last release we could verify from the primary ACES source. Read the version string in your own config's name instead of assuming.

How OpenColorIO Delivers ACES Inside Your Software

ACES defines the color math; OpenColorIO is how your application uses it. OCIO is an Academy Software Foundation project, described as a complete color management solution geared towards motion picture production (OpenColorIO documentation, read 13 October 2026). A configuration file defines the available color spaces, the roles an application relies on (such as the rendering space), and the displays and views. Most applications let you pick it in preferences, and an OCIO environment variable specifies the file path of the config to use (Using OCIO, read 13 October 2026).

OCIO also ships built-in configs referenced by name instead of path. The CG config is a lightweight set for typical DCC apps, for example ocio://cg-config-v4.0.0_aces-v2.0_ocio-v2.5. The Studio config carries the complete set of ACES color spaces, displays and views, for example ocio://studio-config-v4.0.0_aces-v2.0_ocio-v2.5. The name reads as config type, config version, ACES version and minimum OCIO version. Because they are built in, no external LUT files are needed (CG config and Studio config pages, read 13 October 2026).

Every application wires this up differently. What the vendors' own documentation says (all pages read 13 October 2026):

Defaults differ by application and by version, and some of the settings that decide your color live outside the scene file, in an environment variable or a path on your own disk. That is where the trouble starts. For the 2026 Cinema 4D cycle, see our feature recap.

Where Color Goes Wrong When a Scene Leaves Your Workstation

On your own machine, color management is held together by things you never see: an environment variable, a preferences file, a config in a folder you set up a year ago. A render node has none of that unless the scene or the farm provides it. On a managed farm you upload a project and receive frames without logging in to the machines, so you cannot quietly set a variable on the node the way you do on your desktop. Four failures are worth checking first.

1. A different or missing OCIO config. The OCIO variable lives in the environment of the machine that sets it, not in the scene file, and Cinema 4D documents store a path to the config. A path to a drive on your workstation only helps if the machine that opens the scene can read the same file. When it cannot, the application may report unknown color spaces or fall back to another config, and the result no longer matches what you approved. Configs carrying different ACES versions cause a quieter version of the same problem.

2. Texture input color spaces tagged wrong. Color textures such as JPEG and PNG should be read as sRGB, linear HDR images as scene-linear, and data maps (normals, roughness, masks) as raw or non-color. Autodesk's Arnold for Maya page recommends exactly this split, and Redshift's documentation warns that its automatic conversion can get it wrong, so each asset should be checked. A wrong tag does not announce itself: colors look washed out or too dark, or a roughness map quietly changes the material. A farm renders what the scene says, frame after frame.

3. A view transform baked into the output. Maya's documentation says the OCIO view is not applied to rendered image files unless Apply Output Transform to Renderer is turned on. If a display transform is baked into your frames and your compositor applies another, the image is transformed twice: contrast is crushed, highlights clip, and it is hard to undo.

4. Display-referred 8-bit output instead of linear EXR. OpenEXR is designed to represent high-dynamic-range scene-linear image data (OpenEXR, read 13 October 2026). An 8-bit PNG or JPEG holds display-ready values and cannot carry the values above 1.0 that ACEScg expects, so rendering the real job to 8-bit throws away highlight detail and the ability to regrade. Our EXR and Cryptomatte guide covers how multi-layer EXR files are structured.

Four ways color drifts between a workstation and a render farm: config mismatch, wrong input space, baked view transform, and 8-bit output

A Pre-Submit Checklist for Consistent Color

Seven points take a few minutes and cost far less than discovering a mismatch at frame 800.

1. Write down your config. Note whether the scene uses a built-in ocio:// name or a file path, read the ACES version in the name, and note whether an OCIO variable on your workstation supplies it. That variable will not travel with the scene.
2. Set the working space inside the project. Choose the render space explicitly (ACEScg for most CG pipelines) rather than relying on a default. In Cinema 4D, remember a document can be in legacy mode.
3. Check every texture tag. Color images as sRGB, linear HDR as scene-linear, data maps as raw. Spot-check a handful of materials.
4. Keep the view transform for viewing. Confirm no display transform is baked into the output unless your pipeline calls for it.
5. Output scene-linear EXR for the real job. Use 8-bit formats for previews only, and note the EXR's color space for your compositor.
6. Package the project completely. Upload the project folder unpacked, with the scene file and every referenced asset in place. If you use a custom or studio config, tell the farm in advance.
7. Render one frame as a test. Open the workstation render and the farm render in the same viewer with the same view transform, and compare a few pixel values with a color picker as well as by eye. Small differences from sampling or denoising are normal; a visible shift in hue is not.

Pre-submit color checklist in seven steps: config, working space, texture tags, view transform, EXR output, packaged project, test frame

Testing One Frame on a Managed Farm

Super Renders Farm is a fully managed cloud render farm, so you do not log in to the machines, install software on them or manage licenses yourself. That is convenient, and it is also why the checklist matters: everything your workstation gets from its own environment has to be carried by the scene and the files you upload.

There is no published per-config compatibility list for custom OCIO setups. If your pipeline depends on a studio-specific config, contact support before you upload, through the 24/7 live chat or at supportcenter@superrendersfarm.com, and send the config with a one-frame test. One upload rule matters here: the farm does not extract archives (.zip, .rar, .7z, .tar, .tar.gz), so nothing inside an archive gets rendered.

A test frame is a small job. New accounts receive $25 free render credits, and how usage is billed is explained on the pricing page. For Cinema 4D and Redshift scenes, job submission is described on our Cinema 4D cloud render farm page; the Redshift, Maya and Blender pages cover those applications.

FAQ

Q: What does ACES stand for? A: ACES stands for Academy Color Encoding System, an open framework for color management and image interchange created by the Academy of Motion Picture Arts and Sciences and maintained by the Academy Software Foundation since August 2025.

Q: What is the difference between ACES2065-1 and ACEScg? A: Both are linear and share a white point. ACES2065-1 uses the wide AP0 primaries and is the base encoding defined by SMPTE ST 2065-1. ACEScg uses the smaller AP1 primaries and is the working space intended for CG rendering and compositing.

Q: Do I need ACES to use a render farm? A: No. Any consistent color pipeline works, including a plain linear sRGB one. What matters is that the scene, textures and output settings are explicit and identical on every machine that touches the job. ACES is popular because it is a documented, shared standard.

Q: What changed in ACES 2.0? A: The main change is a redesigned set of rendering and output transforms with a gentler tone scale and more robust gamut mapping. The release is dated 4 April 2025 in the project changelog. The documentation we read describes changes at the display end of the pipeline, not a new ACEScg encoding.

Q: Why does my render look different on the farm than on my workstation? A: The usual causes are a different or missing OCIO config, textures tagged with the wrong input color space, a view transform baked into the output, or an 8-bit output format. Check them in that order, then render one test frame and compare it with your workstation render in the same viewer.

Q: Should I render to EXR or to PNG? A: Render the production job to scene-linear EXR and keep the display transform for viewing and final delivery. Use PNG or JPEG for previews, because 8-bit files hold display-ready values and cannot carry values above 1.0.

Q: Does Super Renders Farm support custom OCIO configs? A: There is no published compatibility list for custom configs. If your pipeline uses one, contact support through the 24/7 live chat or by email before you upload, and include a one-frame test to compare against your workstation render.