I used it on a subsequent trip to Yellowstone to take a number of gigapixel panoramas and didnâ€™t discover until I got home that there are defects still in the hand controller software that prevent stitching software from automatically stitching the photos. There are two defects, one adds extra exposures to some, but not all rows of photos. For example, one of my panoramas had rows 1-6 with 56 exposures, rows 7-9 with 58 exposures, and rows 9-16 with 56 exposures. The second causes each row of exposures to be offset from the one above and below it by about a half a frame. While it is possible to manually add control points so that the software can stitch the exposures, it could easily take 40 hours to do an 800-1000 exposure panorama.
The defects show up anytime that you use a telephoto lens with a field of view (FOV) of less than about 3.5 degrees (equivalent to about a 200mm lens and longer). I reported this to Celestron in August, who initially responded with â€œWe'll ask our software engineers and will let you know asap.â€ After a couple of months and a couple more emails asking for status they are now saying (as of 10/18/2012) â€œThe current firmware and basic software included cannot solve your two problems.â€ As of this writing the current version is AllViewV0309AZPanoB18.ssf (Ver.03.09.24). Itâ€™s unfortunate that such an excellent control head has one of its major features crippled by software defects. Smaller panoramas may work on this head, but if you are going to do a smaller panoramas, there are lighter weight and more cost effective solutions.
Thanks for posting this info. I'm a bit concerned at your conclusions - because my AllView is on the way and I bought it especially for Giga Pixel shots. Are you absolutely sure that what you are describing is a software fault? Sorry to disagree with you, but I do not think it is a "fault" in the software, whereas I certainly agree that Celestron should provide better support and advice than they appear to have done. May I explain in more detail?
The controller has an "Preset Pano Mode" for 360 degree panos in which you create one of two presets, each defining the number of rows, inclination/declination angle, and number of shots required per row. When creating this type of preset, the number of pictures per row is a critical parameter that must be calculated, as must the angular steps. The goal is to achieve a 25% overlap between successive shots. This means that the number of pictures per row will vary from the maximum number of shots corresponding to inclination / declination angle of 0 degrees down to a single shot at the zenith (inclination 90 degrees) and nadir (declination 90 degrees).
Even with the "Easy Pano" mode which allows less than 360 degree panos to be taken, I would be disappointed if the number of shots per row was static. We are basically photographing a spherical field of view, taking sufficient images to cover the 0 degree "horizon" and then needing less images as we progress towards the zenith and nadir. The "stitching software" is capable of assembling the images to form a 3D spherical view, or a cylindrical view (for say a few rows of shots in the region +20 to -20 degrees) or a rectilinear projection for printing a part of the pano, where the horizon is printed as a straight line.
So, I think the "issue" is not in fact a software fault in the controller, but is instead there is a need for additional software to calculate the required parameters for instructing the stitching software as to the angular position of the images. Papywizard resolves this by providing an XML positioning file to the stitching software, but note that even with Papywizard, the number of shots per row will decrease until at the zenith and nadir limit, there is just a single shot taken. An alternative mechanism e.g. with PTGui Pro is to create a non-linear grid where the number of shots per row and the row angle correspond to the parameters displayed on the AllView controller. This process is described three quarters the way down this page, the heading "non uniform grids". I expect there is a similar capability in AutoPano Pro, but I have not tried it out yet.http://www.ptgui.com/examples/creating_gigapixel_panoramas_with_a_robotic_panohead.html
It might be a reasonable expectation that Celestron should provide some support in terms of helping users like you and me to calculate the required settings for the AllView controller, and then maybe even helping us to generate the XML file needed to instruct software such as PTGui Pro and AutoPano Pro as to the exact positioning of each image. You can call me naive if you wish, but I do not think it will be difficult to come up with a simple procedure that resolves all these issues. I'm starting down this route now, and I hope developers of AutoPano Pro and PTGui Pro may be willing to assist me in my endeavours. When I have produced a suitable spreadsheet and have tested the calculations and the XML output with AllView and with both AutoPano Pro and PTGui Pro, I will make the spreadsheet available free of charge through these forums. The spreadsheet of course does not have to be used "in the field", only at the time images are uploaded to PTGui Pro or AutoPano Pro.
One of the great things with Papywizard is that it does all this hard work for you without making you aware of the math involved. However I want to find a solution that does not require me to use an additional laptop/ handheld for control purposes in the field. Even though Celestron might appear to be unhelpful, maybe because they lack the necessary expertise, I think in a couple of months time I will have developed a solution and a process that overcomes our concerns. Meanwhile if anyone has a spreadsheet already developed to do this, please let me know now, so you will get all the credit :-)