I can't reproduce the issue you describe. There's not a single white
pixel in the output image (the max of the green and blue bands is <
255). But I suspect this could be related to a pre-existing
composite-bl.tif file you might have. gdalwarp doesn't overwrite by
default the output image. It blends into it. If you add -overwrite, you
should get a reasonable output.
Le 18/09/2021 à 01:06, Patrick Young a écrit :
Hello,
I've found behavior in gdalwarp related to compositing an image with a
variable alpha band. Under bilinear resampling, the alpha compositing
in areas where the alpha band is between 0 and 255 results in
completely white pixels.
To reproduce, I've first grabbed a rgba image from the test suite, e.g.:
wget
https://github.com/OSGeo/gdal/raw/a2db646d1c34905e47eb21657284b529b7478d66/autotest/gcore/data/stefan_full_rgba.tif
<https://github.com/OSGeo/gdal/raw/a2db646d1c34905e47eb21657284b529b7478d66/autotest/gcore/data/stefan_full_rgba.tif>
Then,
gdal_create -ot Byte -bands 3 -burn 71 147 240 -outsize 162 150 -a_srs
EPSG:3857 -a_ullr 0 162 150 0 background.tif
gdal_translate -a_srs EPSG:3857 -a_ullr 0 162 150 0
stefan_full_rgba.tif foreground.tif
gdalwarp -r bilinear background.tif foreground.tif composite-bl.tif
In this case, composite-bl.tif is white wherever the alpha is in [1,
254]. Trying
gdalwarp background.tif foreground.tif composite-nn.tif
produces a reasonable image, although it is blocker than when I
overlay background.tif and foreground.tif in qgis.
Thanks for any tips about what I'm seeing, happy to file a bug if it
is one! I've tested this on gdal 3.2.2 on macos (from brew).
Patrick
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
