Orthophoto Could Not be Generated due to Missing EXIF data that is clearly present


Settings: Using WebODM on Ubuntu 18.04, 112 photos, parameters are “fast-orthophoto:true”, “Min-num-features: 12000”, “skip-3dmodel:true”, and resize photos = true.


An orthophoto could not be generated. To generate one, make sure GPS information is embedded in the EXIF tags of your images, or use a Ground Control Points (GCP) file.

I’ve went through several projects using WebODM, but lately I’ve been running into this error more often than not. I’d like to figure out why this error keeps appearing, and I know it’s not because of EXIF data problems, as you can see in one of the image’s properties here:

(part of the lat/long has been covered up due to privacy reasons)
Some of my projects successfully finish, but other times, this error occurs. Sometimes the number of images seems related. For the most recent time I got the error, I was just given this PNG as output instead of a .TIFF file.

Note: When I hit “No” on resize images, I usually get an error reading “Process exited with code 1”.

And I’ll post part of the log here too:

/code/SuperBuild/install/bin/texrecon (built on Nov 2 2018, 01:40:55)
Load and prepare mesh:
PLY Loader: comment VTK generated PLY File
Reading PLY: 53009 verts…
64628 faces…
Warning: Zero-length normals detected: 16 face normals, 20645 vertex normals
Generating texture views:
NVM: Loading file…
NVM: Number of views: 72
NVM: Number of features: 0
Loading 100%… done. (Took 11.545s)
Building adjacency graph:
Adding edges 100%… done. (Took 0.133s)
96893 total edges.
View selection:
Building BVH from 64628 faces…
done. (Took: 82 ms)
Calculating face qualities 100%… done. (Took 7.239s)
Postprocessing face infos 100%… done. (Took 0.038s)
Maximum quality of a face within an image: 4804.29
Clamping qualities to 1792.18 within normalization.
Writing data cost file…
Time[s] Energy
0 63103
1 62834
1 62550
2 62405
2 62345
2 62311
2 62291
2 62291
2 62281
2 62268
3 62265
3 62259
3 62255
50187 faces have not been seen
Took: 10.962s
Generating texture patches:
done. (Took 3.487s)
196 texture patches.
Running global seam leveling:
Create matrices for optimization…
Lhs dimensionality: 8998 x 8998
Calculating adjustments:
Color channel 2: CG took 97 iterations. Residual is 9.57276e-05
Color channel 0: CG took 113 iterations. Residual is 9.90604e-05
Color channel 1: CG took 113 iterations. Residual is 8.57862e-05
Took 0.033 seconds
Adjusting texture patches 100%… done. (Took 2.029s)
Running local seam leveling:
Blending texture patches 100%… done. (Took 19.049s)
Generating texture atlases:
Sorting texture patches…
Working on atlas 5 100%… done.
Finalizing texture atlases…
done. (Took: 3.388s)
Building objmodel:
Saving model…
Whole texturing procedure took: 61.87s
[INFO] Running ODM Texturing Cell - Finished
[INFO] Running ODM Georeferencing Cell
[WARNING] Georeferencing failed. Make sure your photos have geotags in the EXIF or you have provided a GCP file.
[INFO] Running ODM Georeferencing Cell - Finished
[INFO] Running ODM DEM Cell
[INFO] Classify: False
[INFO] Create DSM: False
[INFO] Create DTM: False
[INFO] DEM input file /var/www/data/a702a64d-34f2-4f53-bce0-9c20550d7308/odm_georeferencing/odm_georeferenced_model.laz found: False
[WARNING] DEM will not be generated
[INFO] Running ODM DEM Cell - Finished
[INFO] Running ODM Orthophoto Cell
[WARNING] Cannot calculate GSD, using requested resolution of 5.0
[DEBUG] running /code/build/bin/odm_orthophoto -inputFile /var/www/data/a702a64d-34f2-4f53-bce0-9c20550d7308/odm_texturing_25d/odm_textured_model.obj -logFile /var/www/data/a702a64d-34f2-4f53-bce0-9c20550d7308/odm_orthophoto/odm_orthophoto_log.txt -outputFile /var/www/data/a702a64d-34f2-4f53-bce0-9c20550d7308/odm_orthophoto/odm_orthophoto.png -resolution 20.0 -outputCornerFile /var/www/data/a702a64d-34f2-4f53-bce0-9c20550d7308/odm_orthophoto/odm_orthophoto_corners.txt
[WARNING] No geo-referenced orthophoto created due to missing geo-referencing or corner coordinates.
[INFO] Running ODM OrthoPhoto Cell - Finished
[INFO] OpenDroneMap app finished - Mon Nov 12 18:36:26 2018
Postprocessing: /var/www/data/a702a64d-34f2-4f53-bce0-9c20550d7308
No orthophoto found at odm_orthophoto/odm_orthophoto.tif: will skip tiling
No orthophoto found at odm_orthophoto/odm_orthophoto.tif: will skip MBTiles generation
Potree point cloud will not be generated (no suitable input files found)
Postprocessing: done (•̀ᴗ•́)و!

