Multicam color matching: the complete guide
Why multi-camera footage never matches out of the box, what "matching" actually means, and how editors can fix it. The complete reference, with workflow recipes for Premiere, Resolve, and Final Cut.
Three cameras, one timeline, three different looks. It is one of the most common color problems editors face today, and the one with the least useful documentation. There are tutorials for color grading. There are tutorials for color correction. There are tutorials for camera-specific LUTs. Very little is written about the in-between step, the one editors actually need: how to make footage from two or three or seven cameras look like it came from the same shoot.
Below is the full picture. Where the mismatch comes from. What "matching" actually means, and what it does not. The manual workflow every editor learns the hard way. The hero-camera concept that simplifies the whole thing. The automation route MOVON Labs is building for. Nothing in this guide is theoretical: it is the workflow editors run on real multi-cam projects, written down properly.
Why multi-camera footage never matches out of the box
The instinct on the first multicam shoot is to assume the cameras will match if the settings line up. White balance to the same number, exposure to the same value, a similar LOG profile. Drop the clips in. Play.
They don't match. They are not close to matching. The A-cam looks slightly warm and the B-cam looks slightly green and the drone looks like it is from a different movie.
This is not a bug in the cameras. It is the cameras working correctly.
Every camera reads light through a different sensor, processes it through different on-board math, and stores it in a different LOG container. A Sony FX6 in S-Log3 and a Canon C70 in C-Log3 are recording the same scene, but the numbers they write to the file are not the same numbers, because the sensors aren't the same sensors and the pipelines aren't the same pipelines. Even with identical settings, the result is two different files describing one scene.
There is a longer write-up of why this is true at the sensor and pipeline level: Why your multicam footage never quite matches. The short version: matched settings are not matched footage.
What "matching" actually means
The first piece of vocabulary that gets in the way is "grading." Most online color tutorials are about grading, which is the creative pass: choosing the look, pushing teal-and-orange, dropping the shadows, deciding the film feels like a sunny afternoon or a cold morning.
Matching is not grading. Matching is the step before grading, and it has a much narrower job: take a set of clips that should look like they came from the same shoot, and make them look like they came from the same shoot. No creative choice, no mood, no look. Just: the cameras agree.
This distinction matters because the workflow is different. A grade is opinion. A match is a measurement. There is a longer piece on this at Matching cameras is not grading them; the practical implication is that matching can be quantified, and anything that can be quantified can be automated. Grading cannot.
So everything below is about the technical step. The creative grade comes after, and it is the part that should stay manual, because it is the part that carries the editor's taste.
Where the mismatch comes from
Three forces pull multicam footage apart. Knowing which one is doing the damage makes the fix less of a guessing game.
The LOG container
LOG is not a look. It is a way of storing more dynamic range than the file format would otherwise carry. S-Log3, C-Log3, V-Log, N-Log, BRAW Gen 5, D-Log, D-Log M: each is a curve that compresses the highlights and shadows so a normal 10-bit or 12-bit container can hold what the sensor saw. Played back without a display LUT, LOG footage looks flat, low-contrast, and slightly green-grey. That is not the look. That is the container, before the conversion to display space happens.
There is a full walk-through of this at LOG to display: what actually happens. The relevant fact for matching: two different LOG profiles describe the same light differently, and applying a display LUT alone does not align them.
The sensor
Every sensor has a different color response. Two cameras pointed at the same chart will record different RGB triplets for the same patch. The differences are small but consistent: a Sony sensor reads a certain green slightly cooler than a Canon sensor, a Blackmagic sensor reads a certain skin tone slightly warmer than a Panasonic. These differences compound when the cameras are pointed at real-world scenes with real-world lighting.
The drone is the worst version of this problem because its sensor is small. A DJI Mavic 3 has a tiny sensor compared to an FX6, with a different color filter array, different bit depth, different processing. It will fight the timeline harder than any other clip. There is more on this at The drone clip always loses.
The white balance and exposure decisions on set
Even with the same camera profile, the operator's choices on set move the file. A B-cam that was set to auto white balance while the A-cam was set to a fixed 5600K will drift. A clip exposed half a stop hotter than the hero will need to come down before the colors can be compared at all.
These are the easy ones to fix, because they are scalar corrections. The LOG-profile and sensor differences are the ones that need a real match.
The manual workflow
Every editor who shoots multicam learns the same five-step workflow, usually by losing a weekend to it.
- Identify the LOG profile on every clip. Right-click. Look at the metadata. Confirm the tag. Premiere does not always read it correctly, especially with proxy workflows or mixed-format ingest.
- Apply the right display LUT per profile. Sony S-Log3 needs the S-Log3 to Rec.709 LUT, not the V-Log one. Canon C-Log3 has its own. Drone footage has its own. Get this wrong and the rest of the work is wasted.
- Pick a reference, usually by feel. Most editors pick the A-cam because it is the most expensive camera on the shoot, and assume the others should match it.
- Pull curves and HSL until the secondaries look like the reference. This is the part that eats the day. Adjust the B-cam. Now the A-cam looks wrong by comparison. Adjust the A-cam back. The drone is still wrong. Loop.
- Notice the matched look drifts under the creative grade. Once the grade goes on, mismatches that were invisible at neutral get amplified. Back to step 4.
A two-hour shoot becomes a six-hour evening. There is a longer field report on this exact loop at The one-man crew problem.
What makes the workflow expensive is not editor skill. It is the eye itself. The eye adapts. It compensates. It tells the editor the clips match before they actually do, and the audience picks it up half an hour later when the cut feels off and they cannot say why.
The hero camera concept
The first piece of structure that makes multicam matching easier is choosing a hero.
The hero is not the most expensive camera. The hero is the camera that nailed the look on this particular shoot: the one with the cleanest whites, the most honest exposure, the skin tones the editor wants to keep. Sometimes it is the A-cam. Often it is not. The B-cam in better light, the drone in golden hour, the second-unit run-and-gun with the corrected white balance: any of them can be the hero on a given day.
Once a hero is named, the matching problem collapses from "make everything look right" to "make everything look like the hero." That is a much smaller, much more tractable problem. The hero defines the target. Everything else gets pulled toward it.
The longer version of this argument, and how to pick a hero in practice, is at Picking a good hero camera.
The automation route
The five-step manual workflow has a property that makes it interesting from an engineering point of view: it is repeatable. Editors are not improvising. They are running roughly the same comparison, the same correction, the same iteration, every time. Anything an editor does the same way ten times in a row can be done by a model.
MOVON Match is built on that premise. Two neural networks, both running on the editor's Mac, do the matching:
- A backbone model reads pixels from each clip and produces an embedding that captures how the camera renders color. This is what lets MOVON group clips by camera without relying on metadata, and what gives every group a stable color signature for the next step to compare.
- A LUT-predictor model takes the backbone's embedding for the hero group and every other group, and generates a custom 33³ .cube LUT per non-hero group that transforms it toward the hero. Standard .cube, the same format Lumetri and Resolve and Final Cut already understand.
The full pipeline runs locally. The footage never uploads. There is no account. There is no waiting on a server. The honest current state: inference performance is still being tuned, and MOVON Labs is not quoting firm timing numbers yet. The target is a full multicam timeline matched in about a minute on an M-series Mac.
There is a separate, longer write-up of why the matching runs locally and not in the cloud at Local vs. cloud AI color tools.
What to look for in a multicam matching tool
The market has options. A handful of paid plugins, some built-in NLE features, a couple of cloud-based color tools. The questions that actually separate them, once the marketing language is stripped away:
Does the tool read the actual shot, or look up a stored profile? This is the deepest split. Most plugins match cameras by applying a precomputed profile that was captured in a controlled studio: same calibration chart, fixed light, sensor as it behaved on the lab day. The match is the same whether the shoot was an interior with daylight bleeding through a window or a sunset wide on a beach. Adaptive tools read the actual frames on the timeline, build a per-clip color signature, and match the hero in the scene the editor actually shot. The first approach is faster per clip; the second adapts to the project. The longer breakdown lives at How MOVON compares to other color-matching plugins.
Does the tool match cameras to a chosen reference, or does it auto-grade? These are different problems. A tool that picks a look on the editor's behalf is solving the grading problem, which the editor probably wants to do by hand. A tool that matches cameras to a chosen reference is solving the matching problem, which the editor wants to be done with.
Does it group clips by camera, or does it ask the editor to do that? On a 47-clip multicam timeline, hand-grouping by camera is itself a chore. A tool that groups on its own, by reading the footage instead of trusting metadata, removes a whole layer of manual prep.
What does it output? A proprietary effect locks the work into one NLE. A standard .cube LUT works in any tool the editor might ever switch to: Lumetri, Resolve, Final Cut, anything that reads a LUT. Standard formats are how a project survives the next NLE migration.
Where does the footage go? Cloud tools upload frames. Local tools do not. For NDA work, this is not a preference. It is a requirement.
What does it cost in five years? Subscription plugins are a recurring tax on every project. A perpetual or one-time license is a known cost. A tool whose business model is uncertain is a tool that might disappear or get expensive.
These are the questions to apply to any tool, including MOVON. The honest answers for MOVON Match: reads the actual frames on the timeline rather than a stored studio profile, matches to a chosen hero (not auto-grade), groups by camera on its own (no metadata required), outputs a standard 33³ .cube per camera group, runs entirely on the Mac (no upload), and is free through January 2027 with paid pricing announced 90 days before the cutover.
Workflow recipes
These are the practical recipes for the three editors who will read this guide. The Premiere flow is the one MOVON Match supports today; the Resolve and Final Cut sections describe what is in the planning pipeline.
Premiere Pro (today)
- Install MOVON Match. The plugin docks as a panel inside Premiere.
- Open the multicam project. If Premiere is reading the LOG profile wrong for any clip, set the correct Input LUT on the source clip in Lumetri before running the match.
- Hit Analyze in the MOVON panel. MOVON reads the timeline, groups every clip by camera on its own, and proposes a hero.
- Confirm the hero, or pick a different camera as the hero.
- MOVON generates one .cube per non-hero camera group and exports the files from the panel.
- For each non-hero camera, select all of its clips in the bin or on the timeline and apply the matching .cube via the Lumetri Color panel. (One-click apply across the whole timeline through MOVON's own effect is the piece in active development for the private beta; until it lands, the per-group .cube flow above is the workflow.) The .cube files can also be carried into Resolve or Final Cut if that is the finishing tool.
There is a project-level walk-through at Running MOVON inside a Premiere project.
DaVinci Resolve (planned)
The Resolve panel is on the roadmap. The node-tree position is already designed: MOVON sits before the creative grade, after any Color Space Transform, on a dedicated node so it can be bypassed for QA. The Resolve build will share the same backbone and LUT-predictor models as the Premiere build, so a project that gets matched in Premiere can finish in Resolve without re-running MOVON.
Final Cut Pro (planned)
The Final Cut extension is on the roadmap behind Resolve. The integration uses the Workflow Extensions API and ships the same standard .cube output, applied via a Custom LUT effect on each camera group.
Common pitfalls
The five most common mistakes editors make when color-matching multicam, and how to avoid them. These are the ones that cost evenings.
Applying the wrong display LUT first. Sony S-Log3 footage with a V-Log LUT applied does not just look slightly off. It looks fundamentally wrong, and every adjustment after that is fighting the wrong baseline. Confirm the LOG profile first. Apply the correct display LUT. Then start matching.
Picking the most expensive camera as the hero by reflex. The A-cam is not automatically the hero. On a shoot where the B-cam was in better light, the B-cam is the hero. Pick by look, not by price tag.
Trying to match in the creative grade. Matching and grading are different passes. Get the cameras agreeing first, then put the creative look on top of all of them at once. Matching inside the creative grade means re-doing the match every time the look changes.
Forgetting the drone. Drone footage almost always needs more correction than the cinema cameras, because the sensor is smaller and the color science is different. Plan for it. Start with the drone, not last.
Letting the eye decide. The eye adapts. The vectorscope does not. When the cameras look matched but the scopes disagree, the scopes are right. There is a short tutorial on scope-based QA at Scopes, not eyeballs: how to verify a match.
Common questions
Does the tool need to know what cameras were used? No. MOVON groups clips by camera by reading the actual color signature of each clip, not by reading metadata. A timeline with no camera metadata, or with wrong metadata, gets the same grouping as a clean one.
Will it work with proxies? MOVON analyzes whatever pixels the panel sees. Proxies that preserve the LOG color signature behave like full-res footage for the match. Proxies that were rendered to Rec.709 will skew the result: for the cleanest match, toggle off proxies before running Analyze, or generate proxies that keep the original color space.
What about HDR? MOVON Match is currently SDR Rec.709. HDR support is on the roadmap and will share the same backbone model with a different output transform.
Can MOVON match to a reference frame instead of a camera? Reference-frame matching, where the editor picks a single still as the look target instead of an entire camera group, is on the planning list. Camera-to-camera matching was built first because it is the more common multicam problem.
Is this just a fancier auto white balance? No. Auto white balance corrects one global scalar. MOVON generates a full 33³ .cube LUT, which is a three-dimensional transform of the entire color volume. The two solve different problems at different resolutions.
The shorter version
Multi-camera footage does not match out of the box because different cameras are not the same camera, no matter how the settings are dialed in. Matching is a measurement, not a grade. The manual workflow takes hours, runs on the editor's eye, and drifts under the creative grade. The hero-camera concept turns it from "match everything" into "match toward this one." Automation makes the rest fast.
MOVON Match is the version of that automation MOVON Labs is building, locally on the Mac, with a standard .cube output and a roadmap that takes it from Premiere today to Resolve and Final Cut. The current build is in private beta, free through January 2027.
For editors who want the workflow without the weekend, the private beta is open. For everything else, this guide is the reference.
— The MOVON Labs team
Get the next dispatch in your inbox.
Release notes, color science notes, and the occasional field report. No marketing. Unsubscribe one click.
