I am a PhD student at the University of Bern in Switzerland and currently evaluating the potential of low-cost UAVs and open-source photogrammetry software for high-resolution glacier monitoring in alpine environments. In our recent project, we draw on the open-source hardware and software project Papaparazzi UAV for mission planning/monitoring and on WebODM/ODM for the processing of acquired aerial images. First of all I would like to thank you - the ODM developers and community - for all your efforts during the last years regarding the development of a robust and powerful open-source photogrammetry software like ODM!
I started to process aerial images from our five glacier surveys during 2017 and 2018 in ODM (v. 0.3), but switched to WebODM (API version 1.1.1) recently. When comparing the ODM and WebODM orthophotos and DEMs, I noticed two things:
The quality of the DEM (in terms of artifacts) improved impressively from the older ODM version 0.3 to the newer WebODM version (see uploaded data). Great work!
However, the WebODM orthophoto seems more blurry in contrast to the ODM (v. 0.3) orthophoto (see uploaded data) despite the same spatial resolution (10 cm), same input data and similar processing settings. In addition, the WebODM and ODM orthophotos (based on the same input data and similar processing settings) do not match. The WebODM is shifted by ca. 15 m. Oddly enough, both DEMs (WebODM vs. ODM) match perfectly.
So far I couldn’t identify/reproduce the error. Do you have any ideas, recommendations or information of similar cases reported before? Thanks in advance for your support!
How did you install WebODM? (Docker, natively, …)?
Natively on a Unix server
What’s your browser and operating system? (Copy/paste the output of https://www.whatismybrowser.com/)
Firefox 57 on Ubuntu Linux
What is the problem?
See explanation above. Lateral shift in the order of ca. 15 m between the orthophoto and DEM generated with WebODM. However, the output orthophoto and DEM match perfectly if the same input data are processed with ODM (v. 0.3) using similar settings.
What should be the expected behavior?
The orthophoto and DEM generated with WebODM should match.
The texture of the WebODM orthophoto should be less “blurry” and comparable with the texture of the ODM (v. 0.3) orthophoto since same aerial images and similar processing settings were used.
For the blurriness, the first thing that comes to mind is --ignore-gsd (you should try to reprocess by turning on that option in WebODM), which is an optimization and is a recent addition to the software.
I’m not sure about the georeferencing difference between ortho and DSM, I will look further into it.
–ignore -gsd “on” worked perfectly. The quality of the WebODM orthophoto is now similar to the older ODM orthophoto. So one issue is solved. However, the georeferencing difference between ortho and DSM remains.
Sorry, I included the wrong version of the shapefile. The GCP file you loaded in the interface is correct.
Unfortunately, I cannot patch the recommended line right now due to limited user rights on our server…
I did some more tests:
I reran WebODM without any GCPs. The xy accuracy of the output orthophoto is ca. 2 - 4 m (that’s actually pretty nice considering no GCPs were used). The shift between orthophoto and dsm didn’t occur anymore.
I generated a separate orthophoto and dsm of the glacier in WebODM using images from another flight (2018-09-29). The shift between orthophoto and dsm also didn’t occur in this case. However, like in all our other tests (with ODM and WebODM) before, the orthophoto/dsm is not georeferenced precisely. There is always an offset at the GCPs in the final output in the order of ca. 0.5 - 2 m (see images below). If we process the same images with the same GCPs in Pix4D, the orthophoto/dsm and GCPs match (see image below). Do you have any recommendation which settings or processing steps we could modify to enhance the accuracy of the WebODM results?
I checked all GCPs in the GCP interface. Some GCP objects (e.g. rocks) are not an ideal choice (limited contrast), but they are all referenced correctly/precisely in the pictures. I think this is not the source of the inaccuracy.
I also checked the WebODM log file and camera settings again. There is only one warning: “Could not find ccd_width in file. Use --force-ccd or edit the sensor_data.json file to manually input ccd width”. Could this have an influence?
All data and outputs (ODM, WebODM, Pix4D) of the 2018-09-29 flight are available here (2.6 GB): https://filesender.switch.ch/filesender/?vid=084ad4c1-5526-ab88-0276-0000736cfc17
Offset between GCP (measured with differential GPS) and Pix4D orthophoto (ca. 0 m)
@pierotofy many thanks for your effort and the latest updates! I very much appreciate your prompt answers and elaborated modifications to fix the reported bugs! I will try to update ODM/WebODM to the latest version within the next days and reprocess the dataset(s). I will report as soon as I have any news.
@denisot thanks for sharing! I am also curious about your findings.
Hello.
Just an update. I’m doing some tests with the new version with very mixed results until now:
on a dataset I had which had a big misalignement issue, the problem is worse now (before the orthophoto was truncated but correctly positioned, now the orthophoto is wrongly shifted by 500m). That was with a WebODM update done on february 18th. I can’t check the point cloud (PC) against my GCP since there is no color in the csv PC, and I never could use .laz PC (liblas configuration error). I didn’t find how to generate .ply files like I used to.
I updated again WebODM yesterday night (feb. 19th, 8p.m. french time), and the process on the same dataset got stuck in the SFM step.
Finally with the same WebODM version, I tried the dataset I made available here, on which @pierotofy had positive results, and I can’t even download the assets.
So all in all, I’m struggling. But I’m keeping faith!
@pierotofy and @denisot I updated ODM (version 0.4.1, 2019-02-18) and reprocessed both datasets. The preliminary results are satisfying! Orthophoto and DSM are perfectly aligned. Three GCPs in each orthophoto match perfectly, but some GCPs still have an offset of ca. 1m (as discussed here). If necessary, I will continue the discussion in the other thread.
thanks for all the details!
