What is your biggest pain with ODM / OpenSfM?

[InsertUser]

I don’t use it very often but when I (ab)use WebODM it is on a resource constrained machine with image sets that are far from ideal so feel free to disregard all of this as not reflecting the target user group.

The most common failure is due to lack of memory and the reason why is often quite opaque so it’s difficult to know what to tweak in the settings or whether it’s best to just give up. If there was an option to offload as much as possible to the SSD rather than keep it all in RAM I think that would be quite helpful.

There are also times when I feel like it would be nice to be able to review the proposed feature matches between images and manually remove bad matches before OpenSFM tries to do the reconstruction^[1]. I expect panorama generation is a much simpler process with far fewer points needed, but Hugin provides an interface for this that is very helpful when an image ends up dramatically misplaced^[2]. At the moment it seems like the only option is to change a few options and hope for the best on a new run.

---

1. e.g. when the resulting point cloud shows clear examples of a feature getting repeated in two separate locations ↩︎

2. it also lets you manually define matching points if the automatic tools fail but this might be impractical when you need a 3D solution for the camera locations. ↩︎

[lupionpe]

Hi all,

One possible “pain point” that might fit this list is georeferencing/CRS consistency in cases where the reported metrics look fine, but the result is clearly off in real-world coordinates.

I ran into a case where the GCP errors looked very good, but the alignment “in reality” was not consistent. The discussion is here: GCP show very good results, but is not what I see in reality

Yann later shared a fix on the OpenSfM side (consistent proj/transform handling), which improved results significantly in that dataset: Commits · YanNoun/OpenSfM · GitHub

And there is also an ODM PR related to this topic: Try to fix georeferencing accuracy by originlake · Pull Request #1851 · OpenDroneMap/ODM · GitHub

My question (mostly to avoid duplicating work): is this class of CRS / proj-transform issue still present in current ODM/WebODM releases, or has it already been integrated somewhere? If it’s not fully merged yet, I’m also curious what the preferred path is (e.g., backporting into ODM, additional validation, test coverage, etc.).

Happy to help test with the same dataset again or provide any reproducible notes if that’s useful.

[smathermather]

@lupionpe

My question (mostly to avoid duplicating work): is this class of CRS / proj-transform issue still present in current ODM/WebODM releases, or has it already been integrated somewhere? If it’s not fully merged yet, I’m also curious what the preferred path is (e.g., backporting into ODM, additional validation, test coverage, etc.).

This is not yet merged, but good to highlight again here for Leonardo to see as he puts together a prioritized list.

@InsertUser

The most common failure is due to lack of memory and the reason why is often quite opaque so it’s difficult to know what to tweak in the settings or whether it’s best to just give up. If there was an option to offload as much as possible to the SSD rather than keep it all in RAM I think that would be quite helpful.

Noted! Yes, reduction of RAM use and also better prediction of RAM use is important.

@InsertUser

There are also times when I feel like it would be nice to be able to review the proposed feature matches between images and manually remove bad matches before OpenSFM tries to do the reconstruction

Ooh, that’s a fun feature request. I wonder if something could be cobbled together with Yann’s 3D quality report, at least for a proof of concept.

[Connah-rs]

Hi everyone,

