Openmvg: Comparison with commercial applications

[madmage]

Dear all,
I am doing some comparison between openMVG and commercial applications, namely PhotoScan and Reality Capture. The first thing I would like to obtain is a working real-world experiment. I have about 2000 photos and I want to build the sparse cloud + camera registration. If I put the images inside the commercial applications, within some hours of computation, I have (almot) all the cameras registered and the sparse cloud is more or less complete. Doing this with openMVG "out-of-the-box", on the other hand, results in a small part (about 100 photos) registered and the related sparse cloud obtained.
So first of all I need to know how to obtain the whole sparse cloud and all the cameras registered in openMVG. I used both the global and the incremental pipelines. Please point me in the direction I have to look for parameters to tweak, things to change.

[pmoulon]

Photogrammetry depends mostly on 2 factors:

• Image intrinsic (approximate focal length)
• Connections between images.

1. Be sure that your image have valid intrinsic for your image (check that the initial focal length value for your image are reasonable)

2. You have to check the image connection graph (Does the image are matched together)

   • If you have graphviz setup on your computer you will have a file matches/geometric_matches.svggenerated. You can see there is there is one CC or multiple one.
   • Having more features per image will often help, you can tweak the parameter -p to HIGH on the ComputeFeatures binary (Using the option -n X with X the number of thread you want can help to process your dataset faster).

There is not reason for OpenMVG to be worst than other commercial applications.
If you want we can take a deeper look to your dataset together and try to see what is happening.

You can also share your OpenMVG binary logs, it can help us to see if something wrong is happening.

[madmage]

Thanks @pmoulon for the reply, here is my test scenario:

• I have 1999 photos, taken from a mobile phone camera, I know the focal length and thus I did:
  openMVG_main_SfMInit_ImageListing -i cellulare -o mvg/matches --focal 4750
• I use SIFT as feature descriptors:
  openMVG_main_ComputeFeatures -i mvg/matches/sfm_data.json -o mvg/matches/ -m SIFT
• Now the problems begin:
  openMVG_main_ComputeMatches -i mvg/matches/sfm_data.json -o mvg/matches/
  does not work, because, I think, there are too many images and exhaustive pairwise matching is too computationally intensive. For this reason, what I did is:
  openMVG_main_ComputeMatches -i mvg-seq/matches/sfm_data.json -o mvg/matches/ -n CASCADEHASHINGL2 -v2
  That kinda work, but of course it is not "fast" and using -v2 reduces too much the search space.
  I think the guided_matching (-m) and the cache_size (-c) are something I should look into, but I am not sure how to use them.

[pmoulon]

Hi @madmage,
One way to make the step openMVG_main_ComputeFeatures faster is to run many thread there by using the -n X option. X is the number of thread you want to use.

If your images have GPS data you can also use OpenMVG to only compute matches between close image.
If you need more speed we can approximation which image is similar to another by using VocTree matching. This project can use natively OpenMVG sift data https://github.com/hlzz/libvot

Looking forward to help you.
I will also one day implement a scheme to pre-select some image by using an option to downsample images. So this way we could preselect some image pair, and then run the final matching on the ful l resolution image. -> Feel free to say if you want to help!

[madmage]

Ok @pmoulon I understand I can speed up the ComputeFeatures step. However, I am having problems with the ComputeMatches step, as I wrote in my last answer.
Now I am trying with
openMVG_main_ComputeMatches -i mvg/matches/sfm_data.json -o mvg/matches/ -v100 -f 1 -m 1 -c 1
But I actually do not know exactly the meaning of -m 1 and -c 1, so it is just a blind test.

[madmage]

The Compute Matches is ongoing. It took 50000 seconds (13 hours) to do the matching and the Geometric filtering is still ongoing (10% so far).
Thanks for the libvot hint, I will look into it.
However, it seems to me that Geometric filtering is very difficult, is there a way to speed up the process?

[madmage]

I had to restart everything because something crashed. I started with -v10 just to see if at least the process finishes. 6K seconds, i.e. 1.6 hours for matching, but still working on geometric filtering. Can I do something to speed up geometric filtering?

[s-wtnb]

@pmoulon How to use VocTree matching for more speed?

[pmoulon]

@s-wtnb You can use the project libvot that is able to read OpenMVG SIFT files and create a pair file.

@madmage You can just type the binary and type enter, the documentation will show up.
https://github.com/openMVG/openMVG/blob/master/src/software/SfM/main_ComputeMatches.cpp#L102

Actually using -m 1 and -c 1 will make everything very slow because you ask to run the process with only 1 feature file in memory....

I would advise the following:

1. Try with not -c parameter to see if you can do everything in memory
2. Try to set the cache to half the size of your dataset if 1. did not work.
3. If 2. is not working you can preprocess first your image as downsized images and then only compute the structure of your scene on the large image according the geometry found with the small images

[s-wtnb]

@pmoulon thank you. I understand livbot is compatible only with SIFT features.

[pmoulon]

We have now the -n <THREAD> option on main_computeFeatures that could help to make this step faster.
Unfortunatly we don't have new optimization for computeMatches but since you can provide pairs there, you can use any other CBIR algorithm (libvot,...) to provide a limited number of pair.