Any ideas what might be doing wrong? Are there any parameters I should change or is there something possibly wrong with the photos themselves?


Have you checked all the files exif, or spotchecked?

You can check all with exiftool: http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=3075.0


I see, I think it’s those couple pictures with the random 500 x 500 Lat/Lon throwing things off. I’ll run a test to confirm this. This problem would confirm why some tests of mine would work - I would rotate the photos in and out, which is why it would only crash some of the time.

Thanks for the info on ExifTool, I had previously installed the program but I never bothered to use it, so I’ll definitely utilize this in the future. Though I would like to know, why would a few of the pictures randomly have bad EXIF data like this?


Alright, I can confirm that did the trick. I’ve been able to generate an orthophoto.

However, I’d like to bring up a different issue here… is there any way I’d be able to improve how the orthophoto looks? Here’s a zoomed-in snippet of it:

I’d had a few orthophotos that turn out pitch-perfect, but then some have distortions everywhere. It seems structures and straight lines usually get messed up… but is because of my photos/camera, or is there a way this could be improved through the parameters?

P.S. I did hear the last WebODM update was supposed to help with a problem of this nature, and I made sure to update the program.


This looks like there are some gaps in the data, which is common for flying 3D piles like this. You can fake the data in those gaps a bit (@pierotofy can give setting recommendations that may help with this). But what sidelap and overlap are you flying with, and what height, and are these in the center of your flights or along the ?

If they are along the edges, I recommend flight planning a larger area, as the perimeter won’t have as much overlap, or fly at a really high overlap and sidelap rate, like 77 to 83%, or fly higher, if legal, practical, and within spec.


You could try to pass the --use-3dmesh option to see if you get better results.


The height is 200 feet. The plan wasn’t following a specific flight plan, so I don’t have an approximate overlap value. It probably didn’t overlap enough, but the distortion I shared above was a part that my drone flew right over, so it’s not like it was on the peripheral.

@pierotofy I’ll try using the 3d mesh option and see what happens.


Here’s a similar clip from the test using the 3D mesh:

This time, the bottom portion has been cut off, but I’m confident that is due to a lack of overlapping. What I’m more concerned about is the distorted portion at the top of the image. The drone flew right above that section, so I don’t know why it came out looking so bad.


It looks bad because the 3D approach isn’t as good (in general) with ortho imagery as is the default (in this case it does better in one spot and worse in the other, which can also happen occasionally).

It is really difficult to get good results from any photogrammetry software without flight planning. What are you using for a drone? We can probably recommend flight planners.


The pictures were taken from a Parrot Disco, which has a flight planning app but no feature to cover a distance like Mission Planner has. I have already purchased a flight controller that can connect to a real flight planner, but I just wanted to see if the Disco’s images could be patched together into orthophotos, and it seems the result is that it would be difficult to go forward with just that.

P.S. Oh, and I should mention that there is a way to get Arduplane to run on Parrot Disco for legitimate flight planning (see link here), but the guide hasn’t worked for me.


Ah, parrot disco. Such a cool drone, but yes a challenge for flight planning.

Cool! Sorry we couldn’t help more with this imagery (unless @pierotofy has some other tricks…).