An OpenDroneMap proposal, PR #2090, gives a concrete example. A contributor reports Float32 multispectral orthophotos with zero-valued bands outside the valid footprint, but transparency indicated by an alpha band. Subsequent raster calculations can produce undefined ratios. The report also describes negative reflectance near some boundaries and implausibly large NDVI results in a DJI Mavic 3M case. The patch remains under review. Its numbers are contributor observations, not independent statistics about all Mavic 3M surveys.
The underlying engineering problem is broader than one patch: validity must travel with every pixel through export, resampling and arithmetic.
A transparent edge is still numeric data
In a multispectral orthophoto, the red and near-infrared bands are mapped to a shared grid. Locations beyond the usable source imagery may contain numeric placeholders even when a map viewer hides them with transparency. The display looks clean because the alpha channel is doing its job. A band calculator may use the placeholders anyway.
The usual normalized difference vegetation index is:
NDVI = (NIR - Red) / (NIR + Red)
If both missing bands are zero, the equation becomes zero divided by zero. If the denominator is only very small, slight positive or negative errors can produce extreme ratios. The OpenDroneMap contributor's case describes outputs far outside the range normally meaningful for an NDVI map. That evidence supports investigation of its specific processing path, not a universal claim that the sensor is defective.
According to OpenDroneMap's multispectral documentation, the orthophoto workflow can combine multiple spectral bands with alpha information. A later calculation has to respect that validity footprint, or construct an equivalent mask before dividing bands.
NoData and alpha do different jobs
NoData is usually a numeric value designated to mean missing. An alpha band or a per-band mask can identify invalid samples independently of their value. A dataset can contain zero in a band without declaring zero as NoData. Software must then decide whether to consult its mask.
Rasterio's raster-mask documentation describes valid-data masks in which zero means invalid and nonzero means valid. NumPy masked arrays use the opposite Boolean meaning: a true mask flag identifies values to exclude. An inverted mask is easy to write and hard to spot in a plot that already has an irregular edge.
Zero is not always missing. A genuine zero-valued reflectance reading may exist in a dataset, and a blanket NoData=0 rule can obscure it. The submitted OpenDroneMap patch proposes NoData=0 for the particular Float32 reflectance products it addresses. That may resolve the reported border failure but is not a universal representation for every raster.
GeoTIFF adds another constraint. The GDAL driver documentation describes a shared NoData value across GeoTIFF bands. Assigning a sentinel independently to red, NIR and alpha is therefore not generally equivalent to preserving separate validity information. In the reported workflow, the PR author observed problems when a -9999 NoData sentinel interacted with the alpha channel during warping. That is a workflow-specific finding, not a rule that -9999 cannot be used safely elsewhere.
For a two-band vegetation index, the usable region normally requires valid data in both bands. A mask retained from only one input can still include gaps in the other.
Reflectance and thermal temperature need different rules
Another part of the proposed change clamps negative reflectance values. Calibrated reflectance below zero is physically suspect, and tiny negative values in the denominator can distort the index. But clamping all Float32 bands to zero would damage temperature products.
Long-wave infrared images may report Celsius temperatures below zero. Such temperatures are valid measurements. The OpenDroneMap PR explicitly distinguishes reflectance bands from thermal outputs when proposing its bounds.
Even for reflectance, clamping has a diagnostic cost. If -0.002 becomes zero, an edge artifact may disappear from the result without explaining whether calibration, interpolation or band registration caused it. A careful test should count negative pixels and examine where they occur before changing their values. Negative samples restricted to the border tell a different story from a large patch over well-observed crop rows.
The calibration stage matters too. A raw digital number is not a calibrated reflectance estimate. OpenDroneMap's radiometric-calibration documentation differentiates processing modes. A workflow should record the selected mode and what its downstream bands represent before interpreting the resulting index.
Five checks before trusting the index
A compact validation sequence is more informative than a screenshot of the finished vegetation map:
- Inspect metadata. Record data types, band meanings, declared NoData values, alpha interpretation and external or internal mask presence. A transparent preview is insufficient.
- Compare validity masks. Read the alpha band and dataset or per-band masks. The GDAL valid-data-mask interface explains the relationship between alpha, NoData and mask flags.
- Count suspect pixels. Within the valid footprint, inspect negative reflectance, zeros, nonfinite values and red-plus-NIR sums near zero. Keep locations, not only a global minimum and maximum.
- Calculate under an explicit mask. Require valid red and NIR values and a documented rule for nearly zero denominators. Mask undefined output instead of inventing an index.
- Reopen the exported file. Confirm that the validity mask, band values and extrema still agree after writing and reopening in a separate reader.
The denominator threshold depends on whether inputs are digital counts, normalized reflectance or another calibrated quantity. An arbitrary fixed epsilon cannot cover all representations.
Test a strip just inside the apparent valid boundary as well as the transparent exterior. Resampling and imperfect alignment can produce bad ratios within an apparently opaque pixel. Where a hotspot appears at an image seam, inspect source bands before attributing it to vegetation.
What would establish a real fix
If PR #2090 is merged, it could define clearer missing-data behavior for the affected OpenDroneMap output path. It would not independently establish accurate radiometric calibration or consistent mask handling across GIS viewers and analysis scripts. The linked community report documents a practitioner problem; it is not a multi-camera benchmark.
A useful regression set would check that invalid border pixels remain invalid after resampling, that legitimate zeros are treated consistently, that reflectance-specific constraints do not alter below-zero thermal temperatures and that a derived NDVI raster retains its mask when exported.
A pixel can hold a number without being an observation. When the workflow loses that distinction, the map can look right while the arithmetic is wrong.