All posts
By Pravit Gandhi··11 min read

Why your S-Log3 footage looks washed out

Why does S-Log3 footage look washed out? Four different problems share that symptom. Diagnose which one you have, then apply the fix that matches it.

S-Log3 looks washed out because nothing has applied a display transform to it. S-Log3 is a recording format, not a viewing format, and Sony describes S-Log as "a gamma curve that is optimized under the assumption that grading will be performed in the post-production process." That covers the common case. It does not cover all of them, and this is where most advice goes wrong: at least four separate problems produce a washed out picture, and the fix for one does nothing for the others. Work out which one you have before you touch a single control.

Which washed out problem do you actually have?

Read these four and pick the one that matches what you are seeing.

  1. The clip is flat and gray the moment it hits the timeline, before you touch anything. That is a missing log conversion.
  2. It looked correct in the editor and went washed out only after export. That is a color tagging problem, not a grading problem.
  3. It looks fine until you lift the shadows, and then it goes grainy, blotchy and green. That is underexposure.
  4. It looks right in one player and washed out in another, or fine on your Mac and pale on a phone. That is a display and tagging mismatch.

Each one gets its own section below. If two of them describe you, fix them in the order listed.

It is flat and gray in the editor

Log encoding is a redistribution of code values, not a look. The comparison that matters is against a linear encoding, where every stop up doubles the values consumed, so the single brightest stop eats half the range. Log flattens that, giving each stop a roughly similar share, which is what lets a high contrast scene fit inside an ordinary 10-bit file without clipping. In absolute terms S-Log3 still puts more code values above middle grey than below it, 603 against 325, because there are simply more stops up there. We computed that split for nine formats from the manufacturers' own published curves.

Sony's technical summary for S-Gamut3.Cine/S-Log3 gives the anchor points. A 0% black patch records at 3.5% (10-bit code value 95), an 18% gray card records at 41% (code value 420), and a 90% white card records at 61% (code value 598). Read that last one twice. A white card that would sit near the top of a normal Rec.709 picture only reaches 61% in S-Log3, because every specular hit, blown window and sky above white still has to fit in the space left over. The flatness is the compression doing its job.

Sony built S-Log3 on the Cineon digital negative revised in 2007. The curve has no shoulder and a reduced toe, which is Sony's way of saying it behaves like a pure log encoding rather than a video curve with a look baked in. The same document notes S-Log3 covers about 1.5 stops more dynamic range than S-Log2. None of that is damage. It is a container, and your editor is showing you the container.

Three routes out. A conversion LUT is the fastest, and Sony's technical summary confirms the company supplies .cube Look Profiles that convert S-Gamut3.Cine/S-Log3 into 709 color space. Your editor's color management is usually better: Premiere Pro transforms raw and log footage into a wide gamut working space based on ACEScct with tone mapping, and Final Cut Pro reads log metadata on import and applies the matching built-in camera LUT. A manual color space transform is the third option and the one worth learning if you mix cameras, because you declare input and output explicitly instead of trusting a lookup table you did not build. The differences between those routes are covered in S-Log3 to Rec.709: LUT vs color space transform.

Opinion, freely given: skip the free "S-Log3 to Rec.709" LUTs bundled into creator preset packs. Most of them are a technical conversion with somebody's creative look welded on, so you inherit their contrast and their skin bias before you have made a decision. Normalize with the manufacturer transform or your editor's color management, then grade on top.

Premiere keeps applying a LUT to my S-Log footage and I cannot turn it off

This one is worth separating because it presents backwards. Instead of flat footage, you get footage that already looks contrasty and slightly wrong, and nothing you do in the Basic Correction tab seems to be the cause.

Premiere's color management is doing it. Adobe's own overview of the feature names the two controls: a preference called Auto Detect Log Video Color Space, and a sequence setting called Auto tone map media. The first identifies the log format on import, the second applies tone mapping on the timeline. Adobe lists Sony S-Log among the formats detected automatically. When it guesses right, you get a clean starting point for free. When it guesses wrong, or when you have already applied your own conversion LUT, you get a transform stacked on a transform, and the image goes plastic in the highlights.

The fix is to decide who owns the conversion. Either let color management handle it and remove your LUT, or turn off the automatic behavior and set the clip's color space by hand in Interpret Footage. Do not run both. Worth noting for anyone working from transcoded media: automatic detection reads metadata, so log footage that has been rewrapped or transcoded to ProRes will often arrive with the metadata stripped and default to Rec.709, which puts you back in the first case above. If you find yourself fighting Lumetri more than you use it, our Premiere Lumetri alternative breakdown covers what changes when the transform lives outside the NLE.

Why does my footage look washed out after export?

This is the version that generates the longest, angriest threads, and it is not a color grading problem at all. Your grade is intact. The file is being interpreted differently by whatever plays it back.

Apple's Technical Note TN2227 explains the machinery. QuickTime files carry an nclc tag that declares three parameters: primaries, transfer function and conversion matrix. ColorSync reads that tag and, in Apple's words, "creates a color transform that provides a perceptual match between a known broadcast video color space and the specific chromaticity and gamma characteristics of your display." The transform runs on every frame during playback. So the same pixel data can look different in two apps because one of them is applying a ColorSync transform based on the tag and the other is not.

The tag itself is the thing to check. Apple states plainly that media without an nclc tag "will be color managed by QuickTime X as if it were created in the SMPTE-C color space," which is not what you graded in and not what you want. A mismatch between the tag you wrote and the transform the player applies is exactly what a washed out export is.

