Native Windows ODM Does Not Work - Errors Everywhere

We have used the Docker version of ODM for a couple years. It had its issues, but it at least worked (usually).

Now, we paid to download and install the Native Windows ODM. It has been a nightmare and we have been unable to get it to complete even a single job.

the System Specs are Dual Xeon Processors (12 cores each), 128GB RAM

We have some photos that we imported from the same drone that we have always used, with the same settings as always. We import the photos, and the processing begins. About 90 minutes into the job, it always generates an error.
Here is the log output:

"File “D:\WebODM\resources\app\apps\ODM\opendm\”, line 106, in run
raise SubprocessException(“Child returned {}”.format(retcode), retcode)
opendm.system.SubprocessException: Child returned 1

===== Done, human-readable information to follow… =====

[ERROR] Uh oh! Processing stopped because of strange values in the reconstruction. This is often a sign that the input data has some issues or the software cannot deal with it. Have you followed best practices for data acquisition? See Flying Tips — OpenDroneMap 2.5.5 documentation"

We tried the SAME PHOTOS on Metashape, and it had ZERO issues processing them. We also loaded the same image set into WebODM that runs on Docker, and the job was a success. This Native Windows ODM is proving to be problematic, and a failure.

Any usable advice would be greatly appreciated.

i am running the native Windows installer on a dual xeon w 32gm (win 7 pro) and am getting great results…1.9.0 version 14

i installed webodm on an external 1tb ssd…and I plug that into the usb port of the Dell xeon workstation…

all my images are also on a folder on the same ssd, and i just invoke the WebOdm.exe off the ssd to start the show,
and save the output to the ssd as well.

this is akin to a liveodm version probably, ala windows.

jobs up to 815 images completed so far, ortho, dsm, dtm on high resolution.

i run webodm as “clean” as i can, no other processes in the background…

1 Like


Sorry to hear that you’re having such trouble.

Could you please provide a link to your dataset on something like (or another cloud sharing site), your processing parameters, and upload the logs from the Tools → View Logs function.

Also, are you on the latest release (R22)?

1 Like

Hello Saijin,
Thank you for the response.
We are on the latest 22 release v1.9.1.
We mainly used the default settings. However, we tried a few different settings at different re-attempts with the same results.

Here is a link to the dataset, and the logs:

1 Like

Hmm… Really interesting. Processing time was about 16min on a rather paltry single i7-6700k and 32GB RAM.

I was able to process the dataset successfully with these settings:

Options: crop: 0, debug: true, dsm: true, verbose: true


Sorry you’re having issues :pray: we’ve had sporadic reports of the native version not working well on certain hardware; unfortunately we don’t have all of these machines available to test, so we’re discovering issues with these as we go. Good news is, we’re working to fix these issues as quickly as we receive reports, and you can continue to use the docker version in the meanwhile. Seems an issue with OpenMVS from the task log.

Can I send you a patched version of the OpenMVS binaries to see if they fix the problem within the next few days? It would help us tremendously.


Hi Piero, please could you send me the OpenMVS binaries patched version? because i have issues me too.

Thank you and best regards

1 Like

What are the specs of your machine (processor)?

Thank you, Pierotofy,
You are certainly welcome to send the patched binaries. Could you provide the path to drop them into, also? Feel free to post them to this Dropbox link:

1 Like

Thank you, Saijin,

Your results are interesting, indeed.
It looks like the orthomosaic only processed a few of the photos, but the DEM processed more.
However, the DEM is still missing some of the photos. Here is the ortho export from Metashape, using the same photo set.

1 Like

Our specs are: Dual Xeon Processors (12 Cores Each), 128GB DDR4

1 Like

Sure, however, are you sure this is the same issue? Can you post the task log of one of your tasks?

1 Like

I wouldn’t trust the data on the extra areas of the DEM. Looks like interpolation, not real data.

I’m curious about metashape’s reconstruction, especially given how few photos are in the area it filled in.

Upon further inspection, this actually looks more of a problem of PoissonRecon rather than OpenMVS.

@HighTechHillbilly could you try to:

Re-run the same dataset, with the same settings.

Does it work then?


We have replaced the file with the new one from the zip package, and are re-running the job, now.
Thank you

We re-ran the job, after replacing the file that you recommended.

The good news is that the job completed without errors!
The Orthomosaic looks correct, with all images processed.

However, the DEM looks a little strange. (see screenshot)

Thank you for looking into this.

1 Like

Thanks for testing and helping us reproduce it!


I wish everyone was as good at sourcing issues as you are.

Will the fix be applied to the next release?
I would love to download the next release, if it will be patched.

1 Like

I don’t have visibility into that at this point, but I think some changes in WebODM 1.9.2 R23 are worth looking at, regardless (unless you have metered internet and you need to conserve bandwidth):

Piero is quite responsive and I’m sure he’ll let you know when he’s got the issue ironed out :slight_smile:

I wish I could reproduce it locally here so I can confirm if v1.9.2 R23 fixes it, but sadly, my stuff is too old to be exhibiting the behavior you and a few others are hitting.

1 Like