Most colorists who run a LUT before their Color Space Transform wonder why the grade feels stiff, over-saturated, or just wrong. It's not the LUT. It's the order — and the math behind it is unforgiving.
The Node Order Problem Nobody Talks About Plainly
Open any DaVinci Resolve forum thread on LUT placement and you'll find contradictory advice, half-explained workflows, and people arguing from gut feel. Let's settle it properly, from first principles, because the answer is not a matter of taste — it's math.
A LUT — whether a creative .cube or a technical transform — is a 3D table of input values mapped to output values. It was built under specific assumptions about what the incoming signal looks like. If you feed it something different from what it expects, it will do the wrong transformation. Full stop.
A Color Space Transform (CST) node in Resolve does one job: it reshapes the signal from one color space and gamma encoding to another. S-Log3/S-Gamut3.Cine to DaVinci Wide Gamut/DaVinci Intermediate. Log-C3/AWF to Rec.709/Gamma 2.4. Whatever the path, the CST node is normalizing your signal into a known state.
A creative LUT — say, a film-emulation or a wedding pack LUT — was built assuming it receives a normalized, display-referred (or at minimum a linearized scene-referred) signal. It was not built to receive raw S-Log3. The moment you drop a creative LUT onto an untransformed log clip, you're asking the table to map logarithmically compressed values as though they were Rec.709 — and the result is exactly the crushed shadows, illegal highlights, and oversaturated skintones you've seen.
What Your Scopes Tell You
The fastest way to confirm the problem empirically — before you touch a single node — is to read your scopes before and after each node.
Pull up a Sony FX3 clip shot in S-Log3/S-Gamut3.Cine. On the Parade scope, the log signal will sit between roughly 17% and 65% IRE — a compressed, low-contrast band. Middle grey (18% grey card) will read around 41 IRE in S-Log3.
Now add a CST node first. Input: S-Log3 / S-Gamut3.Cine. Output: Rec.709 / Gamma 2.4. Your Parade immediately explodes into the full luma range — shadows at 0–15, midtones around 50, highlights at 80–95. Your whites are white. Middle grey is sitting near 45 IRE, where Rec.709 expects it.
That is the signal your creative LUT was built to receive. A LUT node placed after this CST sees exactly the input it was designed for. Skintones map correctly. Shadows roll off naturally. Film emulations that crushed skin before now render the way their maker intended.
Run it backwards — LUT first, CST second — and read the Parade after the LUT. You'll see clipped highlights, lifted and posterized shadows, and vectors on the Vectorscope that have escaped the Rec.709 gamut triangle. The CST after that point is trying to make sense of a signal that's already been corrupted. You can push it toward legality, but the image is already broken at a sub-pixel level.
The Correct Node Tree
Here is the baseline node structure that works for virtually every log-camera-to-display workflow where you're using a creative LUT:
Node 1 — CST In
Input CS: S-Log3 / S-Gamut3.Cine (or Log-C3, BRaw, etc.)
Output CS: DaVinci Wide Gamut / DaVinci Intermediate
(or Rec.709 / Gamma 2.4 if going straight to display)
Node 2 — Primary Correction (Lift / Gamma / Gain or Offset)
Exposure, white balance, basic contrast only.
Get the shot normalized before the LUT sees it.
Node 3 — Creative LUT (.cube)
Applied in node Effects → LUTs, or drag-and-drop.
At this point the signal is in the space the LUT expects.
Node 4 — Qualifier-based secondaries
Skin Qualifier, sky mask, HSL selections.
Adjust what the LUT got wrong for this specific shot.
Node 5 — CST Out (if using DWG/DI as intermediate)
Input CS: DaVinci Wide Gamut / DaVinci Intermediate
Output CS: Rec.709 / Gamma 2.4 (or P3-D65 / Gamma 2.6 for cinema)
If you're working in a Color Managed project (Project Settings → Color Management, with input and output color spaces set), Resolve handles the CST in/out automatically at the timeline level. In that case you don't need explicit CST nodes — but you still need to understand which node your LUT sits in, because the timeline CST runs before your node tree begins. The LUT in Node 1 of a color-managed project still receives a normalized signal. The math still applies.
For unmanaged projects — which many freelance DPs and editors still use because they're working with mixed camera sources and want explicit control — the explicit CST-then-LUT structure above is essential. You cannot rely on implicit transforms you haven't set yourself.
ACES and the Same Logic
The same rule holds if you're working in an ACES pipeline. IDT (Input Device Transform) comes first, converting your camera-native signal into ACEScg scene linear. Your creative grades happen in that linear space. The RRT + ODT (Output Transform) comes last, mapping to the display. If someone gives you an ACES-compatible LUT — built for ACEScg input — it still must be placed after the IDT, not before it.
The mistake is identical in a different wrapper: a LUT expecting linear scene data placed onto a log-compressed signal will exhibit the same clipping and saturation errors. ACES does not make the problem disappear; it just gives the problem different labels.
The "But My LUT Has a Built-In Log Conversion" Caveat
Some LUTs — particularly technical ones from camera manufacturers, and some older creative packs — are designed as combined transforms: they ingest log directly and output Rec.709 in one step. Sony's S-Log3 to Rec.709 technical LUT is a common example. Arri's LogC3 to Rec.709 viewing LUTs work the same way.
If your LUT is one of these all-in-one transforms, placing a CST before it would be wrong — you'd be normalizing the signal and then running a LUT that expects log, producing a doubly-converted mess.
How do you tell the difference? Documentation. A reputable LUT pack will always specify its input expectation: "Apply to S-Log3 / S-Gamut3.Cine footage before any CST" or "Apply after normalizing to Rec.709." If the documentation doesn't say, test it: feed the LUT a chip chart clip and read your Parade after. If middle grey is hitting 45–50 IRE on a Rec.709-expected signal, you're in the right zone. If it's sitting at 15 IRE or 75 IRE, your input assumption is wrong.
The Positiva Bundle
Every LUT in the bundle ships with explicit input-space documentation — so you know exactly where in your node tree to place it, whether you're on FX3, R5 C, or BMPCC 6K.
Practical Workflow for Mixed-Camera Projects
Multicam edits — a common reality on any larger Indian wedding or travel documentary — make node order even more critical because you may have S-Log3 from an FX3 alongside Cinema Gamut/Canon Log 3 from a C70 and BRaw/BM Film Gen 5 from a BMPCC 6K. Each camera's log encoding is different. Each needs its own CST in Node 1.
The efficient approach: create three serial nodes at the head of each clip's node tree — one labelled CST IN, one labelled PRIMARY, one labelled LUT. Apply the camera-specific CST in Node 1 for each clip. The LUT in Node 3 is identical across all cameras, because by the time the signal reaches it, all three cameras are speaking the same normalized language. You can now use Gallery Stills to copy-paste the LUT node (and secondary nodes below it) across clips without worrying about conflicting input spaces.
In Resolve's Color page, right-click any node and Set Flag — use red for CST nodes, blue for creative grades. This takes five seconds per clip and saves you from mis-copying a Sony CST onto a Canon clip three days into the grade when you're running on cold coffee.
When CST Nodes Get Expensive on Slower Systems
If you're grading on a laptop or a system without a strong GPU — common in field situations or when traveling between locations — CST nodes add processing overhead. Every Color Space Transform node forces Resolve to do a full 3D math operation per frame. Stack three of them (CST in, CST between nodes, CST out) and you'll drop GPU-rendered playback on a 4K timeline.
The fix: use Resolve's Color Management at the project level instead of per-clip CST nodes. Set your input color space to match your primary camera, set your timeline to DaVinci Wide Gamut / DaVinci Intermediate, and set your output to Rec.709 / Gamma 2.4. Resolve handles the math in the hardware pipeline rather than as discrete software nodes, which is significantly faster. Your creative LUT in Node 1 then receives the normalized intermediate signal automatically.
You still need per-clip input overrides for any camera that doesn't match the project default — right-click a clip in the Media Pool → Clip Attributes → Color Space override. But the bulk of your timeline runs clean.
A Note on Output-Referred LUTs for Social Delivery
One last placement question that comes up frequently: where does a LUT go when you're delivering for Instagram or YouTube, which re-encode to their own pipeline anyway? The answer is the same. Your node tree should still read CST-then-LUT, with the final output rendering to Rec.709 Gamma 2.4. Let the platform handle the conversion to their delivery spec. Delivering a correctly tagged, display-referred Rec.709 master is always your cleanest starting point — what happens upstream of the CDN is outside your control.
What you can control is whether the LUT in your grade was seeing the signal it was designed to see. Get that right, and every output — from a cinema DCP to an Instagram Reel compressed to 8 Mbps — starts from a solid foundation rather than a corrupted one.
For a deeper look at secondary node work after your LUT is placed — qualifying skintones, pulling selective hue masks — see the post on correcting FX30 skin tones with a single qualifier node. And if you're building a node tree from scratch for a multicam project, the bundle pack documentation walks through camera-specific CST settings for every format in the pack.