I ran an image set through WebODM with mostly the default settings. I ran the same set through Maps Made Easy where you don’t get to set any option.
The WebODM orthoimage was pretty good but the MME product was obviously better. I have no idea if that is just because the MME processor is just better. Or if the default settings are not the best for the set I used. The surface was mostly bare ground (stock pile storage) and the images were captured with an 80% front and 75% side overlap from 300’ using a Phantom 4 Pro.
Any recommendations on how I could improve upon the results using WebODM would be appreciated.
Hello, could you share the resulting orthophotos (from both software) so that we might compare the results and provide possible suggestions?
Sure.
https://www.dropbox.com/sh/1k4ib9d95x82pkp/AADwI4Sya1LhMzfdcfYNzUjWa?dl=0
There was heavy overcast that day so lighting was not the best. But the same set was used in each processor.
Most of the deformation seems to be around structures when compared to MME, so I would try to increase:
To reduce the white slivers try to turn on:
- –texturing-skip-visibility-test
Also try to use “area” instead of “gmi”:
- –texturing-data-term area
Finally try to turn on:
You might want to mix and match these to see if the results improve.
Oh, starting from tomorrow, if you update your processing node (via ./webodm.sh update) you should also try --fast-orthophoto which we just added today, https://github.com/OpenDroneMap/OpenDroneMap/pull/736 )
1 Like
Thanks for the help. I will give it a try. The --fast-orthophoto sounds interesting. I wonder if it’s fast enough to process on-site to verify the image set before leaving the project.
Quick question Piero. Is there a technical reason why ODM cannot be compiled into an executable application, self contained with whatever tool kits are needed? Is it because of licensing issues or something else?
Thank you,
Dave
The reason we don’t have a simple executable is mostly because the dependencies that ODM relies on are themselves not packaged. In turn those dependencies often rely on libraries that are not packaged and the effect trickles up.
It would take a massive effort to package everything into a small set of executables. We’d love for somebody to put efforts toward that!
Processing with the above changes error-ed out this time after 2 1/2 hours. 
Error log:
https://www.dropbox.com/s/48pbn60cc1k7gsb/task_output.txt?dl=0
I tried it again this morning with a sub-set of the images. It returned the same error as the complete set.
Interestingly, there is a note saying
“Process exited with code 1” means that part of the processing failed. Try tweaking the Task Options as follows:
Increase the min-num-features option, especially if your images have lots of vegetation
Enable the use-pmvs option."
use-pmvs was enabled.
I can go back to the default settings and see if it will process. Remember these images processed with the prior build of WebODM (I installed the latest version) and the only options I remember changing were “high quality” and “complex non-forest”. Something is different now I guess.
I ran the sub-set of images through MapsMadeEasy and it processed fine. A .jpg from that process is in the folder below as well.
I have made available the sub-set of images along with the options I used and log here:
https://www.dropbox.com/sh/78vbic7irw106fu/AAA0G-rM9fl2ZJ8l1vVcA6YJa?dl=0
Update 1: I ran the process with all default except: non-forest-complex and it completed. A report and image is included in the folder test-2.
Update 2: Ran the process again with the options you suggested and this time it worked. Unfortunately, the image is worse than with the default settings. More distortion and holes. It is in the folder test-3.
Would it be possible for you to share the entire datasets (266 images)? The log you attached shows that the texrecon program aborted for some reason.
Perhaps this is related to a race condition that was fixed in Fix race condition in continuation nvm and cam/folder scenes · nmoehrle/[email protected] · GitHub but hasn’t been merged into ODM yet.
Or maybe it’s a problem with the --fast-orthophoto setting. In any case, having a copy of the dataset would help to identify the problem.