[GIS] Does GDALWARP have support for OpenCL speedup to orthorectification

gdalgdalwarpgpgpuorthorectification

So I am attempting to orthorectify some images very large images. The process can take several hours so currently I am relying on using 8 threads to perform the speed up. However, the GPU does not appear to be in use at all according to nvidia-smi. I am very confused why this is the case:

Here is the script I am using:

#! /bin/sh

CUR_DIR="$(cd $(dirname ${BASH_SOURCE[0]}); pwd)"
export LD_LIBRARY_PATH="$CUR_DIR/../lib"
$CUR_DIR/gdalwarp -overwrite -rpc -to RPC_DEM="$1" -wo USE_OPENCL=TRUE   "$2" "$3"

I am attempting to orthorectify a large NITF which have I stored into an RPC model:

I have copied the different bands from GDAL info to see if I need to change the -wt or -ot to speed up the computation. I have recompiled GDAL with Nvidia's OPENCL and am running that recompiled version.

Why does GDALWARP not use the GPU in this case?

Band 1 Block=128x128 Type=UInt16, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA 
Band 2 Block=128x128 Type=UInt16, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA 
Band 3 Block=128x128 Type=UInt16, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA 
Band 4 Block=128x128 Type=UInt16, ColorInterp=Alpha

Best Answer

Unfortunately, it turns out at this time, GDAL does NOT support OPENCL speed up on orthorectification. In fact, the only speedup I have been able to find is that compiling with OpenCL does speed up resampling slightly. This would be a good feature for GDAL to implement at a future date.

Related Solutions

[GIS] Georeferencing png using gdal

Here's a world file for you (as per Gene's suggestion). Cut and paste the following into a text editor and name the file the same as your full-sized map but give it the extension '.pgw' instead on '.png':

1.0
0.0
0.0
-1.0
0.0
3231.0

I've made the following assumptions:

Your map has a resolution (pixel size) of 1m square (i.e. each pixel is a reasonable stride length for a fantasy game humanoid character). If I am wrong, edit lines 1 and 4 accordingly.
I have assumed that your map is not rotated.
I have assumed that your LL corner is at 0,0 in your world. If your pixel size is bigger than 1m square then you will need to multiply your Y coordinate (3231.0) accordingly.
Technically the UL coordinate (last two lines) is the center of your pixel. I have been lazy and set it to the corner. This in theory means that your coordinates would be consistently half a meter out but it's a fantasy world so nobody will know; it is consistent so won't screw up any distant calculations; and it saves a negative value as one of your origin coordinates. Adjust if you are sufficiently worried :)

I would then re-tile your map from the georeferenced full-sized one (this saves you making a world file for each tile)

Now, if you load your fantasy map into a GIS or similar system, you will probably be asked for the Spatial Reference System (SRS). The World file doesn't encapsulate that. It just locates and orients the image file in space relative to a nominal 0,0 origin. Since this is a fantasy map, all you need to do is pretend that it is in the real world somewhere and pick any coordinate system that gives you a flat projection with units in meters (or feet if you prefer but you will may have to adjust the values for resolution in the world file). A couple of suggestions for SRS could be:

EPSG: 3857 (aka 900913)
EPSG: 27700 (UK National Grid - the advantage of a national grid system UK or otherwise, is that you mostly stay clear of the poles and the international dateline and can hopefully avoid any weirdness which may result from such a location)

Your choice might not matter at all... on the other hand, you choice of SRS might be influenced by what you intend to do with your KML/CSV file (like you might be making a game with a post-apocalyptic theme but set in Quebec ...with zombies...). If you are using Google Earth or similar as a 'platform' for your game/fantasy world, so long as all your other data are in the same coordinate system, all should be well.

However, I do wonder if you may be better sticking with your PNG file as a text format like KML/CSV will be big. A PNG may be better for an internet-based game (reducing bandwidth). If you have a stand-alone scenario, most programming languages understand image formats well (especially if you call the GDAL libraries) and so I'm not convinced that a text-based format is even necessary here - but that's your choice of course.

[GIS] Gdalwarp orthorectification WorldView-3 not using RPC projection properly

I finally managed to correctly orthorectify my image using Gdal 2.2.2.

I am not 100% sure which made the difference, but there are two things that I did.

Firstly I made sure that the DEM used has the correct datum (WSG84 ellipsoid and not a geoid datum) by applying:

gdalwarp -s_srs "+proj=longlat +datum=WGS84 +no_defs +geoidgrids=egm08_25.gtx" -t_srs "+proj=longlat +datum=WGS84 +no_def" DEM.tif DEM_WSG84_ellipsoid.tif

In this case I used egm08_25.gtx since my DEM was in EGM2008 geoid height, but for NASA's SRTM it should be EGM96.

Then when warping the image I make sure to add the -et 0 option as suggested here: https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044907.html which might be the reason it works now.

gdalwarp -wo "SAMPLE_GRID=NO" -et 0 -rpc -to RPC_DEM=DEM_WSG84_ellipsoid.tif input.tif output.tif

I still get some small artifacts that disappear when I use -r bilinear but then I lose some contrast, so I am still trying to figure out how to improve this. But overall the results are almost exactly what I get when using dedicated GIS software.

Best Answer

Related Solutions

[GIS] Georeferencing png using gdal

[GIS] Gdalwarp orthorectification WorldView-3 not using RPC projection properly

Related Question