All posts
By Pravit Gandhi··9 min read

Premiere is applying a LUT to my log footage

Premiere is applying a LUT to my log footage and I can't turn it off. Find which setting is doing it, then decide who owns the conversion.

No LUT has been applied to your file. Premiere Pro read the log format out of your clip's metadata on import and ran its own conversion, and two separate settings can be responsible. Neither of them lives in Lumetri, which is why deleting the Lumetri effect changes nothing and the Creative tab shows no LUT loaded. The file on your drive is untouched.

So the fix is not a hidden checkbox. It is a decision about which single piece of software owns the log to Rec.709 conversion, followed by removing every other transform in the chain.

First, confirm it is color management and not you

Drop the same clip into a new project with a fresh sequence and add nothing to it.

If it still arrives contrasty and roughly viewable, color management is doing the conversion. If it arrives flat and gray there but contrasty in your working project, the transform is something you or a collaborator added: a LUT in the Creative or Basic Correction tab, an adjustment layer, an ingest preset, or a master clip effect. Master clip effects are the ones people miss, because they follow the clip and never appear on the timeline instance.

Everything below assumes the first outcome.

The two settings, and what each one does

Adobe's own overview of the feature names both controls: a preference called Auto Detect Log Video Color Space, and a sequence setting called Auto tone map media.

The preference is the identifier. On import it reads clip metadata, decides which log format it is looking at, and tags the clip. The sequence setting is the transformer. It takes whatever the clip is tagged as and tone maps it into the sequence's color space.

That difference matters when you go hunting. Turning off Auto tone map media stops the conversion on that sequence only. Turning off Auto Detect Log Video Color Space stops future imports being identified and does nothing to media already in the project, because those clips were tagged when they came in. People flip the preference, see no change, and conclude it is broken. It already ran.

Adobe lists Sony S-Log, Panasonic V-Log, Canon Log and iPhone HLG among the formats detected automatically, alongside other HLG and PQ material.

Decide who owns the conversion, then take everything else out

There are two correct configurations and both are stable.

Let color management own it: leave detection and tone mapping on, delete every conversion LUT you applied by hand, and grade on top of what arrives. This is the low friction option and the right default for a single camera job.

Or own it yourself: turn off Auto tone map media for the sequence, set the clip's color space explicitly, and apply your own transform, whether a manufacturer LUT or a color space transform effect. More clicks, and an identical result on every machine that opens the project.

What people arrive with is neither. It is a transform stacked on a transform: color management normalizes the log, then your LUT normalizes the already normalized picture. The signature is highlights that go flat and plastic while the shadows crush, and skin that turns waxy in the bright half of the face.

Overriding a single clip by hand

When detection guesses wrong for one camera in a mixed bin, you do not need to disable the feature globally. Select the offending clips in the project panel and use the Modify or Interpret Footage dialog, where the color management options live. Override the media color space from the drop down list and set it to what the clip actually is. Adobe's guidance is to select all the undetected clips and override them in one pass, which matters on a job with hundreds of files from one body.

The same complaint arrives from every camera brand

It reads as a Sony problem because the Sony threads are the biggest. It is not.

The highest engagement thread in this space is an FX6 owner reporting S-Log3 that, in their words, has the appearance of a LUT already having been applied. A Canon C70 owner found C-Log3 washed out from Premiere 24.4.1 onward and reported that rolling back to 2024 was the only thing that worked, with 24.3 and older fine. A Panasonic user found V-Log needed a Rec.2100 PQ sequence while DJI footage imported flat regardless, and an Adobe product manager replied in that thread that auto detect does not currently support DJI log. And there is a Nikon report of Premiere auto converting N-Log to Rec.709 against the user's wishes.

Four brands, one mechanism. Something read the file, decided what it was, and acted. Our S-Log3 washed out guide covers the Sony flavour in brief; this is the cross camera version.

Where each format expects the middle of your image to sit

This is what explains why a wrong guess produces a specific, repeatable error rather than random ugliness.

Panasonic publishes a full table. In its V-Log and V-Gamut reference manual, 0 percent reflection records at 7.3 IRE and 10-bit code 128, an 18 percent gray card at 42 IRE and code 433, and a 90 percent white card at 61 IRE and code 602.

Canon publishes its black point. Canon's white paper on its log gamma curves states that Canon Log uses Code 128 in 10 bits for 0 percent black, while Canon Log 2 uses Code 95 and is built on the Cineon digital negative. Canon Log reaches 800 percent dynamic range, and Canon Log 3 extends that to 1600 percent.

