[gdal-dev] Downsampling with gdal_translate and overviews

[Even Rouault]

Hi Julien,

> 
> Yesterday I experienced a strange issue while downsampling image with
> gdal_translate -tr option (-filter is average). I was downsampling data
> before feeding them into a stereo reconstruction processing chain, and
> the output DSM had a clear and straight cutline in the middle of the
> image, as if the whole south part of the image was several meters lower
> than the north part. I compared the downsampled images with an in-house
> downsampling tool, and found indeed that whole rectangular portions of
> the gdal_translate output were a bit shifted (maybe less than a pixel,
> but that counts when doing stereo reconstruction). At one point I
> started suspecting my .ovr files, and indeed removing them made the
> problem disappear (I was subsampling by 10, whereas overviews have been
> generated with the classical 2 4 8 16 32 ... progression). So here are
> my questions :
> 
> - Is gdal_translate using the nearest overview level as a start for
> resampling ?

Yes. Well, "yes essentially" I should say if I'm pedantic: there's some subtely in the 
GDALBandGetBestOverviewLevel2() function in gcore/rasterio.cpp, line 3044 (a candiate 
overview level is accepted even if its resolution is lower up to 20% of the desired resolution, 
but I'm pretty sure that's subtelty is unrelated to your issue)

> 
> - Is there a way to prevent that (other than removing the ovr file) ?

I second Jukka's suggestion to try with gdalwarp. Will be somewhat slower, but you'll likely 
not get those artifacts, given that gdalwarp and gdal_translate works completely 
differently regarding how they process chunks of pixels.

If your whole image fits into RAM, you might also go on using gdal_translate, and set the 
GDAL_SWATH_SIZE environment variable to at least the uncompressed size of the image 
(value in bytes). This impacts the size of the rectangles used in 
GDALDatasetCopyWholeRaster(), which might relate with the artifacts you observe. No 
guarantee though.

> 
> - Is it expected than the resampling yields artifacts when ovr files are
> present ?

No, this is definitely not the expected behaviour. Definitely worth a ticket with ideally an 
easy way to reproduce

I somehow suspect that at some place (likely in rasterio.cpp or in vrtsources.cpp / 
vrtsourcedrasterband.cpp), although I couldn't find an obvious candidate by skimming 
quickly through them, the GDALRasterIOExtraArg argument of IRasterIO() and similar 
methods lacks a proper source window expressed as floating point coordinates, and use 
instead the base integer coordinates. Or something more subtle.

I can't really make sense why this is specific to overviews though. Are you sure the overviews 
don't already have those artifacts ? (you can extract them without any resampling with 
gdal_translate -oo OVERVIEW_LEVEL=x for example) In which case the culprit would be 
GDALRegenerateOverviews() / GDALRegenerateOverviewsMultiBand()

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/20170721/b6082655/attachment.html>