Check three things before you re-grade anything. Does the file look correct in a player that ignores color tags? If yes, your grade is fine and the tag is the problem. What did you actually export? DaVinci Resolve offers Rec.709-A as an output option precisely because Apple's playback path wants a different tag than a broadcast Rec.709 gamma 2.4 deliverable, so exporting the broadcast default and judging it in QuickTime compares two different things. And are you comparing like with like? Adobe's own feature request thread on the macOS gamma shift ran for years, and Adobe's answer in Premiere Pro v24 was an adjustable Viewer Gamma, which tells you how much of this is about matching viewer to deliverable rather than fixing pixels.

The habit that saves the most time: pick the destination first. A file bound for a client on a Mac, one bound for YouTube, and one bound for broadcast do not want the same tag. Concretely:

Where the file is goingWhat to export
Anywhere at allSomething tagged. Untagged is the worst case, because QuickTime treats it as SMPTE-C, which is not what you graded in.
A client who will watch in QuickTime on a MacRec.709-A if your application offers it. Resolve exposes that option precisely because Apple's playback path wants a different tag than a broadcast deliverable.
YouTube, Vimeo or the webStandard Rec.709. The platform re-encodes and reads the tag, so the safe move is the ordinary one rather than the Apple-specific variant.
Broadcast or a facilityWhatever the deliverable spec says, usually Rec.709 gamma 2.4. Ask rather than guess; a spec sheet exists for exactly this and rejections are expensive.

Then check it in two players before you send it: one that ignores tags, and the one your client will actually open. If those two disagree, the tag is doing something you did not intend, and you now know which direction to correct.

Why is my S-Log3 footage grainy when I lift it?

Because it was underexposed, and log punishes that specifically.

Look at the shape of the curve. S-Log3 has a reduced toe, and below roughly 1.1% scene reflectance the encoding is a straight line rather than a log curve. Deep shadows therefore occupy very few code values, sit close to the sensor noise floor, and turn into blotchy chroma noise the moment you raise them. Nothing recovers detail that was never separated from noise.

Sony's guidance is direct. Its Cine EI documentation says exposure index can be set within plus or minus 2 EV of base ISO and that "in general, shooting at an EI equal to or lower than the base ISO value is recommended." Rating higher than base buys highlight gradation, but Sony warns it "will increase noise and graininess, and color grading will become more difficult." The base ISO page is blunter still: shooting at the base ISO is required in log shooting in order to obtain maximum latitude.

Know your body. Sony's help guides list ISO 800 and ISO 12800 for the FX3 and FX3A, and ISO 800 and ISO 2500 for the FX30. The full set of numbers, and the zebra levels to hit, are in how to expose S-Log3 correctly. If the shoot is already over and you are matching underexposed clips against good ones, fixing shot matching on multicam and indie footage covers the salvage side.

It looks right on my Mac and washed out on my phone

Same root cause as the export case, different symptom. The nclc tag travels with the file, but not every playback path honors it the same way, and phone displays apply their own processing on top. A file that relies on a ColorSync transform to look correct will look different anywhere ColorSync is not in the loop.

The test takes two minutes. Play the same file in two apps on one machine, then on a phone. If it changes, the file is depending on the viewer to finish the job. Re-export with a tag chosen for where the video will actually be watched, and check it there rather than in your editor's viewer.

Why adding contrast is the wrong fix in all four cases

There is not much room down there. Between 0% black at code value 95 and 18% gray at code value 420, S-Log3 has 325 of its 1023 available levels, which is more than any of the other major log curves puts below middle gray and still not a lot. In 10-bit that is workable. In an 8-bit file the same span is about 81 levels, and stretching 81 levels across the shadow range of a finished image is how you get banding in a night sky, a painted wall, or the falloff behind an interview subject.

The second cost is hue. An S-curve in RGB raises saturation unevenly as luminance rises, and skin shows it first: faces go orange in the highlights, cheeks go plastic, hands and neck drift away from the face. Reducing saturation afterwards does not undo it, because the shift happened per channel. A proper transform converts log to linear and applies the display curve in a defined space, which is why the same amount of apparent contrast reads clean from a CST and dirty from a curve.

Small contrast and saturation moves after normalization are fine. They are taste. The damage comes from using contrast as the normalization.

Leumos AI, our browser-based grading studio, applies that normalization as an input transform when you upload S-Log3 material, so shots arrive already sitting in a viewable space before any look goes on top. It is in closed beta with a waitlist. The ordering matters more than the tool: normalize first, grade second. If you want the wider view of what these tools automate and what they do not, we wrote what AI color grading actually means.

Frequently asked questions

Why does my footage look washed out after export?

Almost always a color tag mismatch rather than a grading error. Apple's TN2227 describes how ColorSync reads a file's nclc tag and builds a transform to your display, and states that untagged media is treated as SMPTE-C. Play the export in a player that ignores tags: if it looks right there, your grade is fine and you need to change what you export, not what you graded.

Why is my S-Log3 footage grainy?

Underexposure. S-Log3's reduced toe leaves very few code values in the deep shadows, so lifting them amplifies noise instead of detail. Sony recommends shooting at an exposure index equal to or lower than base ISO, and warns that rating higher increases noise and makes grading harder.

Is my S-Log3 file broken if it looks gray and flat?

No. Flat and gray is what a correct S-Log3 file looks like before a display transform. Sony's reference points put 18% gray at 41% and 90% white at 61%, so a well exposed clip will look low contrast on any untransformed monitor.

Do I need a LUT to fix washed out S-Log3?

Not necessarily. A LUT is one of three routes, alongside your editor's color management and a manual color space transform. A .cube file is simply the most portable option, since it loads in any editor. What matters is that only one transform is doing the work.

Sources