requires QuickTime 5 or later:
Choose a quality appropriate for your computer and connection. If you aren't sure, go with the base quality - It's still better than almost every other QTVR panorama on the web.
| Base Quality requires about 40MB of RAM |
2MB | relative size: |
High Quality |
7MB | |
Ludicrous Quality |
23MB | |
Note: The bigger ones may lock up your computer for a bit (15-60 seconds) just after it starts loading while the browser allocates the memory required
Sorry, but I don't have the web space to host the java version.
Hosted by ImageShack
Base Quality:
I've long had an interest in QTVR panoramas. I played around with making computer-generated ones when QTVR was new, but had never captured one. After getting my shiny new Nikon D70, I decided that the time had come when I should make a panorama. My initial result was quite good - I made a cubic panorama of the view from the knoll at the top of the bike path using a regular tripod and it turned out acceptably. However, large parts of it were a cheat. Thy sky was mostly fake (I dropped a single frame in that I had scaled up way beyond what the camera actually took). More importantly, the nature of the ground (dirt and long weeds) allowed the stitcher to cheat horribly in that area and not be noticed. However, results were less impressive with a similarly captured panorama of engineering plaza. Due to the very different nature of the space, the imperfections of the capture process resulted in stitching artifacts that were unbearably bad (like the mullions in the E2 windows jumping up and down 6 inches). The problem with the E2 panorama arises from two things: first, when the stitcher cheats, it a lot easier to see when brickwork or window panes create nice lines that suddenly move several inches. The problem is worthy of a whole section.
Panoramas like those above aren't some sort of 3D representation of the scene. Nothing near that fancy - instead, they're just a flat picture that the computer stretches around to create an arbitrary view, as long as that view is from the exact same position in space. To create the single image, a photographer captures multiple pictures (depending on the lens used, this can be anywhere from two to several dozen) and then "stitches" them together using software that aligns and blends the multiple frames into a single large image. The problem I experienced with my first attempt at the Engineering panorama is that like the viewer, the camera's eye must stay in exactly the same spot when taking all the pictures. However, with a traditional tripod mount, the camera moves around as you change it's aim. The camera's "eye" (when zoomed all the way out) is an inch or so behind the center of the front of the lens. With a regular tripod mount this means that the viewer position will shift left and right as you pan left and right, and more significantly that the viewer will move backwards and forwards as you tilt up and down. These small changes in viewpoint will cause small parallax changes in the scene, which are enough to completely foul up a process that requires adjacent images to match up precisely.
Once the problem is understood, the nature of the fix is pretty obvious: rotate the camera around it's focal point. Doing this requires replacing the tripod's tilt articulation to move the axis of rotation inside the lens, and positioning the new tilt axis directly over the tripod's yaw axis. Given a a CNC cutter & bender this would be 20 minutes in cad and 10 minutes of assembly. However, my resources were limited to much simpler things, like batteries, tape, and K'Nex. With these (mostly K'Nex) I built a yoke on top of my existing tripod, and a frame to hold the camera that sits in this yoke (pictures at ribht). The batteries and tape were used to add a counter-weight to the front of this unit, and the bulk of the weight (the camera body) was now well behind the pivot point.
Legal note: I have a feeling that someone has probably patented such a device, but brief searches of the USPTO didn't turn anything up. If I really am the first person to come up with this concept: I've got up to a year to file ;).
This is really the least interesting part of the process: set up the camera in full manual mode (all the pictures need to be identical) and take a bunch of pictures. In this case, I took them as RAWs, 1/125s f18 ISO200. For this panorama I took 8 columns of 4 pictures, one straight up, and one sorta interesting one. If you look, in the panorama you can see the ground. Notice anything wrong with that? Well, if you were wondering, after taking all the angles I could get from the tripod, I took the camera pivot unit (K'Nex and all) off yoke, pulled the tripod out of the way, and took a single hand-held shot straight down positioning the lens as close to where it would be as I could manage. The result is 204 MP of imagery weighing in at 182MB.
Looking at the pictures on a computer, it became immidiately clear that I underexposed them. Not dramatically so, but enough that they needed work before they could be used. To do this I set up a PhotoShop action to bring them in in 16-bit, run levels to brighten them up, reduce to 8-bit, and save out to a reasonable quality JPEG. After that was done, I tweaked the action and generated a full set of unaltered 16-bit TIFFs, with (white-filled) alpha channels. Why two sets of outputs you ask? The next step explains that
Now that I had the pictures, it was time to get them positioned relative to each other. This is where the first piece special purpose software comes in: Hugin. I created a project in Hugin and brought in all the pictures. Then I spent a few hours going through pairs of adjacent pictures adding control points wherever I could think to add them. This can get rather tedious, but luckily there were only 56 really important connections to worry about. For the straight down picture I assigned a different lens so that Hugin could attempt to adjust for any positioning errors as lens distortions. Once all the images were positioned, I saved out the project and edited it in a text editor to use the TIFFs instead of JPEGs. I started off with the JPEGs because they load MUCH faster than the TIFFs.
Optimization notes: I ran the optimizer in several passes: ypr with just the middle two enabled (only have them visible in the preview, and make sure the box is checked in prefs), everything for mid two rows, tweak any bad CPs and re-run that, ypr for top and bottom rows (enable everything but straight up/down and only check the boxes for the edge rows), then finally a few passes with tweaking for the ypr of the ceiling and everything for the floor.
I used Hugin's gui to set up the file for generating a 16000x8000 multiple TIFF and then saved the project and quit Hugin. I invoked nona (Hugin's replacement for PTStitch) and enblend (-vwz -l9, -l9 makes the sky a lot smoother when you're working at crazy high resolutions like this) sequentially in a terminal window and went to bed, fully expecting enblend to be at least mostly done by the time I woke up. Oh how mistaken I was. Six hours lager, I awake to find that nona did it's job in about 1.5 hours, but since then enblend has managed to get through barely 1/3 of the work it has to do. Fourteen hours after it started, enblend finished compositing the last image and wrote out a 1GB TIFF file. I used photoshop to brighten up the level a lot (remember, it was uniformly under-exposed) saturate the colors, and generate the MakeCubic-ready output. MakeCubic was run with pretty much default setting, save turning up the JPEG quality a bit.