The VXL Project

Did someone mention matlab?

 

Currently I work almost entirely within matlab, but most of my
processing and algorithms are written in vxl.  So I can do things like
this:

 

>> % load an image using vil

>> im = vil_loadimage( "animage.bmp" );

>> % run a harris corner detector on it

>> corners = vsl_harris( im );

 

What makes this worthwhile and really fun is that I now have
command-line vxl.  In general, CV involves a sequence of calls to
algorithms which are themselves rather processing-intensive.  That's why
we code in C(++).  But research (hacking) dictates that we might want to
see what is going on between the function calls:

 

>> % display image and check that the harris has worked correctly

>> image(im);

>> plot(corners(:,1), corners(:,2), '.');

 

For the matlab enthusiasts, I probably don't need to preach the benefits
of this type of thing.  For non-matlab lovers, I don't imagine I'll
every persuade anyone.

 

As a further taster:

 

>> % edge detect the image

>> edges = vsl_canny( im )

>> % transform all the edges using matlab calls (.m functions)

>> for i=1:length(edges);edges{i} = transform_edge( edges{i}); end

>> % display edges

>> hold on;

>> for i=1:length(edges);plot_edge(edges{i},'r');end

 

I've coded interfaces for most of vnl (including things like
vnl_levenberg_marquardt, which is faster than the matlab native
minimizer), vsl and vil.  It's very easy.  How about an agenda item on
this, and the possibility of future releases of vxl including a toolbox
for matlab?  This would probably sell vxl better than just about
anything else.

 

Geoff.

 

 

 

 

-----Original Message-----
From: vxl-maintainers-admin@...
[mailto:vxl-maintainers-admin@...] On Behalf Of Joseph
Mundy
Sent: Thursday, September 26, 2002 3:25 PM
To: vxl-maintainers@...
Subject: [Vxl-maintainers] (no subject)

 

Karen requested several new items so here is the next iteration

Joe

 

Revised agenda:

 

8:30 AM   Dial in 

8:30 AM   Introductions (Brief review of each person's interest in/use
of VXL)

8:45 AM   VIL(MIL) - Ian Scott/Andrew Fitzgibbon

10:30 AM VNL issues (Perhaps Bill Hoffman would dial in at this point)

11:00 AM Library Promotion

                    VGUI (Perhaps Karen McGaul will dial in here)

                    Manchester Libraries

                    Others

11:45 AM Is Oxford's XCV interface to MatLab of general interest?

12:00 PM Lunch

  1:00 PM Discussion on VIDL codec plans

  1:15 PM Image Processing (AWFIPL?)

  2:00 PM Plans for V1.0 (Testing, Doc etc)

  3:00 PM Relation to ITK/VTK (Perhaps Bill Lorensen or Jim Miller would
dial in here)

                    

 

 

 

      o----o----o----o----o----o----o

Professor of Engineering (Research)      

Barus and Holley Bldg., Room 351         

Brown University                                   

Providence, RI                                       

401-863-2655

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

Joe,

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.

Thanks,
Matt

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
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________ Vxl-maintainers mailing list Vxl-maintainers@... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

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.

Andrew

On Sun, Nov 13, 2011 at 6:45 PM, Matt Leotta <matt.leotta@...:

> Joe,
>
> 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.
>
> Thanks,
> Matt
>
> 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
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > _______________________________________________ Vxl-maintainers mailing
> list Vxl-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl-maintainers@...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>

Andrew,

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.

Joe

 

From: anjruu@... [mailto:anjruu@...] 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.

 

Andrew

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

Joe,

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.

Thanks,
Matt


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
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________ Vxl-maintainers mailing
list Vxl-maintainers@...
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers



----------------------------------------------------------------------------
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Vxl-maintainers mailing list
Vxl-maintainers@...
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers

Matt,
Yes, I mainly need you to add sections to the book chapter on vpgl concerning your classes. It seems essential that your bundle adjustment will be moved back to core in order to support cul. So you need to prepare some book sections on its theory of operation and API. The radial distortion code can move up as well if there are tutorial and API sections added to the vpgl book chapter. I plan to have a first version of the vpgl book chapter checked in before Thursday. I will leave headings for your material. 
Joe

-----Original Message-----
From: Matt Leotta [mailto:matt.leotta@...] 
Sent: Sunday, November 13, 2011 6:46 PM
To: Joseph Mundy
Cc: 'Vxl-maintainers'
Subject: Re: [Vxl-maintainers] (no subject)

Joe,

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.

Thanks,
Matt

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
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________ Vxl-maintainers mailing list Vxl-maintainers@... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers