[Gdal-dev] Re: Nodata bitmasks / null processing

[Tim Keitt]

Frank Warmerdam <warmerdam <at> pobox.com> writes:

> 1) Pseudo-Alpha
> 

I assume alpha bands are sometimes used to represent alpha values,
so this seems to mix concepts in the same interface.

> 
> 2) Data Promotion and NODATA pixel value creation
> 

This is my least favorite. This logic should not occur hidden
in the driver layer. If the client needs to specify a nodata value,
it should be responsible for choosing a suitable storage depth to
include a flag value. (I see it does make sense if you need to
_read_ a masked data layer and have no means within GDAL to
represent the mask.)

> 
> 3) Introduce Explicit Nodata Bitmap API
> 

Why not reuse the current raster band API?

flag_t hasMask(this_band)
success_t setMask(this_band, mask_band)
band_t getMask(this_band)

The latter returns a raster band with zero indicating no data.
How the driver stores the mask is its concern (bit packed, etc.).

I would require that a band with a mask must not have a nodata
value (make them orthogonal).

Drivers for formats that do not support explicit masks could
either not allow setting the nodata mask or write the mask
as an ordinary band and use metadata to connect the two.

THK