[Beowulf] cluster for doing real time video panoramas?

[Glen Gardner]

IT all depends on what I was going to do with the imagery.
If the onboard machines are simply processing (which I assume is the
case) and will produce an image from the discrete images acquired from
the cameras, I would create the spherical image in a parallel fashion.

There are many approaches, but I might consider something like breaking
the final image into chunks for each cpu.
For example; If there are 8 cpu's I would divide the problem into 8
pieces.

You can approach it as each machine using the same code but each
processor responding to only a portion if an axis,...

I am shooting from the hip here, so please forgive me for errors in the
conceptual details..

Consider the "world" as having x, y, and z components.... one set of
cpus can handle xy and another can handle xz.  In a similar manner you
can subdivide the problem so that xy is divided among four cpu's and xz
is divided among another four.  The final image is generated in an 8
piece mosiac and assembled in parallel on completion (if you have a
parallel file system).


The entire problem is one that is readily handled using C or Fortran
with MPI.  Once you get the math worked out it is a piece of cake, even
though it looks daunting on the surface.

With enough computing horsepower you can do it realtime, and maybe have
spherical video.

Glen


On Thu, 2005-12-22 at 18:28 -0800, Jim Lux wrote:
> At 04:20 PM 12/22/2005, Glen Gardner wrote:
> >Be bold. Do the image processing in parallel.
> 
> Yes, but how to parallelize??  Do the projections to the sphere 1 or 2 cams 
> per pc, and then "gather" the pieces of the projections?
> Or, send all cams to all pcs, and do frame parallel processing. Some sync 
> issues there.
> 
> A lot of interesting questions arise..
> 
> Just for grins.. 640x480x3 bytes per frame at 30fps = 27 MB/sec = 220 Mbit/sec
> 
> That's a bunch o data to be pushing around.
> 
> 
> 
> 
> >It is the kind of thing that will run very fast on low end cpus
> >and it won't be a difficult job to parallelize.
> >
> >Glen
> >
> >On Wed, 2005-12-21 at 12:00 -0800, Jim Lux wrote:
> > > OK all you cluster fiends.. I've got a cool application (for home, sadly,
> > > not for work where I'd get paid to fool with it)..
> > >
> > > I've got a robot on which I want to put a half dozen or so video cameras
> > > (video in that they capture a stream of images, but not necessarily that
> > > put out analog video..) with overlapping fields of view.  I've also got
> > > some telemetry that tells me what the orientation of the robot is.  I want
> > > to take the video streams and stitch them (in near real time) into a
> > > spherical panorama, that I can then render from a corrected viewpoint
> > > (based on orientation) to "stabilize" the image.
> > >
> > > So.. you can get cheap 1394 video cameras from a variety of sources.
> > > There's a package of tools for doing the panoramas called panotools from
> > > Helmut Dersch, which I've used successfully with still frames (but not
> > > video!) that can do all the needed camera transformations and 
> > resampling (I
> > > think).
> > >
> > > But, then, how do you do the real work... should the camera recalibration
> > > be done all on one processor?  Should each camera (or pair) gets its own
> > > cpu, which builds that part of the overall spherical image, and hands them
> > > off to yet another processor which "looks" at the appropriate part of the
> > > video image and sends that to the user?
> > >
> > > here's an example of someone who did video panoramas on a Mac (but not in
> > > real time, I suspect)
> > > http://www.vrhotwires.com/InexpensivePanoramicVideo.html
> > >
> > > Panotools info at:
> > > http://www.panotools.info/mediawiki/index.php?title=Main_Page
> > >
> > >
> > > James Lux, P.E.
> > > Spacecraft Radio Frequency Subsystems Group
> > > Flight Communications Systems Section
> > > Jet Propulsion Laboratory, Mail Stop 161-213
> > > 4800 Oak Grove Drive
> > > Pasadena CA 91109
> > > tel: (818)354-2075
> > > fax: (818)393-6875
> > >
> > >
> > > _______________________________________________
> > > Beowulf mailing list, Beowulf at beowulf.org
> > > To change your subscription (digest mode or unsubscribe) visit 
> > http://www.beowulf.org/mailman/listinfo/beowulf
> 
> James Lux, P.E.
> Spacecraft Radio Frequency Subsystems Group
> Flight Communications Systems Section
> Jet Propulsion Laboratory, Mail Stop 161-213
> 4800 Oak Grove Drive
> Pasadena CA 91109
> tel: (818)354-2075
> fax: (818)393-6875
>