Panorama Pictures for Reflex XTR scenery.

[HankF]

Has anybody here created a panorama bmp for Reflex XTR scenery? How did you do it (equipment, software, etc)?

Producing an 8120x3060 pixel .bmp file isn't much of a problem. It's taking good pictures to make it that seems to be the real problem. Has anybody been successful using ordinary cameras instead of the specialized panorama variety?

Let's see your 82x31 thumnail.

Hank

HOW TO :cool: :

When Reflex XTR is installed, it creates a set of folders. The top folder is named RefleXTR. One of the sub folders is called WLP. WLP contains the sceneries used by XTR. If you want to add your own scenery, create a new folder within the WLP folder.

Locate the WLP/Modellflugverein Grosse Heide 73.eV scenery folder and open it. Copy the files: S2.wlp and S2_1a.bmp into the new scenery folder you just created. These files define the 3D geometry of the scenery. Until we get a scenery editor from Reflex, we have to use an existing 3D definition. This particular set is reasonably flat. Using a graphics program, you can make the S2_1a.bmp file all black. It represents the objects which mask a vehicle flying behind them.

Create a .jpg or .bmp image file precisely 8160 pixels wide by 3060 pixels high and put it into your new scenery folder. Name it S2.jpg or S2.bmp. The horizon line in this image file should be at precisely 2040 pixels from the top. 8160 pixels represents 360 degrees of horizontal view, 3060 represents 135 degrees of view down from the zenith, and 2040 represents 90 degrees down from the zenith.

When you run XTR, the new scenery folder’s name should appear in the scenery list when selecting scenery. Click on the new scenery and XTR will create a panorama of the S2.jpg or bmp file which will then appear as the background.

[[ o ] cap]

Hey HankF,

My brother and i dove into it deeply about 5 months ago. We released one with our new web site and are working on a couple more right now. Through alot of trial and error we have figured out all the secrets to making top quality pans. there are certain tools that make it alot easier ,mainly a steady tripod and a panaramic head for the tripod ( which i made from seeing pics of them online). as far as the camera goes, we did them using a 5000 dollar, 12 meg camera (mothers a proffessional photographer) and we did them using 500 dollar, 4 meg cameras and there wasn't really any gain using the higher meg camera because of the scaling down you have to do anyway. so with the right tools, a "good" camera and a LOT of patience , you can do extremely good pans. We'll be putting up a good english tutorial on our site as soon as we have time to put everything we've learned in type. web site- http://w3.wehner.cc

-Chris

W3 Group


Heres a pic of the pan head i made for our tripod. It allows you to take pictures in exact degrees and at different angles so all 400-500 pics line up as close as possible.

[HankF]

Hi Chris,

That's a nice site you have. It looks like you guys have settled on the process of stitching multiple pictures rather than using specialized equipment like fisheye lenses or convex parabolic mirrors to take a minimum of pictures. Of course there is an incentive to keep the costs as low as possible. BTW, what sort of software are you using?

I ran across an interesting expeiment on the Panoguide forum you might be interested in. It used a Christmas tree ornament as a mirror - which is certainly cheap enough:

http://www.panoguide.com/forums/tipsntricks/25/

If used horizontally with the camera in portrait position, you could get a 360x180 panorama with just 3 shots. Any distortion caused by being spherical would occur down low or up high and may be acceptable. I'd like to hear your opinion.

Hank

[tewehner]

Hey Hank,

After quite a bit of experimentation, we settled on the process of (as you mentioned) stitching multiple pics together. We did not have an opportunity to use a "one-shot" solution such as a 360 lens. I'm not entirely sure how well they would work for this application, however. I suspect that they would likely be very dependent on camera quality and capability.

Digital cameras only truely support one resolution (the resolution of the ccd). This is the resolution at which the camera takes "RAW" pictures. When we used wide angle zoom factors (thereby getting more real world coverage in a single picture), we found that the camera, even at its highest, raw, resolution) did not give us the "crisp" quality we wanted in our pictures. There was a noticable amount of vignetting and blurriness around the edges. It seems to me that when using a one-shot lens, which of course has to warp the scene into a single pic, that you would not be getting an equal amount of "pixel-coverage" for any given part of the scene. That is to say, that as the scene is compressed around the edges (or maybe even the center, depending on the lens), you essentially get fewer ccd pixels to devote to what amounts to more real-world degrees of space.

We also found that, although we could technically shoot a reasonably acceptable scene with very few photographs (about 15 pics per horizontal row - wide angle), the depth perspective was quite skewed. The human eye sees the world at about a 50mm "zoom". Our camera could zoom out to 7mm, which let us get a full 360 degrees with only 15 pictures per row. However, once we stitched those together, objects close to the camera seemed fine, but objects far from the camera seemed *very* far away.

So, we reshot a particular scene at 7mm and again at 21mm and again at 50mm. We stitched them all up and found that the 21mm and 50mm looked way better than the 7mm, both in perspective and image quality. The latter was due to a couple of factors. First, being zoomed in to a higher zoom factor produces less distortion in pictures. This has the benefit of more equally distributing real world space over the ccd, as well as making the stitching software's life much easier. Second, being zoomed in also means you have to take a lot more pictures to cover a given amount of real space - (at 7mm we could get away with 15 pics/row, at 21mm or better we had to use 36 pics/row...every ten degrees). This meant that much more data had been captured going into the stitch process, assuming we were still shooting pictures at our camera's highest resolution.

The downside to more pictures is that the stitch (and especially the blend) took much much longer to run. So, we decided that we would still take pictures every 10 degrees, but we would lower the resolution of the camera so we wouldn't have so much extraneous data to stitch. After all, if the camera was shooting at 2500 pixels wide, that meant that 36 pictures (with 30% overlap) was generating a master stitch size of 30000 pixels wide...and we would have to scale that down to 8160 pixels wide for Reflex XTR. This turned out to be a not-so-beneficial move. In fact, it completely obliterated the crisp clean look we were trying for. It turns out that the camera's scaling algorithms were not stellar. Thinking about it, its probably a little much to expect the small processor in the camera to do on the fly with the speed we demand while shooting pics (particularly panorama shooting where speed is of the essence...clouds moving, etc).

Because of the real time scaling problems, we submitted to using full ccd resolution for the pictures, and letting the stitcher deal with the large pictures sizes. At first we let the stitcher handle the scaling down to 8160 (in Hugin, we set the output size to 8160 wide). As it turns out, hugin (and other stitching packages we tried) are even worse at scaling down. The interpolators included do a great job of scaling up, but as is not the intent of an "In"terpolator, they are either not used in the scale down operation or they are really really bad at it. Letting the stitcher scale the 30000 down to 8160 produced an image with really bad jaggies and a pixelated feel.

So, we ultimately decided on letting the sticher and blender process the images at full resolution, thereby producing a final stitch at 30000 pixels wide (this takes many days to run, so do some test runs at lower resolutions to get the stiching right). We then take the final image into photoshop, which does a phenomenal job of down-scaling/resampling, to get the the final 8160 wide resolution we need.

These stitches always seem to have problems at the "top" of the world, so you'll probably have to edit them in photoshop (we just do a small gradient blend from a sampled blue color to transparent over the top few - say 50 - pixels on the top of the picture). Reflex doesn't show the ground all the way to the feet so you dont have to take pictures all the way down. If you end up with any unfilled areas at the bottom just clone-stamp them in using photoshop or similar tool).

As for getting the panoramas into reflex, you'll need to find one that closely matches the physical layout and lighting you want. Open up the original you're copying from and notice the vertical position of the horizon and horizontal position of the sun. You'll need to match these in your panorama. You shouldn't need to do any stretching or scaling of your stitch after it comes out of the stitch/blend step. Just crop them vertically as necessary to make sure they are 8160 x 3060, and paint in whatever is missing.

As Chris mentioned, we use a panorama head so we can get more accurate spacing and leveling of our pictures. This pan head requires the camera to be in portrait mode, and we shoot at 1200x1600 (actually not the full ccd res, but plenty of detail given the number of pics taken and a requirement for us as Photoshop cant open images larger than 30k pixels wide) which gives us an "optimal stitch" size of about 30000 pixels when shooting 36 pics / row. We shoot rows at 10 degree vertical increments from about 80 degrees up down to 60 degrees down (considering the horizon as 0 degrees)

Hope this rather long-winded summary helps,

Ted
The W3 Group

P.S. we use the following freeware tools and Adobe Photoshop

http://hugin.sourceforge.net
http://enblend.sourceforge.net/

[tewehner]

we'll take a look at the christmas ball technique...looks fun if nothing else :)
We'll try using the 12 meg camera with it...

[BurkhardE]

Hi Ted,

please allow me an interposed question, since I just tried panorama myself last weekend. I used hugin too, and now I wonder what stitcher program you used. If I understand correctly, hugin is more or less a frontend for panorama tools, both common and the Panorama Tools (by Helmut Dersch). I found the standard stitcher of hugin ("nona", for no name?) pretty bad compared to the PTStitcher program (one of the Panorama Tools), especially with the Sinc interpolation method. What's your experience?

Burkhard

[tewehner]

We actually experimented with both the Hugin frontend and PTStitcher...and used the nona-stitcher as well as PT with each interpolator. We re-stitched the same pan with each interpolator (specifically looking to confirm or deny our theory that the interpolators simply arent used or are not effective when scaling down - or not scaling at all.) We indeed found that the interpolator chosen seemed to have no visible effect on a scaled down image - they all looked bad, which is why we eventually opted to not scale down at all in the stitching software (in Hugin just select "optimal size").

As for the hugin front-end versus the PTStitcher front-end, the only reason we chose Hugin is that we could not find any way in PTStitcher to define true vertical and horizontal lines - particularly necessary in roll correction for those without a good leveling pan head. PTStitcher allowed us to define lines as a series of points, but we could not find a way to call those lines "vertical" or "horizontal".

So, to specifically answer your question, we just used nona as it gave us the option to render to a single tif image using enblend (and save a manual step...course this all went out the window anyway when our pans started consisting of 400+ pictures and hugin could shell out to enblend anyway because of command-line length limitations).

Ted
The W3 Group

[tewehner]

One other point of interest:

After Chris built the pan head shown above, we no longer had to rely so much on the optimization phase. Because we knew the exact coordinates of each picture in the sequences (say 20 degree yaw by 10 degree pitch and 0 degree roll), we were able to key in those positions manually to hugin. After doing this, a preview will yield an ok stitch without any optimization. Then we could run the optimization (p/b/r i think...went very fast as the images were already very near their correct position) and get a perfect stitch with no seams out the other end. I eventually wrote a small command line program to modify the .oto files before we even opened them in hugin. We create the oto from command line with autopano, then run our utility to auto-key in the basic positions (it just takes a starting pitch and ending pitch as arguments and assumes the rows are in sequence and have 36 pics each). We then open the .oto in hugin and run the optimize and generate the stitch. We were able to run our last stitch (the football field) without even previewing - stupid yes considering the render time, but it worked ;) .

[HankF]

Wow! my head hurts.

I tried a test panorama using my digital (low res) camera with protrait mode vertical at my widest angle (about 35mm equivalent). The series was in two rows with overlaping both horizontally and vertically. I did 8 pictures per row. I got about a 360x140 degree coverage.

I then tried a free stitching program without any correction to the images. The scene included a parking lot with stall markings. As you could expect, the stall markings did not match after the stitching. The method worked but was of very low quality.

Several things I learned with this simple experiment: you need a camera with manual exposure controls, you need a panning tripod, you need to correct the (keyhole?) distortion caused by tilting the camera before stitching. You need a good stitching program.

My question is this: Do you correct the individual images for distortion before stitching and when the images are corrected for distortion, they are no longer rectilinear. How does the stitcher handle the resulting images considering that Reflex needs a rectilinear image?

Hank

[tewehner]

Actually, the stitching software will correct for barrel distortion during the optimization (it does a decent job of calculating this using the control points that autopano finds). I'm having trouble figuring out how you were able to get 360 degrees out of 8 pictures :eek: 35 mm should be pretty zoomed in and should probably not represent more than about 10 degrees in portrait orientation (no math here...just guessing based on myexperience).

[mhale71]

