← Guides

Companion guide

Color management in Resolve, actually explained.

The exact settings, with screenshots, taken a step further than the video goes. Plus output tagging: why your renders don’t always look like what you graded.

Start here

What color management actually is

It’s the math that converts your log footage into whatever space you work in, then converts that into your output space. That’s it. Any camera-manufacturer LUT that takes S-Log3 to Rec.709 is doing this: a crude, one-step version of it. The node-level setup below is the same idea, done in two deliberate steps instead of one, so you get a working space to grade in between them.

This guide covers node-level color management: you build the CST yourself, on the clip or the group. Resolve also has a project-level mode that automates this. Node-level is worth learning first because it shows you what project-level is automating for you, and that’s its own guide.

Setup

Project settings: set your working space

Project Settings → Color Management is where you set the working space every input CST in your node trees will target. In this project that’s DaVinci Wide Gamut / DaVinci Intermediate (DWG/DI), set as the Timeline Color Space. You can use others, but whatever you pick here has to match every input CST’s output, or the math downstream is wrong.

Input CST = camera log space → working space. Output CST = working space → delivery space. Also referred to as an IDT (Input Device Transform), and ODT (Output Device Transform).

Project Settings, Color Management panel, DaVinci YRGB with timeline color space set to DaVinci Wide Gamut / DaVinci Intermediate

One setting worth changing while you’re in there: 3D lookup table interpolation sometimes defaults to Trilinear. Set it to Tetrahedral instead: better LUT interpolation, no downside.

Node level

The CST: your camera-in step

Nearly every modern camera has its own log space: S-Log3, LogC3, whatever. The CST (color space transform) maps that into your working space, so footage from different cameras can be graded, shot-matched, and balanced the same way. (You can use “Use Timeline” on the CST’s output to automate matching it to your project’s timeline color space. I have trust issues, so I set it manually.)

Setup: two node stacks at the clip level, not one

Project Settings → General Options → Color → Node Stack Layers, set to 2. Name layer 1 CST, layer 2 Correction. This splits what used to be a single clip node tree into two: the CST stack, and everything after it. The CST goes in the first stack, every shot-level correction goes in the second. Same clip, same node count either way, just organized so the camera-in step and the shot-level grading never end up tangled in the same node tree.

Project Settings, General Options panel, with the Color section's Node Stack Layers set to 2, Layer 1 named CST and Layer 2 named Correction
Project Settings → General Options → Color. Node Stack Layers: 2. Layer 1: CST. Layer 2: Correction.

Apply Active Layer, not Apply Grade

This matters the moment you have two stacks. Apply Grade copies BOTH clip-level stacks, the CST layer and the Correction layer together, and overwrites any work already sitting in both on every clip you apply it to. When you only want to copy one layer, park on that stack and use Apply Active Layer: it copies just the stack you’re on and leaves the other alone.

A color space transform node with input color space set to RED Wide Gamut RGB / RED Log3G10 and output set to DaVinci Wide Gamut / DaVinci Intermediate, tone mapping and gamut mapping both set to None
Input = camera log space. Output = your working space. Tone mapping and gamut mapping off: you're going scene-referred to scene-referred, not to a display space yet.

The CST is a per-camera fact, not a per-shot decision: every clip from the same camera needs the identical transform. Set it on one clip, then apply it to the rest without touching each one by hand: select every clip from that camera (a saved smart filter makes this a one-click selection, see Lightbox below), right-click the one you set up, Apply Active Layer. Or right-click the CST node and set it as a shared node before applying it: every clip sharing that node updates together the moment you change it, no reapplying needed later.

Scene-referred vs. display-referred: why tone mapping is off here

Scene-referred means the pixel values are still proportional to the light that hit the sensor. Log camera footage and DWG/DI are both scene-referred: different encodings of the same scene data, nothing decided yet about how any of it will look on a screen. Highlights can run past anything a display could show, because nothing’s been fit to a display yet.

Display-referred means the values have been mapped to what one specific display can actually reproduce: bounded, with a black point and a white point that fit the target.

