I was under the impression that cul was pretty self-contained as far as the sparse non-linear solver part of the problem. I will look further to see what you use from vpgl, including Matt's vpgl_bundle_adjust. No big deal, I can put it back into vpgl_algo if cul is dependent on it.



From: [] On Behalf Of Andrew Hoelscher
Sent: Sunday, November 13, 2011 7:11 PM
To: Matt Leotta
Cc: Joseph Mundy; Vxl-maintainers
Subject: Re: [Vxl-maintainers] (no subject)


Hey all,


Matt is correct, Bundler uses the vpgl and vpgl_bundle_adjust. It is not an implementation of the  bundle adjust routine, and as far as I'm aware, there are no plans to rewrite the implementation in vpgl, at least on the Cornell side.



On Sun, Nov 13, 2011 at 6:45 PM, Matt Leotta <> wrote:


I am completely in favor of promoting vpgl to core.  Thanks for taking
this on.  I also have no objections to removing vcsl.  I've never used
it, and I don't believe we are using it at Kitware.

I have a few questions about the vpgl transition.  Exactly which parts
do you need me to take ownership of and document and move?  Is it just
radial distortion and bundle adjustment, or is there anything else?  I
believe the inline documentation (i.e. Doxygen comments) are fairly
complete for most of vpgl.  Is it correct that you mainly need me to
contribute to the book chapter on these topics?

As far as bundle adjustment goes, my understanding is that bundler in
cul is a higher level algorithm than bundle adjustment in vpgl_algo.  In
fact, from what I can tell, the bundler code is calling some of that
vpgl bundle adjustment code.  The bundle adjustment in vpgl is nonlinear
optimization of sparse systems of cameras and points.  It is a solver
that assumes you've already defined the point correspondences and
initial guess at the solution.  Bundler (I believe) is a complete system
that takes a collection of images, extracts and matches interest points,
applies fundamental matrix constraints, computes initial estimates of
cameras/point parameters, and applies bundle adjustment.  Many of these
steps, including bundle adjustment, use algorithms in vpgl and
vpgl_algo.  Someone from Cornell can correct me if I'm wrong on that.

It seems that vpgl bundle adjustment code is worth promoting to core,
unless Cornell is planning on rewriting it.  I'm happy to contribute
some documentation in the book chapter on it.


On Sun, 2011-11-13 at 17:15 -0500, Joseph Mundy wrote:
> Dear All,
> Having heard no objections, we will remove the vcsl core library.
> Currently, it is just a set of interface classes with minimal
> implementation.
> Also I will be moving vpgl (the photogrammetry library ) to core. This
> move was discussed last year when Cornell installed bundler into vxl.
> vpgl currently resides in contrib/mrc/vpgl. That library (and
> sub-libraries) will be removed. We will make sure that all contrib
> libraries in the repository build without errors due to the change.
> The vpgl/algo that makes it into core is streamlined to have fewer
> more mature algorithms. The other vpgl algorithms and other
> sub-libraries will be moved to brl/bbas/bvgl/algo so they won't be
> lost.
> A few of the existing classes and algorithms in vpgl and vpgl/algo
> such as radial distortion classes, should be in core, but it will be
> up to Matt Leotta to document them in the vpgl book and move them up,
> if he has time. Also, Matt had bundle adjustment classes in vpgl/algo,
> but there is now an extensive bundle adjustment library (bundler) in
> cul (Cornell), so Matt's code was moved to bvgl/algo. It is planned to
> carry out these moves next Thursday, so the dashboard will likely be
> very red for a few days after. Hopefully everything will be back to
> normal by the following Monday.
> Joe

> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> _______________________________________________ Vxl-maintainers mailing list

RSA(R) Conference 2012
Save $700 by Nov 18
Register now
Vxl-maintainers mailing list