How to contribute

You are missing your geometric vision algorithm? You share the feeling that it would be nice to have a common place for all geometric vision algorithms, which then implicitly would offer automatic benchmarking without having to do the overhead everyime? Well, that place is here! Join the community today and add your algorithm(s). The instructions on this page give you some additional hints if you want to participate.

Preparations

If you haven't done so, please follow the instructions in the "Installation"-section to install the library on your system. We strongly recommend that you are using github's fork/pull request mechanism. It is also recommended that you first collect some experience with using the library, and notably understand the interface of the library. Please checkout the section "How to use".

Design concepts:

The library is developped in C++. The interface is based on the adapter-pattern, and you should use this concept in order to keep things as compatible as possible. In essence, it means that you should reuse the base-classes AbsoluteAdapterBase and RelativeAdapterBase, no matter if implementing a new algorithm or if extending the portability by implementing a new adapter. Have a look at the "How to use"-section in order to get more information.

You should also make yourself familiar with some coding standards. The code written so far doesn't necessarily follow one standard exclusively, but at least reflects the effort of maintaining a reasonable level of consistency. Please try to follow that line, it will substantially facilitate the inclusion of your code. Also have a look at the directory structure, it strictly follows the namespace structure, and this should remain the case. Headers that are only intended for internal use are in sub-folders called "modules", and templated implementation-headers go into sub-directories called "implementation". Also have a look at types.hpp, these are the types used for all geometric vision constructs, and should be reused thoughout the entire library. OpenGV uses two-space indentation, and tries to stick to 80-column width.

Another property that should be maintened is "independence". The library essentially depends only on Eigen. This is a powerful library that should deliver most of the functionality required for the purpose of opengv. For the sake of simplicity of installation and contribution, we should keep things along these lines, which means that it is appreciated if algorithms do not require the inclusion of any further third-party libraries.

The files in the library are encoded with UTF-8. It has been mainly developed under Linux, and compilation with gcc currently returns no warnings (hopefully). If you plan to develop under Windows, make sure you use an editor that understands UTF-8 encoding (no, notepad.exe is not a nice editor ;) ).

Todos:

The following is a non-exhaustive list of things that could be improved. You may also want to contact kneip.nosp@m..lau.nosp@m.rent@.nosp@m.gmai.nosp@m.l.com for further information, if you want to collaborate on one of these points.

• The library should easily permit further benchmarks, for instance all the special cases (e.g. planar structure etc.).
• The triangulation method needs to be able to handle non-central viewpoints. This would avoid some hacks here and there. Same accounts for the point-cloud alignment methods.
• The triangulation methods (and possibly further algorithms) should be included in the opengv-Matlab-interface.
• NoncentralRelativePoseSacProblem could decide automatically whether it should process data in a central or non-central way. Same accounts for the MultiNoncentralRelativePoseSacProblem.
• Sometimes ransac or iterative methods reset the adapter transformation for instance to compute reprojection errors (search recursively for sett). The original value should always be reset, because other parts of the algorithm potentially want to use it.
• Add more adapters to increase the portability. Examples are: OpenCV, Gandalf, VXR, Bundler, libcvd, OpenMVG.
• There is an improved version of p3p_kneip lying around somewhere, which could be included.
• Richard Hartley's implementation of the five-point should be included (replacing the current one).
• Hongdong Li's five-point solver should be included.
• Kukelova's polynomial eigenvalue solution could be included.
• P4P and DLT should be included.
• What about DLS and OPnP? Only Matlab versions are publically available.
• The 6-point by Stewenius is extremly difficult to reimplement. The reimplementation I provide is maybe not the best.
• Most of the current implementations treat the correspondences equally. The AdapterBase-classes however contain already a virtual function called "getWeight", which could be used to weight the correspondences differently for instance in a non-linear optimization scheme. Most of the adapters currently simply return 1.0 for these calls. Only the CentralRelativeWeightingAdapter has constructors that include the weight of the correspondences.
• arun_complete and threept_arun are redundant, we should get rid of one of them.
• The polynomial structures are Matlab-like arrays of coefficients, of different types, and sometimes with different conventions (coefficients once stored along the lines, once along the columns).
• Add more comments in implementation files such that users can potentially understand what's going on.
• Use vector.segment, block...topleftcorner etc.
• Theia by Chris Sweeney has an interesting Sturm root finder, it could be transplanted.