matcher_type=bruteforce does not appear to disable GPS-based pair filtering in some cases

[glamine]

How did you install ODM?

Docker, version 24.0.2
ODM version fixed to 3.5.6

---

What is the problem?

When using matcher_type=bruteforce, I expected ODM to match all image pairs regardless of GPS distance. However, when GPS information is present in the EXIF of the images (27 images), the number of matched pairs is significantly reduced (198 pairs ) compared to a run with no GPS data at all (351 pairs), even though image overlap remains ~80%.

This suggests that GPS-based filtering may still be active under matcher_type=bruteforce, contrary to what the name implies.

---

What should be the expected behavior?

All image pairs should be matched regardless of GPS information when matcher_type=bruteforce is set.

---

How can we reproduce this?

I can't share any data as it is proprietary

---

Specific Parameters Used Outside of Default

--3d-tiles \
--skip-orthophoto \
--matcher-type "bruteforce" \
--matcher-neighbors 0 \
--crop 0 \
--min-num-features 25000 \
--feature-quality "high" \
--pc-las \
--pc-ept \
--pc-filter 0 \
--pc-quality "high" \
--pc-skip-geometric

---

Use Case Specificity

This might be related to my slightly unusual use case:

• I’m not using ODM with standard low-altitude drone imagery.
• My dataset consists of high-resolution images taken at higher altitudes (Not the typical drone altitude), with GPS positions that are farther apart, yet with ~80% image overlap.
• This may lead the internal matching heuristics to wrongly discard many valid pairs based on GPS distance.

---

Questions

• Is there any known GPS-based filtering that remains active even when matcher_type=bruteforce?
• Is there a parameter I may have missed to fully disable GPS-based filtering?
• If this is expected behaviour, could it be documented more explicitly?

---

Thank you for the great work on ODM!
Happy to provide the logs if it helps.

Best,
Guillaume Lamine

[disarticulate]

There may a parallel issue here: 6f68270

The matcher algorithm triggers full pair-pair matching if there's any picture without GPS. The matcher algorithm could be improved by segregating photos with GPS and those without, and doing brute force "only when necessary" for those photos.

Am not sure how ODM manages this fork of OpenSfM, the settings are mangled before they get to OpenSfM, as referenced in the pull request.

[glamine]

Thanks for pinpointing this issue! It helped me understand what was going on.

For future readers:

• In this ODM version, setting matcher-neighbors=0 takes precedence over matcher-type=bruteforce.
• That means matcher-neighbors=0 will enforce triangulation instead of brute force, even if you explicitly set --matcher-type bruteforce.
• My workaround is to set matcher-neighbors to a large enough value to effectively approximate brute force while keeping matcher-type=bruteforce.

This solved the first confusion I had.

I am, however, still facing another issue when using GPS:

• Feature matching behaves the same in both runs (351 pairs, ~10,000 good tracks).
• In the GPS run, Ceres Solver logs: INFO: Shots and/or GCPs are well-conditioned. Using naive 3D-3D alignment.
  In the NO_GPS run, there is no such message.
• Both reconstructions end with similar sparse stats:

INFO: Reconstruction 0: 27 images, ~98000 points
INFO: 1 partial reconstructions in total.

• But during densification with OpenMVS:
• GPS run finishes with only ~7,276 points:

  [App     ] Densifying point-cloud completed: 7276 points (3m39s358ms)
  

• NO_GPS run finishes with ~2,239,991 points:

  [App     ] Densifying point-cloud completed: 2239991 points (1m11s578ms)
  

So although matching and sparse reconstruction look healthy, the dense cloud collapses to almost nothing when GPS is present.

A few questions that might help me (and future readers) understand better:

• How can I get access to both sparse point clouds (with and without GPS) for comparison?
• Could this issue be caused by the Ceres solver reconstruction in OpenSfM or the depth-maps estimation step in OpenMVS?
• What exactly does "naive 3D-3D alignment" mean, and could it explain why the dense reconstruction degrades so much?
• Are there parameters to control how GPS data influences the dense reconstruction phase?

I’m not sure yet if this is a bug or simply parameter-related. If preferable, we can continue the discussion on the related forum discussion here.
If anyone has insights on how GPS alignment could lead to such a sparse dense reconstruction, I’d really appreciate it.