Landsat NDVI: apply the scale and offset before interpreting the number

Two calculations can use the same Landsat pixel and return very different NDVI values. One common reason is that the stored band integers have been treated as reflectance. For Landsat Collection 2 Level-2 surface reflectance, check both the multiplier and the additive offset before calculating the index.

The first question is what your download contains: stored surface-reflectance bands, values already converted to reflectance, or a ready-made NDVI product. Those three inputs need different handling. Applying a correction twice can be as misleading as skipping it.

First identify the product, then the bands

This exercise concerns Landsat 8–9 Collection 2 Level-2 surface-reflectance bands. The USGS scaling FAQ gives their conversion as the stored digital number multiplied by 0.0000275, then reduced by 0.2. The additive term is often called an offset.

For Landsat 8–9, use the near-infrared band 5 and red band 4. USGS defines NDVI as the difference between near-infrared and red reflectance divided by their sum. A colour preview or screenshot of a map is not a substitute for those numeric bands.

Read the product metadata and the service’s export documentation. If a platform has already applied the conversion, work with the resulting reflectance values. Do not apply the stored-data formula again just because the source imagery is Landsat.

One pixel, two answers

The following pixel is a synthetic arithmetic example, not a sampled field. We calculated it locally using decimal arithmetic on 2 November 2026. Let the stored red value be 10,000 and the stored near-infrared value be 18,000.

Using reflectance:
(0.295 - 0.075) / (0.295 + 0.075) = 0.594594...

Using stored integers directly:
(18000 - 10000) / (18000 + 10000) = 0.285714...

The correctly decoded inputs give NDVI of approximately 0.595; the direct integer calculation gives approximately 0.286. Both look plausible on a typical index scale. A plausible-looking output therefore does not verify the calculation.

Why does the offset matter? If the same multiplier were the only conversion, it would cancel from the numerator and denominator. An additive offset cancels from the difference but remains twice in the sum. With stored values N and R, multiplier a and offset b:

NDVI = a(N - R) / [a(N + R) + 2b]

For this product, b is not zero. That is why cancelling the conversion without inspecting it fails. This is an arithmetic check for named inputs, not a universal correction for every vegetation dataset.

A ready-made NDVI file has its own encoding

The USGS ready-made NDVI product is a different case. Its product documentation specifies a scale factor of 0.0001. A valid stored NDVI value of 6,000 consequently represents 0.6. It does not need the input bands’ −0.2 reflectance offset.

Check that you are actually reading that documented product, including its fill and saturation conventions. Do not infer an encoding from a filename alone. Preserve the original values and document every conversion, so a later reviewer can tell whether the index was calculated from bands or decoded from an existing index.

A missing pixel is not a zero-valued pixel

Scaling is only one check. Use the product’s quality information to exclude unsuitable inputs. The USGS quality-band guide explains the flags for fill, clouds, cloud shadow and snow in QA_PIXEL, and radiometric saturation in QA_RADSAT. Choose and record the exclusion rules that fit the analysis; a label saying “cloud-free” is not a reproducible mask.

Try a second synthetic exercise: three positions have NDVI values 0.2, missing, 0.6. The mean of the two valid observations is 0.4. Replacing the missing position with zero gives about 0.267 and changes the question. Report “two valid pixels out of three,” not just the average. If the reflectance sum is zero, the NDVI ratio is undefined and also needs an explicit invalid-data rule.

What the corrected value still cannot tell you

NDVI 0.6 is not “60% vegetation” or “60% healthy.” An index value alone does not identify a crop or establish plant health. Pixel mixtures, the observation date and excluded data affect what can be compared. Use the satellite-resolution guide to assess whether the feature of interest is even separated at the available scale.

Before accepting a greenness claim, ask for the product ID, date, band names, scaling state, quality mask and valid-pixel count. Record these with the calculation in an evidence report. If they are unavailable, the appropriate result is an unverified calculation, even when the map looks convincing.