OpenSfM Processing Time

With large datasets processed in ODM, eventually the SfM portion of the toolchain becomes the predominant bottleneck. This is expected and is quite nicely reduced in effect by the incremental reconstruction technique in Incremental reconstruction algorithm — OpenSfM 0.4.0 documentation.

Never-the-less, I wanted to understand the effect better with a long-running 8k+ dataset. We statically fix bundle_interval which is the main knob on the exponential increase in time with SfM. It defaults to 100, which means the global check on the incremental approach gets triggered every 100 images. In other words, images are added to the reconstruction 1 at a time with local matching and orientation, and then every 100 images, the whole pose model is adjusted to make all the cameras consistent globally. Incremental in this case is a local/global approach unique to OpenSfM, and borrows from video SLAM approaches in order to have global-like accuracies with something closer to local SfM efficiencies.

We can see when this 100th step happens in the logs, e.g.:
docker logs unruffled_dhawan | grep "naive"

2022-04-07 04:48:23,187 INFO: Shots and/or GCPs are well-conditioned. Using naive 3D-3D alignment.
2022-04-07 11:07:46,208 INFO: Shots and/or GCPs are well-conditioned. Using naive 3D-3D alignment.
2022-04-07 16:48:51,795 INFO: Shots and/or GCPs are well-conditioned. Using naive 3D-3D alignment.

If I plot this sequence of additions according to time for the first 3500 images, I get something I expect, a exponential curve:


But at image 3600, it gets pretty interesting:

This is a pleasant surprise. What kind of magic is this?


How does your flight pattern look like?

Re-alignment will get triggered every 100th new camera (assuming you’re using --use-hybrid-bundle-adjustment) - or - when the point count increases by 20%; if you’ve flown a cross pattern for example, I could expect fewer points to be added during the addition of cross-pattern images, which might explain the time observations.


Each of those points in the graph is every 100th image.

Flightwise, it is nothing complicated. This is a set of flights originally intended for aerial imagery, so no extra effort to improve calibration or 3D outputs, just lost of flight blocks and a couple different camera platforms, i.e. standard mower patterns:


I meant to specify: the two different colors are different cameras used – both global shutter, fixed lens, just different models.


Ok, digging a little deeper and labeling things appropriately and with Piero’s hint that it’s more than just bundle_interval that triggers when bundle adjustment events, this is what we see when we plot bundle adjustment events against time:

And if we just look at the number of frames added by time, it looks, unsurprisingly a lot more linear:

But the mystery remains: why / how does the time for each bundle adjustment stop increasing exponentially in time and start a second and third exponential increase? Is this just the influence of the arrangement of my data or something clever in the underlying algorithm to limit exponential increases in time for bundle adjustment?


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.