[gdal-dev] gdalwarp performance with many GCPs

Even Rouault even.rouault at mines-paris.org
Wed Dec 12 07:12:41 PST 2012


Selon Knut-Frode Dagestad <knutfrodesoppel at hotmail.com>:

> 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?
>

Could you file a ticket about that ?

> - 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?

The OpenCL warper was designed to speed-up computational intensive algorithms,
such as lanczos resampling. For nearest resampling, most of the time is spent in
I/O, or reprojection.

>
> - Increasing  memory with -wm had no effect

Yes, it depends on particular configuration of source and target datasets,
particularly if they're tiled or not. Tuning this might be non obvious.

>
> - Using several threads (-multi -wo NUM_THREADS=ALL_CPUS) actually
> increased computing time significantly (my proj version is 4.7.1).

As underlined in
http://osgeo-org.1560.n6.nabble.com/gdal-dev-NEW-Multi-threaded-warping-td4980252.html
, you need proj 4.8.0 for lock-less reprojection. Older versions have a global
mutex that will prevent efficient parallism.


More information about the gdal-dev mailing list