[Gdal-dev] Nodata bitmasks / null processing

[Frank Warmerdam]

Folks,

Currently GDAL supports two mechanisms for identifying nodata/transparent
areas in a raster.  One is use of a particular pixel value as a nodata
value (returned by the GDALRasterBand::GetNodataValue() method) and the other
is by specifying an alpha band with alpha=0 marking transparent areas.

However, a number of file formats support a concept of "nodata masks" -
essentially bitmasks marking areas of the raster that are nodata areas.  But
this is accomplished without having to reserve a special marker value to be
the nodata value.

This is the case with GRASS for instance, and the GDAL GRASS driver actually
jumps through hoops to promote byte data to int16 and overlay a nodata value.
However, this is cumbersome and violates the underlying data model of the
format.

This issue also arises with other formats, including a new JPEG variation
with a nodata bitmask appended to the file.  I also feel that nodata masks
can offer a better

A client has requested support for nodata bitmasking be incorporated into
GDAL in some appropriate fashion.  I can see a few approaches:

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.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org