someone really needs to figure out the deal with the colision file :(

they should have made a scenery maker like they made the rmk model maker.

mike

[Omita]

cap']so all 400-500 pics line up as close as possible.

Ehhh... 400-500 pictures? are you kidding. I can take 32 or so with REALVIZ Stitcher and get good results.

[tewehner]

We did plenty of sub-100 pic scenes...then we did 400 pic scenes. The sub-100 scenes invariably had stitch errors that had to be corrected manually. The 400 pic scene stitched up waaaaay better than the 40 pic scenes. Shooting at 50 mm means very little image distortion. The scenes stitch up with no manual intervention. Then we put the two stitched scenes side by side to compare image quality and perpective. The image quality on the 400 pic scene was hands down better than the sub-100 - and what we were after, above all, was super clean, crisp image quality. And as I mentioned above, shooting a sub-100 scene requires a wide angle while shooting. This leads to major perspective problems. At 7mm zoom, objects past 20 feet will appear way to far away.

Ted
The W3 Group

[tewehner]

mhale71,

Amen! We found mention a few months ago of an RSK (reflex scenery kit) that was supposed to come out this year. Of course, after repeated attempts to contact wolfgang on the subject (with no response) we are still left with only questions and a lot of frustration. We've got some really good scenes in the can that just don't work with borrowed geometry (small-space scenes good for 3d flying) and borrowed lighting. Really wish we could edit those files....

Ted
The W3 Group

[HankF]

I'm having trouble figuring out how you were able to get 360 degrees out of 8 pictures 35 mm should be pretty zoomed in

The camera was an old (in digital terms) Olympus D-620L (1280x1024 CCD). The manual claims it's a 36 - 110, 35 mm equivalent. I had it zoomed out to the widest angled setting and insured that there was overlap as required by the stitcher. It's not what I'd use for a final panorama and might give me an excuse to upgrade.

Can you tell me what functions the sticher and blender do (besides the obvious) and what functions you do with your imager (Photoshop)?

On rereading your treatise, a question occured to me: How much overlap is there between pictures and could you use Photoshop to reduce that as much as possible to speed things up rather than let the stitcher do the cropping?

Lastly, to me the problem seems to be in getting decent vertical coverage - as close to 180 degrees as possible. How many rows of pictures do you deal with?

Hank

[BurkhardE]

Hank, one possible answer to your last question might be in this tutorial:
http://www.path.unimelb.edu.au/~dersch/pted/pteditor.html
And don't fail to look at the examples and to read some of the articles at the main page
http://www.path.unimelb.edu.au/~dersch/
Most of my questions were answered, though I'm not aiming at very high quality. One hint from an Austrian website was very useful: distort the anchor picture before defining and automatically generating the panorama (using the panorama tools), really performs miracles (especially with wide-angle pictures).

Burkhard

[tewehner]

Hank,

The overlap is necessary for the "autopano" program (or even manual control point placement) to match up control points. This is necessary for both relative image positioning as well as determining image distortion. Even on the best pan heads you're likely to get a little roll or inconsitent pitch or yaw spacing between photos. By having overlap, you give the stitcher the necessary information to understand and correct these issues.

[HankF]

Thanks Burkhard, that will keep me busy for a while!

Ted, I do understand the need for overlap or some sort of marking. I just got the impression that there was a lot of overlap when taking 400 odd pictures which had to be thrown away in the joining. I guess you are taking the pictures zoomed in enough to keep overlap to a minimum.

Hank

[tewehner]

That's correct. We only have about 20% overlap. :)

[mhale71]

ok, since, of all the scenes, i honestly like the W3 highschool one the most, i think it deserves a colision file without barriers ( no red wall popups) , now, have a look at the sporthall scene panorama. now have a look at its colision picture, white on black, could be that all the things you can collide with, are made white on the black, youd need an exact, so im gonna try with one of the poles from the HS scene.

mike

[mhale71]

ok it didnt work, but someone should try that, i probably just wasent exact enuf.

mike

[HankF]

Mike, do you think that the Sporthall geometry is basically flat to the horizon and that if you used a plain black collision file there wouldn't be the problem with invisible grass like the ---73 e.V. scenery?

Asked another way, is the collision file required for collisions?

Hank

[tewehner]

Unfortunately, the .wlp (collision/geometry file) is the master file for a given scenery. It is the file that you actually select from the scenery browser in Reflex. It contains not only the collision information but also the light source information. It references a master .bmp (say S2.bmp) as the main panorama as well as any number of masking bitmaps (S2_1a.bmp). This masking file is used by a collision object (such as a tree-line plane) to define what part of the panorama needs to be drawn over the aircraft - thereby allowing you to visually fly behind objects. I've reverse-engineered other binary formats for other applications in the past, but I've had no luck with the reflex .wlp. So, for now I think we're still just stuck at begging wolfgang to get something out. Of course, if he cant get the RSK out, it would at least be nice if he would send out an "empty" .wlp that has nothing but a flat ground and basic 45 degree up light source. :)

[HankF]

Ah, that's what the auxiliary bmp file is for, the visuals of the geometry, of course! Thanks Ted.

I looked at some of the files in the Umwelt directory and notice that there is no .wlp file for the original Reflex scenery. There is however, a .wlt file which seems to be a text file containing some definitions(?) of various ground objects like the runway, heli pad, mowed pads and grassy areas. There are also .sky files which also seem to be text files associated with the sky .bmp's.

Do you suppose it would it be possible to get a perfectly flat ground from modification to any of these files? What do you suppose the .dds files contain?

Hank

[tewehner]

no idea :confused: (haven't looked at the legacy scenes) :) I'll take a peek at them when I get home tonight.

[tewehner]

We might all also try to get a hold of Stefan Kunde, his name appears in some of the original wlp files. I believe that Vincent Charbonneau (one of the Raptor 90 guys) may have access to him.

[HankF]

I'm not sure there will be much success in eliciting a response from Stefan. Burkhard has been unable to do so (so far) in regard to the definition of some of XTR's inputs.

The potential for RSK to be a commercial product my dampen any enthusiam for revealing scenery construction details.

Hank

[skirtz]

Guys, take a look at my simulator at http://rcflightsim.com Clearview now supports equirectangular scenery format (reflex uses equirectangular picture with part of the bottom cut out). We can decide on open colision detection format that any one can use.

Stefan

[BurkhardE]

Hi Ted,

your treatise and the following amendments really were extremely useful since they save much own work and experiences. Though I didn't understand some points yet, at least not completely. (And my experiences are still limited to garden panoramas so far. :)) So several questions are haunting me.

I understand you use a lens set to "normal" focal length to resemble the human viewing angle of 45 degrees (nominally, i.e. for diagonal). In portrait orientation, the horizontal 360 deg will be covered by 36 pictures à 25 deg (24 mm) every 10 deg, the vertical 150 deg by 15 rows à 37 deg (36 mm) every 10 deg.

That would mean you have more rows than needed, since 7 rows would give the same overlap as horizontally. And wouldn't less than 36 pictures be sufficient in the higher rows?

In the past, standard lenses were 50 mm fixed focus and the best lenses at all (cheap, simple, but high picture quality and fast). Today's lenses are zoom lenses and inevitably not so good and fast. The standard focal length is a fixed requirement to get good panoramas, as is a low resolution of each single picture (best quality at "natural" resolution). So today's high resolution ccd chips are really wrong, as are zoom lenses.

It seems to me that just a camera we would need for high quality panoramas is not (more) available. It would be a simple, relativley low-cost camera with fixed-focus high-quality lens (small geometric and color aberrations) and a low-res but otherwise high quality ccd (contrast, colors). Do we have the wrong cameras now?

Concerning the image processing, I think I'm now understanding your procedure. Following a hugin tutorial (http://rbpark.ath.cx/photography/panoramas/tutorial.html) I tried autopano-sift instead of the "standard" autopano and found it better as it distibutes the control points over the whole edge of the pictures. Alas, it must be called directly since hugin fails to call it.

After autopano-sift, hugin is started and the project file loaded. The recommend optimizing procedure (not all at once but step by step) worked very well and nearly all distortions were corrected. Even the horizon was found automatically. But it would be even better to have many undistorted pictures (I had wide-angle pictures) shot from the nodal point (I failed and so some stichting errors remained due to parallax).

So I tried myself (but not the hard way) what you already found out: use a tripod and a panorama head, may be simple and cheap, but it's useless without. And make several virtually undistorted pictures, that additionally gives an even pixel distribution and high image quality. (It would be very interesting to follow Hank's idea to use a mirror ball - or a fisheye lens - and take only a few but overlapping pictures to crop the distorted edges. A high-res camera would be needed, though, if I'm right.)

What I still can't believe is that the stitcher or enblender software isn't able to shrink the images. The nona stitcher isn't bad at all, especially in conjunction with enblend (which has to be called from command line, too). Obviously, I made a mistake trying it. Again I tried PTStitcher since the author claims it's better to do all image modifications in one step to preserve quality. The program should even do the enblender job if the parameters are set appropriately. I tried that only once so far, but it seemed to work.

Image quality after stitching and distortion to optimum size was excellent. Then I generated a tiff panorama file (100 MB size, 13400 pixels wide) and used hugin/PTStitcher to only shrink it. The original pictures (from an IXUS 400) were jpeg, and the shrinked jpeg panorama looks even better than these (imo, of course). Above all it shows no artefacts or similar bad effects.

Today I tried the GIMP instead of Photoshop, but I couldn't find a file size or image width limit so far. There's a PanoTools plugin but it's not needed anyway for scenery panoramas since your procedure is much better. Shouldn't it be possible to completely automate the pano generation process using a shell script and a project file? (Btw, isn't it even possible to define vertical and horizontal lines, by t1 and t2 control points in the .pto file?)

Even your standardized image pattern might be shot automatically. Obviously, it's possible to build a panorama robot (http://philohome.com/legophoto.htm) from relatively cheap components. It could shoot the 400+ pictures in quite a short time to avoid bad panos due to cloud drift. (But Philippe Hurbain even offers standard sky images (http://philohome.com/skycollec/skycollec.htm).)

I don't think this all would be a project for me (will stick to the models), but my questions are not only haunting but of great interest for me. And it's a kind of entertainment to bridge the time until RSK will be there and let us build sceneries, not only panos. ;)

Burkhard

[tewehner]

Hey Burkhard,

Thanks for your comments. As you have probably figured out, the best way to get a hold on all this stuff is the good old trial-and-error method. I'll try to answer a couple of your questions. First, you seem to understand the lens concept as well as I do (here's hoping that is saying something :) ) I intend to get some pictures up soon that demonstrate both the edge distortion and imho the more important depth distortion caused by wide angle shots.

As for the number of pictures needed on "higher" rows - you are also correct. Technically, we do not need as many pictures to represent a row as we move up. We keep them at 10 degree increments for simplicity's sake when manual positioning all the pictures in the project file - it's a lot easier for us to treat it all as a 10 degree grid.

The average digital camera in the market today will work fine for what we are doing. As you guessed, they actually are a little more advanced than we need. Specifically, they have a higher native ccd resolution than we really need. Of course, older cameras with lower resolutions also come with poorer image quality and slower processing.

A couple of points I failed to mention before: The panoramic head is crucial not only for getting a good even distribution of photos, but also for speeding up the picture taking process - quite necessary when shooting skies...stupid moving clouds. ;) Also important is the ability to find the "optical center" of your lens. You need to have the optical center of the lens directly above the pivot point on the pan head. A good pan head will allow you to adjust the camera's position to achieve this alignment.

Aligning the optical center is very important if your scene has any close objects (e.g. shooting your garden). If the center is off, your scene will suffer from a parallax effect, which is quite hard and usually impossible for the stitcher to overcome. If the optical center is not aligned, and the camera is pivoted around the head you are essentially shooting pictures from multiple positions rather than simply multiple angles. For a demonstration of the problem, close one eye and hold both index fingers out in front of you. One about 6 inches in front of you and the other about a foot out in front of you. Now align those fingers so the near one hides the far one. Now switch eyes and of course the fingers no longer appear aligned one in front of the other. It is important that the camera see a given section of your picture exactly the same, regardless of the camera rotation. When the camera is properly aligned, it will. Here is a link for the pan head Chris looked at for inspiration on the pan head he built. This site also has a setup guide that explains how to align your camera to prevent the parallax effect.

http://gregwired.com/pano/Pano.htm

Now, on to the scaling. I've attached a couple photos demonstrating the scaling issues we faced - although these were not the worst we saw, they just happen to be the only ones I could find from "back then". The first image was rendered directly to 8160 in hugin with enblend blending. The second image was rendered to 15055 (optimal size) first, then scaled in Photoshop down to 8160. Looking at the images outside the game, the first image (rendered to 8160) actually appears to look a little better on some parts. It seems to be sharper. Particulary in the near grass. The problem is that when in Reflex, the sharp grass looks terrible. It seems to have a weird "electric" feel to it - kind of jittery and nervous. The second image, having been scaled down in Photoshop has a more antialiased look - and appears very smooth in the game (without appearing blurry). This is a little more noticable in these pictures in the power lines. I wish I had better pictures to demonstrate with, but these are all I have now :(

That's about all I have for now,

Ted
The W3 Group

[BurkhardE]

Hi Ted,

thank you very much for your comprehensive response. It's a very encourageing discussion for me. :)

As for the image quality, I think I've got the point now. I downloaded your two pictures and loaded them into Gimp for comparison. But the preview thumbnail in the Open Image dialog revealed the effect better than the images themselves. Alternately clicking on the two filenames showed a sharp but "pixely" thumbnail or a more (but not really) blurry but "antialiased" one. Obviously, that's the way Windows (or DirectX or the graphics driver or whatever software component) renders bitmap images. But all graphics programs may do it the same (or similar) way or even rely on Windows.

Attached are two enlarged details of my garden pano. They are simple screenshots of the pictures displayed with 800% enlargement. The one shrinked using PTStitcher is as sharp as possible whereas the other one, shrinked in Picture Publisher, is somewhat blurry (and not unsharp-masked as I usually do). The sharp image looks way better if displayed in only moderate reduction.

Another two details of the pano are displayed with 25% reduction and screen-shot. The effect is reversed, the image shrinked by Picture Publisher looks more pleasant than the other one shrinked by PTStitcher (now I know what you mean by "electric feel). It's a different detail, but compare not only the leafs (salvia officinalis) but also the grass (mowing intentionally omitted ;) ).

Now, with your help (saving me some trial-and-error iterations), I learned something important:

For my garden panoramas I'll stick to PTStitcher since it's designed to do really all image processing (including shrinking) in one step and very high quality. As I view my panoramas they look best this way.

If I'd make a scenery panorama for Reflex, I'd use PTStitcher too but for "optimum" image size and then shrink using a bitmap graphics program like Photoshop or Picture Publisher or Gimp (and avoid unsharp-masking).

I wonder if it's only the interpolation method used since the graphics programs have only a limited set of these methods and PTStitcher is almost built around some special methods (as impressively described in this article (http://www.path.unimelb.edu.au/~dersch/interpolator/interpolator.html), only take a look at the images). And the nVidia graphics driver can do some "image sharpening" (turned off so far). This will be my next trial-and-error step.

Thank you again,

Burkhard

[BurkhardE]

Hi Ted,

concerning the panorama tripod head, here in Europe is an Italian manufacturer known for very good (and very expensive) equipment (nice website (http://www.manfrotto.com/303SPH/)). Since you wrote that some inaccuracies in the picture pattern are unavoidable anyway, I think it's best not to strive for mechanical precision but for automated shooting (and image processing).

The Lego Mindstorms Robotics Invention System 2.0 from which Philippe Hurbain built his robotized panoramic head (http://philohome.com/panobot2/panobot2.htm) (interesting website btw) is offered at eBay for 180$. It's not a bargain (though cheaper than in Europe), but it (or similar robotic kits) might be affordable for us. So I'll try to set up a project next year to explore the possibilities of automating the panorama building process. You might then already know all we'd have found out, but it would be fun anyway. :)

Burkhard

P.S.: As you wrote, without a pano head the stitcher (autopano and the optimizer before) will be confused by parallax errors. Here's my simple equipment (IXUS 400 pocket camera, pocket tripod, and a level), of course not "centered" to the nodal point. Surprisingly, there was only one obvious stitching error in the picture. It's in the roof due to the small trees between the roof and the camera. It's an example for your explanation (and for the power of PanoTools). ;)

[Arthur_GA]

Very interesting thread! One question: WHY is it that nobody has yet created a scenery of a field with a PAVED runway??

[KurtHübener]

The Reflex guys have been in the US some weeks ago to take pics for tarmac sceneries. I have no idea when they will be published but I was told that they will come up with some fields in Arizona and Vegas area pretty soon. Pretty soon could be autum.

[tewehner]

Hi Arthur,

We actually have made a couple sceneries with paved runways, but have not released them (they were in our early attempts at scenery which need to be redone for higher quality). The big problem here is that although we can shoot the panoramas with pavement, we cannot as of yet "tell" reflex anything about the environment or layout of the scenery. We are forced to borrow the geometry/layout files from stock sceneries. Therefore, what you visually see does not necessarily match up to 3d world being simulated. Because none of the stock reflex sceneries have pavement, we cannot position our sceneries to match pavement in another scenery. Ultimately, now, you will see pavement, but the aircraft will behave as if it were on grass. Looks funny to see a plane rocking and bumping around like crazy while rolling across pavement.

[Lewis H. Cobb]

This thread has given me an idea - and hopefully I won't end up in a foreign jail if I pursue it - see below -

Ted - Interesting thread on the reflex sceneries. I am keen to make an "exotic" panoramic pic for reflex and will read your website and tutorial to see if it's something within my grasp. I have a 5MP Canon Digital Rebel from work that I can borrow to do it as well as a tripod, but the pano-head is something that I'd have to fab/buy.

I have a question

If a person was set up with the right gear - how long would it take to fire off all the pics needed for a panoramic scene? The key element here is "speed" - I am thinking of an opportunity that I will explain below, but I would have to set-up, shoot, and tear down very quickly - maybe 10-20 minutes tops. This might mean I need a robotic head on the tripod.

Here's what I am thinking. My fiance and future in-laws are Russian. I am travelling to Russia later in July and will be in Moscow for a day or so. I've been there many times before and with some "local help", I could set up and shoot a panorama of Red Square complete with Lenin's tomb, the wall of the Kremlin, and the Onion Domes of St. Basil's cathedral. The trick will be to look like a tourist - of which there are many taking pictures anyway - But if I linger too long, I will attract the attention of the security people and/or curious onlookers.....

What do you think? I don't want to end up in jail of course so it would all be tentiative pending the "environment" when I got on-site. I can get dimensional info either before or after the photo-shoot as well.

Let me know your thoughts.

Cheers,
Lewis

[HankF]

Hi,

I just got back from a trip in which I crossed the state of Colorado (USA) diagonally from south-east to north-west. I sure wished I had a panoramic setup but I didn't. The mountain scenery was really outstanding!

It seems to me one could use a programmable telescope tripod to automate picture taking.

Ted, did you ever try the "Christmas Tree Ornament" lens? I wonder how one determines the nodal point for such a set-up. In the USA, spherical mirrored garden ornaments (globes) are available in diameters from 4" on up in 2" increments. I was thinking of using such on a tripod and moving the camera on it's own tripod around the sphere at 120 degree intervals. Or one could move the sphere around the camera. Which would be best? I don't know but I soon hope to try it.

I notice that Reflex's scenery horizon line occurs at about 1/3 the distance from the bottom of the panoramic pictures. I presume this is due to the cut-off of the bottom of the sphere. It seems that this amounts to about 45 degrees of coverage. Does this seem right?

Hank

[HankF]

Here is the result of using a 6" globe to take 3 pictures 120 degrees apart to produce a panorama using Panotools.

The camera is an old 1280x1028 pixel resolution Olympus DL620. The globe used was a blown glass garden ornament of 6 inches diameter, silvered on the inside. It was fairly spherical but had some minor imperfections. I filled the viewfinder with the globe vertically in landscape mode. I was at nearly full wide angle zoom for the shots. I moved the camera around the globe and the lens was about 19" from it. I think I should have use almost full telescopic and set the camera further away from the globe.

I used Ptpicker.jar to define and run the project and picked about 3 common points between each pair of photographs. I defined the lens as a 7mm unit which I assume was the fisheye equivalent to the sphere.

This is my first attempt with Panotools and the results show it. You can view this image as a spherical panorama by dropping it onto PTviewer.exe which you can download as Burkhard referenced above in this thread.

I sure could use some advice at this point especially regarding what size of lens to call the mirrored ball or any other suggestions for that matter. I'm not particularly encouraged at this point.

Hank

[BurkhardE]

Hi Hank,

unlike you I find your results quite encouraging and wish I'd gone so far. I'm still dealing with garden panoramas (http://time.fh-augsburg.de/~erd/photo/pano/) :) and a polished panorama creating workflow. Just now I'm writing down my knowledge and experiences gained so far in a web page (http://time.fh-augsburg.de/~erd/photo/pano/textTools.html) to later remember all arguments and web links. Maybe you could find something useful for you (at least the link to Horst Lenkeit's tutorial on building panoramas for Reflex XTR, confirming that they are 360x135 degrees).

In passing, I found some information concerning the mirror ball method. They show that you did nothing wrong, and it seems you're 'only' struggling with the tricks of Panorama Tools.

Obviously, you did right to turn the camera around the ball. Look at the TBK panorama page (http://www.tbk.de/panorama/main.htm) for some pictures (the text is German but won't be needed). The button Spiegel Technik (http://www.tbk.de/panorama/show3.htm) leads to a page about mirror techniques. There's a sketch showing that parabolic and hyperbolic mirrors have an internal focal point useable as the turning center. A spherical mirror doesn't have a single focal point but something like a focal circle whose center could be used.

Btw, down that page several commercial mirror solutions are shown. The rightmost button Sonstige Experimente (http://www.tbk.de/panorama/show6.htm) shows some home-made solutions. The 4th button from left ~180° WW Technik (http://www.tbk.de/panorama/show4.htm) means 180 degree wide-angle methods and shows your idea of shooting 3 tilted images (MrotatorCS/CP by Agnos). Finally, the page Segment Technik (http://www.tbk.de/panorama/show2.htm) is about the usual method of shooting picture patterns. On the bottom of the page is a simple solution for automated shooting. You may have seen Philippe Hurbain's PanoRobot (http://philohome.com/legophoto.htm) already.

Only recently I found the Pano Tools wiki (http://www.panotools.info/mediawiki/index.php?title=Main_Page). There is a good ChristmasBallPanoTutor (http://www.panotools.info/mediawiki/index.php?title=ChristmasBallPanoTutor) confirming your assumptions that a bigger ball and longer focal length are better. They also give an equation for the field of view. Maybe there are some other hints for stitching mirror ball pictures. I think that's your actual problem and would recommend to use the hugin GUI since it could boost the workflow (especially iterative use of the optimizer). I think I read something written by Helmut Dersch himself about the mirror ball technique, but I can't find it anymore. (Might have been Philippe Hurbain's tutorial (http://philohome.com/panotutorial/panoramatutorial1.html). Should have written my web page from the beginning.) Another straightforward tutorial (http://www.cgtechniques.com/tutorials/makepano.php) might be helpful.

Last idea: For Reflex XTR, you might shoot only one mirror ball picture 360 degrees around, the camera pointing vertically upwards. Use one of Philippe Hurbain's panoramic skies (http://philohome.com/skycollec/skycollec.htm) to cover the panorama.

Hope that helps,

Burkhard

[BurkhardE]

OK, not yet really helpful.

Seems hugin (and PTEditor and PTPicker) doesn't know the spherical mirror projection. H. Dersch mentions spherical mirror in his readme (http://www.path.unimelb.edu.au/~dersch/Readme1) only in connection with remapping. The formerly mentioned article (http://perso.wanadoo.fr/panoramas.re/vrt/vrt06.htm) demonstrates the procedure for one single image.

Obviously, for two or three images the procedure could be to apply the remap function of Panorama tools and assemble them to one single image. This can be done with the Photoshop or Gimp plugin as a frontend. I found a short tutorial (http://www.cgtechniques.com/tutorials/getridof.php) describing this procedure. There seem to be some inconsistencies in the article, though.

This article (http://www.designwizardry.com/oneshotvr/) is especially good for a brilliant idea what sort of mirror could be used, but the rest is interesting, too.

Burkhard

[HankF]

Hi Burkhard,

Your reply was all very helpful. Since I posted the above, I also have used Hugin which makes things a bit easier than Ptpicker as a front end. It is very helpful for rapid iteration to make sure your test files are in the default folder for quickest access. I tried several iterations involving the lens definition but was not able to get a reasonable output. Looking through your links above the one that seems the closest to my problem is the tutorial using 3 fisyeye pictures.

Here are some random observations:

o I wanted a cloudy day because the sky has more character but I should have increased the exposure. The mirror cuts the available light by something like 1/2.

o Comments on the Web that I have encountered about lens types all say that multiple shots with normal lenses will always be superior to fisheye pictures (because of the inherent resolution differences and less distortion). This applies to mirrored spheres too.

o Given XTR's panorama resolution of 8160x3060, with my camera (1280x1024) it would take 32 full CCD pictures (8x4 in landscape orientation) to cover that with at least 15% allowance for overlap, not considering the lens.

o I downloaded Gimp 2.2 but the Gimp plugin available with Planotools apparently won't work with that version. It wants Gimp 1.2. At least it says that the gimp_1.2.dll file is missing when Gimp is started. Plano12.dll is in the correct folder. I'm trying to avoid Photo Shop as best as I can.

o I also downloaded Enblend but for some reason it won't run. I'm missing the secret here.

o I'm not very clear on what to expect from Ptools as far as it's ability for distortion correction. I have read about correcting barrel distortion as a separate function. Is that true?

o I had the "devils own time" trying to add the lower 1/4 to a XTR panorama picture in Gimp so I could view it in PTViewer with the horizon line straight. I finally resorted to copying the whole panorama to the clipboard and pasting it on a new blank picture of the proper size (8160x4080) and moving it up to the top. How does one stretch the canvas in Gimp for an existing picture? My normal photo editor (Presto ImageFolio LE) has an expand canvas function.

Hank

[BurkhardE]

Hi Hank,

by now I think closest to your problem is the tutorial linked in my second post in the second paragraph, since it deals with remapping spherical mirror pictures and stitching them to a complete panorama. The last article I linked to is especially interesting for mirror and exposure.

The PanoTools plugin for Gimp 2.0 is the Next Generation plugin for 2.0, available on the SourceForge download page (http://sourceforge.net/project/showfiles.php?group_id=96188) (the newest pano12.dll is there, too). It's absolutely needed for the remapping function. Set Sinc256 in Prefs -> More.

All information about enblend and the program download is here (http://enblend.sourceforge.net/). It's only an .exe file, 1.2 MB big in the latest version. I attached my batch file (zipped) as an example for calling it.

Most of these facts you'll find collected on my page (http://time.fh-augsburg.de/~erd/photo/pano/textTools.html) (to remind myself). Unfortunately, I'm a rank beginner with Gimp (didn't Image -> Canvas size... work?), but I know a bit about Pano Tools. It's a true toolbox and you may apply any tool (e.g. barrel distortion) seperately. But a big strength is to do all transformations and corrections in one step so image quality is preserved. And you'll have to read the tutorials since you won't find a function named barrel distortion.

Some questions might be answered on my page.

Burkhard

[HankF]

Burkhard,

Thanks to you I now have a functioning Panotool plug-in in my Gimp. Initially I didn't realize that the download was the plug-in itself and not an install file so I had a bit of a time figuring out where to put it. Anyway now it shows up in the filter menu.

The tutorial that you mentioned said that Ptools can't do a horizontal fisheye. I haven't yet figured out what that means but I hope to.

I'm still working the Enblend problem.

I've got this strange feeling that I'm going nowhere - fast!

Hank

P.S. It's entertaining to view a Mercator projection global map (sized to 2:1 ratio) in PTviewer - just like being inside your own globe!

[BurkhardE]

Hank,

horizontal fisheye means the lens is pointing horizontally. If you're holding the camera that means you'll shoot the hemisphere in front of you, including sky and ground. Vertical fisheye is the lens pointing upwards to the zenith, shooting mostly the sky and your surroundings only on the edge of the round image.

PanoTools can deal with horizontal fisheye, and I think you should even try to remap your mirror ball shots to that projection. If I understand correctly, PanoTools only doesn't implement all "theoretically" possible conversions. E.g. it's not possible to remap fisheye horizontal to a convex mirror projection. In the tutorial showing "How to get rid of the photographer" remapping from Convex Mirror to PSphere and then to Fisheye Vertical is applied. Looking at the pictures there I was reminded of your parking lot pictures.

The Enblend problem is somewhat obscure. First time downloading it here (http://enblend.sourceforge.net/) I mistakenly right-clicked on the link "enblend-2.3.zip [971 KB] Windows executable" and somehow managed to download an enblend.exe file. But it wasn't the the right one and I had to go back to the download page, left-click the link and choose a download mirror. Does your .exe file run when called from the command line? But Enblend isn't really needed, only nice to have if all other things fit.

So if you feel like going nowhere maybe you should stop implementing programs. ;) I've got this feeling too each time I install programs, both known and unknown ones. In your case I'd try to process the mirror pictures with the PanoTools plugin for Gimp or shoot a pattern of normal pictures and try hugin. The latter is what I did the last 6 weeks and I still don't know enough. That's why I wrote my web page, to sort out the puzzle.

The global map in PTViewer is a very nice idea, but isn't it a strange feeling to be inside the globe? Now I wonder why I never found a panorama of the starry sky (but I didn't really search for).

Burkhard

P.S.: Correction: It doesn't look like being inside the globe, but the map is converted from Mercator to conic projection. Looks very familiar (ICAO aeronautical charts).

[HankF]

Burkhard,

That gave me a laugh. The map you included shows the USA being in the dark!

Anyway, I'm always happy to have someone to complain to and thank you for obliging me. Running Hugin (and by definition, Ptools) has been a frustrating experience because of its unforgiving nature, constantly crashing. I finally tried Autopano and (of course) it picked points on the camera itself! I still haven't gotten a successful run in Hugin running it.

After many iterations in Hugin, the best I've been able to do involved setting the lens type as a normal rectilinear of 165 degree FOV and setting the opimization to "everything."

I may try the conversions next.

I was thinking along the lines you noted about using a simple 35 mm film camera and scanning the pictures. You can order them scanned to CD and (I presume) specify the resolution. I have an old Olympus OM-2 but finding a 16mm fisheye for it seems impossible. The 16 seems like the right size for the 135 degree FOV that is needed for XTR panoramas. Getting a fisheye lens for a digital is rather breathtaking (wallet flattening?). Olympus announced a new one for its E digital series for a list price of $800 making the combo $1600!

My idea was to take 8 or 10 horizontal fisheye shots to get high horizontal resolution and still need only one row of pictures. I think it may be useful to pre crop them too before running them thru Hugin, etc. Maybe this would work with the ball mirror too.

I did edit the pictures before producing the one below, increasing brightness, squaring them and cropping.

Hank

[BurkhardE]

Hank,

the timezone map was simply the first one I remembered. After posting it I hade the same idea as you, so there was no intention but I nevertheless was curious what would be the effect. :)

As to hugin, yes, it's a bit unstable, but it's not always the reason for problems. I'm still confused what program does what in the workflow. By now I'm convinced that the autopano program used as default in hugin has the deficiency of clustering the control points. You mentioned that, I read it in one of the (many) tutorials, and I remember Ted reporting problems with wide-angle pictures. I'd recommend to use autopano-SIFT since it doesn't have this problem. It's one more program to master, but it's worth it. (Use it's own GUI!) In any case, you have to remap from Spherical Mirror to Fisheye or PSphere first since both autopanos don't know mirror projection, afaik.

Next step: All experts recommend to be cautious when optimizing. If complex distortions occur in the pictures, autopano might not be able to find suitable control points. After it has done it's job, you have to correct unsuitable points and maybe add points in the problem zones. Your problem will be to find out where the problems are. The recommended way to do that is to begin with the simplest optimizations and find problems in the preview, then correct or set control points to remove the problems, then iterate with the next optimization step. Sometimes the optimizer seems to crash (not hugin), but only if I tried full optimization of bad pictures (the algorithm seems to be numerically unstable under certain conditions or simply has overflows).

My idea was to use my old equipment with a wide-angle to have a low picture count (at least <= 36 ;) ). For only 16 pictures I'd spend some time to correct control points, if necessary at all. I was frightened by the prices paid even for old fisheye lenses. But I think 16 20mm-rectilinear pictures require even less manual work than 3 8mm-fisheye ones, since there is less distortion and ample overlap. You have a very fine film camera, why don't you look for a used rectilinear wide-angle, not-so-fast but high-quality and cheap? (You might even sell it later without a loss.) I attach my Excel file used when thinking about these issues as a starting point (labels in German, but should be no problem).

And, last point, I really enjoy our discussions and always understand something new when writing and trying to come to the point. ;)

Burkhard

[HankF]

Burkhard,

Well, I finally got a useable (if crude) panorama (of my back yard) using my silvered globe. I faithfully followed the steps outlined in the "Christmas Ball Panorama" Web site which you refered me to and nothing could be simpler and with just a single picture. I suspended the globe horizontally on a 4 foot arm (broom stick) attached to a tall tripod (about 7 feet) and took the picture hand held from below. It was strictly a test. For software all it required was the Ptools conversion program which I accessed as a Gimp plugin. I had to vertically flip and mirror the resulting image to get it oriented right.

However, to get a panorama suitable for XTR certain upgrades would be required:

1. Use the best globe obtainable.

2. A large frame format film camera (6cmx6cm) would really be helpful. The resulting negative could be scanned at high resolution or a large print made and then scanned.

3. The camera should be mounted on a tripod and adjusted until the ball fills the viewfinder. Here it really would be helpful to have the lookdown viewfinder of the large scale camera. Also use the camera's self timer.

4. The camera should be straight down from the center of the ball and the ball should be as high as possible to inprove the field of view.

5. If you could shoot from above the ball it might give a better picture for XTR but the field of view from below is amazing including much of the sky.

Hank

P.S. The more I learn, I'm beginning to believe that there is no way to produce a decent panorama by stitching together pictures taken with a horizontal spherical mirror using Panotools. I don't see any such option. Maybe the original pictures need to be converted to normal before running Hugin.

[BurkhardE]

P.S. The more I learn, I'm beginning to believe that there is no way to produce a decent panorama by stitching together pictures taken with a horizontal spherical mirror using Panotools. I don't see any such option. Maybe the original pictures need to be converted to normal before running Hugin. Seems so, at least here (http://www.cgtechniques.com/tutorials/getridof.php) the pictures are converted to PSphere. hugin doesn't know mirrors but fisheyes, and here (http://www.cgtechniques.com/tutorials/makepano.php) three fishey pictures are stitched without prior conversion. Maybe you could convert Convex Mirror to Circular Fisheye and enhance the pictures in Gimp, then stitch to PShpere in hugin.

But do you know the mirror praised here (http://www.designwizardry.com/oneshotvr/)? I don't know such mirrors from our hospitals, maybe it's an American speciality. It's reported to have good optical quality. I wonder if shooting three pictures horizontally could reduce or even solve the resolution problem (with a 35mm film camera). The mirror had to be rotated in 120 deg steps and the camera with a tele lens should point at it from some distance. Isn't that the way you shot the pictures shown above? Then after stitching the get rid of the photographer (http://www.cgtechniques.com/tutorials/getridof.php) method has to be applied.

Burkhard

[HankF]

Burkhard,

The dome mirror referenced in the "one shot VR photography" is used on the ceiling of stores for surveillance and to warn people shopping of an inpending collision with others (See Here (http://www.seeall.com/products/dome_mirrors.html)) . Unfortunately they are not usually a full 180 degrees. But, for horizontal work it might be enough.

On the question of shooting up or down on a spherical mirror, remember that XTR has a 45 degree hole at the bottom which might be enough to hide the photographer. You do, however, have to add some sky (because the globe itself creates a hole) which might not be very hard to do. Also, note that the farther away from the mirror the smaller the hole in the sky.

In any case, you provided confirmation that high resolution is a must and I think the way to get that is with a film camera expecially on the single shot panoramas. For a 3 shot panorama with conversion to fisheye you might be able to get away using a 35 mm film camera as you suggested and scanning the prints of the images.

I'll try the convex mirror to fisheye on my 3 image set and see what happens.

Anything to simplify things, I say.

On another matter, do you have a reference to the definition of Hugin's inputs? It seems obvious to me that you have to be able to tell it (and Ptools by reference) the direction that lens is pointing. Is this called "Image Center Shift" in Hugin?

Hank

[BurkhardE]

Hank,

indeed the parameters are passed from hugin to PanoTools. The .pto file seems to be the the communications medium for all programs contributing to the workflow (attached is a real example). The hugin help explains shortly the meaning of the parameters, but actually it refers to the PanoTools descriptions. Unfortunately, I lost the link to a more comprehensive explanation by H. Dersch. Now I only know of the two readmes and some tutorials mentioning the scripting parameters. It's all about the single-letter parameters a to e and the like. In the barrel distortion tutorial is a more in-depth explanation.

I never had to set the lens direction since I used autopano-SIFT doing that for me. In the Images screenshot, you see the state after running all optimizations including setting additional control points. The pitch and roll angles are small corrections, but the yaw angle is the shooting direction relative to the anchor image. (In all of my panos one of the images is wildly turned and tilted but I don't know why. Obviously, it does no harm.)

In the Camera and Lens dialog, you have to enter at least the Design Parameters, if not read as EXIF data. The Lens Correction Parameters a, b and c are calculated by the optimizer, as well as Image Center Shift and Image Shearing. Normally, shift and shearing are zero, but in this pano I successfully corrected two stitching errors (due to parallax) by setting additional control points. Actually, I forced correction of the stitching errors by somehow modifying the images and that caused the center shift.

Burkhard

[HankF]

Burkhard,

Well it's been a "no go" with the 3 horizontal ball images converted to circular fisheye. The circular fisheye lens selection in Hugin consistently crashes the program. I have tried all the other lens options to no avail. The best I could do was to use a normal lens set to 160 degrees. I made several conversions from convex mirror to fisheye and cropped them in Gimp making sure that all the images were the same size. If I didn't, Hugin would crash.

I followed the directions in the example you gave me and made sure I had vertical control points. That helped but the result wasn't any better than using the original mirror shots. Maybe when you say fisheye to Ptools it assumes a particular orientation.

I have to say I'm stymied. Could it be that I have the wrong versions of Ptools and Hugin trying to work together? I think my Hugin download has it own version of Ptools included. I also got a message when I tried to convert a convex mirror image to horizontal circular fisheye: "Sorry, not yet available." Only the vertical remap would work. Maybe that's my problem.

BTW, those acrylic domes can be gotten pretty cheap over here. A 12" version without the backing plate can be had for about $38 US. If I go that route I'll first have to try it with my 35 mm Olympus film camera and scanned a print. If that works out but needs higher resolution, then I'll look around for a used larger format camera. I think shooting up is the way to go considering XTR's hole in the bottom.

Hank

[BurkhardE]

Hank,

seems you're right, Convex Mirror to Horizontal Fishey is not available. (I never tried before.) It remembers me of the tutorial converting to PSphere directly, that works. And I've just remembered that you might set a horizon line in your images, at least an estimated one.

I wonder what crashes in your installation. You have the latest hugin version, it should even call Enblend correctly. I've got PTOptimizer version from 2005-05-16 (don't know the source anymore), PTStitcher of 2003-08-17, nona of 2005-05-17 (as hugin), autopano of 2004-07-21, autopano_SIFT of 2005-04-09, all works fine. These are some newer versions than coming with hugin, but that shouldn't matter.

I reckon you remapped the images in Gimp and loaded them in hugin, declaring one as the anchor. Then you set control points by hand and ran the optimizer, which crashed. In that case, I'd first use the preview function before optimizing anything. Btw, I forgot (sorry) to report a recommendation from the tutorials to save every step in hugin before trying the next, so you could revert to the previous step if something goes wrong (or even crashes).

It could be worth a try to let autopano-SIFT find control points (including horizon lines). And did hugin crash in the first optimizing stage "Positions (incremental, starting from anchor)"? Seems I'm at a loss.

Burkhard

[HankF]

Burkhard,

No, the optimizer never has crashed. If I somehow get mismatched control points, stitcher will crash. My crashes come when I select convex or equirectangular lens from the pull-down menu. Sometimes, the full frame fisheye will crash depending on what the parameters are set at. Stitcher will not process fisheyes with a FOV larger than 160 degrees.

Anyway, what we really need is a series of synthetic pictures taken with perfect virtual lenses that we can use for testing. Something like taking pictures from the inside of a half dome that is made up of grid lines (lattitude and longitude) with a radial grid on the floor from the center (where the picture is taken) to each of the longitude lines. The series would be used to construct a virtual panorama using each of the lens types. Using these pictures in our software would tell us when we are doing things right. If you know how to produce such a thing I sure would like to hear your thoughts.


Hank

P.S. I somehow managed to have an old pano12.dll (I got it from the Dersch site). When I replaced it with the one that came with Hugin, the circular fisheye finally works without crashing ---------but it didn't help the result. The best I can do is with a 160 degree normal lens (on the circular fisheye input images).

[BurkhardE]

Hank,

160 degrees - that's the crippled version! (The USA being in the dark, but Europe soon no longer enlightened, too. ;) ) I've got the latest version from SourceForge and it seems to be crippled, too. I tried to copy the How to get rid of the Photographer (http://www.cgtechniques.com/tutorials/getridof.php) example, but only the first step worked as in the screenshots given there. Maybe even the Gimp plugin is restricted. There must be an uncrippled version of the pano12 lib somewhere, but I didn't bother so far since I tried the picture pattern method anyway and had not to think of patent issues.

For the ideal panorama grid, your mentioning of latitude and longitude reminds me of the Mercator map and it's grid. H. Dersch has something like that in his PTEditor tutorial (http://www.path.unimelb.edu.au/~dersch/pted/pteditor.html), along with some hints how to edit panoramas and extract pictures from it. The tutorial pictures are not shot but extracted from a completed panorama. I wonder if a half dome would be right, thinking that a full sphere is the natural projection for a panorama. And since we see a conic projection in the viewer, we could take several "maps" with a conic grid to assemble a panorama. The single maps might be constructed with a vector graphics program, but I'm not an expert for that. Seems easier to draw a Mercator grid and extract single pictures with PanoTools, provided they work.

Burkhard

[HankF]

Burkhard,

I looked for later versions of pano12.dll and the latest I could find is 2.7.0.10. I have 2.7.0.9 currently. I understand the .10 version is more like a beta (maybe they all are) and has a much speed-improved optimizer. It may be worth using. Have you found any more info about it?

I reread the article on using the half dome acrilic mirror and it seems like the best he could do was a 120 degree VFOV panoram. XTR, on the otherhand, needs 135 and thats in the upper side of the panoram. I'm just not sure any single shot will give the required FOV.

I also looked a the Kaidan site and their "360one" parabolic mirror attachment seems to give pretty limited VFOV. I looked at a lot of their promotional QTVRs. But maybe the Quick Time viewer has limitations on VFOV also, do you know?.

My suggestion for a hemisphere as the basis for a set of synthetic pictures was simply that it would represent a synthetic world as we see it, not how we would project it as a panorama which, I agree, would be full spherical.

If I can't get the 3 image horizontal mirror to work, it's beginning to look like the multi image stitched panoram is going to be the most practical approach even if it is the most time consuming.

Hank
P.S. An Interesting Site (http://www.path.unimelb.edu.au/~bernardk/tutorials/360/)
Kiev Lenses (http://www.kievcamera.com/product.php?ID=14)

[BurkhardE]

Hank,

the pano12 lib at SourceForge is definitely restricted to 160 degrees FOV for fisheyes (I found it on the main page (http://panotools.sourceforge.net/) under "Important Information"). I used the newest version 2.7.0.10 as you did. Oddly enough, I missed Ben Kreunen's excellent tutorial even though he is hosting H. Dersch's old web pages. Following the link you gave, under "Software Links" I found a link to a "Recompiled pano12.dll with 1000° FOV limit". Maybe it's an unrestricted version, but it's dated 2001-12-02 and thus might show the problems you encountered (crashing). But Jim Watters (http://photocreations.ca/panotools/) seems to have a "WinZip Replacement DLL with changes incorporated including FoV limit of 1000°". We should try it (Jim recommends to put it into Windows\System32) instead of the SourceForge version with the same version number.

Interesting enough, B. Kreunen shows in one of his tutorials (http://www.path.unimelb.edu.au/~bernardk/tutorials/360/background/process.html) how to remap mirror or fisheye images to final projection before stitching them together. So it might work! When looking for used lenses on eBay, I already found the Peleng lenses from (supposedly) Ukraina and the Zenitar lenses from Russia. But I didn't find any reliable reviews and wouldn't dare to buy one, particularly since I now read here (http://www.path.unimelb.edu.au/~bernardk/tutorials/360/photo/lens.html) that image sharpness is a so important property of a lens. And I'm too stingy to buy even an used Nikkor fisheye, so I'll stick to the 18 images (or even less) full-sphere pattern with my 20mm rectilinear Nikkor. And after reading Ben's considerations on dynamic range I wonder if I should change from slide film to negative film.

For a single-shot panorama for Reflex I think it's no problem to use a somewhat FOV-restricted dome mirror. The ground isn't needed anyway, and there will be a zenith hole in any case. So you have to shoot a zenith picture or use one of Philippe Hurbain's sky images which might fill any hole of whatever size. Btw, I don't know of any FOV restrictions of Quicktime. Look here (http://zermatt.arounder.com/fullscreen.html) and select "Gornergrat", it's amazing. :)

As to synthetic pictures, I slightly missed the point. If I understand you correctly now, we'd need kind of a scenery drawn with a grid showing if the panorama is correct. As a non-expert, I imagine a half-dome with flat bottom or a box like an aerobatics contest box. It could be drawn in a 3D graphics or CAD program and rendered as if you were at the center point and looking around. Some screenshots at different viewing directions would be the replacement for real-world photos. Stitching them together should give a correct panorama seen in the viewer exactly as in the CAD program. Hm, sounds daring...

But gradually I'm wondering if we are on the right way at all. We learn more and more about making panoramas, but the only reference to XTR panoramas is that they are 360x135 degrees. I remember Ted writing that he couldn't reverse-engineer them, so it's all in the dark. What do you think?

Burkhard

[HankF]

And I'm too stingy to buy even an used Nikkor fisheye

Burkhard,

That about sez it all! I spent many hours looking for a M42 (Pentax) adapter for my Olympus OM camera but they seem to be as scarce as hen's teeth. I was looking for a cheap way to adapt the Peleng fisheye to my camera. But I'm about to give up on that.

Jim Watters' suggestion of putting pano12.dll in the System32 directory seems a bit odd. Surely he meant the System directory. That's where it seems to work O.K.

The Site where "Gornergrat" is displayed is, indeed, amazing. I really enjoyed the panorama of the Coliseum in the Roman display. I wonder what equipment and technique they used in those pictures. Also amazing is how fast XTR is in displaying those large panoramas compared to QTVR.

I think I'll just buy one of those acrilic dome mirrors since they are cheap enough and give it a try with my Olympus. You're probably right on fleshing out the sky with something else.

If Reflex eventually does come out with a scenery editor I'd like to be ready for it if I can. That's why I'll continue pursuing the issue. I do think it's time to sit back and mull thing over as you suggested.

Hank

[BurkhardE]

Hank,

here (http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&category=80438&item=7500049556) seems to be the Zenitar with Olympus adapter (review (http://photonotes.org/reviews/zenitar-fisheye/), not very specific). I couldn't find the English version, but the seller claims to be in Canada. Same seller offers Peleng with Olympus adapter. But who knows if not this (http://www.zenit-foto.ru/english/production/cameras/panoramic/horizon.htm) has to be used for Reflex XTR panoramas? ;)

Burkhard

[HankF]

Burkard,

Bugs, bugs, bugs!

Bah! Autopano-sift-2.3 crashes for me either by itself (GUI or command) or in Hugin. It's the latest version, too.

Autopano runs O.K.

Hugin would not run with pano12.dll version 2.7.0.10 until I copied msvcr72.dll into the \Window\system directory.

I did order a 12" acrylic mirror and put a new battery in my Olympus OM-2n so we shall see.

Hank

P.S. Zenitar 16mm review (http://photonotes.org/articles/zenitar-panoramas/)

[BurkhardE]

Hank,

autopano-SIFT crashing and pano12.dll requiring the msvcr72.dll might both mean you'd need a Microsoft-conforming .NET installation. Both programs work fine in my XP setup (I used Windows Update), even pano12.dll in system32. But I still didn't manage to call autopano-SIFT from hugin. Instead I read about a bug in the hugin/enblend combo. In Preferences->Enblend uncheck "Delete remapped tiff files"! And others already found and reported the bug in the Gimp plugin (PSphere to PSphere in adjust), but without response from the developers.

The Peleng lens (made in Belarus, not in Ukraina, I now learned) seems to be a bargain with acceptable quality. Unfortunately, it's likely not to fit my Nikon FM body (mirror collision). But the Zenitar might be even better for resolution reasons, and there's an alternative by Sigma.

Playing around with the mirror pano tutorials, I managed to copy all three. But I think the method here (http://perso.wanadoo.fr/panoramas.re/vrt/vrt06.htm) ist best (i.e. correct), at least better than both this (http://www.cgtechniques.com/tutorials/getridof.php) and even this (http://www.panotools.info/mediawiki/index.php?title=ChristmasBallPanoTutor). All of the three panos were better using this method (mainly hfov and vfov settings and no shrinking or enlarging).

I can hardly wait to see your mirror pictures.

Burkhard

[HankF]

Burkhard,

See if this is true: the output of Pstitcher using the rectilinear (wrong, equirectangular - ed) option is a panorama in which the vertical field of view is distributed symmetrically about the horizontal middle of the picture. This means that if you want the horizon to appear as a straight line across the middle of the panorama, there must be a row of input pictures where this is the case and it must be the anchor row.

I had the idea of using a 135 degree VFOV full frame fisheye (16mm) pitched up 22 - 1/2 degrees to shoot a row of pictures for an XTR panorama, the VFOV running from -45 degrees to 90 degrees. In these pictures, the horizon line wouuld be slightly curved down, I believe. But this probably wouldn't work considering the assumptions of Pstitcher above. I even thought of adding the bottom 45 degrees to the pictures before processing but I doubt that Pstitcher could remove the curvature of the horizon line even though it would now be in the middle.

BTW, to install Autopano-sift (which I did) required the installation of the .NET frame from M$ (which I did). When I got the message from pano12 2.7.0.10 about msvcr72.dll, I did a search and there were two copies of it but neither in the \windows\system directory. When I copied one to the system directory, pano12.dll worked fine.

I have many questions as to what Pstitcher assumes about the input pictures. For example, if one took a horizontal row of 135 degree VFOV pictures, and one vertically to fill the zenith hole, where does Pstitcher get its boundary definition for the rectilinear panorama? Does one also have to provide a nadir picture for balance?

Hank

[BurkhardE]

Hank,

since I had a naive approach to the problem I never questioned that these "asymmetric" picture patterns work. In fact, my first attempt was an incomplete and asymmetric panorama (of my garden, of course :) ). Admittedly, it's a single-row panorama. The workflow described in my web page worked well and virtually "automatic". Autopano identified suitable control points, PTOptimizer calculated the distortions, PTStitcher bended and overlayed the images. It was already then that I got the impression that autopano-SIFT works better, especially in finding the horizon (that option has to be checked in the GUI).

Sure it would help to declare the yaw and pitch of each image in the GUI. And setting an appropriate anchor picture at least would reduce optimizer's work. I did only the latter. I don't know yet if it's necessary to declare the pitch for multi-row patterns, but I suppose it's not. H. Dersch even recommends in one of his tutorials not to stitch the rows seperately. I guess also that a zenith picture isn't necessary if there's some overlap. But Ben Kreunen recommends one to avoid bad image quality in the zenith. I'm rather sure that no nadir picture is needed for balance. (You may only have to declare the panorama pitch in PTViewer.)

I would let the portrait images go down to -55 or even -60 degrees to allow for cropping the curvatures after stitching. The upper bound of 75 degrees is no problem since it's advisable to have a zenith picture anyway. Btw, I still missed the fov angles of a full-frame fishey. Maybe they are 150x100 degrees (for film) if diagonal fov is 180 degrees? In this case, you might even skip the zenith picture (but reducing quality). In any case, I'm sure autopano is able to sort out the image arrangement and find horizon and zenith automatically. And autopano or the stitcher is able to crop the panorama on both sides if it's all-around, and on top and bottom if zenith and nadir exist. It derives all from the image distortions, and these are derived from the control points. Must be a brilliant algorithm.

Burkhard

P.S.: 360-degree panoramas have to be Equirectangular. Rectilinear works only up to 110 (or 160?) degrees, afaik. Did I miss something?

[HankF]

Burkhard, I meant Equirectangular not Rectilinear, a slip of the mind.

How would Ptools know where the horizon is unless you tell it? I'm sure you took your pictures with the camera lens axis held reasonably horizontally for a least one row of pictures and Ptools assumed that it was so. I'm sure that was your intention. If, in fact the horizon was 1/3 the way up from the bottom and curved how do you suppose Ptools would know it to be the horizon "line"? I guess I just haven't experimented enough. This is where some synthetic pictures would be invaluable in discovering the capabilities of Ptools.

What kind of a mirrored ball do you suppose that is that they used for that chess board panorama? It doesn't seem very big! A large ball bearing? I didn't see where it said.

Hank

[BurkhardE]

Hank,

surely a large bearing ball would be a good mirror since it's shape is virtually perfect and it's polished. I'd put some plasticine below it so it would stay there. ;) The first picture shows it's nearly as big as a chessboard square. But wait, just now I'm looking at the WindowsXP taskbar and see the window caption: "A pinball panorama ...". :) H. Dersch supposedly used a small bearing ball for his Macro Panoramas (http://www.path.unimelb.edu.au/~dersch/html/Micros.html). (The web page is called Micros, obviously he couldn't decide.) I wonder if they used a macro-tele lens.

I'll post separately for the other topic.

Burkhard

[BurkhardE]

Hank,

this is going to be an XL size post, due to some screenshots attached. ;) After some confusion, I decided to rely on my before-mentioned panorama, being "asymmetric" and "incomplete". That means I didn't bother about horizon but simply pointed the camera to the intended subject, and I shot only a 3/4 circle (one row).

In the Images dialog, I declared different anchors for exposure and position. The latter only means that the other images are positioned relative to the anchor image, what is easier for the optimizer. And the whole image row wouldn't "waggle" so much as if anchored on one side. The yaw, pitch and roll values are later calculated by the optimizer. In any case, I didn't set them at all. The different pitch and roll values show that my "panorama tripod" (see above) is somewhat sloppy, but that's all made good by the optimizer.

In the Camera and Lens dialog, the lens data were first loaded from EXIF, but later recalculated by the optimizer. The barrel correction factor was at all calculated by the optimizer.

In the Control Points dialog, the points are evenly distributed over the whole image height. That is autopano-SIFT's work (not autopano's)!

In the Optimizer dialog, I called the optimizations step by step and avoided "Everything". I had not to affect the process by doing something like setting or correcting control points.

In the Stitcher dialog, FOV and optimum size were calculated by the program. It already "knew" the panorama dimensions from the previous steps. Both exposure correction and EnBlend weren't needed for these images, feather would suffice.

The Preview window is really wysiwyg. It shows that each rectilinear image is remapped to a spherical part of the panorama. Since it's less than 360 degrees, the center is marked as a vertical line in the middle of the image. The horizon line is derived from the remapping of the images. If you'd take two of the images printed on paper and stitch them together on their common control points, the paper would bend to a conical shape since it would refuse to assume a spherical shape, but the "virtual panorama paper" won't.

Now I intend to use the grid H. Dersch uses in his PTEditor tutorial (http://www.path.unimelb.edu.au/~dersch/pted/pteditor.html) or the timezone map for a test. Rectininear images covering the whole sphere would be needed (except nadir for XTR). One could render them in PTViewer and make screenshots or extract them using the Adjust tool. And it would be interesting to make them as if a 20mm lens or a 15mm fisheye were used. Finally, one of the real XTR panoramas should be used for such a test. Just now a new one is published on RC-Sim, to a large extent lacking detail suited for control points. Manual work should be necessary!

Burkhard

[BurkhardE]

Hank,

the grid turned out to be a bad example for panorama creation sinc it's not a real image but more of a drawing. I "shot" 5 or 6 images in portrait orientation with 100x150 degrees FOV. This turned out to be 13.75 mm focal length of a full-frame fisheye (calculated by hugin). I used the Adjust tool in the Gimp plugin to extract the images in FF fisheye projection. First try was 6 images every 60 degrees azimuth at 15 degrees pitch, second 5 images every 72 degrees at 7 degrees pitch. There was a zenith image in both cases but no nadir image.

The first case gave a completely identical pattern in the portrait images, the second somewhat displaced grids. But even that didn't help. Both autopano programs were unable to find any control point (more or less, they crashed). I think they failed because there are so many indistinguishable pixels and because the grid lines were not really anti-aliased in the more bended regions.

Nevertheless, it's possible to create a panorama if the yaw and pitch angles are declared, as you suspected. No optimization is needed at all, the panorama image is aligned and sized automatically (in the Stitcher dialog of hugin), including horizon. Of course, that wasn't just what I wanted to show. :o But at least it's shown that rendering the zenith is difficult (compare the original grid and the pano). Some manual work might be required in any case.

You may copy this test with the files in the attached zip files.

Burkhard

[BurkhardE]

Hank,

the test using the timezone map is a bit better. Now both autopanos found several control points, autopano even better than autopano-SIFT. But anyway, control points don't help in this case. The rough, low-resolution drawing is too much distorted and un-antialiased when extracting the single images.

First I tried with control points only (autopano-SIFT.pto) and let the optimizer find yaw, pitch and roll of the images. Actually it succeded, but the values were all somewhat off, not exactly the right ones.

The second try used the control points too, and I additionally entered yaw, pitch and roll by hand. But as soon as the optimizer is started it replaces these values with the wrong ones calculated from the control points.

So the third try was to enter all data and use no control points at all. Of course, the result was virtually the same as that of the grid test case (bad zenith rendering), but this time one stitching error in the middle of the picture occurred (compare the original map and the pano in Windows image viewer).

My conclusions for the time being:
- Good source image resolution is paramount, not only for good-looking results but for finding good, useful control points also.
- Control points are needed in all practical cases because perfect image alingnment (yaw, pitch, roll) is not possible.
- It would not help (at least not much) to exactly know the lens distortion parameters since the yaw-pitch-roll correction will be needed anyway. The optimizer will find these using control points.
- It would help to make finding control points easier so it can be done automatically. That is achieved by using a normal focal length (no distortions and aberrations) when shooting a regular pattern of many images and declaring the rough yaw and pitch values in the .pto file. Essentially, that's what Ted reported.
- It should be possible to shoot only a few wide-angle images, generate control points with autopano and enhance them manually. Film or good digital resolution would be sufficient. That's what several tutorials are showing, above all Ben Kreunen's.
- If perfect image alignment would be possible (why not?), and provided the lens distortion is known, it might be possible to stitch with only a few control points or without control points at all.

The last test proposed above, using a real XTR panorama with a sky without control points, will probably give not really new findings except concerning the last point.

Burkhard

P.S.: The error in the timezone map panorama was due to a barrel correction factor that sneaked in.

[BurkhardE]

Hank,

the XTR panorama stitches perfectly, given the yaw and pitch values and no control points. There are no visible quality losses, so supposedly a 4 MPix camera would suffice exactly (100/360 degress x 8160 pixel = 2267 pixel, the camera has 2272), provided there's a suitable fisheye lens. There's not so much FOV needed below the -45 degrees line, so the 150 degrees VFOV may cover the whole panorama height. A zenith picture would be needed only for better quality.

Using control points the XTR panorama stitches at all, but quite wavy. That may be remedied by setting horizontal line points since there is a visible horizon. Besides, there are several control point candidates not found by autopano that might be set by hand.

But the idea of a "perfect" panorama tripod/head is fascinating. I have to deal more with the optimizer to find out how to make full use of declared yaw and pitch (and lens) values and use control points for only subtle corrections.

Burkhard

P.S.: XTR panorama posted to RC-Sim (http://www.maltemedia.de/harry/Szenerien/Marktplatz_Heide/Vorschau.jpg)

[HankF]

Burkhard,

Boy, that was a mouth full! But I did chew it up and have digested most of it.

First though, I had a breakthrough of sorts: I got a pretty good panorama of my original (horrible) 3 mirror shots of the parking lot. I did it by setting the lens to a 270! degree circular fisheye. The Hugin preview showed some artifacts that didn't show up in PTviewer or in the output file. I'm going to try this again with the new mirror, a decent day and my 35 mm film camera.

It was interesting to learn that, yes, you need to tell Ptools which way the camera was pointed at least for the anchor picture. I used your techinque of using Ptviewer to generate screen shots. I did 5 of the top of a globe with the camera pointed up at 45 degrees and was able to generate an appropriate panorama (except for a ragged bottom edge). You may not think it but it displays properly in PTviewer.

I also learned that you should reset the image pointing parameters in Hugin each time before you run optimizer (after making a change) otherwise you may not get what you want. Hugin needs a universal reset to default button (maybe it's called "New" in the file menu. I also finally got Autopano-sift to work outside Hugin. Hugin doesn't seem to pass the right folder parameters to it (at least in my installation). With your generous help I think I'm finally beginning to understand something about using Ptools.

That's a nice XTR panorama. You say it's available on the Reflex site?

As an aside, have you looked at the Olympus E-300? 8 mp and you can buy an M42 (Pentax) screw thread adapter for it and use all those 35mm lenses including the Zenitar 16mm and the Peleng 8mm.

Hank

[tewehner]

Wow...I go away for a few weeks and you guys go nuts on this stuff! :) Too late here to absorb all of this discussion tonight, but hopefully I can catch up tomorrow and get back to participating.

[BurkhardE]

Hank,

the E-300 surely is a fine camera and I wish I had one (or would I stick to Nikon? ;) ). My problem is the combination of a digital SLR and the old lenses. I don't want to end up like this (http://www.muellerworld.com/dsc4044/relay_system-54.html) or this (http://www.nearfield.com/%7Edan/Photo/wide/fish/). Though I happen to own just the lenses used there, I would feel strange when I'd go out and shoot panoramas using such a cannon (no pun intended). So I'll wait till Reflex offers the RSK to see what equipment is needed.

The scenery should soon be uploaded to rc-sim.de. But if you follow the link given above and remove the "Vorschau.jpg" in the browser you'll have acces to the files of the scenery.

Burkhard

[HankF]

Ted, welcome back. I'm sure you could have helped Burkhard clear things up for me! We're working hard to reduce the picture taking workload and also be as cheap as possible. The two my be contradictory goals when also requiring some level of quality.

Burkhard, I download the Vorchau scenery and it's a nice panorama but a terrible place to fly helis. They just disappear in the tree line! It's too bad Reflex doesn't provide a way to adjust the lighting on the model.

Wow, those are some cannons alright. It must be that the E-300 has a large enough sensor to take 35mm lenses directly (wrong, it is almost exactly half size so a 50 mm lens acts like a 100 mm- ed). The adaptor doesn't look that large (deep). I whined at Mike at Kiev Camera about not having an Olympus OM to the M42 adapter for the two lenses (Zenitar @ Peleng) he sells and he declared he would have them on the 24 of this month - now that's a temptation. But as you say, now is not the time to jump.

If Ptools can handle multi mirror horizontal shots as a 270 (more or less) degree fisheye then all that should be required are two back to back shots. I shall be trying that when my mirror arrives (to be shipped today) along with vertical shots. My Olympus OM-2n with a Tokina 35-105 zoom fills the frame with a 12 inch circle from 19 inches (target to front lens distance) at full wide angle and 59 inches at full telephoto and 23 feet for my 500mm telephoto lens. For a single vertical shot, wide ange looks to be easier to set up with the camera on a short tripod and the mirror overhead on a tall tripod with a 1/8" by 2" aluminum arm of about 4 to 6 foot length which should minimize the cropping of the equipment. To minimize equipment cropping for the horizontal shots, the 500mm tele may be the ticket.

BTW, have you a guess as to the order Optimizer applies the lens positioning parameters? In my parking lot "thing" the right had shot has the wrong roll angle but is that after pitching and yawing have been applied?

Hank

[tewehner]

Hey guys,

Well I'm still not caught up but glancing through I noticed Burkhard mentioned that autopano missed some control point candidates. Nothing much to add here as it does indeed miss synching some obvious image pairs. Actually, just wanted to add a tip (if you havent already figured it out and it is even pertinent here); Within hugin, in the images section, if you select two images and click "create ctrl points" it will add new points for just those two images to the existing control point list (it will find plenty this time even though it missed them when doing the initial big pass). So, when I bring the .oto (or .pto or whatever) file in, i step through all images pairs in the control points section (select 0 in left side 1 in right, then use the big browse right button at the top to look through all of them). When I find a pair that is completely missing points when it should have easily found some, I switch back to the images section and run the create points on those two images. Having a thorough set of control points really helped us prevent stitching errors (edges).

Also, you are correct about the horizontal lines - they, and vertical lines, can help a great deal toward elimnating the "wave"...tho, the manual positioning before optimization helped the most in this area.

Ted
The W3 Group

[BurkhardE]

Ted, you see we did much trial and error here - both. :) And, indeed, your tip is pertinent, thank you! I didn't figure it out yet (since I tried to prove that it's possible to do without control points ;) ).

Hank, I guess the optimizer corrects all parameters you selected (e.g. Positions, View, ...) in one step. Maybe the problem with your three pictures is projection. I'm quite sure you should first convert them to a different projection (maybe PSphere as in one of the tutorials) and only then process them in hugin. I'm not sure how hugin handles PSphere source images (never tried). I only tried the conversion using the Remap tool of the plugin. The Adjust tool was also needed. PSphere seems to be easier since I didn't really succeed remapping to fisheye projection. Vertical Fisheye worked best, but in any case I didn't notice a difference when changing FOV parameters (but HFOV=360 and VFOV=270 might be good). I still have to try the equation. You might use it as well for your mirror shots (I mean for calculation of FOV when remapping).

For the XTR sceneries, I can emphasize what you said - they are nice panoramas but bad sceneries. Do you think they behave differently for aircraft and helicopters? I found the lighting quite correct in the new scenery. (Btw, it's called "Marktplatz Heide", translated "Heide marketplace", and Heide being a town near the place where the Reflex people live.) Maybe the sunlight direction is 20 degrees off (you might do a Google search for WLPEdit and try yourself), but it's hardly noticeable.

Burkhard

[HankF]

Ted: I've been unable to execute Autopano-sift from within Hugin but it works as a standalone. Could you tell me what arguments you are using in the preference section of Hugin under Autopano-sift? Hugin is not passing the right file or folder parameters to Autopano in my setup. I did have problems with Autopano-Sift finding points on only two of the three pictures and it complained but I really couldn't decipher what it was complaining about. I though it was simply sufficiently bad starting pictures.

Burkhard: Airplanes present much more surface to be seen than helis of the same approximate size so are harder to see. Also the tail booms tend to be painted black and the whirrling blades are all but invisible. The lighting of the model doesn't seem to have anything to do with the scenery. Have you looked at the "nightime" scenery that is available? They had to make a special black model with lighting on it. A regular model is lighted just the same as in other sceneries.

Hank

[BurkhardE]

Hank,

now I got it. But it must be possible to adjust even diffuse light in DirectX, like in the indoor scenery. Seems nobody found out how to do it and we really have to wait for RSK. (Wasn't there a guy named Nobody in a movie? ;) )

Calling autopano-SIFT is obviously possible, but not necessarily successful (the script is missing a parameter, I didn't find out yet):
Path:C:\Program Files\Autopano-SIFT-2.3\win-autopano-sift-cmdline.vbs
Arguments: -o %o -p %p %i
Don't use the " ... " button, hugin may crash. Instead, enter the path where you installed the program by hand.

I tried only twice not yet knowing Ted's tip and decided to call the program's own GUI. After all, it's the first program in the workflow and used only once (I then thought). Now I see it's worth more tries. (But there was also Rob Park's tutorial (http://rbpark.ath.cx/photography/panoramas/tutorial.html), especially his remark under the Hugin - Introduction heading. Btw, there's a link to a thorough description of the GUI options, also worth a closer look.)

Burkhard

[HankF]

Thanks Burkard: I was even calling the wrong program! Anyway I shall try it.

I took two back to back mirror shots (with the low res camera and my distorted garden ornament) and after much iteration in hugin, got a reasonably decent panorama of my street (see below).

The main thing that I learned is to use Hugin's custom optimization. I set the yaw and pitch and let Optimizer compute the roll but I still had a horizon mismatch on both sides of the join line. When I let Optimize adjust the lens shift parameters it got rid of that. Finally I had a notch missing from one joint but I got that back (mostly) by letting Optimize figure out the lens FOV (253 degrees). I think Hugin and Ptools did a pretty fair job considering the poor quality of the photos. Now All I have to do is get rid of the camera(s).

I think that when I use my new globe mirror with my 500mm tele on the Olympus and with the scanned film, I'll be getting pretty decent panoramas - hopefully by the end of the week.

Hank

[BurkhardE]

Wow, that's great! Indeed that was a good job. Zenith and nadir look perfect, and the tripod legs are perfectly straight. The garden ornament can't be bad. But I wonder how PanoTools handles the spherical mirror projection, I simply don't understand it yet. It's also interesting to see how the seams are placed - quite plainly (they surely would disappear with only exposure correction set in hugin). Now you know how to optimize you can even take three pictures with some pitch if the new mirror is not fully 180 degrees.

Burkhard

P.S.: Calling autopano-SIFT from hugin works now, there was a bug in the calling script "win-autopano-sift-cmdline.vbs". Open it in WordPad, search for "filespec" and replace that by "KeyFileName". It works, as Ted reported, for all images at once or for two selected images. But it doesn't find control points in the sky or in the pavement in the "Heide" panorama either. I guess it's the small resolution of the preview image I used, so the cloud details are rendered differently in the overlapping images. I couldn't believe it's the fisheye projection with it's different viewing angles.

2. P.S.: Following my path of trial, I extracted high-resolution images from the full-size XTR panorama (rectilinear with 20mm focal length). Autopano-SIFT found only a few or no control points in the images containing only sky. My experiment was higher resolution, so the -s 2400 directed autopano to not scale down images smaller than this pixel size. It helped, but not much. As Ted said, setting yaw and pitch helps most. Obviously, the optimizer takes these for granted and applies only minor corrections if control points are available. These corrections are due to small differences in pixel placement in the images and are smaller than one pixel or degree.

3. P.S.: For fisheye lenses or spherical mirrors, RANSAC filtering must be off, so add "-n" to the Arguments for autopano-SIFT.

[HankF]

Burkard:

Well, even with the .vbs correction you gave, Autopano-sift still crashes in Hugin, taking Hugin with it. It seems to finish processing, the command windows go away, the computer makes the "error" sound and the Hugin autopano pop-up remains (and is corrupted) and Hugin itself is dead. I have to close the process and reboot to recover the lost memory (Win98SE).

BTW, Autopano-sift couldn't find any control points in my back to back pictures! I had to set them all by hand. And, yes, I did try it with RanSac off.

Hugin doesn't remember it's settings very well, maybe they're not being written to the script. It won't remember custom optimization or it's parameters. You have to go through before each run and make sure everything is set as you wanted. It could be a bit friendlier.

In my final street panorama I did have Pstitcher correct exposure brightness but there's still a bit of anomaly at the joint. Maybe Enblend would help here.

Hank

[BurkhardE]

Hank,

it's too bad that autopano-SIFT crashes on your PC. Seems it's use is limited anyway because it works best for typical multi-image panoramas. When I described my test with the garden panorama, I hadn't believed that such trouble could occur. After all, it worked fine automatically ordering the image row and finding the horizon line.

My latest experiments only proved Ted's method to be reliable. Many high-resolution pictures contain many control point candidates. If there are no control points in an image (e.g. blue sky) there will be no visible seams, too. More and more I'm thinking about the "perfect" panorama tripod head. How precise must it really be for practical purposes? If yaw and pitch are known, control points are needed for minor corrections only (lens correction factors should be known in advance), if at all.

Even exposure correction seems to work with multi-image rows. Maybe only two images must be corrected in Gimp. Enblend only varies the width of the transition zone.

Burkhard

[HankF]

Burkhard,

Finally, Autopano-sift works with Hugin (a mythical crow?) in my installation. It seems I edited the wrong script file to correct the bug you mentioned above (filespec vs KeyFileName). Duh!

I've taken several pictures with my 7" globe with the film camera and I will take more today. When I get them developed and scanned I should have an idea if that's the way to go. For this trial, I'm going to scan 4x6 inch prints at the 1200 dpi native resolution of my scanner. That should give me about a 4000x4000 pixel image size. Two back to back images should come close to XTR's need for 8160x3060. I wish I could scan the negatives because the automated printing adjusts the exposure and I really don't want that but I can't get the resolution I want with my equipment.

Hank

P.S. Well, that was a wasted effort but not too pricey (<$10 US). That telephoto lens from 12 feet, processed as described above, doesn't have any better resolution than my old 1.4 mp digital. I will have to shoot much closer with a much sharper lens than that and drop down to finer grained film. I was using ASA 200 cheap stuff and had to run my camera at 1/1000 sec (no aperture control on the mirror tele). Still learning more about Hugin: when optimizing on individual parameters, do them one at a time and see if it did what you want before locking it out for the next go-around.

The resolution of a panorama can be no better than the lens can provide!

[BurkhardE]

Hank,

just now I finished my next garden panorama using the 4 MPix camera. I didn't notice clouds shadowing the scene in two pictures, and there's not much to do about it except shooting again (tomorrow, if there are no thunderstorms). But the workflow was fully automatic again. I even called autopano-SIFT and enblend from hugin. Optimizations were Positions (starting from anchor); Positions and View; Positions, View and Barrel (in this order). It was a full row of 13 pictures again, plenty of control points evenly distributed, no problems. I should have defined some vertical lines, though.

Might be a coincidence: Just today I got one of the first Fujichrome Velvia 100 slide films. Now I'm as good as obliged (because my photo shop made an effort to provide me with the film) to try it with my best equipment. I charged the FM and put the 85mm and the 20mm lens into the bag, these should be adequate to the film. Now I have to loan at least a good tripod to not waste the precious film for a handheld panorama. The film (36 exp.) cost almost 15$ without processing (cheapskate speaking). It might take a while till I'll be back with results.

Burkhard

P.S.: Just remembered this (http://www.clarkvision.com/imagedetail/scandetail.html#printpixels). Maybe your lens is not so bad but the prints are too small (4x6 inches giving only 1600x2400 pixels).

[HankF]

Hi Burkhard,

Why don't you post a reduced version of your latest panorama (say 800x400)? I'd like to see it.

I ordered a (used) zuiko normal 50 mm 1.8 lens for my Olympus OM2. It's the standard one that came on the camera originally. (Sometime in the distant past I gave the original with an OM1 camera body to my daughter and it got stolen.)

This is the sharpest lens available for the Olympus so it should show the best you can do with 35mm film for image sharpness with high speed film and the aperture stopped down to 11 or 16 for great depth of field.

As it stands for me, the limiting factor on my efforts to date is the resolution of the lens (500 mm telephoto). It has waayy to little depth of field. I want to get to the point where the imager (the 36x24mm film itself) is the limiting factor. I'm not sure that the one or two shot 35mm mirror image(s) will ever have enough resolution not to mention any distortions in the mirror. (But I don't consider that to be a real problem.)

If the limitation turns out to be the 35mm film size, then there is the option of going to a larger film format, 6cm x 6cm. The Kiev 88 C MLU camera with a 80mm f2.8 lens would cost $450. It may be the answer to low shot count panoramas.

It will be a week before I will know the answer. Good luck on your picture taking. I would much rather use 12 exposure film if I could find it. I'm much too impatient for 24 or 36.

Hank

[BurkhardE]

Hi Hank,

here is the panorama, but you might better view it here (http://time.fh-augsburg.de/~erd/photo/pano/) (along with the other two). If you click one of the links a web page calling PTViewer should appear.

6x6cm should give sufficient resolution, but again I remember something I read recently. Ken Rockwell (who himself says he's a cheapskate) wrote how to start medium format even cheaper (here (http://www.kenrockwell.com/tech/intro2mf.htm)). I think he even wrote that some used large-format cameras are very cheap (here (http://www.kenrockwell.com/tech/4x5.htm)). Might be better for only trying?

Burkhard

[HankF]

Hi Burkhard,
Maybe your lens is not so bad but the prints are too small (4x6 inches giving only 1600x2400 pixels).

With this I have to politely disagree. The 4x6 print has the same resolution as the negative which is above 12 mps for 35mm (from your reference above) assuming no loss from the enlarger lens.

Hank

Here's our flying spot using the mirror globe, 500mm mirror telephoto lens, scanned 4x6 prints. Just too blurry!

[BurkhardE]

Hi Hank,

each time you post something new it's so interesting that I just can't stop thinking about it. When you complained about the mirror lens I only remembered the 400 pixels per inch figure since I used to assume even 120 as a rule of thumb before. Besides, I often had trouble to get the whole resolution and sharpness when scanning with my film scanner (unsharp masking needed). But I have no experience with flatbed scanners or mirror lenses.

Your latest panorama is again amazing. But I was a bit confused by the irregular line drawn on the ground around the globe, particularly since the markings are completely straight (I still can't believe it). Now I wonder if you used the garden ornament. I thought the mirror dome is bigger and has no full 180 degrees, what might fit twice. A more normal lens nearer to the mirror would give an image filled with the dome. And you might choose an even smaller coverage (and more images, of course) like with a full-frame fisheye and that might give sufficient resolution with 35mm film.

Burkhard

[tewehner]

Here's me chiming in late again :) Hank, I never got autopano-sift to work either (now that I see the solution here I'll be sure to get that in), but because I was primarily doing manual positioning and I was kicking off autopano "pairs" for anything missed, autopano worked ok for me. Also, Burkhard, as to the pano head accuracy - ours was terribly useful but I wouldn't say too terribly accurate. Ours had tick marks every 5 degrees, but no "click stops" to help you align to them, and with the speed we were clicking off pictures (one pic every 2 secs) I'm pretty positive we weren't hitting them dead on. Of course we put them into hugin on even 10 degree marks, but the control point optimization corrected for our minor errors.

Ted
The W3 Group

[BurkhardE]

Hi Ted,

thanks for the information, it just saves me some trial and error again. But I still wonder what happens to the blue-sky-only images. Are there control points in them or are they simply stitched together and misalignments are not visible?

Burkhard

[HankF]

Burkhard:
Sorry for misleading you, but I inadvertently changed my definitions. What I refered to as a mirror globe is in fact the garden ornament, not the mirrored dome. I did receive the new mirror dome yesterday but haven't had time to do anything with it. It sure seems to have much better optical quality compared to the garden globe. It has a 19mm mounting flange which I think is too wide and might partially reduce the FOV for single vertical shots. I have to figure out a mounting arrangement.

That irregular mark in the parking lot panorama is actually on the pavement. I have no idea what it's for or how it got there. Maybe a part of a car dragging on the pavement?

Ted: I get pretty consistent crashes with Hugin when trying to uncheck the Inherit box next to the lens distortion parameters, most consistently, barrel distortion. I would like to have the Optimizer calculate these parameters separately for the two images. I did for the FOV and it came up with two different values for the two different images (255 and 300 degrees) and the result had a better mating line. Have you had the same problem with your Hugin installation? I generally have better luck with Autopano-sift if I run it as a stand alone. For my last panorama it had problems within Hugin but ran O.K. on the outside.

I keep thinking that we need some standards to measure against. Maybe something like pixels per degree of FOV (22.67 for XTR). I haven't calculated what the minimum would be for an XTR panorama but I reduced one of the XTR panoramas (Dormagen) to 816x306 and added to the bottom so it would display properly in PTViewer. Here it is. We have to get at least as good as this I think.

Another way to look at it is to compare the resolution of our panoramas to a PTView of an XTR panorama. That's the next image at the PTView default FOV (70 degrees, I think), also of Dormagen. And the last is one I produced for comparison.

Hank

[BurkhardE]

Hi Hank,

my suggestion is 33 pixels per degree as a minimum. I used that in my experiments extracting images from an XTR panorama and re-stitching them. From H. Dersch's article about interpolation I concluded that source resolution should at least be equal to target resolution. That gives the 22.67 px/deg you mentioned. Several tutorials about panoramas recommend at least 30% image overlap (maybe there were a single source of this recommendation and the others copied), so only 70% of an image are usable (in one direction). 22.67/0.7=32.38 px/deg is minimum.

Did you mean that? I concluded that 11880 pixels image width is needed, requiring a row of 5 (4.4 rounded up) images in portrait orientation if 35mm film is scanned at 2700 dpi. Hence the idea to shoot only part of the mirror dome and to shoot 3 or 4 images horizontally (as you did with the globe). That would be slightly below estimated minimum, but who knows if that wouldn't suffice. After all, the full pixel count is needed only on the equator/horizon, the higher elevation the bigger is overlap. 3 or 4 picture rows are possible with mirror balls or fisheye lenses only. For a 5 picture row a 15mm lens would just suffice (has 100 degrees, 103 are needed acoording to the estimate above), a 20mm lens requires at least 8 pictures per row.

Btw, I found a web shop offering the mirror domes here in Germany. They look exactly like "yours" and are intended for shops, too. If they are imported from US then there's a peculiar increase in price ($175).

Burkhard

[HankF]

Hi Burkhard,

I added another standard test picture above and my best (1.4mp digital camera) for comparison.

if 35mm film is scanned at 2700 dpi

But only if you scan the negative directly. You don't have to scan at that high a resolution if you print an enlargement from the negative and scan it. Because the enlargements don't lose resolution as bad. I use 4x6 inches only because that's what's commonly available so I don't need any more than 1200 dpi. I would prefer 6x9 and would do that if my technique pans (no pun intended) out.

If you are interested in a dome I'm sure the place I got mine would be glad to ship one overseas. Mine cost about $38 not including shipping. I have no idea what shipping would cost. These domes are made by vacuum forming heated sheet acrylic in a dome shaped mold and then the mirror metal is vacuum deposited on the inside.

Hank

[BurkhardE]

Hi Hank,

as you may have noticed, I'm really attracted by the mirror dome solution as a one-shot or two-shot solution for panoramas. The dreadful price would put me off completely. But even for a lower price it seems to not suit my needs, as you showed. Since I want to stick to my available equipment (35mm film and the 2700 dpi film scanner), I would have a resolution problem.

Nevertheless, I can't stop thinking about the dome mirror. ;) I guess the flange is needed not only for mounting but for stiffening also, and if it were removed the dome could distort due to internal strain. So the FOV is somewhat restricted and you'd need three horizontal images or one vertical and an additional zenith image (might be self-shot or one of Philippe Hurbain's). But that's not bad since a zenith picture is needed in any case.

And you're right, I will get not so much pixels out of 35mm film. Even if the Velvia has 11 to 16 MPix available, a 2700 dpi scanner will get only 9.3 MPix out of the 24x36mm. That's why I'll stick to the 20mm lens (if only because I have it), and it will even give some excess resolution. If 33 pix/deg are minimum, 62 deg x 33 pix/deg = 2046 pix are needed in 24mm. Scanning 2700 dpi gives 2551 pix what means 25% excess.

Now I'm searching for a neat (and cheap) way to either loan a panorama tripod or build a very simple panorama head. It could be very simple if tailored to my camera and lens and might even have sort of click stops for the image pattern needed with the lens.

If unfortunately your technique would not pan out, you might even resort to the image pattern solution. Instead of buying a $400 camera you'd better buy a $180 robotics kit and build a pano robot. That would be even cheaper than buying a specific panorama head (e.g. Manfrotto). And your 1.4 MPix camera would just fit and, as a digital, be comfortable. If e.g. the narrower image side is 1024 pix wide, 31 deg FOV were required. That is between 50mm and 35mm focal length, so if you set the zoom lens to 50mm equivalent you'll have best optical quality and some excess resolution - perfect!

But I'm racking your brains and should better stop.

Burkhard

[BurkhardE]

Hi Hank,

as to the test images, here are two details of the Heide panorama I used for my tests last week. They are from my last test where 2 rows of 8 images each were extracted and then re-stitched.

Extraction was done with the PanoTools Adjust tool in the Gimp plugin, setting Sinc256 interpolation. Projection was for my 20mm rectilinear lens, image size only 1400x2100 pixels. Given only yaw (45 deg steps) and pitch (-15 and 55 deg), the panorama would stitch perfectly, of course. But autopano-SIFT was applied for some control points and the usual optimizations were done. Only very small corrections (less than 1 degree) were the only result. Then PTStitcher was used with Sinc1024 interpolation but without exposure correction to create the final 8160x4080 jpg panorama image.

There's not much difference. I think there's no really visible difference. The details show one stitching error in the original image ;) and an additional pixel column in the re-stitched one. But the overall impression is the same for me. I can't really read the writings on the yellow road-sign (only suspect since I know what it should be) in both images.

Bottom line (for me): 1. the 33 pix/deg (or even less) resolution would suffice (thanks to Sinc interpolator?) and 2. small stitching errors (due to small pixel shifts?) wouldn't be visible.

Burkhard

[Bucko]

I appreciate the lucid and very informative discussion in these posts re shooting/generating panorama images for RC sim flying sceneries... For months I have been following these posts and associated links trying to get a handle on this topic but I remain WAY behind the curve of these ongoing discussions!!

Thanks to insightful comments in recent posts I was finally able to use the automated GUI-faced Autopano-SIFT and Hugin, followed by the command line version of Enblend to stitch a set of 40 1600x1200 images (5 rows of 8 shots each) and the pano stitching process finally worked for me!! I actually got a high quality equirectangular pano image of my back yard... admittedly it took perhaps 3 hours of processing time on my PC system but hey who's counting, it worked and I didn't have to enter a single control point or deal with any other tedious image manipulation whatsoever!!

I am elated!! Thank you very much to Burkhart, Hank, and Ted for the insights and links, and the continuing discussions and posts that finally made this possible!!

But now consider this... Sometime early on, possibly from info in one of the links noted above, I ran across and tried the freeware pano stitching program Autostitch by Matthew Brown and David Lowe (see www.autostitch.net). This is a great piece of free software, it is simple, quick, and works perfectly for stitching a number of adjacent images in a single row, but at some point I ran into some problems which discouraged me from further tests, perhaps I had an inadequate set of images or perhaps I was trying to stitch together adjacent rows of composite images that had themselves already been previously stitched or something equally weird?

Anyway after having experienced success stitching a set of images using Autopano-Sift/Hugin/Enblend, I attempted to stitch the same 40 original photos using Autostitch. I was amazed that Autostitch whipped through those 40 images and generated an equirectangular pano in just a few minutes!! And the quality seems very acceptable!!

I did subsequent additional runs with Autostitch specifying larger output files each time, and discovered that for an output file at the 8192 pixel width required by our RC sim programs, Autostitch does require additional processing time… about 1/2 hour total in this case… but the entire procedure is much faster and easier than using Autopano-Sift/Hugin/Enblend. At the 8192 pixel width the output quality is outstanding, there are only a few points where the stitch is just slightly off in my test runs.

Best of all in my view, Autostitch is totally automated... you merely start the program, specify the size of your output file, and point Autostitch to the set of images to be stitched. Now I'm wondering if input image resolutions lower than my current set of 1600x1200 images might work just as well?

Has anyone else had success using the Autostitch program for generating full equirectangular pano images?

Charlie

[HankF]

Hi Charlie,

at some point I ran into some problems which discouraged me from further tests

Maybe I should revisit Autostitch. I had the same experience. I think I was trying to stitch a single row that was taken with the camera pointed up to just include the horizon line and a little bit below - maybe 15 degrees. In Panotools you can specify the pitch of the camera. I'll have to re-download it having uninstalled it (neatness freak).

In the end, multiple rows of many pictures may be the way to go but I've been working from the other end (being lazy). Unfortunately, it puts a premium on resolution! Right now I'm trying to answer the question whether a 35mm film camera is capable of producing a panorama of sufficient resolution with just one or two shots.

Burkhard,

You're right of course the flange on the mirror does provide strength and so I left it at about 6 mm. I've glued it to a plywood backing on which I will glue the mount. I cut the rim down with a bandsaw and finished it with a belt sander both of which worked well. My lens is in the mail so we'll have a definitive answer to my question above.

Please tell me what the adjust tool in Ptools does. I've never used it. Can you point me to a tutorial on it? It sounds like it is simply a reverse stitcher or more accurately an image extractor.

The best mix of equipment and technique may be one that limits the image requirement to just one row. For my Olympus 35mm camera that may mean the Zenitar or Peling lens. Using one of these, there wouldn't be the problem of removing the image of the camera that you have in the mirror shots. I have one more question though. If you took multiple shots of one row using the mirror, what sort of preadjustment (i.e. cropping) should one do to the images (say using Gimp) before running them thru Hugin and Ptools? I've been cropping the ball images to a square all of the same size. Ptools seems to be happier that way. (Imaging software gripe: why don't they provide a means of entering coordinates in these programs?)

I had a pleasant surprise, while rummaging around in my garage I found a tripod I bought loooonng ago. It's a robust video unit which has a beautiful fluid panhead on it. Both tilt and pan can be locked. Once leveled, with the tilt locked it smoothly pans without undulation. It should help.

Hank

[BurkhardE]

Hi Charlie,

that's a nice surprise that someone else is not only following our discussion but also copying our trials. Alas, I never heard of Autostitch. Seems like a fully integrated and "seamless" version of the PanoTools/autopano/Enblend/hugin combo. I can well imagine that it works fully automatic, but I still wonder what any panorama program will do with images containing no control points (like blue sky). Did you ever try such a puzzle?

Hank,

I envy you the tripod, it really should help! Unfortunately, I gave away the two big tripods inherited from my father. We never used them much, and I thought I'd keep only the pocket tripod which was in regular use. Now I regret, having only a makeshift (http://time.fh-augsburg.de/~erd/photo/pano/textKamera.html) (this might be called a tetrapod, or simply a fork ;) ).

Btw, I forgot the viewing angle in my last post. In Reflex XTR, I prefer a 90 degrees "Camera aperture angle". That seems to be equivalent to 45 degrees FOV in PTViewer. I can't remember the default, but it seems to be bigger, as you wrote. Anyway, in the html file calling the applet insert the line
<param name="fov" value="45" />
to get this.

All I know about mirror or fisheye panoramas is from the tutorials. I never thought about it, but they all cropped the images to square. I learned the Adjust tool from these tutorials, too. It's part of the plugin and seems to be a general panorama handling tool. It works on a panorama buffer which may be displayed as a window in Gimp. You may insert images into the buffer/panorama or extract images from it. I remember especially the pinball panorama tutorial (http://perso.wanadoo.fr/panoramas.re/vrt/vrt06.htm), the get rid of the Photographer tutorial (http://www.cgtechniques.com/tutorials/getridof.php), and H. Dersch's Panorama Tools readme (http://www.path.unimelb.edu.au/~dersch/Readme1). Seems quite easy to stitch only two or three images. And you have the Remap and Correct tools on hand, too.

As you say, a fisheye lens for our old film cameras might be the best (and nearly cheapest) solution for the resolution problem. I'd prefer the Zenitar since it fully exploits the film frame and no cropping is needed. You'd need less images with the Peleng but resolution would be worse. I tried the full-frame fisheye projection in my grid and map experiments above, it worked very well.

Burkhard

[HankF]

Hi Burkhard, et al.

Here the new mirror mounted (with a temporary C-clamp.) and the video tripod.

So far on this endeavor I've spent: $139 US. I actually consider it well spent considering what I have learned. This includes the lens (about 1/2 the total) which will be used for other projects so can't be fairly charged to this project.

As for control points in the blue sky you can always use the sun, but it's only one.

Hank

[tewehner]

Hi Burkhard,

We did not have any control points in the sky either. The manual positioning of images in hugin was sufficient as those images are feathered and blended in enblend anyway - thereby creating a smooth enough transition from one area to another. As it worked out, the sky on the day we took pictures did not have any well defined clouds, so there were no visible indications of stitch errors (edges). Of course, if there were well defined clouds, then I imagine autopano would find sufficient control points. I guess it all leads to a lazy man rule of - "if it can't find control points, you probably don't need them" :)

The only place we had to post-process correct was naturally the zenith (for which I have not successfully worked out a solution). On my list of places to shoot is an indoor sports arena. This, of course, will require a rock solid solution for the zenith when using the many-pic-many-row approach as the ceiling will undoubtedly have much detail that needs to stitch well, as opposed to the clouds which are so nebulous that you can manually correct with a photoshop smear brush).

I beginning to think that the ultimate technique may be a many-pic-many-row approach with a single shot dome/globe pic tacked on for the zenith.

[HankF]

Ted,
Have you figured out which of two overlaping images PTools uses as the base for the resulting combination? Do you suppose it is selectable?

Hank

[tewehner]

Hi Hank,

Hmmm, not sure what you mean :) To which part of PTools are you referring? If you mean the blend operation, I imagine both images are treated equally - that is to say, that the same amount of feathering is applied to each (from opposite directions). If you're referring the stitch operation, I would suspect that the order of the images in the image list (say, in hugin) would be obeyed - so images appearing later in the list would probably be drawn over "earlier" images.

Hope this helps,

Ted
The W3 Group