[Gdal-dev] Nodata bitmasks / null processing

[Simon Perkins]

So, would the default implementation return a universal RasterBand 
derived class that implements IReadBlock() and IWriteBlock() in terms of 
the underlying format RasterIO() method in conjunction with NODATA values?

There's a certain elegance to not duplicating a bunch of code that's 
already in RasterBand. I guess the only drawback I can see would be if 
RasterBand includes methods that don't really make any sense for 
bitmasks. However, looking down the list of methods, I can't see 
anything that's obviously out of place.

One thing though - if the GetBitmask() method is a RasterBand method, 
then presumably invoking that method on a RasterBand returned by 
GetBitmask() wouldn't make sense. Either this could just raise some kind 
of error. Or we could make GetBitmask() a method of the Dataset instead.

Sy


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