Changes between Version 5 and Version 6 of rfc15_nodatabitmask
- Timestamp:
- Aug 21, 2007, 7:51:52 AM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
rfc15_nodatabitmask
v5 v6 7 7 == Summary == 8 8 9 Some file formats support a concept of a bitmask to identify pixels that are not valid data. This can be particularly valuable with byte image formats where a nodata pixel value can not be used because all pixel values have a valid meaning. This RFC tries to formalize a way of recognising and accessing such n odata bitmasks through the GDAL API.9 Some file formats support a concept of a bitmask to identify pixels that are not valid data. This can be particularly valuable with byte image formats where a nodata pixel value can not be used because all pixel values have a valid meaning. This RFC tries to formalize a way of recognising and accessing such null masks through the GDAL API. 10 10 11 The basic approach is to treat such masks as raster bands, but not regular raster bands on the datasource. Instead they are freestanding raster bands in a manner similar to the overview raster band objects. The nodata masks are represented as GDT_Byte bands with a value of zero indicating nodata and 255 indicating valid data. Intermediate values do not normally occur but in they future they might be interpreted as a confidence value or alpha transparency values.11 The basic approach is to treat such masks as raster bands, but not regular raster bands on the datasource. Instead they are freestanding raster bands in a manner similar to the overview raster band objects. The nodata masks are represented as GDT_Byte bands with a value of zero indicating nodata and non-zero values indicating valid data. Normally the value 255 will be used for valid data pixels. 12 12 13 13 == API == … … 32 32 == Default Implementation == 33 33 34 The GDALRasterBand class will include a default implementation of !GetNullMask() that returns one of two default implementations. The first default implement is a GNMF_ALL_VALID band that returns all 255. The second default implementation would return a mask computed by reading the imagery data and comparing it to the nodata value. The nodata based one would be used when the base band has a nodata value set. 34 The GDALRasterBand class will include a default implementation of !GetNullMask() that returns one of three default implementations. 35 36 * If the band has a nodata value set, an instance of the new GDALNodataMaskRasterBand class will be returned. GetNullMaskFlags() will return zero (no flags set). 37 * If there is no nodata value, but the dataset has an alpha band that seems to apply to this band (specific rules yet to be determined) and that is of type GDT_Byte then that alpha band will be returned, and the flags GNMF_PER_DATASET and GNMF_ALPHA will be returned in the flags. 38 * If neither of the above apply, an instance of the new GDALAllValidRasterBand class will be returned that has 255 values for all pixels. The null flags will return GNMF_ALL_VALID. 39 40 == Alpha Bands == 41 42 When a dataset has a normal GDT_Byte alpha (transparency) band that applies, it should be returned as the null mask, but the !GetNullMaskFlags() method should include GNMF_ALPHA. For processing purposes any value other than 0 should be treated as valid data, though some algorithms will treat values between 1 and 254 as partially transparent. 35 43 36 44 == Drivers Updated == … … 44 52 * HDF4 Driver: This driver might possibly be updated to return real mask if we can figure out a way. 45 53 * SDE Driver: This driver might be updated if Howard has sufficient time and enthusiasm. 54 55 == Utilities == 56 57 The gdalwarp utility and the gdal warper algorithm will be updated to use null masks on input. The warper algorithm already uses essentially this model internally. For now gdalwarp output (nodata or alpha band) will remain unchanged, though at some point in the future support may be added for explicitly generating null masks, but for most purposes producing an alpha band is producing a null mask. 46 58 47 59 == Implementation Plan == … … 57 69 == Issues == 58 70 59 I'm tempted to change !GetNullMaskType() into !GetNullMaskFlags() and have the result be an or-ed set of flags. It would allow us to differentiate mask bands auto generated from nodata, and add special interpretations in the future, like is-alpha or is-confidence.60 61 71 * I haven't filled in how creation of masks works. 62 72 * I haven't talked about bitmask-via-spill file possibilities for the PAM subsystem.
