[gdal-dev] gdalwarper destination alpha mask

[Even Rouault]

> It turns out that the change you made for treating the alpha band
> separately
> (https://github.com/OSGeo/gdal/commit/b427cb23ff1bc2a5ba2f6634fc3bd90816bb77
> 89) fixed one other problem that you might have intended to fix, but has
> caused another.
> 
> I have a general question - the new code assumes that the alpha band
> will always be the last one in the dataset.  Is that guaranteed by some
> standard?  In the previous code, the alpha band could have been band 1,
> and the band number was recorded for later use.

That's an informal convention used in GDAL, and in particularly by the 
gdalwarp utility and the warping kernel itself. If the alpha band is not the 
last one, it would be reprojected as any other band. In fact, the warping 
kernel does not reproject the source alpha band (when it is the last one): it 
uses it as a mask for the other bands. And it updates the destination alpha 
band with the pixel "density" of the reprojected pixels.
The intent of the changes done in GDALReprojectImage() is that it behaves like 
GDALWarp() as much as possible. It seems GDALReprojectImage() didn't initially 
take into accout the specificities of alpha at all, and that a later attempt 
at doing so was broken.

> 
> After I changed the WorldWind code to initialize the target alpha band
> to 0, which fixed my immediate problem, I discovered that if the source
> dataset has no alpha band, that the alpha band of the result has all
> zeros.  That doesn't happen with your change - it doesn't matter what's
> in the target alpha band initially if there is no alpha band in the
> source - after reprojectImage, the alpha band of the result has all 255
> regardless of the values initially in the target dataset.

Depends. If the reprojection doesn't cause geometry changes, then yes, this 
will be 255. Otherwise you'll get 0 in the areas that don't have a 
corresponding source pixel.

> 
> Perhaps that's the problem you intended to fix.
> 
> The new problem in the WorldWind code is that 'reprojectImage' was used
> to clip the source dataset to a 'region-of-interest' (ROI).  That's
> probably an improper use of reprojectImage.  If you refer to this code:
> 
> https://github.com/WorldWindEarth/WorldWindJava/blob/develop/src/gov/nasa/wo
> rldwind/data/GDALDataRaster.java
> 
> in createMaskDataset at line 466, it's creating a dataset with a single
> alpha band for the ROI.  When the mask dataset is used at line 1135 in a
> reprojectImage call, GDAL correctly reports a warning:
> 
>      GDAL error 5 : GDALWarpOptions.Validate(): nBandCount=0, no bands
> configured!
> 
> The intent was to generate a dataset with alpha=0 outside of the ROI. 
> In the call to GDALUtils.composeDataRaster at line 1154, the alpha band
> is retrieved from the mask data set, and eventually used in
> 'GDALUtils.applyImageMask()' to clip the image.

I believe you should proceed differently. Create a composite image *before* 
reproject with the source alpha band at 0 in the areas outside of the ROI.
Or unmark your mask band as being an alpha band so it is treated as a regular 
band.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com