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
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
