Prematch, the math!

So, I found a way to calculate the numbers for prematching. It was actually in front of me because I made some excel documents with some stuff already.

Matcher distance!
Well this was in fact pretty obvious, if you know the GSD and the width and hight in pixels of your sensor you can easily calculate this distance. If you got an overlap of 50% and the width on the ground is 40 meter then theres 40 meters between the center of the first image to the next.

Matcher neighbours!
So if you got an overlap of 80% how many neighbours does an image have. 100/(100-80)=5 and 5*5-1=24. 24 isn’t totally correct but it’s pretty close, the corner overlap hasn’t been taken into account here.

If someone else has a better way to calculate it I would love to hear it!


One complication- if the drone is flown at a constant height above TO, but the ground elevation varies, then the overlap will vary, and therefore the number of neighbours in the will vary a bit. It probably wont have a huge effect for most situations, but some flight plans I recently flew had over 100m variation in elevation. Fortunately FlyLitchi allows you to vary way point height AGL.

1 Like

There’s always exceptions, maybe som drones can sense the ground level with the sensor looking down.

Only when close to the ground can drones sense how far above the ground they are, generally at <20m. For flying a flight plan, the heights must be programmed in beforehand, either manually or via a file/some other method using Google Earth altitudes (in DroneDeploy and with iphones at least, don’t know of others), but given the inaccuracies in that, I would not rely on it in steep terrain.

And that’s why when I find a money tree my Solo is getting a LightWare SF11/C


We’ve been adding some cool features to OpenSfM lately that greatly improve the matching :slight_smile:

  • matching_graph_rounds uses a triangulation method, which remove any need to tweak the matching_gps_distance value. matching_graph_rounds: 50 and matching_gps_distance: 0 can be used a default values now for ODM. feat: triangulation pair selection · mapillary/OpenSfM@ca219bd · GitHub
  • OpenSfM now support Omega / Phi / Kappa input angles (feat: orientation-based triangulation · mapillary/OpenSfM@1f89d43 · GitHub). For now, OpenSfM doesn’t read the angles directly from the image EXIFs. If anyone writes the code that reads the EXIFs of the image, to the OpenSfM exif file, then these angles would be used to greatly improve the pair selection/pre-match. Using OPK + matching_graph_rounds is a big winner for matching.
  • OpenSfM now supports rig fully.

ping @pierotofy



Awesome improvements Yann ! :clap:

I’m hoping to give a solid update to our OpenSfM branch in the upcoming weeks since we’re a few months behind main.


Astounding stuff, @YanNoun!

Started the process of merging the new changes; hopefully I can make them ready at the next release before year end.


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