All posts
By Pravit Gandhi··8 min read

Matching log footage to baked-in LUT clips

How do you match V-Log footage to clips that already have a LUT baked in? Choose a reference, choose a direction, and know what cannot be recovered.

Decide which source is the reference before you touch a wheel, and in almost every case it should be the baked material, since it has nothing left to give. Then pick a direction. Either bring the log clips up to the baked look and build your new look on top of everything at once, or try to pull the baked clips back toward a neutral space so both sources start level. The first route is more reliable and less pretty. The second is cleaner in theory and depends entirely on whether the LUT clipped anything.

Start by naming what the bake removed

A conversion LUT is not a filter sitting on top of your footage. Panasonic describes what one does in its own LUT library: "A Conversion LUT translates the flat V-Log material to a more restricted, yet contrasty, dynamic range and shifts the color-space to match the monitor."

Restricted is the word to sit with. When that LUT was applied and the result written to a file, the tonal range was compressed into what a display can show and values outside the range the table was built for were discarded. Blackmagic says this plainly of lookup tables generally: they "clip image detail that goes outside of the numeric range they're designed to handle," which is why colorists routinely pull highlights back before a LUT to retrieve them. That pull back had to happen before the bake, and it did not.

The gamut half is just as permanent. V-Gamut is a wide capture space Panasonic positions as an archive master, converted down to P3 or BT.709 for delivery. Once a clip is converted to 709 and re-encoded, the saturated colors that lived outside 709 are not waiting in the file.

Your log clips still carry all of it. Panasonic publishes where the anchors sit in V-Log: 0% reflection at 7.3 IRE and code 128, 18% grey at 42 IRE and code 433, 90% white at 61 IRE and code 602. Those clips have room. The baked ones do not, and that asymmetry drives every decision below.

Decision one: which source is the reference

The instinct is to match toward whichever footage looks better. That is usually the wrong test.

Match toward whichever source has the least room left. The baked material cannot be pushed far without falling apart, especially if it was written to an 8-bit or heavily compressed codec. Moving the flexible source toward the rigid one costs less than the reverse.

Two situations override that. If the baked clips are a small minority of screen time and never cut directly against the log material, treat them as an exception and grade them alone. If the baked look is a strong stylised one you do not want in the finished piece, matching everything to it locks you in.

Once decided, stop revisiting it. Much of the pain in these jobs comes from switching reference partway through.

If the baked clips are the reference: bring the log up to them

Normalize the log material first, using color management or a color space transform to put it in the same display space the baked clips already live in. Do not skip this because you plan to match afterwards. Two clips can only be compared once they mean the same thing numerically, and why CST, ACES and LUTs look different covers what each method decides for you. Done properly they do mean the same thing, exactly: two log formats normalized with their own published inverses come out numerically identical.

Then match, using a still from a baked clip as the target rather than eyeballing the two in a viewer. Matching a moving clip to a fixed still is a different exercise from matching two cameras: matching video to an edited still walks through the mechanics.

The part people get wrong is the new look. If the brief calls for a look neither source has, build it above the match rather than inside it. Match every clip to the baked reference first, on its own node, then apply the creative look to the whole timeline in one layer on top. The look is then identical across both sources by construction, and the match underneath stays inspectable. Grading each clip toward an imagined final look independently produces a timeline where nothing quite matches and you cannot tell whether the fault is the match or the look.

If the log clips are the reference: pull the baked material back

This is the theoretically clean route, and it works exactly as well as the original LUT was gentle.

Run a check first. Put a waveform on the baked clips and look at the top and bottom. Flat plateaus where highlights should roll off, or a shelf where shadow detail should be, mean the LUT clipped and no reversal restores what is not there. A trace that still moves at both ends means there is something to work with.

If it passes, you need an inverse. Where the original conversion was a computed transform you have an exact one, since a color space transform is arithmetic that runs both ways: "The Swap button lets you quickly reverse the color and gamma space conversion." Where the original was a 3D LUT, you need an inverse LUT, which is a different kind of object.

Inverse LUTs cannot give everything back

An inverse LUT is a numerical approximation of running a table backwards, and it inherits two problems from the forward table.

Wherever the forward LUT clipped, many different input values mapped to the same output value. Running that backwards, the inverse has one number and no way to know which original it came from. It picks one, and it picks wrong for all but one of them. That is not an implementation flaw to shop around for; it is what the forward operation did.

Wherever the forward LUT compressed a range, the inverse stretches it back out, and it is stretching quantized values. Gradients that looked smooth in the baked file can step visibly once expanded, and the effect worsens the shallower the bit depth.

Both problems are why an inverse gets you a workable starting point rather than your negative back. Use it as one and match by eye from there. Do not treat an inverted clip as camera original, because your grading tools will behave as though it has latitude it does not. There is a practical trap too: Blackmagic notes that in an ACES project you must transform out of ACES into the space the LUT expects, apply it, then transform back, and that this "does not alway provide ideal results."

Where you stop and take the compromise

Some of these jobs are not winnable and it is cheaper to know early.

If the baked clips are clipped where the audience will look, a blown sky behind a face or skin gone flat in the highlights, no workflow recovers that. Reshoot if the shot is cheap to get again. If not, choose a look that lives below the clip point and bring the log material down to meet it, which loses range but produces a consistent piece.

The other compromise is local. A perfect global match is often unnecessary, because what a viewer notices is discontinuity across a cut. Match the pairs that actually touch, accept a wider drift between scenes that never cut together, and spend the saved hours on the shots that carry the piece. Do you have to color grade every clip is about that trade at timeline scale.

Consistency after the decision is made

Keep the normalization decision fixed for the whole project. Once you have chosen how log material enters the timeline, every clip enters that way, including the ones added in week three. Mixed normalization is how a matched timeline drifts apart, the same failure described in why your cameras don't match.

Do not reach for an automatic matcher to clean up afterwards either. Blackmagic states directly that Shot Match is not the right tool for matching normalized clips to un-normalized ones, which is exactly what a half converted timeline is. Get everything into one space first, then use the tool if you want it, with the caveats in Resolve Shot Match not working.

Leumos AI, our browser-based grading studio, fits the first route rather than the second: upload the edit, hand it a frame from the baked material as the reference, and each detected shot is graded toward that frame and rendered out. It returns finished graded files, not LUTs or project data, and cannot recover anything the bake clipped any more than a manual grade can. It is in closed beta with a waitlist at leumos.ai.

Frequently asked questions

Can you remove a LUT that is baked into a clip?

Not cleanly. The conversion compressed the tonal range and discarded values outside the range the table was built for, then the file was re-encoded without them. An inverse LUT approximates the reversal where the forward LUT did not clip, but cannot resolve values it collapsed together.

Should I match my log footage to the baked clips or the other way around?

Usually match the log footage to the baked clips, because they have the least latitude left and break first. Reverse that only when the baked material is a small minority that never cuts against your log clips, or when its look is one you do not want.

How do I build a new look when half my footage already has one baked in?

Match first, look second. Bring every clip into agreement with the reference on its own node, then put the creative look on one layer above the whole timeline. Building the look into each clip individually makes it impossible to tell whether a mismatch came from the match or the look.

Why does my inverted footage look noisy and banded?

Because the inverse stretches a compressed range back out, and the values it stretches are quantized. A gradient that was smooth at the baked contrast becomes visible steps once expanded, and shallower bit depths make it worse.

Sources