[gdal-dev] Potential issue with gdaladdo overviews setting alpha channel to nodata value instead of zero

[Even Rouault]

On jeudi 5 octobre 2017 18:46:32 CEST Tim Waters wrote:
> Hello,
> 
> I'm seeing an issue which is present in 2.2.2 (tags/2.2.2 from github) and
> seen in 1.11.3 (Ubuntu 16.04) but not present in 1.10.1 (Ubuntu 14.04).
> 
> If a raster with an alpha channel has nodata set, and overviews via
> gdaladdo are created, the overviews use the nodata value for the value of
> the alpha channel.  However, using the nearest resampling method correctly
> sets the alpha to zero. All other resampling methods except nearest seem to
> give the same wrong result.
> 
> I've created a repository with all the files and readme containing the
> workflow.
> https://github.com/timwaters/gdal_gdaladdo_issue with screenshots of the
> expected and observed files opened in Gimp to view the pixel values.
> 
> The use case is mapwarper.net where users upload ungeoreferenced images,
> they get converted to tifs and have overviews added, then they can mask
> them (gdal_rasterize) and then warp the masked files, with overviews added
> finally. I'm updating the server to run on Ubuntu 16.04 and will have to
> compile gdal.
> 
> Flow is:
> 
> #Apply overviews to ungeoreferenced raster
> gdaladdo -r average treasure_island.tif 2 4 8 16
> 
> #Rasterise ungeoreferenced raster with the cropping mask
> gdal_rasterize -i  -b 1 -b 2 -b 3 -burn 17 -burn 17 -burn 17  20.gml -l
> features treasure_island.tif
> 
> #Georeference & warp the raster
> gdal_translate -a_srs '+init=epsg:4326' -of VRT treasure_island.tif
> temp.vrt  -gcp 100.38, 83.096, -122.377, 37.830 -gcp 430.1966, 370.08,
> -122.363, 37.8207 -gcp 313.69, 61.68, -122.368, 37.831


> gdalwarp -rn  -dstalpha -srcnodata '17 17 17' -s_srs 'EPSG:4326' temp.vrt
> treasure_island_warped.tif -co TILED=YES -co COMPRESS=LZW

Tim,

The issue come from the above step. Basically this will add an alpha channel and also set 
implicitly a dest nodata value to 17. In GDAL extended TIFF, the nodata value applies to all 
channels. But when you have an alpha channel, having nodata values in addition doesn't 
really make sense and just confuse everything afterwards.
If you add -dstnodata none, this will fix the issue.
I think we should probably default to this behaviour when -dstalpha is specified.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171005/ef26d038/attachment.html>