ACES in Nuke: the FAQ

ACES (Academy Color Encoding System) is a free colour management system from the Academy of Motion Picture Arts and Sciences. It defines a few standard colour spaces, a standard way to convert every camera into them (Input Transforms) and a standard way to show them on every screen (Output Transforms). The point is that a plate from an ARRI, a Sony, an iPhone and a CG render all end up in the same linear colour space, can be mixed without guessing, and look the same on every monitor in every company working on the film.

For a compositor it means three things: the Read converts every file into the working space (ACEScg), you comp in linear, and the Viewer shows the image through the Output Transform, which adds a film-like tone curve.

ACES 2.0 (released in 2025) keeps the same colour spaces (ACEScg, ACES2065-1, ACEScct): your EXRs don't change. What changes is the Output Transform, the way the image is shown on screen:

• A new tone curve, a little softer: in my measures 18% grey goes to 0.349 on an sRGB screen (0.356 with 1.3), scene value 1.0 goes to 0.707 (0.812 with 1.3).
• A new gamut mapping, built on a colour appearance model: very saturated colours go towards white smoothly and keep their hue. In 1.3 a bright blue turned cyan or purple and a bright red turned orange (see the lights in question 20).
• Better inversion: you can go from the screen back to the scene more reliably, useful for logos and graphics.
• The same transforms for SDR and HDR, designed together, so an HDR and an SDR version look like the same film.

In practice: the same comp looks a little different in 2.0. Don't switch version in the middle of a show.

ACEScg and ACEScct are the same colours, only the curve is different: converting between them doesn't change hue or saturation.

• IDT, Input Device Transform, now called Input Transform: from a camera or a file into ACES. In Nuke it's the colour space of the Read (ARRI LogC4, Apple Log, sRGB Encoded Rec.709...).
• RRT (Reference Rendering Transform) and ODT (Output Device Transform): in ACES 1 the image went through both to reach the screen. Together they're now called the Output Transform: in Nuke, the view of the Viewer, for example "ACES 2.0 - SDR 100 nits (Rec.709)".
• LMT, Look Modification Transform: a creative look applied before the Output Transform, the same for the whole show. You meet it as a "show LUT" or a look in the config.

