Advice wanted regarding ODM run time

I run a small drone photography business primarily serving real estate and construction. For almost a year I’ve been growing into mapping, and have used Pix4d and Drone Deploy at various subscription levels. Have also researched available alternative mapping engines and am strongly motivated to want ODM to work for me.

With only a handful of mapping gigs in a year, the obvious biggest problem for a small business is the cost of the mapping processing. I would like to have ODM become my primary engine, but my first outing with it on a job with ~400 photos had to be aborted after 19 hours so I could switch to a known alternative and get the job delivered.

I’m running Win10 on a dual-quad core machine at 2.4GHz clock speed with SSD and 60GB RAM. Not the latest and greatest, but I thought it shouldn’t be a huge handicap either. That same job on this same machine was done in 12 hours in Pix4d, also all processed locally.

I’m seeking advice on what I should expect from ODM. I may have toggled on some features that caused the long run in ODM, and if so, it’ll get better as I climb the learning curve. Could I expect to cut the ODM run time in half if I spring for a high end PC? Should I recognize that ODM isn’t yet at similar processing turn-around times that the commercial programs achieve?

Perhaps stated more plainly, should I expect to get similar run time performance on ODM that I get with Pix4d for the same list of deliverables? I already believe that the quality of the ODM deliverables will take care of my needs, but the long processing time won’t let me support the client timing needs. Trying to decide what direction to move. Any advice from those with more ODM milage is appreciated.

Thanks … Bob R

1 Like

Hi Bob,

~400 photos on a dual quad core with 60 GB of RAM should finish, so I am quite curious about your settings. We just processed 600 images on a machine with 12 cores in 2.5 hours, and it’s rare for the Swiss project to beat us on performance, particularly memory and processor requirements. But your experience is acknowledged, so let us break down the available resources.

Alexandre @bevingtona has a similar question regarding predicting memory usage. How much is enough:

In that, we discuss OpenDroneMap benchmarks, a project that is working with the broader community to document resource usage for different example datasets.

We also have the UAV Arena. This is broadly for comparing quality of outputs, but starts to get at the question of settings and their results.

So, I always ask when queries like this are posted for lots of details so we can help:

  • What is your processor
  • Did you add swap space to this
  • Where did the process stop progressing (if anywhere)
  • Did you run out of storage?
  • What are your settings (that’s at the top of every log)?
  • Can you share (if only privately) the dataset for testing
  • What is your overlap and sidelap, etc.

If you’re on Windows/Mac, make sure you have allocated enough RAM to docker.


I very much appreciate the replies. It convinces me that I should hang in there with ODM and learn a lot more about running it on my machine. I have several job files that I can play with and will start small/simple and work my way up in size and complexity. See what I can learn as I go. I’m also going to get back into the most excellent manual and make sure I haven’t overlooked something.

So… I’m starting to commit to the ODM as my path forward. (Looking like it might also give me a good excuse to get into a higher end desktop) :slight_smile:

I’m guessing that the 600 image/2.5 hour performance that smathermather-cm described above is running Ubuntu (?). I’m so underwater with learning new stuff that I’d rather not add a new operating system to the list of things I almost know enough about. Am I giving up a lot if I stay with Win10?

How many cores can ODM utilize effectively? Does that depend on the operating system?

1 Like

Docker is pretty small overhead, even on windows, but you should be sure to check your disk, memory, and CPU allocations. By default it doesn’t take all your resources (nor should it). There are some great threads on this forum about docker and windows settings that are a short search away.

OpenDroneMap, for much of the toolchain, maxes out the CPUs it has available to it. But if they aren’t allocated in docker on Windows, it can’t use them. You can leave 1-2 cpus for the OS, and take the rest for OpenDroneMap, in your case you could easily use 6 processors in your docker instance.

Let us know how it goes!


Hey Bob, I agree with the other comments here that your issues are probably related to default Docker settings, and a few tweaks should get things moving along nicely for you. Stick with Windows 10 - no need to learn a new OS.

Find your docker configuration (right click the little whale in the taskbar and then Settings). Sometimes the docker icon is hidden near the right end of the toolbar under the up-arrow-looking-thing.

