Ticket #3120 (new enhancement)
[PATCH] gdalwarp speed-up when warping small images into a big mosaic
| Reported by: | peifer | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Algorithms | Version: | unspecified |
| Severity: | normal | Keywords: | |
| Cc: | neteler, rouault |
Description
Here a summary of some discussion at gdal-dev@…
Adam Nowacki wrote:
Some rather counterintuitive gdalwarp behavior: the bigger dfWarpMemoryLimit (-wm setting) the more cpu time will be wasted on warping not existing pixels. Why? Warping begins with the destination window size of entire output image size. If this size is larger than dfWarpMemoryLimit it is split in half along the longest axis and any half that doesn't contain the currently processed source file is discarded. With large dfWarpMemoryLimit this subdivision process will stop early with still large portions of out of source image pixels.
My observation while gdalwarping *many* small GeoTiffs? into a big mosaic, with -wm 300:
Src=0,0,3601x3601 Dst=36375,31125,12125x10375
I understand this as follows: the source image of 3601x3601 pixels is read as one chunk (which after reprojection and resampling should be around 800x1100 pixels). However, 12125x10375 pixels are actually written to the output file. So 99.5% of the destination window must be completely unrelated to my input image.
If I counter-intuitively reduce the memory limit to, say: 40 MB and leave anything else unchanged, then gdalwarp is processing the input files much faster.
Perhaps gdalwarp should not only test if the destination window fits into memory, but also check what would be the minimum destination window for warping the input image. This could speed up the mosaicing of small tiles into a bigger output file.
Adam provided a patch with a new variable dfFillRatio, which made things even faster. The patch is here: http://pastebin.com/m45e46f53

