LOG to display: what actually happens
LOG isn't a look, it's a container. The display LUT isn't a creative choice, it's a math operation. Here's what's happening when you slap that S-Log3 to Rec.709 LUT on your timeline.
Most editors learn LOG the same way: someone tells them "shoot in LOG, it captures more dynamic range, then apply this LUT in post." It works. The footage looks good. Nobody explains what's actually happening.
So here's what's actually happening.
LOG is a container, not a look
When a camera captures a scene, each pixel has a brightness value. A bright sky might be 10,000× brighter than a shadow. Your monitor can only display about 100× dynamic range. Something has to give.
There are two strategies:
- Rec.709 / display gamma: Throw away the highlights and shadows that don't fit. Fast, easy, looks "right" out of camera. You can't recover what's gone.
- LOG (logarithmic encoding): Compress the full dynamic range into the 0-1 video signal using a logarithmic curve. Highlights get squished, shadows get lifted. The footage looks flat and washed out because every value is in the middle of the histogram.
LOG looks bad on a monitor because a monitor isn't where LOG is supposed to live. LOG is a transport format. The screen is the final destination.
The display LUT is the inverse function
When you drop a "S-Log3 to Rec.709" LUT on your clip, the math being done is: for every input value in the LOG signal, look up the corresponding display value using the inverse of the camera's LOG curve.
That's it. The LUT isn't a creative grade. It's the mathematical inverse of the curve the camera used to encode the signal. It takes the compressed LOG signal and stretches it back out into a displayable image.
This is why a Sony S-Log3 LUT doesn't work on a Canon C-Log clip: the encoding curves are different. The inverse must match the original.
Where camera matching gets hard
If LOG is just a container and the display LUT is just an inverse, two cameras shooting LOG should match perfectly once you apply the right display LUTs, right? No.
The display LUT brings the signal back to displayable range. But it doesn't account for:
- Sensor color science. Each manufacturer's CMOS sensor and color filter array has a different spectral response. Green grass off a Sony sensor is a slightly different green than the same grass off a Canon sensor.
- White balance interpretation. Each manufacturer's "5600K" is a slightly different chromaticity coordinate.
- Gamut mapping. S-Gamut3.Cine, C-Gamut, DaVinci Wide Gamut. These are different color spaces, and converting between them involves choices.
A perfect display LUT applied to S-Log3 footage and another perfect display LUT applied to C-Log footage will produce two clips that both look fine on their own but don't match each other.
This is the camera matching problem. Not a LOG problem. Not a LUT problem. A sensor + gamut + interpretation problem.
Where MOVON sits in this chain
MOVON doesn't replace the display LUT. The display LUT still does its job: converting LOG to displayable range.
MOVON sits after the display LUT, in the matching step. It analyzes the displayable signal from the hero camera and from the cameras matched to it, then generates a custom .cube LUT that nudges each sensor's colorimetry toward the hero's.
Output is standard .cube. Drops into Lumetri after the display LUT in the stack. No magic. Just the part of the pipeline nobody had a tool for.
Practical takeaway
If your three cameras "almost match" after the display LUTs but skin tones are slightly off, that's the gap MOVON closes. The display LUTs got you to the right range. The matching step gets you to the right camera consensus.