Nikon publishes a single anchor. Its Professional Services guidance for filming N-Log says that with a waveform display you can film an 18 percent gray chart and expose for a video signal level of 35 percent IRE, equivalent to a 10-bit code value of around 372.

Middle gray sits at 42 IRE in V-Log and 35 IRE in N-Log. Black sits at code 128 in Canon Log and code 95 in Canon Log 2. Those anchors are far enough apart that the formats are only comparable once all nine curves are read off one 10-bit ruler. If your editor identifies one of these as another, the result is not an offset you can dial back out. The error varies across the whole range and varies fastest in the shadows, which is why the picture looks almost graded and stubbornly wrong at the same time. The size of that error has been computed: decoding one log format with a different format's inverse costs 0.853 stops at middle gray on the median pairing, against roughly 0.04 stops when the tag is right. A corrective curve on top only papers over it. S-Log3 to Rec.709 conversion works through what the transform is actually doing.

Transcoded and rewrapped files lose the thing Premiere reads

Detection reads file metadata, not the picture. Adobe's own discussion of the feature is explicit that transcoded media, such as Canon Log converted to ProRes, loses log format recognition because the original metadata is not preserved, and that Premiere relies on header data rather than analysing the image. When detection cannot happen, Rec.709 is the default the media falls back to.

That flips the symptom. Camera originals arrive too contrasty because a transform ran. Your ProRes transcodes of the same material arrive flat and gray because none did. Same shoot, opposite complaints, one cause.

Range handling compounds it. Canon's white paper documents that for ProRes files, in accordance with QuickTime specifications, the log curve is changed automatically to full range or video range depending on the readout path, with YUV readout converting to video range and RGB readout to full range. Canon recommends RGB readout for all ProRes formats so log data is treated as full range. That is why a rewrap can shift your black level even when nothing else changed.

If you work with transcoded log, set the color space in Modify or Interpret Footage at ingest and stop expecting detection to save you.

When a version update changes the behavior under you

The most demoralizing version of this is the one where nothing in your project changed and the picture did.

That is real. Adobe rebuilt the feature: its September 2024 announcement describes an entirely new color management system that transforms raw and log formats from nearly every camera on import without requiring LUTs, and moves the working space from HD Rec.709 to a wide gamut space based on the industry standard ACEScct. The same post notes support was added for more Canon, Sony and RED cameras, and the old Auto Detect Log Video Color Space setting was renamed as part of that work.

Two consequences follow. A camera not detected in one release can start being detected in the next, turning a project that looked correct into one with a doubled transform. And a setting you remember by name may no longer carry it, which is why so much advice points at a checkbox that has moved.

The defensive habit is small: when you update, open an old project and check one log clip against a known reference frame before you trust anything. If the picture moved, the transform moved. Fix the ownership decision rather than re-grading around it. Why your cameras don't match picks up what happens once everything is normalized.

Leumos AI, our browser-based grading studio, takes the ownership question off the table: you upload an edit, the input transform comes from an ACES based set covering Canon Log, S-Log3, ARRI LogC, V-Log, N-Log and the rest, and there is only one place the conversion can happen. It is in closed beta with a waitlist at leumos.ai. If you would rather stay in Premiere, our Lumetri alternative breakdown covers what changes when the transform lives outside the NLE, and how to grade N-Log footage walks through the Nikon side.

Frequently asked questions

Why is Premiere automatically applying a LUT to my S-Log footage and I can't fix it?

No LUT is applied. Premiere's color management detected the log format from your clip's metadata and tone mapped it. Two settings control that: the Auto Detect Log Video Color Space preference, which tags clips on import, and the Auto tone map media sequence setting, which does the transform. Turning off the preference will not change clips already imported.

My S-Log3 footage is coming in with a LUT applied and I am unable to change or remove it

Test it in a new empty project first. If it still looks converted, disable Auto tone map media in Sequence Settings, or override the clip's color space through Modify or Interpret Footage. If it looks flat there, the transform is a master clip effect or an ingest preset in your original project.

Why did my C-Log3 footage change appearance after a Premiere update?

Adobe replaced its color management system, moved the working space to one based on ACEScct, and added detection support for more cameras. One Canon C70 owner pinned the change to a boundary: Premiere 24.3 and older were fine, 24.4.1 onward were not. Check one clip against a reference frame after any update and remove whichever transform is now redundant.

Why does my ProRes transcode look flat when the camera original did not?

Detection reads metadata, not pixels. Transcoding or rewrapping usually drops the log identification, and Premiere then treats the file as Rec.709, so no conversion runs. Set the color space by hand through Modify or Interpret Footage at ingest for any transcoded log material.

Sources