Hi all, I am using gdal_translate to read a VRT file made up of COGs stored in S3. This works great when downsampling using nearest neighbour (GDAL 2.4.2):
$ time gdal_translate /vsis3/bucket/mosaic.vrt /tmp/out.tiff -projwin -9177335.364031402 5305341.259217514 -9174889.379126277 5302895.274312388 -outsize 256 256 -r nearest Input file size is 52916, 61539 0...10...20...30...40...50...60...70...80...90...100 - done. real 0m3.418s user 0m0.234s sys 0m0.297s Takes about 3 seconds to produce a downsampled 256x256 subset. If I switch the re-sampling method to bilinear: $ time gdal_translate /vsis3/bucket/mosaic.vrt /tmp/out.tiff -projwin -9177335.364031402 5305341.259217514 -9174889.379126277 5302895.274312388 -outsize 256 256 -r bilinear Input file size is 52916, 61539 0...10...20...30...40...50...60...70...80...90...100 - done. real 0m54.588s user 0m13.563s sys 0m3.438s Takes about a minute. I would assume that any of the re-sampling methods will take longer than nearest, but 51 seconds longer? That can't just be the extra processing. If I turn GDAL debug statements on I can see that the first command uses the the pre-built COG overviews: ... GTiff: Opened 1991x30351 overview. GTiff: Opened 996x15176 overview. GTiff: Opened 498x7588 overview. ... But the second command ignores the overviews and downloads the full resolution imagery leading to very long download times. Is it expected behaviour that all re-sampling methods except 'nearest neighbour' need to request the full resolution data? Can't they apply the selected re-sampling method to the overviews? Is it something to do with the way I created my VRT file? The COGs all have internal overviews and gdalbuildvrt is used to create the VRT file itself. Any input or suggestions would be appreciated. Thanks, Angus
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
