[gdal-dev] Geotiff nodata handling

[Even Rouault]

Le mercredi 18 juin 2014 18:35:49, Andrea Aime a écrit :
> Hi,
> I'm trying to wrap my head around how gdal handles nodata values.
> In an image with this gdalinfo exceprt:
> 
> Band 1 Block=512x512 Type=Byte, ColorInterp=Red
>   NoData Value=0
> Band 2 Block=512x512 Type=Byte, ColorInterp=Green
>   NoData Value=0
> Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
>   NoData Value=0
> 
> and using software based on gdal (e.g. qgis), it seems that a pixel is
> considered
> nodata if any of the three pixel bands are zero (even just one).
> 
> I could swear I saw some gdal specific way to embed metadata
> saying "if all three bands are zero, then the pixel is nodata"
> (pull pixel as opposed band per band treatment), but I cannot
> find it anymore.
> 
> Did I imagine it? If existing, do you have a feeling of how well
> supported that is in common software?

This is a rather tricky area indeed.

A few facts :
- The concept of nodata value in GDAL is something per band, which leave 
multi-band processing of nodata values subject to interpretation.
- The TIFFTAG_GDAL_NODATA extension tag in TIFF only holds one nodata value 
for all bands.
- In gdalwarp utility, the warping option UNIFIED_SRC_NODATA is set to YES, 
which means that a pixel is considered to be transparent if all bands hit 
their respective nodata value (what you want here).
- In gdaladdo, similar behaviour will be found if the dataset has a 
NODATA_VALUES metadata item set to "0 0 0" for example, which makes an 
implicit mask band of type GDALNoDataValuesMaskBand to be generated and 
honoured. This metadata item is only set by the PNG driver for now. With VRT, 
the metadata item could be also set for other datasets.

I guess QGIS only look band per band. A reliable way of solving this would be 
to generate a RGBA dataset instead.

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html