dstalpha outputs thin borders around edge of source image in gdalwarp

[dstahlke@…]

When warping an image with bilinear or cubic convolution resampling and with the "-dstalpha" option, the resulting alpha mask has some extra lines in it. The alpha mask improperly shows the edges of the source data as being valid data even if they were set to the srcnodata value. The RGB output properly labels the edge pixels as being dstnodata.

If nearest neighbor or cubic spline resampling is used there is no problem. I suspect that this is because there is no nResWinSize set for those in GWKGeneralCase.

I took a look at the code and the root of the problem seems to lie in the GWKGeneralCase function. There is some general bounds checking in the beginning of the loop that can cause a pixel to be skipped. If this passes, then the dfDensity variable is set to 1.0. This variable can possibly be set or the loop skipped by the UnifiedSourceDensity check, but in the situation of concern this doesn't happen. Next comes the actual resampling and checking of pixel values. It is at this point that the processing of dstalpha vs. dstnodata differs. If no valid source pixel is found then GWKSetPixelValue is not called. The loop over iBand falls through and GWKOverlayDensity is called with dfDensity=1. The result is that the RGB output gets left as dstnodata but the density mask gets a 1.0 written to it.

As a workaround I put in a check that skips the GWKOverlayDensity call if GWKSetPixelValue was not called for any of the bands. This fixed the problem, although I don't know what you would want the alpha mask to be if half of the bands had data and half the bands didn't.

Here is the command that I was using as a test case:

gdalwarp -t_srs '+proj=stere +lat_ts=80 +lat_0=90 +lon_0=0 \
  +ellps=WGS84' -tr 200 200 -te -1665228 2134989 -1243754 2558347 \
  -srcnodata 0 -dstalpha -dstnodata 100 -wm 1000 -rc rgb-in.tif out.tif

The same problem happens with or without the "-dstnodata 100" option - that is just there to prove that the pixels in question were in fact considered no data pixels. I could send you the landsat band that I was using as a test case if you want it.

[Even Rouault]

This is probably fixed. Closing under that assumption