Why your cameras don't match, and how to fix it in post

Two cameras don't match for four reasons, and they stack: what each sensor saw, what each picture profile did with those numbers, white balance on its two independent axes, and exposure. Only the sensor difference is permanent; the other three you fix in post, in a fixed order — both cameras into the same space, then exposure, then white balance. Two bodies, one job, and the footage refuses to cut together. The wide is warmer than the close-up. Skin sits in a different place on every reverse. The person who has to fix it is the editor, who was not on set, did not choose the picture profiles, and has no intention of becoming a colorist.

They can be brought much closer together than they look right now. Not identical, and anyone promising identical is selling something, but close enough that an audience stops noticing the cut. What follows is why the two cameras diverged in the first place, why almost every article you have found is useless to you at this stage, and the order of operations that survives contact with real footage.

What the two cameras actually did differently

Four things, and they stack on each other, which is why the mismatch feels bigger than any single cause would suggest.

The first is what the sensor saw. ARRI's own color FAQ makes a point worth sitting with: it argues there are no colors a camera cannot see, so it does not really make sense to talk about "the gamut of a camera" at all. What differs between manufacturers is how each red, green and blue filter responds across the spectrum, and therefore what three numbers come off the sensor when two bodies are pointed at the same face under the same light. That divergence exists before anybody has made a creative decision. It is also the part you cannot undo, only compensate for.

The second is what the camera did with those numbers. A picture profile is a rendering: a tone curve and a set of color decisions the manufacturer made on your behalf. ARRI describes Rec.709 as a display specific encoding, the what you see is what you get case, and describes wide gamut as the generic label for encodings larger than Rec.709. So a body set to a Rec.709 profile has already committed to a look, while a body set to log has deliberately not. Two cameras on the same job, one baked and one flat, are not two versions of the same image. They are an image and a negative.

The third is white balance, and it is usually the loudest offender. ARRI's FAQ describes the two controls plainly: color temperature in Kelvin moves the white point between blue and red, and the CC or tint control moves it between green and magenta. Those are two independent axes, which is why a shot that looks too warm often also looks too green, and why nudging temperature alone never quite lands. Set both cameras to auto and they will disagree, because each is solving the same problem with a different algorithm against a slightly different framing. Set them by eye and they will disagree by however much the two operators disagreed.

The fourth is exposure, and it is the one people misread as color. A face half a stop down does not look darker so much as duller and slightly different in hue, because contrast and saturation move together in almost every rendering. Chasing that with the color wheels is how an evening disappears.

Why every answer you have found is pre-production advice

Search this problem and you will be told to shoot a color chart at the head of every setup, to put both cameras in log, to match picture profiles, ISO and white balance on set, and to buy a matched pair of bodies. All of that is correct. None of it is available to you.

This is the structural gap in the existing content. It was written for the person holding the camera, and the person searching has usually already wrapped. Worse, the advice tends to arrive with an edge of you should have known, which is not useful to an editor who was handed a drive and a deadline.

There is one piece of pre-production advice worth keeping in your head for next time, and it is not the chart. It is that the cheapest fix is agreeing on white balance and exposure between two bodies, in that order, because those two are the ones post has to fight hardest. Everything else post can absorb.

First move: put both cameras in the same space

Do not start by making camera B look like camera A. Start by making both of them look like nothing at all.

Every log format is an encoding with a defined transform back out of it. Apply that transform per camera, as an input transform, before you make a single creative decision. In DaVinci Resolve this is the Color Space Transform or the project color management settings, in Premiere it is the automatic log detection and tone mapping, and in an ACES setup it is the Input Transform, which the Academy's documentation describes as the step that converts camera native data into ACES2065-1, the linear wide gamut encoding at the center of the system. The point of all three is the same: disparate sources are conformed to one common encoding first, and viewed through a single output transform second.