This CST goes scene-referred to scene-referred: camera log into DWG/DI. It’s a re-encoding, not a decision, so tone mapping and gamut mapping stay off. Turning them on here would roll off highlights before you’ve even started grading, baking a display decision into a step that’s supposed to be neutral.

Node level

Groups: reserved for the scene, not the camera

A group gives you two extra node trees around the clip: a pre-clip that runs before every shot’s own corrections, and a post-clip that runs after. With the CST already handled by the node stack above, groups are free for one job: the look.

Why scene, not camera

You could still group by camera and put the CST in the pre-clip instead of the node stack, that works fine for a single-camera scene. It breaks down the moment a scene has more than one camera in it, a two-camera interview, an A-cam/B-cam setup, anything where the same look needs to land on footage from two different color spaces. Grouping by scene instead sidesteps that entirely: the CST already ran at the clip level before the group ever sees the image, so every clip in a scene group arrives at the group post-clip already speaking DWG/DI, regardless of which camera shot it.

Group pre-clip

Clip · CST stack

Clip · Correction stack

Group post-clip

Timeline

Usually empty

In a scene group with more than one camera in it, nothing happens here: the CST already ran before the group ever saw the image, so there’s no per-camera work left to do. If you group strictly by camera instead of by scene, this is where that camera’s CST would live instead.

Click a node: this is the actual node tree, left to right, the way it reads in Resolve.

Because every clip lands in the same DWG/DI space before the group ever touches it, the post-clip can treat a red-camera shot and a Sony shot identically. That’s the payoff: one look decision covers a whole scene, mixed cameras included, because by the time the look sees any of them, they’re already speaking the same language.

The payoff

Negative per scene, one print for the whole thing

This is what the group post-clip and the timeline node are actually for, and it borrows straight from how a film lab works: different scenes get shot on different negative stocks depending on what they need, then the whole reel gets printed through one consistent print stock. The negative can vary. The print doesn’t.

In Resolve, the negative is the group post-clip: run EMBR in Digital to Negative, then pick a stock for that scene. Because every clip in the group already arrived in DWG/DI regardless of camera, that one stock choice grades the whole scene at once, and different scenes can carry different negatives without looking like they belong to different projects. The look doesn’t stop at the stock, either: scene-level adjustments, printer lights, an overall balance or contrast move for that scene, live here too, inside EMBR or in extra nodes in the same group post-clip tree.

EMBR Film FX panel with Output Tone set to Digital to Negative (Cineon) and, under the Negative section, Negative Stock set to Kodak Vision3 200T (5213)
Output Tone: Digital to Negative. Negative Stock: the stock for that scene. This is the group post-clip node.

A print LUT isn’t the only way to keep a piece cohesive across scenes, you can grade for consistency scene to scene without ever touching one. What it buys you is a single, mechanical way to lay one consistent DNA over everything downstream of it, e.g. Resolve’s bundled Rec.709 Kodak 2383 (pick a white point, D55, D60, D65), even across scenes that were graded differently at the group level.

The print also does more than add a look: properly prepped, it performs the working-space-to-display transform too, the same job the output CST does. That’s why the typical DWG/DI → Rec709/Cineon CST doesn’t hold up as a terminal step on its own; Resolve’s Film LUTs are not meant for Rec709 primaries, which is why the colors don’t map as cleanly as the Digital to Negative transform built into EMBR’s DCTL and OFX. Use a properly prepped print LUT as your last node and you don’t need a separate output CST after it. The two usually aren’t paired, pick one.

Where it sits changes what it touches. At the timeline level, one print LUT catches everything downstream, including graphics and titles, which isn’t always what you want. Make it a shared node instead and drop it as the last node in each scene group’s post-clip, and it does the same job scoped to just that group’s clips, protecting anything at the timeline level that shouldn’t get the print treatment.

A color space transform node with input color space set to DaVinci Wide Gamut / DaVinci Intermediate and output set to Rec.709 Gamma 2.4, tone mapping method set to DaVinci and gamut mapping set to Saturation Compression
The output CST, at the timeline level. If you're not using a properly prepped print LUT to do this job, this is how you set one up instead: working space to delivery space. Not usually stacked with the print LUT, pick one.

