ODM not processing correctly when loading multiple batches of images

When I load a large batch (850 images) of images that is comprised with photos from several flights, ODM seems to only process a small subset of the images if matching is enabled.

The behavior seems to be very similar to “Incomplete output while processing the complete dataset #870”, except that the subset that gets processed seems to be fairly clear, only having spikes around the edges.

The dataset consists of three flights, one from a consistent altitude above the ground, and two separate flights much closer to the ground to capture more detail over certain areas. The goal being to have a reasonable quality orthophoto with higher level of detail in the two areas that were scanned in higher detail.
The result is that only one of the subsets gets made into an orthophoto, with the rest of the data being discarded, seemingly only when using matcher distance?

I’m trying to compile screenshots but the batch takes ~6 hours to run, so it will be a bit for the successful lower resolution map.

Picture is the “failed” processing with the following settings (bounds of the picture are approximately how big the mapped area should be:

Options: rerun-from: dataset, matcher-distance: 3, depthmap-resolution: 1000, ignore-gsd: true, crop: 0, pc-classify: true, dtm: true, dsm: true, dem-resolution: 2.0, orthophoto-resolution: 1, orthophoto-png: true



matcher-distance: 3

this flag means that pairs will be matched with photos that are 3 meters apart.
my suggestion is disable this option (leave 0 to disable) and use the default --matcher-neighbors


I had added that paremeter originally to try and get the engine to incorporate some of the datasets correctly. Only part of the map was imaged as a regular grid flight, some was mapped after in manual flight mode and I’ve found in the past that the seperate parts of the flight don’t often get combined properly when just using regular matching?

I’m trying a re-run with that option turned off.

regarding mission preparation - check the Smathermather blog - all 4 parts of Selft Calibration of Camera.
it’s was a big improvement for my mapping.

backing to the issue - what would I do now:
first - via exiftool list georeference of your’s dataset to the .txt file and display it on map on qgis,
this will visualize your fly path and you will see where the gap are.
secondly - tweek parameters of task. play with --min-num-features, --texturing-nadir-weight, --mesh-size, --mesh-octree-depth.


I generally fly a Pix4D flight planner double grid at 65-75 degree angle (15+ degrees off from Nadir), so the maps come out quite accurate.

The issue here isn’t that there is a gap in the data, but rather that I fly the main cross-grid at around 100 feet altitude (1CM/PX max resolving power of the images) then re-fly over key areas that I want better views of (mainly areas that may have been partially obscured by trees in the initial flight) by manually flying at 15-20 feet altitude and much lower speed, thus capturing many more images of these specific areas.

What then happens is that only one of the areas that I did extra photos of gets processed, and the overall map does not get processed.

Edit to add: I initially started using the matcher settings to try and control how much ram WebODM was using. I ran into issues with it needing more than the 48GB that is assigned to my docker image (I have 64 in the machine but due to windows inefficiencies if I assign more than 48 to docker I get lots of crashes) My hope was that by limiting the matching options I might reduce the processing load by a bit.

Re-running the map with the matching distance turned off, I do get an output, but the areas that I flew over lower to get better detail do not show any better clarity, and in fact seem to have more artifacts when zooming in on them. Possibly this is just the nature of ODM’s toolchain.



Interestingly, the point cloud only shows a tiny bit of the bottom of the map, but does show all the camera positions from the main over-flight… It does however show that something glitched and turned a set of the cameras sideways in the area around the generated portion of the point-cloud… something seems fishy here. I’ll try processing on different settings and see what the result is.


1 Like

i thing increase the --min-num-features to 60000 and --texturing-nadir-weight to 28-32.
sometimes they can help to get more straight and sharp line.
look at the missing guide book there is explained in depth the behavior of ODM.

ps. if you need more stable machine and don’t have a bilion of gigabits of ram :wink: just simply install ubuntu 18 or 20 and run ODM insted od WebODM.
it’s really peace of cake and what’s important can a litle bit of save time and ram


I’ll take a look at those options and see how it goes! Thanks!

I used to run WebODM on a linux box but unfortunately it is now too out-dated to run properly (it’s got pre-virtualization intel Xeon processors that don’t play nice with Ubuntu 18) Currently making do with what I’ve got as money is going elsewhere.

If I keep getting weird camera position glitches on the next run, I’ll post a seperate thread on that as I think that might be a legitimate bug :stuck_out_tongue:

I think what you see here is a deficiency in how OpenSfM is handling multiple altitudes. I am checking in on options.


Awesome thanks!! I’m running this dataset again with slightly different settings, and next time we get sunny weather on a weekend (which might be a bit here in the PNW) I’ll try running another flight set over this area with more altitudes as a test!