Opened 16 years ago
Closed 6 years ago
#2083 closed defect (fixed)
gtiff driver not respecting separate nodata for each band
Reported by: | maphew | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | unspecified |
Severity: | normal | Keywords: | gtiff |
Cc: | dron, Even Rouault, Mateusz Łoskot, Kyle Shannon |
Description
The geotiff format driver assigns all bands the same nodata value, even if only a single band was specified with bandN.SetNoDataValue
Also see http://www.nabble.com/python%3A-setting-nodata-affects-all-bands-td14303097.html
----- gdalsetnull.py ----- import gdal import sys import os.path if len(sys.argv) < 2: print "Usage: gdalsetnull.py raster_file null_value" sys.exit(1) input = sys.argv[1] null_value = sys.argv[2] dataset = gdal.Open( input, gdal.GA_Update ) if dataset is None: print 'Unable to open', input, 'for writing' sys.exit(1) b1 = dataset.GetRasterBand(1) b2 = dataset.GetRasterBand(2) b3 = dataset.GetRasterBand(3) print 'Initial nodata:\t', b1.GetNoDataValue(), b2.GetNoDataValue(), b3.GetNoDataValue() b1.SetNoDataValue( float(null_value) ) print 'Output nodata:\t', b1.GetNoDataValue(), b2.GetNoDataValue(), b3.GetNoDataValue() ---------------------------
Results:
python gdalsetnull.py nodata-test.tif 0 Initial nodata: 46.0 46.0 46.0 Output nodata: 0.0 0.0 0.0
Attachments (1)
Change History (11)
by , 16 years ago
Attachment: | nodata-test.tif added |
---|
comment:1 by , 16 years ago
Cc: | added |
---|
comment:2 by , 16 years ago
-2 means that there's a value for each band, right ? But how do you handle the case where a band has a nodata value, and another one none. Should we decide that a particular value of a double (a NaN for example) means that there's no nodata value for the band ?
comment:3 by , 16 years ago
Cc: | added |
---|
comment:4 by , 16 years ago
Keywords: | gtiff added |
---|---|
Milestone: | → 1.6.0 |
I would prefer to not try and address this issue before the 1.5 release. It will require changes to the "GDAL nodata tag specification" and I'd rather not do that without due consideration of alternatives and whether the issue is critical enough to justify the disruption.
comment:5 by , 16 years ago
Cc: | added |
---|
comment:6 by , 15 years ago
Milestone: | 1.6.1 → 1.7.0 |
---|
comment:7 by , 15 years ago
Cc: | added |
---|
comment:8 by , 9 years ago
Heads-up: still a valid ticket in 2014 and GDAL 1.11
"GDAL stores band nodata value in the non standard TIFFTAG_GDAL_NODATA ASCII tag (code 42113) for files created with the default profile GDALGeoTIFF. Note that all bands must use the same nodata value. When BASELINE or GeoTIFF profile are used, the nodata value is stored into a PAM .aux.xml file."
I think it is a good cause to change the way how NODATA handled in TIFFs. We should switch from ASCII representation of the NODATA value to binary one, because ASCII serialization of the floating point values is always error-prone (and actually not necessary).
The new tag definition could look like this: