LOG to display: what actually happens
LOG is a container, not a look. The display conversion is math, not taste.
Most editors learn LOG the same way: someone says "shoot LOG, it captures more dynamic range, then apply this conversion in post." It works. The footage looks good. Nobody explains what is happening.
So here is what is 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 times brighter than a shadow. Your monitor can only show about 100 times. Something has to give.
There are two strategies:
- Rec.709 / display gamma. Throw away the highlights and shadows that do not fit. Fast, easy, looks right out of camera. You cannot get back what is gone.
- LOG. Compress the full range into the 0-1 video signal with a logarithmic curve. Highlights get squished, shadows get lifted. The picture looks flat because every value sits in the middle of the histogram.
LOG looks bad on a monitor because a monitor is not where LOG is meant to live. LOG is a transport format.
The display conversion is the inverse function
When you drop an "S-Log3 to Rec.709" LUT on a clip in Premiere, the math is simple: for every value in the LOG signal, look up the display value using the inverse of the camera's LOG curve.
That is it. It is not a creative grade. It is the mathematical inverse of the curve the camera used. It stretches the compressed signal back into a viewable image.
This is why a Sony S-Log3 conversion does not work on a Canon C-Log clip. The curves are different. The inverse has to match the original.
Where camera matching gets hard
If LOG is a container and the conversion is its inverse, two cameras shooting LOG should agree once converted. They do not.
The conversion brings the signal back to viewable range. It does not account for:
- Sensor color science. Each maker's sensor and color filter array sees light differently. Green grass off a Sony sensor is a slightly different green than the same grass off a Canon.
- White balance interpretation. Each maker's 5600K is a slightly different point.
- Gamut mapping. S-Gamut3.Cine, C-Gamut, DaVinci Wide Gamut. Different spaces, and converting between them involves choices.
Two correct conversions produce two clips that each look fine alone and do not match each other. That is the camera matching problem. Not a LOG problem.
Where MOVON sits in this chain
MOVON reads your clip as the camera recorded it, works out one grade for it, and applies it. You do not prepare anything first.
If your workflow converts footage for viewing, that step still does its job. Converting for viewing and making two cameras agree are two different jobs. MOVON does the second one.
Practical takeaway
If your three cameras almost agree but skin is slightly off, that is the gap MOVON closes.
