S-Log3 is two things at once, and both of them matter when you convert.
The curve and the gamut
The curve is how brightness is written to the file. S-Log3 puts 18% grey at code 420/1023 — 0.4106 normalised — and above a threshold near code 171/1023 it is logarithmic, with a short linear toe below for the deep shadows. That is why the image looks flat: the file spends its code values on dynamic range rather than on looking correct.
The gamut is which colours those values describe. S-Gamut3.Cine and Rec.709 do not use the same primaries, which is why a conversion carries a 3×3 matrix as well as a curve. Fix one half and not the other and you get the right brightness with the wrong colour.
What our conversion does, in order
Every conversion here is baked from the same transform library the previewer uses, in four steps:
- Decode. Undo the S-Log3 curve back to linear.
- Matrix. A 3×3 from S-Gamut3.Cine into Rec.709 primaries.
- Shoulder. Extended Reinhard, white point 8 — roughly 5.5 stops above mid grey. This is the step that matters at a show: log encodes far above diffuse white, so without a shoulder every laser spike and LED flare clips flat at the display curve.
- Display curve. The Rec.709 OETF.
How we know it lands
- All eight cameras in the library put 18% grey on the same Rec.709 value, 0.373. Different curves converging on one display value is the cross-check that matters.
- Round-trip tested against the shipped file:
decode(encode(x)) == x, anchors in place, matrix rows summing to 1.0, monotonic, neutral staying neutral. - 33×33×33, written red-fastest per the
.cubespec, with the generator asserting the axis order against a deliberately asymmetric corner — a technical conversion has to be right in Resolve, not just self-consistent here. - The GPU previewer was checked against a CPU reference at 0/255 deviation, and the shader against the JavaScript chain at a maximum of 1/255 across all eight cameras.
Conversion, or creative look?
Reach for the conversion when you shot S-Log3 and want a neutral starting point to grade on top of.
Reach for a creative look when the footage is already in Rec.709 — because you shot it that way, or because you already converted. A conversion applied to display-referred material undoes a curve that was never there, which is easy to misread as a broken LUT.
Do not ask one file to do both, and do not convert twice. The double conversion is the sneaky failure: a Color Space Transform and a conversion LUT on the same clip, each step individually correct.
This site's previewer solves exactly that. It routes by preset structure rather than camera name, and Sony S-Log3 presets are sent direct, with no transform in front, because those presets already convert from log themselves — a CST first would double-convert them. Same reasoning in your node tree: exposure and white balance on the native log image, then the conversion, then the look. The Academy explains why that order is mechanical rather than a preference.
Try it on your own frame
Drop a still onto any LUT page and set the log format to Sony S-Log3. The file is read straight into a WebGL texture in your browser — it never leaves the machine, and there is no endpoint receiving it.
The card preview on each conversion LUT is built the same way, on a reference frame synthesised into that camera's own log space. The site's default stills are RED, and applying an S-Log3 conversion to a RED frame is itself a mismatch — a broken image for the wrong reason.
Browse the log → Rec.709 conversions · Sony FX3 and FX5 hub
Sources
The curve, the threshold, the matrix, the Reinhard shoulder and the Rec.709 OETF all come from the transform library this site ships, read in the order the library itself applies them. The validator results, the 0.373 convergence figure, the .cube axis order and the two preview deviation figures come from the site's own colour-pipeline notes. The direct-routing rule comes from the previewer's routing table, the no-upload guarantee from the try-on script, and the per-camera reference frames from the preview generator.