One more data point; another colleague who is on a mac but built gdal himself instead of using brew does not see the artifact, so I suppose the lesson is, build your own gdal!
Best, P On Fri, Sep 17, 2021 at 8:51 PM Patrick Young < [email protected]> wrote: > Hi Even, > > Thanks for checking! I tried this in a docker container (osgeo/gdal) and > sure enough, the output looks fine there. > > It reproduces for me with my brew installed gdal (3.3.2) and I was careful > to do everything in a clean directory. I tried a few other outputs as well > (png, jpeg) and the toucan remains surrounded by white. I also had a > colleague check (he is also on a mac, using a brew installed GDAL 3.3.0) > and he sees the same artifact that I see. > > I have no idea what could be causing it! Interestingly, if the background > raster is (255, 0, 0), you don't get the white everywhere, but instead you > get solid red wherever the alpha is in [1,254]. I wonder what it could be! > > Best, > Patrick > > > > On Fri, Sep 17, 2021 at 5:18 PM Even Rouault <[email protected]> > wrote: > >> 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 >> >> 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 >> [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
