Sony S-Log3 records an 18% grey card at code 0.4106. RED Log3G10 puts the same card at 0.3333, Apple Log at 0.4883. Eight log formats, eight different starting points — and run each one through its own conversion and all eight land middle grey on the same Rec.709 value, 0.373.
That convergence is the whole job. It is also what makes a conversion checkable in a way a creative look never is, and almost everything else here follows from it.
The three operations
A log to Rec.709 conversion is three operations in a fixed order. Nothing in it is a matter of taste.
- Decode. The log curve is undone and the recorded code value goes back to scene-linear reflectance. Every camera publishes its own curve, and they are not close to each other.
- Gamut. The camera's primaries are matrixed into Rec.709's — S-Gamut3.Cine, Cinema Gamut, V-Gamut, ALEXA Wide Gamut, REDWideGamutRGB, Blackmagic Wide Gamut Gen5, D-Gamut, or Rec.2020 in Apple Log's case. The matrix is a 3×3 whose rows each sum to 1.0, and that property is what keeps a neutral neutral.
- Display encode. Scene-linear values run far above diffuse white, so a shoulder brings them back into range — this site uses extended Reinhard with W = 8, about 5.5 stops over mid grey — and then the Rec.709 OETF encodes the result for a display.
Note what is not in that list. No contrast curve of choice, no saturation, no split toning. A conversion is a change of coordinates, not an opinion: a saved colour transformation rather than an effect with settings.
Which is why it can be checked, and the check is 18% grey. Here is where each format in the transform library behind this site's previews puts it:
| Log format | 18% grey, log code | Confidence |
|---|---|---|
| Sony S-Log3 | 0.4106 | high — matches published 420/1023 |
| ARRI LogC3 (EI 800) | 0.3910 | high |
| Panasonic V-Log | 0.4233 | high |
| RED Log3G10 | 0.3333 | high |
| Apple Log | 0.4883 | high |
| Canon C-Log3 | 0.3310 | high curve, toe derived |
| Blackmagic Film Gen5 | 0.3836 | medium |
| DJI D-Log M | 0.3988 | medium |
Different curves are supposed to disagree in log and agree on the display. Run all eight through their own decode, matrix, shoulder and OETF and every one arrives at 0.373. If two of them do not, one of them is wrong.
Why the look goes after the conversion
A creative LUT here is display-referred. Of the thirty presets behind this site's own previews, twenty-eight are an S-curve pivoting at 0.5 plus HSL saturation, and they only behave correctly on normalised input.
Feed one raw log and two things go wrong at once:
- The contrast pivot lands in the wrong place. The S-curve pivots at 0.5. Middle grey in S-Log3 sits at 0.4106 and in RED Log3G10 at 0.3333, so it falls below the pivot and gets pushed down, taking everything under it with it. In Apple Log, at 0.4883, it sits almost on the pivot and barely moves. Same LUT, two different failures.
- Everything above diffuse white is still up there. No shoulder has run, so the highlights either clip flat or arrive somewhere the look was never designed for.
The mirror-image mistake is converting twice — a Color Space Transform and a conversion LUT on the same clip. It is the sneaky failure, because each step is individually correct. This site's own previewer routes by preset structure rather than by camera label for exactly that reason: the S-Log3 and C-Log3 presets do their own pow(rgb, ~0.45) plus S-curve, so putting a CST in front of them double-converts, while DJI D-Cinelike carries a camera name and an ordinary HSL preset that needs one. A camera name on a file tells you nothing reliable about what that file expects.
CST or a baked conversion LUT
Both aim at the same destination.
| Color Space Transform | Conversion LUT (.cube) | |
|---|---|---|
| Where it lives | Resolve, on its own node | Any application that reads the format |
| Precision | Computed in Resolve's 32-bit float pipeline | Interpolated between lattice points; 33×33×33 here |
| Adjustable | Tone Mapping Method, Gamut Mapping Method, Saturation Knee/Max, Adaptation, white point adaptation | No parameters — a saved transformation, not an effect with settings |
The CST wins on control, and its parameters are the ones a stage show actually needs. Set Gamut Mapping Method to Saturation Compression and use Saturation Knee to place the roll-off: narrow-band LED and laser spikes are out-of-gamut saturation rather than simple over-exposure, so pulling exposure down does not fix them. Highlight Recovery is a different control for a different job — it lives in the Camera RAW tab and only applies to RAW formats. A baked LUT has already made every one of those choices for you; in these six, extended Reinhard at W = 8 and nothing else.
The LUT wins on reach. One file loads in DaVinci Resolve, Premiere Pro, Final Cut Pro and Photoshop's Color Lookup adjustment layer — anything that reads .cube.
One caveat on the LUT side is easy to miss: lattice size is a real limit, not a spec footnote. The conversions here are 33×33×33 and the creative looks are 17×17×17, because a conversion has to be accurate rather than merely pleasing. Seventeen points can band on a smooth gradient in 10-bit delivery, and a night sky or a haze-filled stage wash is exactly that.
Node order, and the reason for it
Correct your exposure, convert, then apply the look. In Resolve that is Node 1 primary exposure and white balance on the native log image, Node 2 the CST or conversion LUT, Node 3 the creative look.
The first reason is the Offset wheel. Offset is additive, and an additive shift in log space is a multiplication in linear space — a stop change, which is what an exposure adjustment is. In a display-referred image exposure is multiplicative; that is the Gain wheel. An additive Offset there is a pedestal lift that washes the blacks out.
The second reason is range. A CST tone-maps rather than hard-clips — Resolve works in 32-bit float, so highlights are compressed, not destroyed. Compressed is not the same as recoverable: pull exposure down afterwards and you drag that compressed block down as a whole, which reads muddy rather than recovered.
The fuller professional version is the sandwich: convert into DaVinci Wide Gamut / Intermediate, grade there, convert out to Rec.709, then put the look on.
Two applications do not give you that order for free:
- Premiere. Lumetri has two LUT slots and they are not interchangeable; picking the wrong one is the most common reason a LUT looks wrong there.
Basic Correction → Input LUTis the technical slot, and Lumetri applies it before the Basic Correction sliders — so the conversion lands first whether you want it to or not. If you need log-first correction, stack two Lumetri instances on the clip: correct in the first, put the conversion in the second's Input LUT, and the look in its Creative panel. - Final Cut. Also splits the job in two. The Camera LUT in
Inspector → Info → Settingsis the technical slot, applied at the clip level before anything else; the Custom LUT effect is the creative slot, applied and reordered like any other effect.
Full per-application steps are on the DaVinci Resolve, Premiere Pro and Final Cut Pro pages.
Six formats shipped, two withheld
The transform library implements eight cameras. The Log → Rec.709 category ships six conversion LUTs: Sony S-Log3, Canon C-Log3, Apple Log, RED Log3G10, Panasonic V-Log and ARRI LogC3. Blackmagic Film Gen5 and DJI D-Log are deliberately absent until they have been cross-checked against a Resolve CST.
The two withheld formats are the two the library itself rates medium confidence: their constants are published but less consistently documented, and the DJI curve implements D-Log while D-Log M on the smaller-sensor bodies is a variant that may differ. A creative look that is slightly off is still a look. A conversion that is slightly off is a bug in everybody's grade.
The same standard applies inside the six. Canon's published three-segment curve produced a decode that stepped backwards at the join — non-monotonic, which inverts tones in the shadows. The linear toe is therefore derived from the log branch's own derivative at the cut, so the join is continuous by construction; it agrees with Canon above 1.4% reflectance and differs only below that, under the noise floor of real footage.
"Checked" means specific things here, and they are all things a curve can fail:
- Every curve round-trips — encode a reflectance, decode it, get it back — and every decode is monotonic across the full 0–1 range.
- Every gamut matrix has rows summing to 1.0, so a neutral input comes out neutral.
- All eight formats land 18% grey on 0.373.
- Converting RED footage directly, and synthesising the same frame into Apple Log and converting that back, land within 0.3/255 of each other.
- The previewer applies each LUT's actual
.cubeon the GPU, verified against a CPU reference at 0/255 deviation.
One last detail specific to technical LUTs: these six are written red-fastest, per the .cube spec, unlike the creative looks on this site, and the generator asserts the axis order by checking a deliberately asymmetric corner. A creative look only has to be self-consistent. A conversion has to be correct in Resolve.
If a LUT looks wrong on your footage
It is almost always a mismatch between what the LUT expects and what it was given. Three causes, in order of how often they turn up:
- A Rec.709 creative LUT applied straight to log footage.
- A conversion LUT for the wrong log format — match the format you recorded, not the camera's marketing name.
- A double conversion: a Color Space Transform and a conversion LUT on one clip.
Every LUT page here carries a Try it on your footage panel — drop a still, pick its log format, see the conversion on your own frame. It runs entirely in the browser: the file is read into a WebGL texture and never uploaded.
In short
- A conversion is decode, gamut matrix, shoulder, OETF. It has no opinions.
- A creative look expects Rec.709 already. Correct, convert, then apply the look.
- Match the log format you recorded, not the camera's marketing name.
- Check it on 18% grey: every format in this chain lands it on 0.373 in Rec.709.
- Premiere and Final Cut each have a technical LUT slot and a creative one, and they are not interchangeable.
Sources
- The transform library this site ships — the per-camera decode curves and gamut matrices, the shared extended-Reinhard shoulder and Rec.709 OETF, the 18% grey codes, the high/medium confidence ratings and the D-Log versus D-Log M note. The round-trip, monotonicity, row-sum and 0.373 figures in this article were run against that file directly.
- This site's colour-pipeline reference — the six shipped conversions and the two withheld ones, the 0.3/255 round-trip verification, the previewer's 0/255 deviation against a CPU reference, red-fastest axis order, Canon's derived toe, 33³ versus 17³, and the preset-structure routing behind the previews.
- The site's own notes on grading traps — correct before convert, Offset being additive on log only, a CST compressing rather than hard-clipping, Gamut Mapping → Saturation Compression for stage lighting, Photoshop's Color Lookup layer reading
.cube, and 17³ banding in 10-bit delivery. - The site's per-application install pages — the Resolve node order and the sandwich, Saturation Knee placing the roll-off, the two-Lumetri-instance workaround in Premiere, and Final Cut's clip-level Camera LUT versus its Custom LUT effect.
- The live homepage FAQ — the three causes of a LUT looking wrong, "a saved colour transformation, not an effect with settings", 33³ being accurate rather than merely pleasing, and the six/two split. This guide extends it rather than repeats it.