Adam Nowacki wrote:
You can test with http://pastebin.com/m45e46f53
Also remember to use -wo SKIP_NOSOURCE=YES


Now the input images are read in many chunks, rather than 1 (or max 2) before. Nevertheless, the performance is really great. Now, 100 tiles are warped in 5 minutes! That's 4-5 times faster than anything else I tried before.

Hermann


Before applying the patch, with intentionally small memory
(-wm 40, which was fastest, as far as I could see)

GDAL: GDALOpen(unzipped/ASTGTM_N30E039_dem.tif, this=0x9711470) succeeds as GTiff.
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=0,0,3601x2185 Dst=42437,38906,3031x2594
GDAL: Potential thrashing on band 1 of unzipped/ASTGTM_N30E039_dem.tif.
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=636,0,2965x3601 Dst=45468,38906,3032x2594
GDAL: GDALClose(unzipped/ASTGTM_N30E039_dem.tif, this=0x9711470)


After applying the patch, with -wm 300 --config GDAL_CACHEMAX 300
(and -wo SKIP_NOSOURCE=YES, which I always used)

GDAL: GDALOpen(unzipped/ASTGTM_N30E039_dem.tif, this=0x86f5dd0) succeeds as GTiff.
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=704,0,435x91 Dst=45278,40770,95x81
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=1042,0,435x207 Dst=45373,40770,95x81
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=0,0,1383x2185 Dst=45089,40851,379x649
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=1380,0,863x439 Dst=45468,40689,189x162
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=2051,0,1058x673 Dst=45657,40527,190x324
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=2725,0,876x908 Dst=45847,40527,189x324
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=3585,167,16x368 Dst=46036,40608,95x81
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=3490,413,111x367 Dst=46036,40689,95x81
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=3395,659,206x367 Dst=46036,40770,95x81
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=636,204,2965x2911 Dst=45468,40851,758x649
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=3592,2125,9x366 Dst=46226,41175,94x81
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=3498,2371,103x366 Dst=46226,41256,94x81
GDAL: GDALWarpKernel()::GWKGeneralCase()
Src=3309,2617,292x615 Dst=46226,41337,94x163
GDAL: GDALClose(unzipped/ASTGTM_N30E039_dem.tif, this=0x86f5dd0)























Hermann Peifer wrote:
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.


Given Adam's explanations above, could someone tell me if my below assumptions are correct? Thanks.

Just to repeat, the input files are ASTER GTiffs in WGS84, 3601x3601 pixels each. The output is a single mosaic of all tiles, a 100m GTiff, in LAEA projection


gdalwarp -wm 300 --config GDAL_CACHEMAX 300 --debug on ... reports:

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 behaviour changes to

Src=0,0,3601x3601 Dst=45468,38906,1516x2594

This tells me that the destination window is much smaller and gdalwarp will not waste time to write out so many irrelevant pixels, correct?

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.

Hermann
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev



_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to