OSGeo
Incorrect warping with larger warper memory
What is the bug?
I noticed satellite imagery I am processing appears to have a tiny notch on the eastmost extent, and after an enormous amount of debugging the cause seems to be the amount of memory allocated to the warper via -wm.
Values of -wm >=512MB result in an incorrect image. 256MB is fine!
256 vs 512
Steps to reproduce the issue
Sample data: http://static.skysight.io/sat.tiff
I have broken it down to a test case: docker run -v $(pwd):/data/ -ti ghcr.io/osgeo/gdal:ubuntu-full-3.10.3 gdalwarp -t_srs EPSG:3857 /data/sat.tiff /data/sat.crop.tiff -te_srs EPSG:4326 -te 179 -65 180 75 -wm 256
Choosing different latitude extents also alters whether the notch appears.
Simple test with md5sum shows where the results change:
% for w in 128 256 512 1024 2048 4096; do rm sat.crop.tiff; docker run -v $(pwd):/data/ -ti ghcr.io/osgeo/gdal:ubuntu-full-3.10.3 gdalwarp -t_srs EPSG:3857 /data/sat.tiff /data/sat.crop.tiff -te_srs EPSG:4326 -te 179 -65 180 75 -wm $w; md5sum sat.crop.tiff; done Creating output file that is 177P x 35790L. Using internal nodata values (e.g. 0) for image /data/sat.tiff. Copying nodata values from source /data/sat.tiff to destination /data/sat.crop.tiff. Processing /data/sat.tiff [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done. 012e2e63a3db5efc83ed89dc455daf36 sat.crop.tiff Creating output file that is 177P x 35790L. Using internal nodata values (e.g. 0) for image /data/sat.tiff. Copying nodata values from source /data/sat.tiff to destination /data/sat.crop.tiff. Processing /data/sat.tiff [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done. 012e2e63a3db5efc83ed89dc455daf36 sat.crop.tiff Creating output file that is 177P x 35790L. Using internal nodata values (e.g. 0) for image /data/sat.tiff. Copying nodata values from source /data/sat.tiff to destination /data/sat.crop.tiff. Processing /data/sat.tiff [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done. 430c2d906b81ec3521a4bcc798808dbb sat.crop.tiff Creating output file that is 177P x 35790L. Using internal nodata values (e.g. 0) for image /data/sat.tiff. Copying nodata values from source /data/sat.tiff to destination /data/sat.crop.tiff. Processing /data/sat.tiff [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done. 430c2d906b81ec3521a4bcc798808dbb sat.crop.tiff Creating output file that is 177P x 35790L. Using internal nodata values (e.g. 0) for image /data/sat.tiff. Copying nodata values from source /data/sat.tiff to destination /data/sat.crop.tiff. Processing /data/sat.tiff [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done. 430c2d906b81ec3521a4bcc798808dbb sat.crop.tiff Creating output file that is 177P x 35790L. Using internal nodata values (e.g. 0) for image /data/sat.tiff. Copying nodata values from source /data/sat.tiff to destination /data/sat.crop.tiff. Processing /data/sat.tiff [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done. 430c2d906b81ec3521a4bcc798808dbb sat.crop.tiff
Versions and provenance
Observed with ghcr.io/osgeo/gdal:ubuntu-full-3.10.3 (ARM), and also on 3.10 x86.
Additional context
No response
What else did you try? In some other use cases increasing "sample_steps" help. Have you tried -wo SAMPLE_STEPS=1000 or -wo SAMPLE_STEPS=ALL?
Indeed, increasing sample_steps causes it to not occur. I think it's still a bug that warper memory allocation can affect the warp?
On Tue, Apr 8, 2025 at 5:12 PM Jukka Rahkonen @.***> wrote:
What else did you try? In some other use cases increasing "sample_steps" help. Have you tried -wo SAMPLE_STEPS=1000 or -wo SAMPLE_STEPS=ALL?
— Reply to this email directly, view it on GitHub https://github.com/OSGeo/gdal/issues/12106#issuecomment-2785460999, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACODFYPU5AKXD4WJHIM3RL2YNZFXAVCNFSM6AAAAAB2U6GQ3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBVGQ3DAOJZHE . You are receiving this because you authored the thread.Message ID: @.***> [image: jratike80]jratike80 left a comment (OSGeo/gdal#12106) https://github.com/OSGeo/gdal/issues/12106#issuecomment-2785460999
What else did you try? In some other use cases increasing "sample_steps" help. Have you tried -wo SAMPLE_STEPS=1000 or -wo SAMPLE_STEPS=ALL?
— Reply to this email directly, view it on GitHub https://github.com/OSGeo/gdal/issues/12106#issuecomment-2785460999, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACODFYPU5AKXD4WJHIM3RL2YNZFXAVCNFSM6AAAAAB2U6GQ3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBVGQ3DAOJZHE . You are receiving this because you authored the thread.Message ID: @.***>