None of this is mandatory. You can finish a look entirely at the scene level and skip film emulation altogether, or do the whole grade at the timeline level with no groups at all. This is one way to work, the way that’s been working, not the only correct shape for the node tree.

Monitoring

An honest viewer

The export matching what you see in Resolve comes down to three things: how you’re viewing the image, whether Resolve’s viewer matches your display, and what the file says about itself on the way out. The first two are this section. The third is output tagging, next.

Where you're viewing, and what applies

A dedicated monitor on a clean feed. A DeckLink or UltraStudio sends the video signal straight to a calibrated monitor, outside macOS and outside ColorSync. Nothing in the steps below touches it. Calibration is the whole job, and it’s the reference the GUI viewer is trying to match.

An external display plugged into the Mac. Still a Mac display: the system and Resolve talk to it through ColorSync, so the display preset, where it offers one, and the Resolve preferences below apply exactly as they do to the built-in panel.

The Mac’s own display. The same two steps, with the HDTV preset available on the 14 and 16-inch MacBook Pro from 2021 on, Studio Display, Studio Display XDR and Pro Display XDR.

Windows. None of these settings exist: the viewer follows your display directly, so a calibrated monitor is the whole job, and the 1-1-1 vs 1-13-1 decision in the next section applies exactly as written.

Mac viewer setup, Resolve 20.2.2 or later

1. Set the display to a video preset. System Settings → Displays → Preset → HDTV Video (BT.709-BT.1886), on the displays that offer it: the 14 and 16-inch MacBook Pro from 2021 on, Studio Display, Studio Display XDR and Pro Display XDR. This locks the panel to Rec.709 primaries and gamma 2.4 in hardware, so Resolve has a correct display to talk to in the first place. True Tone, auto-brightness and the brightness controls can go unavailable while the preset is active. That’s the panel holding steady.

2. Tell Resolve to trust that display. Resolve Preferences → General: Use Mac display color profiles for viewers, on by default since 20.2.2, so confirm it. Viewers match QuickTime player when using Rec.709 Scene, on. Automatically tag Rec.709 Scene clips as Rec.709-A, off. The first routes the viewer through the display profile you just set. The second makes the viewer and QuickTime agree, so the file you export looks in QuickTime the way it looked in the grade. Since 20.2, Rec.709 Scene also hands ColorSync the right metadata directly, and that covers what you see while grading. The third would quietly override the tag you’ll set on the Deliver page.

3. Tell Resolve what the viewer is looking at. Project Settings → Color Management → Output Color Space: Rec.709 (Scene). The second preference in step 2 is built around the output being Rec.709 (Scene), and this is where you set it. In a node-based (DaVinci YRGB) project, which is what this guide builds, it’s a display-only transform for the viewer. The export tag stays on the Deliver page. In a color-managed project, the SDR Rec.709 output preset does the same job.

4. Pick whichever Rec.709 the panel offers. Resolve names the same transform differently in different panels. Rec.709 (Scene) and Rec.709 Gamma 2.4 in the Output Color Space list, and a CST node set to Rec.709 / Rec.709 with Apply Forward OOTF on, all show the viewer the same thing: gamma 2.4. Where they differ is the tag they hand the Deliver page when it’s left on Same as Project: Rec.709 (Scene) writes 1-1-1, Rec.709 Gamma 2.4 writes 1-2-1. In a color-managed project that tag follows the Output Color Space, so Rec.709 (Scene) tags 1-1-1 on its own. In a DaVinci YRGB project it follows the Timeline Color Space, so on this guide’s DWG timeline you set the tag yourself, next section. The one that’s different is Rec.709-A: it carries a compensating shift from when macOS read Rec.709 through a ~1.961 gamma approximation instead of the BT.1886 2.4 curve, and 20.2.2 makes that workaround unnecessary for Mac viewing.

Resolve Preferences, General panel, with Use Mac display color profiles for viewers and Viewers match QuickTime player when using Rec.709 Scene both checked
Preferences → General. Both boxes checked: the monitoring fix, and the QuickTime-matching sub-option.

Delivery

Output tagging

The third thing: what the file says about itself. A tag tells whatever opens it which curve to assume. You set it on the Deliver page.

