No, this is unaaceptable, but I cannot reproduce it. The only problem I
had was with control points that were too close together. Are yours
evenly distributed? Can you do tests with subsets of control points?
On 12/12/2012 01:27 PM, Knut-Frode Dagestad wrote:
Hi Jan,
That sounds interesting and promising.
For the mentioned file it takes about 2 minutes with "-et 5" (low
accuracy), and 12 minutes without this switch. Without -tps it takes
less than 0.5 seconds.
The machine is quite decent with 16 GB memory and SSD disk.
Best regards from Knut-Frode
On 12. des. 2012 13:24, Jan Hartmann wrote:
Hi Knut,
What do you mean by "very slow"? I regularly use gdalwarp -tps on much
larger rasters with a few thousand gcp-s, and never noticed unacceptable
delays. Do you have very little physical memory, or many parallel
processes running?
Jan
On 12/12/2012 01:12 PM, Knut-Frode Dagestad wrote:
Hi list,
When warping images with many GCPs, the -tps switch (Thin Plate
Spline) is found to be necessary to get decent accuracy. This makes
however warping very slow. The only method I found to increase speed
is the -et switch, but at cost of spatial accuracy.
Below some comments about the other tries which did not help:
- compiling GDAL with armadillo support had no effect on speed.
Btw, to compile with armadillo I had to manually insert -llapack in
the following line in configure:
if test -z "`${CXX} testarmadillo.cpp -o testarmadillo -larmadillo
2>&1`" ; then .....
Perhaps ${LIBS} should be added permanently to this line in trunk?
- compiling GDAL with OpenCL had also no effect. At first surprising,
but looking at the opencl warp kernel it seems that it only makes a
difference for other resampling algorithms than nearest neighbour?
- Increasing memory with -wm had no effect
- Using several threads (-multi -wo NUM_THREADS=ALL_CPUS) actually
increased computing time significantly (my proj version is 4.7.1).
From the debug output, a lot of the time is apparently spent on:
"WARP: Copying metadata from first source to destination dataset"
Is this an indication that much time is simply spent on reading and
writing the GCPs to/from file? If so, we could perhaps expect improved
performance if Geolocation Arrays could be used instead (not possible
due to http://trac.osgeo.org/gdal/ticket/4907).
The tests are made with the following file and command on Ubuntu:
http://dl.dropbox.com/u/15885758/testgcp.tif (3212 GCPs and 2048x2511
pixels covering Southern Europe)
time gdalwarp --debug on -et 5 -tps -t_srs '+proj=merc' testgcp.tif
out.tif (+ other swithces mentioned above)
Best regards from Knut-Frode
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
