Producing Denser SiftGPU points - at the expense of time and RAM

One of the old adages I learnt doing CS was that you can not optimise everything - there is always a trade-off between speed and RAM (and sometimes accuracy). If you solve a problem faster then there will be a bigger problem that cannot be solved by your faster method. GPU computing seems to suffer from this scalability problem a fair bit mainly due to limited GPU Memory. In some cases there can also be issues with numerical stability. There is a fine line between Amdahl's law and Gustafson's law.

The latter is actually more fun since large problems have a patently real world feel. While playing around with large collection of aerial and terrestrial photography we found that SiftGPU seemed to be producing similar amount of key points no matter how big an image we threw at it and asked it operate at lower octaves to take advantage of the higher resolution. A bit of code inspection later I found the usual collection of magic numbers designed to prevent memory overflows ( if you have 60+GB RAM and some Teslas the magic numbers are too small). For posteriry here are the hard limits you can unsafely raise if your hardware can take a thrashing.

//hardware parameter,   automatically retrieved
int GlobalParam::        _texMaxDim = 12800;    //Maximum working size for SiftGPU, 3200 for packed
int    GlobalParam::        _texMaxDimGL = 16384;        //GPU texture limit
int GlobalParam::       _texMinDim = 16; //
int    GlobalParam::        _MemCapGPU = 0;
int GlobalParam::        _FitMemoryCap = 0;
int    GlobalParam::        _IsNvidia = 0;                //GPU vendor

The large aerial frames were defaulting to octave 3 silently, running them at octave 0 produced 500k SIFT features per frame (yes that is ridiculously huge, but these cameras are ridiculously good). With greater number of features you can perform sparse bundle adjustment using more restrictive angle range constraints and more accuracy.

Bundle adjusment has also had a recent boost from the release of Google Ceres library. This has been suitably adapted to allow faster solution of general multi-camera problems. Asteroids seem to be on everyone's mind.

"... for it is now clearly shown that the orbit of a heavenly body may be determined quite nearly from good observations embracing only a few days; and this without any hypothetical assumption."
- Carl Friedrich Gauss

Building faster Bundler with CPU/GPU parallelism

The initial Bundler release caused quite a stir allowing simple bundle adjustment from random collection of photos. It leverages the sparse bundle adjustment - SBA created by Lourakis. However being totally single threaded it does not scale quite well to large images. Sift point finding can be accelerated using SiftGPU - Changchang seem to have moved to greater things at Google since his PhD and academic research days.

I have built bundler for Windows 64 bit + CUDA as the MCBA documentation suggests. A few flags are not supported as shown below.
    CHECK_PARAM_SUPPORT(explicit_camera_centers == false);
    CHECK_PARAM_SUPPORT(optimize_for_fisheye);
    CHECK_PARAM_SUPPORT(use_constraints);
    CHECK_PARAM_SUPPORT(use_point_constraints);
    CHECK_PARAM_SUPPORT(fix_points);


I am calling it PBA_Bundler, please give it a try and let me know if it makes bundle adjustments faster for you. The GPU has higher error rates on floating-point calculations and can lead to large bundles drifting off reality. Even computers can have optical illusions. CPU parallel version has less error rate and yields more stable bundles. I am currently working on adding pthreads based parallelism to match filtering stages of Bundler (computing Epipolar Geometry and establishing bundle bounds) and removing the constraint in multi-core bundler which prevents the use of camera constraints.