I’m bringing over some thoughts from a recent GitHub issue (#2001) where I mentioned I’d share some broader feedback regarding image versioning and general usage. For context, I run ODM in a headless capacity as part of automated data pipelines on Kubernetes/GCP.

Here are my main pain points and some potential solutions:

1. Docker Image Tagging / Versioning
Currently, the :gpu tag on Docker Hub tracks master, which means it functions as a floating/edge tag. For those of us running automated production pipelines, pulling a floating tag can introduce sudden breaking changes. It would be incredibly helpful to publish stable, versioned tags for GPU images (e.g., opendronemap/odm:gpu-3.x.x) alongside the CPU versions to ensure infrastructure stability.

2. Developer Experience & Docker Build Times
I completely agree with @spwoodcock regarding the slow setup and building process. Currently, the Dockerfiles copy all local files right at the beginning of the build. This means that even a one-line change to the Python code invalidates the Docker cache and triggers a lengthy, full recompilation of the C++ SuperBuild.

I’ve been using a modified Dockerfile locally that splits this into three distinct cache layers:

1. Run the C++ SuperBuild
2. Install Python requirements (requirements.txt)
3. Copy the Python app code

This makes iterating and testing small Python changes significantly faster. If there’s interest from the maintainers in adopting this approach, I’d be very happy to submit a PR!

3. High Memory Consumption
Echoing what others have noted in this thread, the processing memory requirements can scale very aggressively. In our GKE cluster, we regularly have to route tasks to machines with 416 GiB of RAM for larger datasets. We currently manage this by dynamically provisioning larger machines based on the input dataset size, and using split-merge as another workaround, but any core optimisations to lower peak memory usage would be a massive win.

It would also be very helpful to have a better way to predict/extract RAM usage. That would make it much easier to set resource requests dynamically for processing tasks - we currently rely on a mapping based on dataset size which can be temperamental/inefficient.

Thanks to all the maintainers for building such a fantastic tool. I’m very happy to help out with PRs where I can!

[Lucky_Luke]

Simple, without GCPs, 3D terrain models are completely flawed. Especially on sloped terrain, even slightly. With an RTk drone, the program is completely unreliable.
Point cloud output is difficult to use with surveying programs.
I’m speaking after using AUTEL MAPPER and METASHAPE, which, on the other hand, output point clouds virtually identical to GPS surveys even without GCPs.
You need to create fewer presets, but they’re more precise.
I stopped using WEBODM when I realized it wasn’t viable for producing documentation.

[DodgySpaniard]

Thank you for the feedback Lucky_Luke. It’s sad to hear that ODM couldn’t be useful for you. Could you be so kind as to provide us with some data samples so we can properly benchmark our current shortcomings?

[smathermather]

Reminded of this issue by Lucky_Luke’s post:

Reconstructing models from multiple levels (aerial and ground), initial findings

Ok my friends. I present to you my findings on combining ground level photos with aerial imagery in a cohesive and fantastic model. Now, there are some limitations to this model: one set of photos was taken on a sunny day at sunset and the other on a partially cloudy day a couple hours before sunset. In addition to lighting differences, we can expect challenges from differences in GPS between days (we cannot rely on lower relative error for short flights). But the challenges are an important par…

We do have model initialization / rotation issues both in degenerate cases like I post (terrible GNSS accuracy on ground level shots) but also in subtler ways with a variety of datasets.

I would be interested if we have other datasets that exhibit this behavior. I feel like @Kerrowman and @Gordon have shown examples.

[Lucky_Luke]

It’s simple, take a flight on a sloped terrain, even slightly, and compare the webodm model with one from other, a program like Autel Mapper which is free for 4 months and has ground points detected by GPS. I used an Autel Eco 2 RTK v3. At first, I thought the drone was having problems, given the differences between the model and the GPS measurements. However, if I model the same photos with Metashape, (1 month trial) The model differs only by a few centimeters from the GPS measurements. Another problem is that the point clouds are very dirty, especially vertically, and the contour lines are superimposed unnecessarily.I repeat, I have tried many combinations of presets and custom presets, photo grids, etc. etc.Try it out as I wrote, it’s easy; you don’t need user photos. Photos aren’t the problem. I always fly with the recommended settings.

The forum is full of posts, but almost all of them are from people who don’t use drones professionally like I did. Many use them as a hobby and have no idea what they’re doing or using. Just read the forum.

[DodgySpaniard]

Thank you for your input Lucky_Luke, I gather from your comments that the main issue you are facing is due to sloped terrain; for that, I have several ideas on what may be causing your issue, most likely missing/incorrect position and orientation priors. An actual data sample and the settings/version would be useful to debug it further.

I appreciate that you are frustrated due to “wasted” time testing ODM. However, regarding this part:

@Lucky_Luke

The forum is full of posts, but almost all of them are from people who don’t use drones professionally like I did. Many use them as a hobby and have no idea what they’re doing or using. Just read the forum.

We deeply value our community members. While many users are hobbyists or just learning, there are plenty of professional users who are extracting value from ODM, granted that they may not be as active on the forum (they usually have their own forks and seldom require support). Nevertheless, I hope you can use a more constructive and encouraging language moving forward. I am sure the community will appreciate your expertise.

[ricardoarce]

As mine basic level user ,the roof issue, metal or tiles are fighting against the algorithm and done artifacts, and title to the report the name project , and add the flight Height and overlap % of pictures can help for basic users to improve future taslk by “ try and error “. Thanks edit also to add the camera name near to the name project of the report.

[Lucky_Luke]

Question… If my dataset is incorrect, how is it possible that using Metashape the results from GPS ground control measurements are perfect? Even in the presence of elevation changes.

I have an RTK drone that works very well, I have 2 Sokkia GPS, I have a Sokkia total station, I have topography programs, I have 25 years of work to know what I’m talking about.

[DodgySpaniard]

Lucky_Luke, our current data handling requires a lot of piping across the different layers, meaning that the data could be fine, but along the way, it contains something that causes our software to “drop” parts of it or, worse, “interpret” the wrong values. It can also be a missing feature/bug on our side, too. Yann N. did some great work, and among other things, he added OPK angles fixes; you can see it here OpenSfM torch passing

In general, having good priors, i.e. camera intrinsic (calibration) and extrinsic (GPS+Orientation), makes a huge difference in SfM performance, and it is likely the root cause of many of the issues we experience.

On the point clouds being “noisy”, AKA “fairy dust”. My guess is that we are too lenient with “feature matches” across images. This is a known tradeoff for OpenSfM as it optimises adding as many images to the reconstructions as possible over “quality”. To be honest, this is hard to quantify as we stand now.

Our focus for the year is going to be on the quality and robustness, and to be successful, we are going to need as much feedback and data as possible. So, let me shamelessly ask for sample data once more

[YanNoun]

Yes, we need more data, happy to have a look.

[YanNoun]

If you have any legitimate interest in making OpenDroneMap a better software, this would help us correct it : if it work with Agisoft, we want to make it work on ODM.

[YanNoun]

Yes, but if you don’t share data so we can reproduce the problem and your observations, all of this work is completely useless for the maintainers.

[smathermather]

Missed this response from @Darafei Praliaskouski on bluesky:

Something is wrong with reconstruction that has duplicated filenames, which happens when drone wraps around to next 1000. I don’t know what it is but when I rename all files to be unique stuff that failed builds. - there’s a pull request from Aliaksandr Hancharenka to sfm to use dji yaw/pitch/roll data for better pairing of off-nadir imagery, Added functionality to pair images with Field Of View Cones by aliaksandr960 · Pull Request #1090 · mapillary/OpenSfM · GitHub - reeeally need something like that for matching views on the city from different sides without forcing to review all pairs.

[smathermather]

One additional challenge on the general photogrammetry side: if a dataset is processed in ODM and that dataset doesn’t contain GNSS data, reconstruction often fails due to a problem estimating appropriate resolution for orthophotos. It is usually possible to filter the dataset for outliers by grabbing the opensfm/openmvs/ ply, editing, and feed it back into the process, but this is tedious and error prone.

[INFO]    Finished odm_filterpoints stage
[INFO]    Running odm_meshing stage
[INFO]    Writing ODM Mesh file in: /var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_meshing/odm_mesh.ply
[INFO]    running "/code/SuperBuild/install/bin/PoissonRecon" --in "/var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_filterpoints/point_cloud.ply" --out "/var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_meshing/odm_mesh.dirty.ply" --depth 11 --pointWeight 4.0 --samplesPerNode 1.0 --threads 4 --bType 2 --linearFit
[INFO]    running "/code/SuperBuild/install/bin/OpenMVS/ReconstructMesh" -i "/var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_meshing/odm_mesh.dirty.ply" -o "/var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_meshing/odm_mesh.ply" --archive-type 3 --remove-spikes 0 --remove-spurious 20 --smooth 0 --target-face-num 400000 -v 0
03:25:08 [App     ] OpenMVS x64 v2.2.0
03:25:08 [App     ] Build date: Aug 20 2025, 06:03:53
03:25:08 [App     ] CPU: QEMU Virtual CPU version 2.5+ (20 cores)
03:25:08 [App     ] RAM: 62.79GB Physical Memory 128.00GB Virtual Memory
03:25:08 [App     ] OS: Linux 6.17.0-23-generic (x86_64)
03:25:08 [App     ] Disk:
03:25:08 [App     ] warning: no AVX compatible CPU or OS detected
03:25:08 [App     ] Command line: ReconstructMesh -i /var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_meshing/odm_mesh.dirty.ply -o /var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_meshing/odm_mesh.ply --archive-type 3 --remove-spikes 0 --remove-spurious 20 --smooth 0 --target-face-num 400000 -v 0
03:25:08 [App     ] MEMORYINFO: {
03:25:08 [App     ] 	VmPeak:	  173108 kB
03:25:08 [App     ] 	VmSize:	  121628 kB
03:25:08 [App     ] } ENDINFO
[INFO]    Writing ODM 2.5D Mesh file in: /var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_meshing/odm_25dmesh.ply
[INFO]    ODM 2.5D DSM resolution: 0.01
[INFO]    Created temporary directory: /var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_meshing/tmp
[INFO]    Creating DSM for 2.5D mesh
[INFO]    running renderdem "/var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_filterpoints/point_cloud.ply" --outdir "/var/www/data/adbebdd6-968d-4248-8af5-ab641961dbb4/odm_meshing/tmp" --output-type max --radiuses 0.015707963267948967,0.022214414690791835,0.03141592653589794 --resolution 0.01 --max-tiles 18 --decimation 1 --classification -1 --tile-size 4096 --force
Reading 3829637 points
Point cloud bounds are [minx: -39.2257003784, maxx: 86.3854827881, miny: -85.7704467773, maxy: 117.738388062]
DEM resolution is (12562, 20351), max tile size is 4096, will split DEM generation into 20 tiles
Max tiles limit exceeded (18). This is a strong indicator that the reconstruction failed

===== Dumping Info for Geeks (developers need this to fix bugs) =====
Child returned 1
Traceback (most recent call last):
File "/code/stages/odm_app.py", line 82, in execute
self.first_stage.run()
File "/code/opendm/types.py", line 470, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 470, in run
self.next_stage.run(outputs)
File "/code/opendm/types.py", line 470, in run
self.next_stage.run(outputs)
[Previous line repeated 3 more times]
File "/code/opendm/types.py", line 449, in run
self.process(self.args, outputs)
File "/code/stages/odm_meshing.py", line 54, in process
mesh.create_25dmesh(tree.filtered_point_cloud, tree.odm_25dmesh,
File "/code/opendm/mesh.py", line 25, in create_25dmesh
commands.create_dem(
File "/code/opendm/dem/commands.py", line 90, in create_dem
system.run('renderdem "{input}" '
File "/code/opendm/system.py", line 112, in run
raise SubprocessException("Child returned {}".format(retcode), retcode)
opendm.system.SubprocessException: Child returned 1