Does prematching by gps data increase the speed of processing?
And does the prematch mean that every image won’t be tested against every other image?
1 Like
Yes, drastically!
Try --matcher-neighbors 0 and --matcher-distance 0 to see how much longer it takes.
Way more of an impact as the image count rises, but noticeable even for the brighton_beach dataset.
Yes, if the matching parameters are sane, then only “valid” matches should be tested.
If however, you’re using something like --matcher-neighbors 500 on a 200 image dataset…
Now I use matching neighbours 24, matcher distance 20 and gps accuracy 10m.
A least with a clear sky my cellphone can have an accuracy below ten meters so I think my Mavic 2 Pro at 40 meters with a clear sky would get at least that accuracy.
100 images have taken about 3h to compute but 550 images seems to take more that a day. I’m struggling with the math here.
1 Like
Many things in the pipeline do not have a linear relationship or scaling. Matching is one of those.
If we look at a simple set of your 100 images vs 500 images, assuming we do no pre-matching at all, we have this:
100 images matched in pairs
500 images matched in pairs
I’m doing a bit of hand-waving here, but if we take that same example and use 25 images (24 neighbors + matched image) per “group” and assume no repeats, then we’d have:
25 images matched in pairs by 4 groups (100 total images):
x 4 = 1200 image pairs to test
25 images matched in pairs by 20 groups (500 total images):
x 20 = 6000 image pairs to test
So if you can constrain your matching tighter, you can potentially free up a lot of time in SIFT/HAHOG.
Well looking at the readable output then after a day those 500 images is still in the matching phase.
If I went without pre-matching I would get it but with pre-matching I have a hard time getting it. Let’s say the matching of 100 images takes 1 hour then 500 would take 5.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.