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\system.py”, 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.
Thanks!
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…
Could you please provide a link to your dataset on something like dronedb.app (or another cloud sharing site), your processing parameters, and upload the logs from the Tools → View Logs function.
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.
Sorry you’re having issues 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.
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: https://www.dropbox.com/request/y0kfHuhdVOyb7x4XRYZA
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.
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
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.
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.
