[Gdal-dev] Nodata bitmasks / null processing

Peng Gao pgao at esri.com
Mon Aug 6 11:51:59 EDT 2007


> 
> 1) Pseudo-Alpha
> 
> In this approach the nodata mask is treated as a sort of 
> alpha band with values of 0 and 255.  One downside to this is 
> that alpha bands are not clearly associated with a particular 
> band, so if you wanted to have distinct nodata bitmasks for 
> each band in a dataset there would be no explicit association 
> between particular alpha bands and particular original bands.
> 
> 2) Data Promotion and NODATA pixel value creation
> 
> This is the approached used now in the GDAL GRASS driver.  A 
> nodata value outside the current valid range is created 
> within the driver, and if necessary the pixel data type is 
> promoted to a larger type to make space for this "extra 
> value" value.  For instance Byte pixel type would be promoted 
> to UInt16 so we could use 256 as our nodata value.
> 
> 3) Introduce Explicit Nodata Bitmap API
> 
> Extend the GDAL API to include an option for reading a 
> validity bitmask in the RasterIO() call - or perhaps a new 
> BitmaskIO() method paralleling the RasterIO() method.
> 
> Potentially the default implementation of this method could 
> generate a bitmask based on the raster data and nodata pixel 
> values if they are present so that applications could use 
> this one method for both models.
> 
> In one sense this is the cleanest solution, but it is also by 
> far the most disruptive.  It requires new support in 
> applications that want to take advantage of it, further 
> complicates the GDAL API and worst, it may be very hard to 
> implement properly for formats without bitmasks, but with 
> complicated resampling or blocking logic.
> 
> I am looking for some feedback from the community.  In 
> particular I'm interested in examples of file formats that 
> include bit masking.
> 

ESRI GeoDatabase Raster, both ArcSDE and FileGDB, uses NoData bitmask.
It has one mask per band (vs.
one mask for all bands). ArcGIS Raster IO is based on NoData bitmask. A
Pixel Block
contains both pixel values, and NoData bitmap.

I think Option 3 is better. Also, I think bitmask access at BlockIO
level will be very useful.

One issue is not covered is the storage of the NoData bitmap for known
formats, e.g. jpeg, bmp, and etc
that do not
support mask. Is there going to be a native GDAL bitmap support, sort of
like "PAM" file 
for NoData bitmask?

Gao, Peng






More information about the Gdal-dev mailing list