[gdal-dev] Re: Strange things with gdalwarp ...

[Adam Nowacki]

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

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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
>