Blackmagic describes color management as controlling the conversion of color between cameras, scanners, monitors, broadcast displays and projectors, and Resolve supports both its own system and ACES. That sentence is doing more work than it looks like. Once both cameras are sitting in one working space with one output transform, the difference between them collapses from "everything" to "exposure, white balance, and some hue behavior in the saturated colors." Those are three problems you can solve. The original pile was not. That collapse is measurable rather than rhetorical: encode one scene in two different log formats, normalize each with its manufacturer's own inverse, and the tonal difference between them is zero, with 10-bit rounding leaving about 0.04 stops across everything normally photographed.

Two practical notes. If one camera shot Rec.709 and the other shot log, the Rec.709 material is already display referred and does not get an input transform, it gets left alone and matched to. And if the log footage still looks flat and gray at this point, nothing has applied a transform to it yet, which is a different problem covered in why your S-Log3 footage looks washed out and, for the specific conversion routes, in S-Log3 to Rec.709.

Second move: exposure, then white balance, in that order

Pick a hero camera. Usually the one with more shots, better exposure, or the closer coverage of faces. Everything else moves toward it.

Match exposure first, using the waveform rather than your eyes, and match it on something that exists in both shots. A face is best. A wall in shade is fine. Get the same feature landing at the same level in both clips before you touch a color control, because every color judgment you make against mismatched exposure is a judgment you will make again.

Then white balance, and here the two axes from earlier become the working method. Correct the blue and red axis first, then the green and magenta axis, checking each on the parade rather than the picture. Neutral surfaces are the tell: a white shirt, a gray road, a paper cup. If the three channels stack on the parade for the neutral object in both cameras, the two clips will already look like siblings, and you have not made a single creative decision yet.

Only now do you build a look, once, and push it to both cameras. Doing it in the other order means every look adjustment reopens the match. Pushing one look across many clips is its own subject, and the short version is that you normalize per clip and grade per scene, which is the argument in do you have to color grade every clip.

The shots that still refuse

There will be a few. Usually a skin tone that stays slightly ruddy on one body, or a branded blue that goes purple on the other. This is the part where the two sensors genuinely disagree and no global control will reconcile them, because a global control moves everything.

That is what a qualifier is for. Blackmagic describes qualifiers as selecting parts of the image based on hue, saturation or luminance, and power windows as drawing a shape around a specific object, with a tracker that animates the window to follow movement. The workflow is narrow on purpose: isolate only the color that disagrees, shift only that, feather generously, and check the edges of the selection on a moving frame rather than a still.

Two rules keep this from becoming a rabbit hole. Do the qualifier pass last, after normalization and after the primary match, because a qualifier keyed against an unnormalized image will fall apart the moment you change anything upstream. And do it on the shots the audience will look at, not all of them. A three second cutaway does not need a skin key.

A longer walk through this at multi-camera scale, including what to do when there are three bodies rather than two, is in fixing shot matching on multicam and indie footage.

Where automatic matching earns its place, and where it stops

The automatic tools are better than their reputation and worse than their marketing.

Blackmagic documents two distinct features. One matches a clip to a color chart in frame, where you pick the chart type, line up the overlay and let it solve. The other is shot match, where you select one clip, right click another, and Resolve moves color, contrast and brightness of the clip you are on toward the one you picked. Premiere has a comparable match in the Lumetri panel driven off a reference frame. These are all solving the same math problem: find a transform that moves one image's statistics toward another's.

Where they genuinely help: getting a timeline's worth of clips into the same neighborhood quickly, so the work you do by hand is correction rather than construction. That is a real saving and it is why working colorists use them at all.

Where they stop, and this is the part the tutorials skip. They work on whole frame statistics, so a clip whose framing differs from the reference will drag the match in the wrong direction: a reverse with a bright window in it will be pulled dark to compensate for something that is not the subject. They assume both clips have already been normalized, so running shot match on raw log against baked Rec.709 produces nonsense. They match global tone, not the local hue disagreements the qualifier pass exists for. And they have no idea what the shot is about, so a match that is numerically closer can be perceptually worse if it moved the face to fix the background.

