PanoTools:
RE: Stitching ultra large panoramas
Max Lyons 2006-May-30 15:32:26
When I created my gigapixel image in 2003
(http://www.tawbaware.com/maxlyons/gigapixel.htm) , I had to write special
software to do it. That software is also unconstrained by output size. Since
2003, I've done several more 1-2 gigapixel images with my own software.
Publicly available software has improved in its ability to deal with large
images since 2003. If you've got some time and patience (and a large hard-
drive), size isn't the really the issue.
Having been shooting these large images for a few years, I am now firmly of the
opinion that the main challenges to these types of images are photographic, not
technical. Here are some thoughts:
1. Depth of field. Let's say that you want to create an interesting 10
gigapixel photographic image. If you shoot with a 600mm lens on a partial-
frame camera like the Canon 20D, then you'll end up with a final image that
covers about 75 degrees...a reasonable sort of FOV for most landscapes.
However, each individual frame from your camera will have miniscule depth of
field. Trying to produce a classic landscape shot (where the image is sharply
focused from foreground to background) will be next to impossible: The
hyperfocal distance is over one mile from the camera, and even when focused as
far away as 200 feet, the DOF is only about 14 feet (assuming flen=600,
sDist=200, fNum=11, CoC=-0.019). For all reasonable subject matter, It is
impossible to get everything in focus at the same time. If you are shooting a
completely flat surface from a great distance, then this might be OK.
The more gigapixels you want to create, the longer the focal length you'll
need. And, the shallower the DOF becomes.
2. Light changes. The other big problem is that the more images you shoot, the
longer it takes. And, the longer it takes, the more chance there is of the
light changing. You can forget about shooting at the "interesting" times of
day (sunset, sunrise), as it would simply take too long to capture all the
images before the light had changed. Also, partly cloudy days are also a real
challenge.
Even on completely sunny days, the changing position of shadows can be very
tricky. In this gigapixel image of the National Building Museum in Washington,
the sunlight patches on the floor moved significantly during the time that I
was shooting...blending them convincingly was a a real challenge. More images
would have made this even more difficult:
http://www.tawbaware.com/maxlyons/gigapixel2.htm.
(An aside: Some of the other gigapixel images I've seen have been produced
without much attention to details like this...the images have been
automatically blended and contain all sorts of oddities like decapitated bodies
and cars merged with buses and so on. If this doesn't bother you, then the
lighting challenges may not be too much of a concern either).
Because of the light challenges, you might try shooting things indoors, but
then your DOF problems become even more apparent because your subject distance
is likely to be shorter.
3. The motorized head idea seems to be popular (it is usually one of the first
questions people ask when they ask about the gigapixel images I've done), but
I've never been really interested in that idea, largely because I never thought
it too difficult to turn the tripod head manually. If I was to use one,
however, I'd want to make sure that it had some "intelligence" built into it.
For example, if the lighting is changing, you probably don't want a machine to
be blindly shooting away as the sun is coming in and out of the clouds. You'd
want to be able to pause, and then resume after the light had returned. The
same thing is true for people wandering through your frame, or gusts of wind
that blow a tree around, and so on. Except in unusual circumstances, you need
to be in control of when all the images are taken. You'd also need it to be
smart enough to know to stop when your card was full, your camera's memory
buffer was full, your battery had died, and so on.
I hope this has been some food for thought. I don't doubt that a 10 or 50
gigapixel image can be created. Its been possible for a while. But, can an
interesting 10 or 50 gigapixel photograph be created? That's the challenge I'm
interested in solving!
By the way, it looks like you are using PTStitcher to generate the images. A
number of us are working on PTMender (a replacement for PTStitcher), that
generates "cropped TIFF" files as output. Not only do these generate much
faster than the files from PTStitcher, they are also considerably smaller
files. My compiled copy of PTMender is here:
http://www.tawbaware.com/maxlyons/pano12ml.htm
Max
> Reinhard,
>
> I think you need to add two more items to your problems list:
>
> 4) - How to print an image that measures 45.6'x 17.7'.
> 5) - Where to display this large image (unless you have a really big dining
> room at home) :o)
>
> Mark
>
> -----Original Message-----
> From: #removed# [mailto:#removed#] On Behalf
> Of reinhard schartel
> Sent: Tuesday, May 30, 2006 4:20 AM
> To: #removed#
> Subject: [PanoTools] Stitching ultra large panoramas
>
> Hi, everyone.
>
> The largest "panos" I stitched are (164256 x 63840 pixel) ( 10,4 GPixel)
> (10.May 2006)
> another pano (322944 x 77440 pixel) ( 24 Gigapixel) (25.May 2006)
>
>
> It is not a REAL panorama because the 2835 Source-Images are
> Computer generated to test my Software. All other steps to create the
> panos are REAL.
> It is not a problem to stitch ultra large Panos ( 50 GPixel and more )
> because the
> required hardware-resources ( Diskspace and Computertime )are linear
> in "NumberOfSourceImages" (see below).
>
> But three problems I have still to solve.
> 1.)-I don't know how to handle that large OutputPanoFile ( 30 Gbyte).
> To handle that huge File, I split the Outputfile into 70 TIFF-Files, 435MB
> each.
> What can I do with such an ultra large pano? Is there any application ?
> Now it's only a challenge.
> 2.)-creating the Controlpoints of a REAL 10.4 GPixel pano.
> 3.)-shut the 2500 Source-Images.
>
> The software is ready to stich a REAL 10 GigaPixel pano.
> First of all, I have to get a computer-controlled motorized camera to shut
> about 2500 Images.
>
> I'll report again, when it's done.
> Reinhard
>
>
> Details 10Gpixel pano: (10.May 2006)
> ====================================
> panosize: 164256 x 63840 pix
> 354^ x 137^ (degrees)
> 105 images per row
> 27 images per collumn
>
>
> Source imagesize: 2304 x 3072 pix ( 7 Mpixel)
>
> Computer: Intel Celeron-Processor
> 700 MHz ;174 MFLOPS,
> read RAM 358MB/sec, write RAM 112 MB/sec
> 512 MB RAM ( 1 GB if the Source-Images are larger than 7Mpixel)
> ( 1 GB if the overlap between two Source-Images is
> larger then 30% )
> 127 GB IDE Disk ( NTFS, 4k Cluster)
> 300 GB IDE Disk ( NTFS, 4k Cluster)
> seq.read 52MB/sec, seq.write 34MB/sec
> OS: Wndows XP pro
>
>
> Software: PTStitcher (pano12.dll) by Helmut Dersch
> PTOptimizer (pano12.dll) by Helmut Dersch
> CPG2 (own software package)
>
> Diskspace used : approx. 120 GB
> diskspace = ( SourceImageSize * 4 * NoOfSourceImages ) + ( PanoSize * 3 )
> + TempSpace(~10GB)
> 2304 * 3072 * 4 * 2835 + 164256 * 63840 *
> 3
>
> Computertime:
> optimizer : 30 min. or much more (depends on the precision
> of positioning the camera) (PTOptimizer)
> converting images : 4 days 21 hours ( approx. 2min 30sec per
> SourceImage ) (PTStitcher)
> preparing stitching mask : 3h 30min
> arranging Outputfiles : 3h 20min
> blending ( multi-resolution-spline) : ???
>
> restrictions:
> The Source-images are in a regular arrangement.
> Indicate the Source-images by Column (c) and Row (r) P(r,c) then :
> yaw(r,c+1) = yaw(r,c) + deltaYaw
> yaw(r+1,c) = yaw(r,c)
> pitch(r+1,c) = pitch(r,c) + deltaPitch
> pitch(r,c+1) = pitch(r,c)
>
> deltaYaw is the rotating angle between two neighbour Source-images of the
> same row.
> deltaYaw is identical for all rows.
> deltaPitch is the pitch-angle between two rows .
>
>
> It is possible to use a finite number of computers to reduce the
> computertime
>
> Details 24GPixel pano: (25.Mai 2006)
> =====================================
> panosize: 322944 x 77440 pix
> 348^ x 84^ (degrees)
> 206 images per row
> 31 images per collumn
> 6386 Source-images
> 37595 Controlpoints
>
> Source imagesize: 2304 x 3072 pix ( 7 Mpixel)
>
> computertime: ( Computing-time below, when using only one computer for the
> steps
> "converting images" , "blending" and "preparing stitching
> mask".
> Only one computer is possible calculating :
> "optimizer" and "arranging Outputfiles" )
> optimizer : 4h (with the possibility of "morph to fit")
> (depends also on the positioning-precision
> of the camera)
> : 45min ( without the possibility of "morph to
> fit" )
> converting images : 14 days 1 hours ( approx. 3min 10sec per
> SourceImage )
> preparing stitching mask : 4h 10min
> arranging Outputfiles : 7h 20min
> blending ( multi-resolution-spline) : 4 days 5h
>
> No. of outputfiles: 160 , 429MB each ( 68.6 GByte)
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Protect your PC from spy ware with award winning anti spy technology. It's free.
http://us.click.yahoo.com/97bhrC/LGxNAA/yQLSAA/.Cr1lB/TM
--------------------------------------------------------------------~->
<*> PanoTools.Info (wiki, news and more...)
http://www.panotools.info
<*> PanoTools List Reader @ GMane:
http://news.gmane.org/gmane.comp.graphics.panotools
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/PanoTools/
<*> To unsubscribe from this group, send an email to:
#removed#
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/