Technical
Colour, managed
Every setting in the panel can be correct and the picture on screen can still be wrong. This is the failure that eats an afternoon, and the habit that prevents it takes about ninety seconds.
Modern cameras don't record a picture. They record a container of numbers plus a claim about what those numbers mean, the transfer curve they were encoded with, and the set of primaries they were measured against. Log footage in a wide gamut is exactly this: deliberately flat, deliberately unviewable, and completely dependent on the receiving software believing the same claim the camera made.
When that belief breaks, nothing errors. There is no warning. You simply get a picture that is slightly wrong in a way that is very hard to name, skin a little plastic, blacks that sit above zero, saturation that goes strange when you push it, and because every dialog says the right words, you spend an hour adjusting the wrong things.
The three places the claim gets lost
The tag. A file carries metadata saying "this is log, in this gamut." Transcoding, proxy generation, or a round trip through another application can drop or rewrite that tag. The pixels don't change; the label does. Now the same numbers get interpreted as ordinary video, and everything downstream is built on a misreading.
The transform. Colour-managed pipelines apply a conversion from the source encoding to the working space, and then another to the display. Two conversions, either of which can be set to the wrong source. Applying a display transform twice, once by the project settings and once by a look you added, is the single most common version of this, and it produces contrast that looks almost plausible, which is why it survives.
The viewer. The monitor, the operating system's colour handling, and the application's preview all get a vote. A preview window that isn't colour-managed will happily show you something no viewer will ever see. This is the one that catches people on laptops with wide-gamut displays.
A correct conversion table does not guarantee a correct picture. It guarantees a correct picture if the input was what you said it was.
Measure the decoded frame, not the settings
The fix is to stop auditing the interface and start auditing the pixels that come out of it. Pull a frame after the full pipeline has been applied, the actual output, not the timeline preview, and look at what the numbers say.
- Check black. Find something in the frame that should be genuinely black, a shadowed doorway, the inside of a wheel arch, and read its value. It should sit at or near the floor. If your blacks land well above zero, a log-to-display transform probably hasn't been applied, or has been applied against the wrong source.
- Check white. A practical light or a specular highlight should approach the ceiling without a wide plateau of clipped values. A large flat area at maximum means something in the chain is crushing, usually a transform applied twice.
- Check skin. The most sensitive test available, because everyone knows when it's wrong even if they can't say why. On a properly decoded frame, mid-tone skin in daylight sits in a broadly predictable band. If it reads far outside that, too pale, too orange, oddly waxy, trust it over any dialog.
- Check a known reference. If you shot a grey card or a chart, this takes ten seconds. If you didn't, use a frame from a previous job you know was right and compare the two side by side.
The important discipline is in step zero: measure the frame that comes out, not the table that goes in. Inspecting a conversion table only tells you the table is internally consistent. It cannot tell you the footage entering it was the thing the table expects. Those are separate claims, and only one of them is verifiable by looking at a picture.
The ninety-second habit
Before grading anything, export a single frame from the finished chain and open it fresh. Read black, white, and skin. Write those three numbers down. If a later export disagrees with them, something in the pipeline moved, and you'll know it in seconds rather than after a full render.
Why it matters more than it sounds
None of this is visible as a catastrophic failure, which is exactly the problem. Wrongly-decoded footage still cuts, still plays, still gets delivered. It just looks a bit cheap, and every correction you apply on top of the wrong base makes the eventual right answer further away. Grades built on a bad decode fall apart the moment they're moved to another display, because they were compensating for a mistake rather than describing a look.
Getting it right is not a purist exercise. It's the difference between a grade that survives a phone, a laptop, a television and a projector, and one that only ever looked correct in the room where it was made.
A short checklist
- Confirm what the camera actually recorded, encoding and gamut, from the source file, not from memory.
- Set the project to a managed pipeline and let it do the conversion once. Don't stack a display transform on top of a look that already contains one.
- Keep proxies in the same colour handling as the originals, or expect a shift when you relink.
- Grade on a display you have characterised, and check on an ordinary one before delivery.
- Measure black, white and skin on the exported frame. Every time.
Ninety seconds at the start. Hours saved at the end.