Support for importing Colmap SfM models

[SBCV]

This PR allows to import Colmap's SfM model formats (.bin as well as .txt files).

Let us assume the following folder structure:

<Colmap workspace> 
    <images>
    <sparse model>
        cameras.txt / cameras.bin
        images.txt / images.bin 
        points3D.txt / points3D.bin

The importer looks on the same level than the <sparse model> for the <image folder> with the corresponding images.
Also, the importer searches first for the .txt files in the <sparse model> folder.

In order to validate the imported results, I performed a reconstruction with Colmap and exported the results as .NVM file as well as Colmap's standard model folders (.txt and .bin). Then, I compared the values in the Bundle::Ptr returned by load_nvm_bundle and load_colmap_bundle. I did not add the testing code, since I did not find a suitable place in the MVE library.

If you have any questions or comments, please let me know.

[SBCV]

Once #510 is merged, I'll update this PR accordingly (i.e. rebasing this on the master branch)

[SBCV]

Side note, I've used the addon mentioned in #512 to import a Colmap reconstruction and the corresponding MVE workspace using the functionality provided by this PR. The camera poses and points aligned perfectly.
Because of those results, I guess that the import of the extrinsic camera parameters should work as expected.
For comparison purposes, I've shifted one reconstruction a bit in the image below.

[SBCV]

Rebased and Squashed the commits

[SBCV]

Another side note: I figured out that colmap exports nvm files with feature observation positions within [0, width] x [0, height]. However, nvm files created with VisualSfM contain features that are centered around the principal point, e.g. they lie within [-width/2, width/2] x [-height/2, height/2].
What is the correct range that MVE expects? Does MVE provide an option to visualize feature observations?

[simonfuhrmann]

What is the correct range that MVE expects? Does MVE provide an option to visualize feature observations?

I believe in the bundle MVE expects [0,width]x[0,height]. In SfM code it's a little different and centered around 0 to apply radial distortion.

[simonfuhrmann]

Would you mind squashing and force commiting the PR? It'll get a little easier to review.
I'm not entirely happy how Github's code review works, or I just don't know how to work with it very well... is there a way to review all effective changes in one diff?

[SBCV]

No problem. I'm afraid, I'm not an github review expert either :o
Is it clearer now?

[simonfuhrmann]

I'm merging this for now. I'm still not convinced with the paspect thing, so it would be great it you could empirically validate this (see which one of the two versions produce better results?) :)

[simonfuhrmann]

Thanks for your contribution!

[SBCV]

Thx for merging!

[SBCV]

I've done some experiments and could verify that paspect = fy / fx is correct.

Here a result with paspect = fy / fx

And here a result with paspect = fx / fy

Btw:
Both branches of the if-else case in camera.cc use also (implicit) the relation: paspect = fy / fx

[simonfuhrmann]

Thank you for confirming it works. This is a nice reconstruction. What was the software process for reconstructing this? How was the imagery taken?

[simonfuhrmann]

Also, have you tried using UMVE for mesh inspection? It doesn't have a ton of features, but it's faster than Meshlab.

[SBCV]

Thank you for confirming it works. This is a nice reconstruction. What was the software process for reconstructing this? How was the imagery taken?

The sfm part has been performed with this colmap fork. Other pre- and post processing steps have been performed with some custom code. The imagery is part of https://spacenetchallenge.github.io/datasets/mvs_summary.html

Also, have you tried using UMVE for mesh inspection? It doesn't have a ton of features, but it's faster than Meshlab.

Oh, I wasnt aware of that. Thanks for pointing out.