[Gdal-dev] Nodata bitmasks / null processing

[Howard Butler]

Frank,

I prefer Option 4, which is to treat bitmasks as just another  
RasterBand for each "data" RasterBand.  Something like

bitmask = GetBand(1).GetBitmask()

Why I like this approach:
  - Familiarity to mentally challenged raster coders like myself.  I  
know how to work with a RasterBand.  I can make the mental leap to  
the bitmasks being a RasterBand with just on/off booleans.
- Support for other language bindings with this approach is simple.
- It would limit API additions.
- Would it lessen some of the downsides of Option 3 (BitmaskIO)?

I'll let others chime in on the downsides...

Howard

On Aug 4, 2007, at 12:06 PM, Frank Warmerdam wrote:

> 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
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev