OpenDroneMap / OpenDroneMap/ODM
matcher_type=bruteforce does not appear to disable GPS-based pair filtering in some cases
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 6.5k
- Forks
- 1.3k
- Avg merge
- 5d 6h
- Merged PRs (30d)
- 4
Description
Hi ODM team,
I’ve encountered a potential issue with the matcher_type=bruteforce option in ODM (version 3.5.6). Despite setting this option, not all image pairs are being matched — suggesting that GPS-based pre-filtering may still be happening internally.
🔍 Context
- I’m running ODM with the following config:
matcher_type: bruteforceuse_exif: Falseforce_gps: False
- The image dataset has 27 images, all with positional information provided manually (i.e., via external XML metadata, not EXIF).
- The matcher's job should be to compare all pairs, yet the logs show fewer pairings in the GPS_ONLY version of the run.
Full ODM Parameters Used
[INFO] Initializing ODM 3.5.6 - Tue Aug 05 13:55:50 2025
[INFO] ==============
[INFO] 3d_tiles: True
[INFO] align: None
[INFO] auto_boundary: False
[INFO] auto_boundary_distance: 0
[INFO] bg_removal: False
[INFO] boundary: {}
[INFO] build_overviews: False
[INFO] camera_lens: auto
[INFO] cameras: {}
[INFO] cog: False
[INFO] copy_to: None
[INFO] crop: 0.0
[INFO] dem_decimation: 1
[INFO] dem_euclidean_map: False
[INFO] dem_gapfill_steps: 3
[INFO] dem_resolution: 5
[INFO] dsm: False
[INFO] dtm: False
[INFO] end_with: odm_postprocess
[INFO] fast_orthophoto: False
[INFO] feature_quality: high
[INFO] feature_type: dspsift
[INFO] force_gps: False
[INFO] gcp: None
[INFO] geo: None
[INFO] gltf: False
[INFO] gps_accuracy: 3
[INFO] gps_z_offset: 0
[INFO] ignore_gsd: False
[INFO] matcher_neighbors: 0
[INFO] matcher_order: 0
[INFO] matcher_type: bruteforce
[INFO] max_concurrency: 32
[INFO] merge: all
[INFO] mesh_octree_depth: 11
[INFO] mesh_size: 200000
[INFO] min_num_features: 25000
[INFO] name: code
[INFO] no_gpu: False
[INFO] optimize_disk_space: False
[INFO] orthophoto_compression: DEFLATE
[INFO] orthophoto_cutline: False
[INFO] orthophoto_kmz: False
[INFO] orthophoto_no_tiled: False
[INFO] orthophoto_png: False
[INFO] orthophoto_resolution: 5
[INFO] pc_classify: False
[INFO] pc_copc: False
[INFO] pc_csv: False
[INFO] pc_ept: True
[INFO] pc_filter: 0.0
[INFO] pc_las: True
[INFO] pc_quality: high
[INFO] pc_rectify: False
[INFO] pc_sample: 0
[INFO] pc_skip_geometric: True
[INFO] primary_band: auto
[INFO] project_path: /code
[INFO] radiometric_calibration: none
[INFO] rerun: None
[INFO] rerun_all: False
[INFO] rerun_from: None
[INFO] rolling_shutter: False
[INFO] rolling_shutter_readout: 0
[INFO] sfm_algorithm: incremental
[INFO] sfm_no_partial: False
[INFO] skip_3dmodel: False
[INFO] skip_band_alignment: False
[INFO] skip_orthophoto: True
[INFO] skip_report: False
[INFO] sky_removal: False
[INFO] sm_cluster: None
[INFO] sm_no_align: False
[INFO] smrf_scalar: 1.25
[INFO] smrf_slope: 0.15
[INFO] smrf_threshold: 0.5
[INFO] smrf_window: 18.0
[INFO] split: 999999
[INFO] split_image_groups: None
[INFO] split_overlap: 150
[INFO] texturing_keep_unseen_faces: False
[INFO] texturing_single_material: False
[INFO] texturing_skip_global_seam_leveling: False
[INFO] tiles: False
[INFO] use_3dmesh: False
[INFO] use_exif: False
[INFO] use_fixed_camera_params: False
[INFO] use_hybrid_bundle_adjustment: False
[INFO] video_limit: 500
[INFO] video_resolution: 4000
[INFO] ==============
[INFO] Running dataset stage
[INFO] Loading dataset from: /code/images
[INFO] Loading 27 images
[INFO] Wrote images database: /code/images.json
[INFO] Found 27 usable images
Specific Observations
- Using
matcher_type=bruteforce, I expected all image pairs to be tried. - However, in the "GPS_ONLY" version of the run (which uses the same parameters, only with image positions and altitude specified in the exif data), the number of matched image pairs is significantly lower than in the "NO_GPS" version, where GPS metadata was removed.
- This suggests that GPS filtering is still being applied, even when using bruteforce matching.
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 logs or a sample dataset if it helps.
Best,
Guillaume Lamine
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how matcher_type=bruteforce, use_exif=False, and force_gps=False are handled during matching, then compare the GPS_ONLY and NO_GPS runs described in the issue. Reproduce with the 27-image setup if available and verify whether bruteforce attempts all image pairs or whether GPS-based filtering remains active.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- computer-vision
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100