The honest way to use them is as the first pass, never the last, and always after normalization. We wrote up the mechanics of that in more depth in how shot matching works in AI color grading. Matching against a still picture rather than another clip is a related but genuinely different problem, and it has its own method in how to match video to an edited still photo.

Where we fit, said plainly because it is our product: Leumos AI is a browser-based color grading studio that takes an exported edit, detects the scene cuts, and grades each shot toward a reference image rather than toward another clip. The input side is ACES based, with transforms for Canon Log, Log 2 and Log 3, S-Log2 and S-Log3, ARRI LogC, V-Log, F-Log, N-Log, Apple Log, Log3G10, BMDFilm and GoPro Protune, which is the normalization step above applied per source automatically. The reference image approach matters specifically for the mismatched camera problem, because both cameras are being pulled toward the same third thing rather than toward each other, which is what keeps a three body job from turning into pairwise whack-a-mole. It is in closed beta as of Q3 2026, so it is not available for a job you are finishing this week. It does not edit, and it is not an NLE.

If this is going to keep happening

Worth saying out loud, because it is the actual shape of the problem in most organizations: the person who has to fix the mismatch is frequently not the person who caused it, and has no authority over the shoot. Telling them to buy a chart does not help. Two things do.

Standardize the two settings that cost post the most time, which are white balance and exposure, and let everything else vary. A written note that says both cameras go to a fixed Kelvin value and a fixed tint for the day is a thirty second conversation that removes the loudest cause of drift.

And separate normalization from grading permanently in your own process, so that a mismatched delivery is a bounded problem rather than a rescue. If your machine struggles the moment you enable color on a multicam timeline, that is a separate issue with its own causes, covered in why your 4K render is taking hours and, for the working-without-Resolve case, in how to grade log footage without DaVinci Resolve.

Frequently asked questions

Can two very different cameras be matched into one look?

Usually yes for tone and overall balance, partially for saturated color, and never perfectly. Normalize both to a common space, match exposure and white balance, then use a qualifier for the specific colors that still disagree. The limit is that two sensors with different spectral responses will always disagree slightly on some hues, most visibly on skin and on strong blues and greens.

Is there any way to make Sony match Canon colors in post?

Yes, and it is the same procedure as any other pair. Apply the correct input transform per camera so neither is carrying a manufacturer rendering, pick one as the hero, match exposure on the waveform and white balance on the parade, then handle skin separately with a qualifier if it is still off. Brand specific LUT packs sold for this shortcut the middle step but do not remove it.

Why is Resolve shot match not working on my clips?

The three common causes are that the clips have not been normalized to the same space, so the tool is comparing an apple to a negative, that the two shots frame very different content, so whole frame statistics pull the match toward the background rather than the subject, or that the source clip is itself badly exposed, in which case the match is working correctly and copying a problem. Fix normalization first and re-run it.

Do both cameras need to be shooting log for this to work?

No. A camera shooting Rec.709 has a baked rendering, which means less latitude to move it, not an impossible one. Match the log camera to the Rec.709 camera rather than the other way round when the Rec.709 material has more shots, since it is the less flexible of the two and dragging it far is where highlights go plastic.

Sources

• ARRI Color FAQ, Image Science for the statement on camera gamut, the description of Rec.709 as a display specific encoding, the definition of wide gamut, and the two white balance axes (color temperature in Kelvin, and CC between green and magenta).
• ACES documentation: system overview for Input Transforms converting camera native data into ACES2065-1, and for the framework of conforming disparate inputs to one encoding before an Output Transform.
• Blackmagic Design: DaVinci Resolve color page for color management scope, ACES support, the chart based color match, shot match behavior, qualifiers keyed on hue, saturation or luminance, power windows and the tracker.
• Image Engineering technote: Rec.709 versus sRGB for the point that two standards can share primaries and white point and still differ in transfer function.