[gdal-dev] gdalwarper destination alpha mask

[Even Rouault]

Glenn,

> I'm trying to track down a discrepancy between GDAL 1.7.2 and GDAL
> 2.4.0.  The NASA Worldwind code makes a call to gdal.ReprojectImage()
> using a dataset generated from an input file to a working destination
> dataset that's empty, except that the alpha band has been filled with
> 0xFF.  In the case I'm examining, the projection is 1 to 1; no change. 
> The source file has an appropriate alpha mask to clip the image so only
> relevant data is shown.
> 
> When using the 1.7.2 release, the image is shown with a proper overlay
> on the lower priority layers, with the portions with alpha mask of 0
> being completely transparent.  But the more recent 2.4.0 release has a
> black boundary around the image, indicating that the alpha mask was set
> to 0xff for the whole image.
> 
> It looks like there's a difference in behavior in the Java call
> 
>                          gdal.ReprojectImage(srcDS, destDS, s_srs_wkt,
> t_srs_wkt, gdalconst.GRA_Average);
> 
> For the 1.7.2 release, the alpha mask in the destination data set is
> filled in correctly, matching the alpha band in the source. But in the
> 2.4.0 release, the destination alpha band is filled with 0xFF, which
> sort of explains the black boundary.  Curiously, for the 1.7.2 release,
> it doesn't matter if the destination alpha band was filled with zeros or
> 0xFF.  For the 2.4.0 release, if the destination dataset alpha band is
> filled with zeros, the image displays correctly, and the reprojected
> destination dataset alpha band matches the source.
> 
> I'm trying to understand what the purpose is of the destination alpha
> density mask in 'gdalwarpper.cpp'.  In the file 'gdalwarpoperation.cpp',
> I see a note that says "Note that detailed semantics of the masks should
> be found in
> 
> GDALWarpKernel."  And in 'gdalwarpkernel.cpp': "A detailed explanation
> of the semantics of the validity and density masks, and their effects on
> resampling kernels is needed here."
> 
> So if there's a place where the semantics are explained, please send me
> link.  And, if this rings a bell about a change that was made some time
> between the 1.7.2 (April 23, 2010) and the 2.4.0, please let me know.

Looking at the NEWS file, the change of behaviour likely dates back to GDAL 
1.8.0:
 * GDALReprojectImage() : correctly assign nSrcAlphaBand and nDstAlphaBand 
(#3821) --> https://trac.osgeo.org/gdal/ticket/3821

Previously the source and target alpha bands were treated as regular bands.
If the target alpha band is initialized to 0xFF, then it means that all target 
pixels are valid, and thus they will remain the same if there is no 
corresponding source pixel, or if they have source_alpha = 0.

The maths involved with destination density are in:
https://github.com/OSGeo/gdal/blob/master/gdal/alg/gdalwarpkernel.cpp#L1330
https://github.com/OSGeo/gdal/blob/master/gdal/alg/gdalwarpkernel.cpp#L1414
Basically this is for alpha blending of source onto target.

That said, looking at the above mentionned change in GDALReprojectImage(), I 
noticed there was something slightly wrong, which I just fixed, in which the 
alpha bands were treated both as regular bands and alpha bands. So I'm not 
sure what the effect was exactly. That said, the difference in results seemed 
minimal when warping over a target image initialized with alpha = 0.

So all in all, you should initialize your target image with alpha = 0 as you 
noticed.

Even


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