Openmvg: opemvg vs colmap( Speed and trajectory)

Created on 24 Sep 2020  ·  4Comments  ·  Source: openMVG/openMVG

@pmoulon
sorry to bother you !!!!!!!!!!!!!
Firstly, we have to admit that the function of openmvg increment SFM is better than colmap. Moreover, openmvg incremental SFM can realize the non rigid registration of GPS, which is equivalent to tightly coupled GPS, and can solve the problem of trajectory bending and drift, as follows (the first figure is the openmvg trajectory, the second is the colmap trajectory, colmap trajectory has obvious curvature)
1 openmvg increment SFM no use gps prior
sfm_openmvg_no_use_gps
2 colmap increment SFM(bending map)
sfm_no_use_gps
3、openmvg increment SFM use gps prior (non rigid registration of GPS)
sfm_openmvg_use_gps

But the speed of openmvg feature extraction and matching is too slow (the first graph is openmvg, the second is colmap, I'm sorry to put the time of feature matching, because openmvg is too slow)
445 frame feature extract
colmap speed
colmap
openmvg speed
opemvg

445 frame feature matching
colmap
colmap matching
openmvg
about More than half an hour(it is too slow, i stop it )
htop

Finally, I would like to ask, how can I improve the speed of openmvg feature matching and extraction?

Thank you for your wonderful work

All 4 comments

The modules of feautre extraction and feature matching in openMVG are based on CPU instead of GPU which is the default option in that of colmap.

  • In terms of CPU-based feature extraction, the speed of openMVG should be the same as that of colmap.

  • In terms of CPU-based feature matching, thanks to the one-to-many index used by openMVG, openMVG is many times faster than colmap.

Finally, I would like to ask, how can I improve the speed of openmvg feature matching and extraction?

@whuaegeanse perfectly sum up the situation. openMVG uses only CPU while the others often uses GPU. So to give enhanced performance, you could try to use some GPU feature extractor/matcher. (siftgpu per ex.)

However, GPU implementation may not be as accurate as the CPU ones, this is notably the case in a PR for a CUDA implementation of SIFT : https://github.com/openMVG/openMVG/pull/837.

Hello @yuancaimaiyi
Thank you for your feedback.
First, you must be aware that OpenMVG and Colmap pipelines are a bit different for the image description and matching process.

|Process | Colmap | OpenMVG |
|---|---|---|
| Feature extraction | GPU SIFT | CPU SIFT |
| Feature Count per image | Limited (max X features) | Unlimited (No Limit) |
| Matching | VocTree + GPS | CascadeHashing or ANN |

Here some tips:

  • Use all the thread you can from your machine (using 15 thread is the max you can do perhaps due to memory reason for feature extraction). You could use -n 32 for the feature extraction stage.

Since you have GPS info I would recommend you use this prior to speed up the matching process by generating only the relevant pair to match. See here https://openmvg.readthedocs.io/en/latest/software/Geodesy/geodesy/#to-speed-up-the-pairwise-feature-matching-step

Note, we are also working on using less feature to speed up matching or SfM by using preemptive matching see here https://github.com/openMVG/openMVG/tree/develop_preemptive_matching

If you're writing the features and matches according to the correct file format that could be feasible.

Was this page helpful?
0 / 5 - 0 ratings