Georeferencing error "run.py: error: unrecognized arguments: false" (Seneca Test set)

[jnederend]

I wrestled with processing the Seneca NIR test set. These images are geotagged with embedded metadata, so I copied and pasted the suggested script --odm_georeferencing-useGcp false --start with georeferencing straight from the terminal window.

The error is in the log below.

uoguelphdrones@ubuntu:~/odm_data/seneca$ '/home/uoguelphdrones/OpenDroneMap_old/run.py' --odm_georeferencing-useGcp false --start-with odm_georeferencing usage: run.py [-h] [--resize-to ] [--job-dir-name ] [--start-with ] [--end-with ] [--run-only ] [--use-opensfm | --use-bundler] [--force-focal ] [--force-ccd ] [--min-num-features ] [--matcher-threshold ] [--matcher-ratio ] [--matcher-neighbors ] [--matcher-distance ] [--cmvs-maxImages ] [--pmvs-level ] [--pmvs-csize < positive integer>] [--pmvs-threshold <float: -1.0 <= x <= 1.0>] [--pmvs-wsize ] [--pmvs-minImageNum ] [--odm_meshing-maxVertexCount ] [--odm_meshing-octreeDepth ] [--odm_meshing-samplesPerNode = 1.0>] [--odm_meshing-solverDivide ] [--odm_texturing-textureResolution ] [--odm_texturing-textureWithSize ] [--odm_georeferencing-gcpFile ] [--odm_georeferencing-useGcp] [--odm_orthophoto-resolution 0.0>] [--zip-results] run.py: error: unrecognized arguments: false

I have one personal dataset with embedded GPS that I would like to test out. I also have several flights with non-embedded GPS data. Is there a way I can use the telemetry log file (it is a .csv) with ODM instead of having to embed them into the image?

[dakotabenjamin]

--odm_georeferencing-useGcp is false by default, and in any case for T/F args "true" or "false" are unnecessary. Run python run.py -h for more info on argument calls.

There are several programs that are useful for writing GPS to EXIF metadata. I've used Mapillary's python tools in the past, but not knowing what your telemetry log file looks like, I can't help you more specifically. You could probably write a quick processing script, as there are readily available command-line exif-writing tools and python libraries out there.

Additionally, you can manually create a GCP file (instructions here)

[jnederend]

Thanks for the help. I will give Mapillary a try for geotagging, and if it doesn't work out there may be a Windows alternative for geotagging.

W.R.T. the "--odm_georeferencing-useGcp false" issue, I am still confused as to how to use the EXIF tags. If I remove "false" from the script, ODM tells me that no GCP file exists. I instead simply ran "--start with georeferencing" to re-run only the orthophoto generation and it says that it defaults to EXIF data. Seems to have produced an GeoTIFF that is as good as the one in the tutorial video.

My personal flight must have used the Exif data as well since I did not specify any runtime parameters. I will try it again to see if I can improve it because the ortho turned out very poorly, whereas in Pix4D it was the best flight I have ever processed.

[dakotabenjamin]

Simply remove the whole argument, since you do not have a GCP file. The program assumes you have exif data in the photos by default (unless you put --odm_georeferencing-useGcp in the command)

For your personal flight, what did you specify for photo overlap / sidelap?

[jnederend]

The flight was done at 75/75 overlap/sidelap at about a 6cm/pix resolution. I re-processed with the parameters --resize-to 4048 --min-num-features 12000 --matcher-neighbors 10 --odm_orthophoto-resolution 10.

The orthophoto turned out roughly the same. The issue being that many straight lines (roads and pathways) are all over the place. I check the coordFile.txt and the program did not extract the EXIF tags correctly. The lat/long are incorrect and place images all over the globe, but the jpegs themselves are fine

coodFile.txt begins with: WGS84 UTM 17N 549358 4831351 Lat, Long, Alt.,

[Fi156]

Another tool suggestions: If you have a log file with the GPS coordinates: Try to rewrite the GPS exiftags via "exiftool" by P. Harvey. http://www.sno.phy.queensu.ca/~phil/exiftool/geotag.html

Are you sure, that the GPS tags are wrong? In some cases the texturing algorithm disrupts straight lines. Especially when used with wide aperture images...

[jnederend]

@Fi156 I am quite sure the coordFile.txt is incorrect. I thought at first that it was pulling the GPS tags in WGS84 decimal degree form and entering them as UTM but that isn't right either. The images are all around N43.xxxxx degrees W80.xxxxxx, 426.25m altitude degrees, but the first image in the coordFile says 72.xxxxxxx, 125.xxxxxx, 426.25m altitude. If those are in UTM, that places me somewhere off the Southern coast of Sri Lanka in the Indian Ocean. If they are in WSG 84 DD format, that places me on the North Eastern cost of Russia. I am in Ontario, Canada.

I am going to try creating my own GCP file using image marks from Pix4D just to see how the flight processes. Two GCPs are sub-cm RTK quality, while two others are manual tie points where I pulled the UTM coordinates from the Pix4D orthomosaic.

I would still like to see where I am going wrong with the embedded geotags though as that will be the method I use going forward.

[Fi156]

coodFile.txt begins with: WGS84 UTM 17N 549358 4831351 Lat, Long, Alt.,

Its in fact not Lat, Long, Alt., but: x, y, z where x and y are UTM 17N coordinates and z is the height..

You need to add the values from the second line "549358 4831351" to these coordinates to get valid UTM points. I guess that the main driver for this construction is filesize and ply format constraints.

[jnederend]

