All posts
By Pravit Gandhi··9 min read

Why banding appears after grading and export

Why does my export have banding? It is quantisation becoming visible. Here is how many code values each log format actually has to spend down there.

Banding is quantisation becoming visible. A gradient in the real world is continuous; a file stores it as a finite ladder of numbers, and when a grade stretches part of that ladder far enough apart, the rungs stop being invisible and start being stripes. So the useful question is not "what causes banding" but "how many rungs were in the region you stretched." That is answerable. We computed how every major log curve distributes 10-bit code values across scene exposure, validating each implementation against the manufacturer's published anchors first, and the answer for the deep shadows is smaller than most people expect.

How many values are actually down there

Take the whole shadow budget first: the code values a curve spends between zero light and an 18 percent grey card, on a 10-bit full-range scale. Sony S-Log3 spends 325 of its 1023. Panasonic V-Log and ARRI LogC3 at EI 800 both spend 305. Nikon N-Log spends 245, RED Log3G10 247, Canon Log 3 223, and ARRI LogC4 just 190. Express the same curves on an 8-bit scale, the same ladder with three quarters of the rungs removed, and S-Log3's shadow budget becomes about 81 values, V-Log and LogC3 about 76, Canon Log 3 about 56, LogC4 about 48. That is every distinct step available to describe black through middle grey.

The per-stop figures make it concrete, because a grade does not stretch the shadow range evenly. In 10 bits, the stop of scene light running from six stops under middle grey to five stops under consumes 19 code values in S-Log3, 16 in V-Log, 15 in LogC3, 14 in Log3G10, 12 in N-Log, 8 in LogC4 and 6 in Canon Log 3. In 8 bits those same stops are between about one and a half and five code values. One stop of scene light, under five numbers to describe it.

Once the same curves reach their straight-line region the slope settles between roughly 66 and 113 code values per stop in 10 bits, so between about 17 and 28 in 8 bits. The mid-range is described five to ten times more finely than the region you are trying to open up. The full ladder is published with the method, and you can read any curve at any exposure with the code value reference.

Stretching a region that has almost nothing in it

Those numbers are the mechanism. Normalizing log to a viewable image is, among other things, an expansion of the shadow region: values packed into a narrow band get spread across a much wider share of the display's range, so every step in the source becomes a wider step in the output. At 19 code values per stop that is survivable, because the steps stay narrow enough to hide under whatever texture the shot has. At four or five, there is nothing to interpolate through, and the expansion turns each recorded value into a visible plateau. Plateaus in a smooth region are what a band is.

That is why banding appears in specific subjects and almost never in others. It needs a large, smooth, slowly varying area: a clear sky, a painted wall, a cyclorama, the falloff behind an interview subject. Blackmagic names the same subjects, calling it a property of "low bit-depth media that has areas with shallow gradients of color, such as a sky or a wall," which then "exhibit color banding, seen as visible stripes, because there aren't enough color values to smoothly represent the gradiation from light blue to darker blue in the sky." A textured surface breaks the plateaus up on its own, which is the shot hiding the problem rather than not having it.

Where 8-bit runs out and 10-bit has room

The distinction is not "8-bit bad, 10-bit good." It is that 8-bit source material has banding baked in that cannot be removed, whereas a 10-bit source usually still has headroom you have not spent.

Blackmagic puts the first half plainly: "if you try to perform any significant gamma or color correction on 8-bit images, you can often see more visible banding," and on the tempting workaround, "although you can select 16-bit integer processing for an 8-bit clip, it does not reduce banding that already exists in the original file." Higher-precision processing stops you adding more. It does not restore what the camera never wrote.

One subtraction people forget: a camera offering a data level choice is not always giving you the full ladder. Fujifilm's X-H2 manual gives both: video range limits 8-bit movies to 16 through 235 and 10-bit movies to 64 through 940, while full range gives 0 through 255 and 0 through 1023. Shoot 8-bit video range and the picture has 220 levels before your first correction lands.

The grade moves that make it visible

Three moves do most of the damage, all by applying a lot of expansion to a small range.

Heavy contrast curves are the obvious one. A steep S-curve does not add contrast uniformly; it takes the region around its steepest section and spreads it much further than the rest, so whatever plateaus exist there get multiplied hardest. Building the whole normalization out of a curve makes it worse, for reasons in why S-Log3 footage looks washed out.

Extreme saturation pushes are the less obvious one. Raising saturation expands the distance between the channels at every pixel, so a gradient that was smooth in each channel individually can develop steps in the difference between them. Skies suffer first, being a slow gradient in all three channels at once.