No. OpenColorIO (OCIO) is the software that does the colour conversions in Nuke, Maya, Houdini, Blender, Resolve and many other programs. A config (an .ocio file) lists the colour spaces, displays and views a project uses. ACES is one possible set of colour spaces and transforms; an OCIO config can contain ACES, or something else entirely (the old nuke-default, a studio's own system).

When people say "we work in ACES" they usually mean: an OCIO config with the ACES colour spaces, ACEScg as working space, and an ACES Output Transform in the Viewer.

In Project Settings > Color, set the colour management to OCIO and choose a config. Nuke 17.0 ships these:

The rule: use the config of the show. If you're on your own and you start now, the studio config with ACES 2.0 is the most complete choice. Whatever you choose, it's saved in the script, so check it when you open somebody else's.

A role is a job name that points to a colour space: "the linear working space", "the log space", "the space for 8-bit textures". Nuke and other programs ask for the role, and the config decides which space it is. I read them from the three Nuke 17 configs: they are the same in all of them.

Which role each file type uses is set in Project Settings > Color, in the defaults for 8-bit, 16-bit, log and float files.

The studio config v3 has three views for every display:

• ACES 2.0 - SDR 100 nits (Rec.709): the default, and the one to judge your work with. It's the look the client sees.
• Un-tone-mapped: only the gamut and the display curve, no tone curve. Useful to check values, never to judge the look: everything above 1.0 clips hard.
• Raw: no conversion at all, you see the numbers as they are. For data passes, mattes, STMaps, normals.

The ACES 1.3 config has "ACES 1.0 - SDR Video", its "(D60 sim on D65)" variant, Un-tone-mapped and Raw.

The display must match the monitor, the view stays the same. The studio config v3 has: sRGB, Display P3, Display P3 HDR, P3-D65, Rec.1886 Rec.709, Rec.2100-HLG, Rec.2100-PQ and ST2084-P3-D65.

• A normal computer monitor: sRGB.
• A wide-gamut monitor set to P3, like most Mac screens: Display P3.
• A calibrated grading monitor for TV: Rec.1886 Rec.709.
• HDR: Rec.2100-PQ (or ST2084-P3-D65 for cinema HDR), on a real HDR monitor and with Nuke's HDR viewer set up. Choosing an HDR display on an SDR monitor just gives a wrong image.

With the OCIO environment variable: set it to the path of the show's config.ocio on every machine (and on the render farm). Nuke, Maya, Houdini and the others all read it, and Nuke uses it instead of its built-in configs. In a studio the pipeline does this for you; on your own, you can set it in your system, or choose the custom config in Project Settings.

setx OCIO "D:\shows\myshow\config\config.ocio"

export OCIO="/shows/myshow/config/config.ocio"

Nothing breaks: Nuke 17 still ships aces_1.2, and the script opens with it. The new configs also know the old names as aliases: in the studio v3 config, "Utility - sRGB - Texture" is an alias of "sRGB Encoded Rec.709 (sRGB)", so old Reads find their colour space.

Move a show to a new config only if the whole show moves: ACES 2.0 shows the same EXRs a little differently, so comps done in 1.2 and 2.0 won't match in the Viewer.

When you don't know, ask whoever made the file. A wrong guess is invisible in a grey render and obvious in a red car.

Because of the defaults. I created Reads in Nuke 17.0v1 with the ACES 2.0 configs, and these are the colour spaces they pick by themselves:

An 8-bit sRGB image read as ACEScct comes out too dark in the shadows and far too bright in the highlights. Set the Read by hand, or change the default for 8-bit files in Project Settings > Color to texture_paint (sRGB).

• Comps, precomps, renders for other artists: EXR in ACEScg, 16-bit half. That's the default of a Write in an ACES config (scene_linear). Use 32-bit float only for data that needs it (depth, positions, STMaps).
• Delivery to the DI: what the show asks. Often EXR in ACES2065-1, sometimes in the camera's log as DPX or EXR. The specs are in the delivery document: read them.
• Previews and dailies (QuickTime, JPG): with the Output Transform applied, so they look like your Viewer. In the Write set transform type to display, then the display (sRGB or Rec.1886) and the view (ACES 2.0 - SDR 100 nits).
• Data (mattes, STMaps): Raw.

There are two ways, and they give different results:

• sRGB Encoded Rec.709 (sRGB) (once called Utility - sRGB - Texture): the image becomes linear light with its sRGB colours. White 1.0 stays 1.0 in the scene, and in the Viewer it looks a bit darker and less saturated, because the Output Transform's tone curve shows 1.0 as 0.707. Right for textures, photos, anything that must behave like a real object in the light.
• The inverse of the Output Transform (the display colour space, e.g. sRGB - Display with the ACES view, inverted): the image comes back on screen exactly as it was. But to do it the values grow a lot: in my measures display white 1.0 needs scene value 128 with ACES 2.0 (16.3 with ACES 1.3). Right for logos and graphics that must look exact, and only if nothing (blur, glow, motion blur) touches them in the comp.

All the details, with the values and images: my page 8-bit images in ACES.

Because the colour spaces have different primaries, and a colour that exists in one may be outside the other. Pure red in ACEScg, (1, 0, 0), converted to linear Rec.709 gives (1.705, −0.130, −0.024) in my measures: it's a red more saturated than any Rec.709 screen can show, and the only way to write it in Rec.709 numbers is with negatives.

• They are not an error: don't clamp them in the middle of a comp, or you change the colour.
• Negatives can break some operations (a divide, a log, a keyer, a gamma in a Grade): check those nodes when you see strange black or NaN pixels.
• In the other direction there's no problem: every sRGB colour is inside ACEScg. Red (1, 0, 0) in an sRGB texture becomes (0.613, 0.070, 0.021) in ACEScg.

Inside the VFX company, ACEScg: it's what everyone works in. Between companies and to the DI, the ACES standard says ACES2065-1 (the "aces_interchange" role): it's the archival format, and the files are marked as such. Most shows say it in the specs; when they don't, ask, and write the colour space in the name of the folder or in the metadata.

The same pixel is very different in the two: ACEScg (0.18, 0.05, 0.02) is (0.136, 0.053, 0.019) in ACES2065-1. Read in the wrong space, the colours shift visibly.

Because of the tone curve of the Output Transform. In the old linear sRGB setup, a value of 1.0 in the scene was white on screen. With ACES, the scene can go much higher than 1.0, and the Output Transform needs room to show it: so scene 1.0 is shown at 0.707 with ACES 2.0 (0.812 with 1.3), and only very high values reach white. 18% grey is shown at 0.349 instead of 0.461. Move the line on the image:

Un-tone-mappedACES 2.0 SDR

A frame of Climax, one of my personal projects, pushed two stops brighter (×4) in ACEScg and rendered from Nuke 17 with the two views of the studio config. Un-tone-mapped clips everything above 1.0; the ACES curve rolls the highlights off.

The lab in section 02 shows the whole curve.

Same reason: 1.0 in the scene is a bright diffuse white, not the brightest thing the screen can show. With ACES 2.0 on an sRGB screen I measured: scene 1.0 → 0.707, 2 → 0.82, 4 → 0.90, 8 → 0.948, 16 → 0.975, 100 → 0.999. Going backwards, display 0.9 needs scene 4.0, display 0.99 needs 34.5, display 1.0 needs 128.

So a white wall at 1.0 looks light grey, and that's correct: the screen keeps its brightest values for lamps, the sun and speculars. If something must be exactly white on screen (a title, a UI), see question 15.

Because of the gamut mapping. I rendered rows of coloured lights (red, blue, green, orange), from exposure 0.5 to 16, through the two Output Transforms. Move the line:

ACES 1.3ACES 2.0

Rendered in Nuke 17 with the studio configs v2.2.0 (ACES 1.3) and v3.0.0 (ACES 2.0). Same EXR values, two Output Transforms.

• ACES 1.3: as the lights get brighter, blue turns cyan, red turns orange, and the colours stay saturated until they clip. A scene red of (4, 0, 0) gave (1.166, 0, 0.111) on an sRGB display: a value above 1, which the screen clips.
• ACES 2.0: the hue holds and the light goes towards white, like a real bright light or film. The same red gave (1.0, 0.371, 0.304).
• For comp it matters with neon, LEDs, fire, lasers, sci-fi glows and sky gradients: a look approved in 1.3 can change in 2.0.

No, in linear they're normal: the sun, a lamp, a specular highlight are much brighter than a white wall. Keep them: blurs, defocus, glows and motion blur look real only if the highlights keep their energy. Clamp only where a node needs it (some keyers, some filters) or on a matte, never on the whole image.

No: comp in ACEScg, linear, where merges, blurs and light behave like light. Go to ACEScct only for a few operations that work better on a log image, and come back right after:

• Grading as a colourist would, with lift, gamma and gain on a log image.
• Some keyers and edge tools, which behave better when the values are spread evenly.
• Sharpening, and filters that ring around very bright highlights.

Use an OCIOColorSpace node from scene_linear to compositing_log and back (or a Log2Lin in the config's log). My page Linear and log explains why.

The Viewer shows the image through the Output Transform; the pixel values in the info bar are the real linear values of the image, before the transform. The colour picker uses the color_picking role (sRGB Encoded Rec.709 in these configs). When you match two images, compare the values, not what you see; when you judge the look, use the Viewer.

Not always, but it helps. If your renders and plates come from different programs and cameras, ACES (or any OCIO config) gives you a single linear space and a good-looking display transform for free. What matters most is consistency: one config for the project, the right colour space on every Read, and the same view for everyone who looks at the work.

Read the EXR as Linear Rec.709 (sRGB). Nuke converts it to ACEScg: the colours are the same, only described with other primaries. Don't read it as ACEScg: the colours become more saturated and shift. Agree with the 3D department on one space for the whole show, and write it in the file names or the metadata.

A show LUT is a look, and it belongs to the Viewer, not to the image: in a studio it's in the config, as a view or a look. On your own, put it in an input process or a Viewer node (a Vectorfield node, in the right colour space), so it changes what you see and not what you render. Ask which colour space the LUT expects: most show LUTs expect log (ACEScct or the camera's log), not linear.

Paste this in the Script Editor: it prints the config of the script, the default view, and the colour space of every Read.

import nuke
root = nuke.root()
print("Colour management:", root["colorManagement"].value())
print("Config:", root["OCIO_config"].value())
print("Viewer:", root["monitorLut"].value())
for r in nuke.allNodes("Read"):
    print(r.name(), "|", r["colorspace"].value(), "|", r["file"].value())