[gdal-dev] gdalwarp alpha band resampling bug
Patrick Young
patrick.mckendree.young at gmail.com
Fri Sep 17 20:08:38 PDT 2021
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 <
patrick.mckendree.young at gmail.com> 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 <even.rouault at spatialys.com>
> 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 listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> -- http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210917/c1bf1540/attachment.html>
More information about the gdal-dev
mailing list