Update as follows: Start with CPUs at 80%, Memory at 80%, swap at 1 GB, and disk image size where it is.

Start with a subset of your photos (try 100 photos which are near one another) and see how it goes. Use all the default settings in WebODM when you select the photos. Including resize… let it resize the photos, at least for now. Run again with more photos, and then more, and keep repeating until you’ve run the whole set.

Let us know how it goes!


You should see similar performance on Windows, with the right settings. It might be a bit (10%?) slower due to the docker overhead but not much.


Excellent advise – Thanks All! Just got in off the road all day, and will start getting into this in the morning. REALLY appreciate the contributions here, and I’ll definitely keep the thread posted on progress. I’m encouraged!

Bob R.


A progress update – I’m primarily interested in orthophoto and contours for current work, so that’s all I’m looking at for the moment.

Run #1 (Full Default option template): Went to a recent 118 image job and ran it in ODM with full default settings. Job finished in 1:34. The orthophoto (GeoTIFF) in the ODM viewer was grainy and had jaggies (aliasing) when zoomed in to 3 meters. These conditions normally go with low resolution so decided to make next run with High Resolution template.

Run # 2 (High Resolution option template). Same 118 image job finished in ODM in 3:36. Orthophoto (GeoTIFF) in ODM viewer is still grainy at all altitudes and jaggie at 3 meters.

Run #3 (Default Option template with re-sizing disabled (set to -1) just for grins. I do understand that resizing is not supposed to make any difference in finished resolution). Same 118 images finished ODM in 8:24. Wow, that makes a big difference in run time! Same grainy and jaggie ortho-photo.

Run #4, back to full Default options but now with an earlier data set, same field under construction captured with a cross-hatch pattern at 396 images. Is still running as I write this after 6:20 and progress bar is about 1/3 completed. Ugh!

Two thoughts rolling around:

  • I’ve only been looking at the orthophoto in the WebODM viewer and only in GeoTIFF. Need to export results and examine in G.E.Pro and in ArcGIS or QGIS. And see how the result looks using tiles. ODM may be giving me good resolution results that I just can’t see in the ODM native viewer.

  • Have been unable to check my configuration. Have searched on forum and tried to follow @correysnipes instructions above, but my set up just doesn’t respond that way. Suspecting I have a hybrid install because the download didn’t go like the manual described and it didn’t look like the download instructions called out either. Have WebODM Manager that I run everything with, and a Docker Toolbox, both on desktop and neither seem to offer access to configuration settings. Am considering uninstalling and starting over again with fresh download. Pretty sure I allocated RAM, storage and cores according to the suggestions during the install. Recap from Post #1 - am running Win10 on a dual-quad core machine at 2.4GHz clock speed with 1 TB SSD and 60GB RAM.

The journey continues. Now working on run time and ortho quality. Figure to let Run #4 finish, see what gets posted here, and export the Runs #1 and #2 orthophotos for try out in GIS and GEPro.

1 Like

Can you share data and screen shots?

1 Like

Sure. I’ll put both sets of images on Dropbox and provide a link here for download. What screen shots would you like?


Run #4 just finished out in 9:10. Still have aliasing at 5 meters with ODM viewer. Haven’t exported the files yet for viewing outside ODM.

Am uploading images to Dropbox. It’ll take about an hour to upload and I’ll post link here as soon as it’s available. These are from a “Miracle Park” construction project in Rock Hill SC. It’s a sports park being built for special needs kids. Began construction in November. The 1-26-20 folder in Dropbox is the cross-hatch capture with 396 jpg’s and the 5-1-2020 folder is the single-grid capture with 118 images. Captures were all nadir with P4P using Map Pilot by Maps Made Easy.

Thanks for the handholding. Much appreciated… Bob R.

1 Like

Files won’t finish uploading and be available until after about 5:00pm Eastern. But here’s the link:

Lemmeknow what screen shots would be useful. …R

I’ve exported the ODM deliverables and taken the GeoTiff file from the full default runs #1 and #4 (single grid and cross-hatch respectively) into GEPro as a superoverlay, and they both look excellent. No grainy and no jaggies even with the full default options template. So the ODM output must be fine and the native viewer in the ODM manager is just not showing the potential. Moving on to getting contours on an orthomosaic.