[Beowulf] cluster for doing real time video panoramas?

[Bogdan Costescu]

On Wed, 21 Dec 2005, Jim Lux wrote:

> http://industrialcomponent.com/unibrain/ubwebcam.html

It's not clear from the description what you need to do to get the 
video stream. It's connected through FireWire, but it doesn't say 
anything about DV - and given the resolution which is different from 
standard NTSC or PAL...

> For instance, if the cameras pointed along the x axis have the long 
> direction of the frame in the y direction and the short in the z, 
> and the cameras on the y axis have the long direction in z, and the 
> short in x, and the cameras on z have the long direction in x and 
> short in y.  IF the short direction covers 90 degrees, then you'll 
> have overlap (I think..)

Your setup would have to match the short side from one frame with the 
long side from another frame which I think is not so easy. IMHO it 
would be easier to have something like 8 cameras, 4 disposed in a 
horizontal plane at 90 degrees from each other such that their short 
sides match, then have 2 cameras pointing upwards each directed 60 
degrees from the horizontal plane and from the other camera; then 
other 2 cameras pointing downwards like in a mirror. The long sides 
from all the 4 last cameras would correspond to the long sides of 2 
opposite cameras from the horizontal plane.

> http://www.luxfamily.com/pano1.htm

404, but don't bother, I got the idea.

> e.g., the cameras on the Mars rovers)

I thought that you want to have such a nice machine for yourself :-)

> It just occurred to me that another way might be to interleave 
> frames among CPUs (there'd be some lag, and there's the sync 
> problem).. Say it takes 0.1 seconds to process all the cameras into 
> a single image.  Then, with three processors, I could keep up at 30 
> frames/second.

Indeed, I mentioned this as a possibility in the end of my message. 
However, don't forget that a cluster is not only about CPUs but also 
about communication. A typical NTSC frame (720x480) with 24bits per 
pixel takes about 1Mb (you don't want to loose quality with lossy 
compression and CPU time with any compression in general). With 
100Mbit/s networking you can transfer only about 10 frames per second 
- and this while adding anyway delay to the video stream (0.1s which 
translates into 3 NTSC frames). So GigE or better should be chosen... 
or some delay added to the audio stream.

Furthermore, if all cameras connect to only one computer (head 
node, to simplify cabling) and the end result is assembled also by a 
single computer, these 2 need a better network connection than the 
rest to be able to cope with the increased data flow.

> I envision a scheme where you generate a series of full spherical 
> frames that you could record (e.g. onto a hard disk), and then, 
> later you could play it back looking in any direction.  And, in real 
> time (while driving the robot), you could look at a subset.

When looking at a subset, you would actually not care about 
reconstructing the whole spherical image, so you could handle only the 
1-3 cameras that point approximately in the direction that you are 
interested in, which would be decided based on the mapping of camera 
space to real space. This might mean a serious decrease in 
computational and communication needs, especially as you might not 
need to make the full transformations even for these 1-3 cameras (f.e. 
if the "window" corresponds exactly to one camera, you don't need any 
transformation, except maybe for color correction) and then maybe even 
one computer is able to do the whole work.

-- 
Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu at IWR.Uni-Heidelberg.De