The third is stacking. Each correction rounds, and as the manual notes, "the more operations that are applied to an image, the more color precision is lost to rounding when using 8- or 16-bit integer processing." Four moderate nodes can produce banding none of them would produce alone. When the shadows go speckled rather than stepped the diagnosis is different, and it is in why log footage gets noisy when you grade it.

The export codec is usually not the culprit

Many of these threads start with banding in a ProRes export, and the codec is frequently blamed for something it did not do. Apple's ProRes white paper states that ProRes 4444 and ProRes 4444 XQ each support "up to 12 bits per image channel," and that ProRes 422 HQ "supports full-width, 4:2:2 video sources at 10-bit pixel depths." A 12-bit container has four times the ladder of a 10-bit one and sixteen times that of an 8-bit one. If you graded a 10-bit or 12-bit source, exported ProRes 4444, and there are bands in the sky, the bands were in the graded image before the encoder saw them, or they are arriving after the file.

Codec choice does matter at the other end. Fujifilm's manual documents that H.264 records at 8 bits with 4:2:0 subsampling, while H.265 records at 10 bits. Delivering a graded gradient into an 8-bit distribution codec, at a bit rate chosen for a platform rather than for your sky, genuinely introduces banding that was not in your master. The fix for that is at the encode.

Banding you did not create

Two sources have nothing to do with your file, and both should be ruled out first.

The first is the display path. Resolve's manual is explicit that monitoring in 10-bit is "preferable to avoid the appearance of banding that may not in fact be in the image data being processed by DaVinci Resolve," and that monitoring at 8-bit "improves real time performance, at the expense of possibly introducing banding to the monitored image." An 8-bit viewer previewing a 12-bit file can show you stripes that exist nowhere in your project, so check the same file on a second display first. The wider version of that check is in why does my grade look off.

The second is interpolation inside your own processing. Resolve offers two methods for evaluating values falling between a 3D LUT's sample points, and notes that tetrahedral "results in higher image quality LUT and DCTL processing, with reduced color-banding" against the trilinear default. If banding appeared when you added a conversion LUT and not before, check that before blaming the source. See also why CST, ACES and LUTs look different.

What actually helps

Dithering is the real repair, in a particular sense: it adds no information, it hides the absence of information by making the boundary between two plateaus irregular instead of straight. Fusion's Change Depth node exposes it directly, and the manual gives the use case: "when down converting from a higher bit depth, it can be useful to add Error Diffusion or Additive Noise to camouflage artifacts that result from problematic (high-contrast) areas."

Resolve's Deband filter does the same thing selectively, isolating "the edges of color banding" and minimizing them "by dithering pixels from either side to soften the transition." The attached warning is worth heeding: it "works best when applied to regions of the image that have been isolated with a secondary qualifier or window, otherwise you risk all edges within your image being dithered and thus softened." Applied to a windowed sky it is close to invisible. Grain works on the same principle and is often better on a shot that will carry it.

Everything else is prevention: shoot 10-bit where the camera offers it, keep normalization in a defined transform, and make fewer and larger moves.

Leumos AI, our browser-based grading studio, works in the direction this argument points: uploads get an ACES-based input transform and come back as a rendered 4K ProRes or H.265 file, so the number of separate integer round trips between source and deliverable stays small. It is in closed beta with a waitlist at leumos.ai.

Frequently asked questions

Why does my ProRes export have banding when the source was clean?

Usually it does not, and the bands are either already in the graded image or being added by the display path. Apple's white paper puts ProRes 4444 at up to 12 bits per image channel and ProRes 422 HQ at 10-bit, so the container is rarely the constraint. Check the same file on a second display before re-grading.

Can banding in 8-bit footage be fixed?

Not recovered, only concealed. Blackmagic states that selecting 16-bit integer processing for an 8-bit clip does not reduce banding that already exists in the original file. Higher-precision processing stops you adding more; it cannot restore code values the camera never wrote.

How many code values does log leave in the shadows?

On a 10-bit full-range scale, between zero light and an 18 percent grey card, our computation from the published curves gives 325 for Sony S-Log3, 305 for Panasonic V-Log and ARRI LogC3 at EI 800, 247 for RED Log3G10, 245 for Nikon N-Log, 223 for Canon Log 3 and 190 for ARRI LogC4. In 8 bits, divide each by four.

Does adding grain really fix banding?

It conceals it, which for a finished deliverable is usually what you want. Both of Blackmagic's dithering tools work this way, and neither adds back detail: Fusion's Change Depth node offers error diffusion or additive noise when down converting, and the Deband filter softens band edges by dithering pixels from either side.

Sources