[Beowulf] cluster for doing real time video panoramas?
Bogdan.Costescu at iwr.uni-heidelberg.de
Thu Dec 22 06:01:56 PST 2005
On Wed, 21 Dec 2005, Jim Lux wrote:
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.
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
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.
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
More information about the Beowulf