Matcher_neighbours no effect

Setting the matcher_neighbours (higher/lower) doesn’t seam to have any effect.

39 images allways gives 515 image pairs (tried 8, 2, 0, …).

Images have exif GPS info

1 Like

What feature_type are you using?

Sift

1 Like

Can you provide the full console log, please?

Looks like no log was received, but I’m wondering about this too.
What does ‘[INFO] matcher_neighbors: 8’ actually mean?

I have a task running with this default setting, and it is still matching pairs. Wondering how far through the process it was, I figured counting how many pairings of an image had been performed might give me an indication of how far there was to go.

One image selected at random has already had 17 pair matchings, so clearly 8 isn’t a top limit, maybe it’s the minimum number attempted?

1 Like

There’s two mechanisms by which image matches are currently computed in ODM (OpenSfM) using GPS coordinates, one is neighbor-based (matcher-neighbors), the other is based on the delaunay triangulation of the GPS points (GPS points are triangulated on the XY plane, all edges are used as matching candidates, plus some “iterative random jittering” to guarantee good graph connectivity). We currently don’t expose a function to disable this second one (I was just debating whether we should). It was added recently with the latest updates to OpenSfM.

It’s controlled it via ODM/osfm.py at master · OpenDroneMap/ODM · GitHub (matching_graph_rounds)

The two mechanisms compute their own set of matches and the resulting matches are the union of the two sets.

2 Likes

Opened Better logic for matcher neighbors · Issue #1450 · OpenDroneMap/ODM · GitHub

1 Like