An NCLC tag isn’t “what space is this file in.” It’s an instruction to whatever decodes the file: assume this transfer curve. Two tags matter for most delivery:

Which tag, and why

1-1-1 is true Rec.709: the full BT.1886 decode, roughly gamma 2.4. Correct by the spec, for broadcast and calibrated reference-monitor delivery.

1-13-1 is Rec.709 primaries with the sRGB transfer curve, roughly gamma 2.2: what a computer monitor usually assumes. This is the one for YouTube and most web delivery.

Most real-world playback doesn’t properly implement the BT.1886 decode 1-1-1 promises. It decodes closer to 2.2 regardless of the tag. Grade and tag true 2.4, and most screens play it back too dark and too contrasty. Pick the tag whose failure mode is safe. If a platform ignores your tag and does a naive decode (common on the consumer web), 1-13-1 barely changes. 1-1-1 crushes.

Tested end to end rather than assumed: a file played locally through QuickTime or Preview on a Mac, and that same file watched on YouTube through a Mac browser or the YouTube app, reads correctly at 1-1-1. The same YouTube upload watched on Windows, iOS, or Android reads correctly only at 1-13-1; 1-1-1 comes out gamma-shifted, too dark and too contrasty there.

Becasue there are so many different potential hardware and software and delivery combinations, its worth testing on your own setup before treating a particular combination as law: render a test file, upload it to the platform you’re delivering to, and check it on the devices you expect your audience to use. If you see a shift, swap the tags. Simple as that.

Deliver page render settings with Color Space Tag set to Rec.709 and Gamma Tag set to Rec.709 (the 1-1-1 configuration)
1-1-1: Color Space Tag Rec.709, Gamma Tag Rec.709
Deliver page render settings with Color Space Tag set to Rec.709 and Gamma Tag set to sRGB (the 1-13-1 configuration)
1-13-1: Color Space Tag Rec.709, Gamma Tag sRGB

To confirm what actually landed on an exported file, check it in Finder: select the file, Get Info, Color profile.

Finder's Get Info panel for an exported QuickTime file, showing Color profile: HD (1-1-1)
The tag as Finder reads it back. This file is 1-1-1.

Keep this to the tag, not the pixels. Grade and monitor at true Rec.709 gamma 2.4, calibrated, same as always, and render at that same 2.4. The only thing that changes for a 1-13-1 delivery is the Gamma Tag, set to sRGB. That’s an instruction, not a pixel remap: you’re not baking a different curve into the file, you’re telling whatever decodes it to assume one. Switching Resolve’s actual output curve to its own sRGB option instead of leaving it at 2.4 does the remap for real, which skips the tag doing its job and isn’t necessary for a safe 1-13-1 delivery.

One trap on the Deliver page: “Same as Project” follows the Timeline Color Space in a DaVinci YRGB project, so with a DWG/DI timeline it does not give you a Rec.709 tag. Set the Color Space Tag and Gamma Tag explicitly, as above. In a color-managed project, Same as Project follows the Output Color Space instead.

On Instagram: sRGB as the output gamma tag (2.2 gamma) can read slightly more accurate on Instagram and a few other apps that decode a little differently than YouTube does. If your Instagram exports look more contrasty and darker than what you graded, that’s the first thing to try.

None of this guarantees pixel-identical playback everywhere. YouTube, Vimeo, Instagram, and TikTok all decode slightly differently, and that’s not fixable from your end. The goal is a calibrated, zero baseline: tag correctly, and whatever drift remains is the platform’s, not a mistake you made.

Where to go from here

This is node-level setup: you build the CST and manage the transforms by hand, into whatever working space you land on. That’s the same idea EMBR’s OFX tool uses for its own Input Color Space setting. Point it at the space you built your CST into (DWG or otherwise) and the tool receives exactly what it expects, no extra transform needed. The DCTL kit is narrower: those are built and locked to DWG/DI specifically, so if you’re working with the DCTLs, that’s the working space to standardize your project on. See how EMBR manages color or go see what EMBR does.

The next guide

New videos and guides, when they land — once a week at most, usually less.