Thanks that makes much more sense! I checked and adding those values puts me in the right location, which means that the embedded GPS must have worked perfectly...kind of discouraging.

[jnederend]

Ran the flight again using a gcp_list.txt file. The GCPs are in UTM northing/easting format, and Z=altitude. Received this error:

ERROR 1: Translating source or target SRS failed: WSG84 UTM 17N Traceback (most recent call last): File "/home/uoguelphdrones/OpenDroneMap_old/run.py", line 999, in func() File "/home/uoguelphdrones/OpenDroneMap_old/run.py", line 889, in odm_georeferencing lat_frac = coord_to_fractions(coords_wgs84[1],['N','S']) IndexError: list index out of range

[dakotabenjamin]

Can you paste your gcp_list.txt?

[Fi156]

I think the error is already visible...

WSG84 UTM 17N

[dakotabenjamin]

Nice catch! :+1:

[jnederend]

Thanks for the responses guys. I'm new to GIS and command line work so it's a steep learning curve.

Here's my GCP list. Z is actually elevation not altitude. Image resolution is 4000x3000 to put the pixel position into perspective.

WSG84 UTM 17N 549324.0912 4831263.122 371.53 110 307 IMG_0026_NIR.jpg 549324.0912 4831263.122 371.53 3073 1229 IMG_0033_NIR.jpg 549324.0912 4831263.122 371.53 2609 434 IMG_0068_NIR.jpg 549324.0912 4831263.122 371.53 2112 816 IMG_0069_NIR.jpg 549324.0912 4831263.122 371.53 2654 1979 IMG_0070_NIR.jpg 549324.0912 4831263.122 371.53 3502 689 IMG_0075_NIR.jpg 549324.0912 4831263.122 371.53 3221 2923 IMG_0076_NIR.jpg 549324.0912 4831263.122 371.53 1532 205 IMG_0136_NIR.jpg 549324.0912 4831263.122 371.53 1244 1071 IMG_0137_NIR.jpg 549324.0912 4831263.122 371.53 871 1938 IMG_0138_NIR.jpg 549324.0912 4831263.122 371.53 1000 2724 IMG_0139_NIR.jpg 549324.0912 4831263.122 371.53 622 2539 IMG_0149_NIR.jpg 549324.0912 4831263.122 371.53 2801 699 IMG_0170_NIR.jpg 549324.0912 4831263.122 371.53 2277 1617 IMG_0171_NIR.jpg 549324.0912 4831263.122 371.53 1628 2723 IMG_0172_NIR.jpg 549324.0912 4831263.122 371.53 3017 1032 IMG_0182_NIR.jpg 549373.1822 4831452.131 374.587 2179 201 IMG_0022_NIR.jpg 549373.1822 4831452.131 374.587 2540 1328 IMG_0023_NIR.jpg 549373.1822 4831452.131 374.587 2436 2854 IMG_0024_NIR.jpg 549373.1822 4831452.131 374.587 670 245 IMG_0078_NIR.jpg 549373.1822 4831452.131 374.587 283 1896 IMG_0079_NIR.jpg 549373.1822 4831452.131 374.587 2311 776 IMG_0124_NIR.jpg 549373.1822 4831452.131 374.587 1859 1597 IMG_0125_NIR.jpg 549373.1822 4831452.131 374.587 1459 2965 IMG_0126_NIR.jpg 549373.1822 4831452.131 374.587 3506 515 IMG_0188_NIR.jpg 549373.1822 4831452.131 374.587 2462 1317 IMG_0189_NIR.jpg 549373.1822 4831452.131 374.587 2696 2793 IMG_0190_NIR.jpg 549373.1822 4831452.131 374.587 2234 1053 IMG_0195_NIR.jpg 549373.1822 4831452.131 374.587 3431 2683 IMG_0196_NIR.jpg 549358.67 4831347.33 371.47 307 1948 IMG_0025_NIR.jpg 549358.67 4831347.33 371.47 646 2615 IMG_0026_NIR.jpg 549358.67 4831347.33 371.47 1469 1788 IMG_0035_NIR.jpg 549358.67 4831347.33 371.47 2295 1697 IMG_0077_NIR.jpg 549358.67 4831347.33 371.47 2547 804 IMG_0132_NIR.jpg 549358.67 4831347.33 371.47 736 949 IMG_0181_NIR.jpg 549326.49 4831345.7 371.31 1288 1903 IMG_0026_NIR.jpg 549326.49 4831345.7 371.31 2172 594 IMG_0076_NIR.jpg 549326.49 4831345.7 371.31 2665 2928 IMG_0140_NIR.jpg 549326.49 4831345.7 371.31 3545 2264 IMG_0173_NIR.jpg 549326.49 4831345.7 371.31 1621 1479 IMG_0181_NIR.jpg

[dakotabenjamin]

Yeah like @Fi156 said, you need to change the first line to WGS84 UTM 17N

[jnederend]

Well that's and embarrassing mistake. Turned out pretty poor again so I need to adjust other runtime parameters.

My only question remaining is whether or not the geo-tagged jpegs actually worked. It looks to me like they did, assuming that ODM correctly identified WGS84 in decimal degrees and automatically converted to UTM.

The orthophoto using the above GCPs can be found here http://1drv.ms/1PNNoTq

[Fi156]

Load the tif into QGis (or similar) and evaluate if it is mapped correctly. (The OpenLayersPlugin can help too...)

In terms of the stitching quality: Not a surprising result.

The visible error in the tiff has nothing to do with the reconstruction process, have a look by yourself and open one of the ply files with meshlab (or similar).

Try to delete blurry and not vertically taken images first and try again.