my27questions wrote:The battery compartment is inside the head, it holds x10 AA batteries. At this point, power is my main concern with the head, as I don't believe 10 AA batteries will be capable of powering the head for a full length gigapan. I will most likely be getting and external juice-pack to power the head on extended shoots.
tived wrote:well you just need to adjust the Nodal point, as you have a few close errors.
It would be interesting if you can it to shoot multiple exposures per position (HDR)
thanks for sharing and keep us posted, please
my27questions wrote:Well, I have discovered a major problem with shooting gigapans with the handset control on this mount. It seems that when the field of view is too small, and the range of the photo is too large (which is the situation when shooting gigapans), the handset looses it's marbles and begins functioning eratically. Example: If I set the field of view to my zoom lense at full zoom (which works out to about H:8 degrees V:5 degrees based on the measurements from the auto setup mode), and set the picture range (+- 90 degrees horizontally from center and +- 10 degrees vertically from center), then set the halt time ( 2 seconds) and the exposure time ( 5 seconds), the mount should then calculate the amount of shots it takes to take the photo but instead shows an asterisk and begins counting down from random numbers after moving to the first point. This basically make the auto shooting useless because it will sometimes countdown from as much as 600 seconds between shots, even though I only set it for 2 seconds hault and 5 seconds exposure. I will be speaking with a celestron rep tomorrow if possible to explain the issue, which seems to be related to the software in the contoller. Looks like I'll be using papywizard out in the field instead.
RobSherratt wrote:Has this issue with the software been fixed by Celestron? Any update on your views of the product, now you are a long-term user?
Does anyone know a vendor in Europe who stocks the AllView product with the nodal point adjusting bracket and camera mount?
klausesser wrote:No good for spherical panos, iÂ´m sure, because of the very huge base - even bigger than the MerlinÂ´s base - the Nadir-shot will show nothing but the base.
IÂ´m curious about how steep the downlook-angle can be - by judging the head visually it must be even less than with the Merlin.
So it might be good for mosaics - depends on the preceision of positioning when you use long lenses and the speed of the moves.
Looks quite sturdy - but i wouldnÂ´t expect miracles - regarding the price.
I guess it canÂ´t do better than the Merlin - but itÂ´s bigger, seems to be heavier and most likely less comfortable than the Merlin.
RobSherratt wrote:Hi Klaus,
Thanks a lot for your reply.
The nadir shot footprint size for spherical panos is not a big issue for me. I will suspend a plumb line from the tripod and mark the nadir point with a stone, and then will take the nadir shot manually, and substitute the image. This is what everyone has to do anyway to get rid of the tripod footprint.
klausesser wrote:How exactly will you shoot your Nadir using the AllView?
I mean the AllView-construction might be interesting for hires-mosaics. But here you use tele-lenses of about 200-600mm. That means - definitely with 600mm - you need very, very high precision combined with acceptable speed. The Merlin works fine up to 200-300mm - but runs very slow with longer than 100mm-lenses.
WhatÂ´s the payload for the AllView? WhatÂ´s the precision? WhatÂ´s the speed? What are the functions of the controller regarding panorama-photography? Does the controller write XML-files for positioning in APG?
I just read:
payload 4Kg - thatÂ´s not sufficient for hires - 8Kg would be appropriate for 600/800mm).
weight of the head (without or with tripod?): 9,5Kg.
Torque? No information.
Precision? No information.
These are two vital values for panorama-photography.
phill.butte wrote: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.
RobSherratt wrote: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 :-)
Support ID Ticket Ref WBH-250393
Sky-Watcher AllView Mount (item# S20150)
Please could you provide me with exact details of the calculations performed by the AllView controller firmware version B18 when determining the number of images taken per row, and number of rows? I need to know your algorithm for a given Horizontal and Vertical field of view, and set of 4 coordinates Right Limit, Left Limit, Up Limit and Down Limit. I need to know the exact % image overlap (vertical and horizontal) and number of images for each row and adjacent image, and I need to know the altitude and azimuth angles for the exact center of each image.
The reason for requesting these details is that I have to generate an XML file containing picture position data in "Papywizard XML format" in order to import images (up to 128 per row, 9999 per panorama) into PTGui Pro and AutoPano Pro for accurate stitching when creating GigaPixel panoramas. I will supply the spreadsheet calculator free of charge and free of copyright restrictions to you for distribution to other users of the AllView mount.
I believe that once such a spreadsheet is provided to "AllView" customers, the criticisms of the product (e.g. on Kolor AutoPano forums) will go away, and the product will become extremely popular. I am currently making a supporting case for your AllView product on Kolor Forums (search for posts under my name) and I hope you will give me the back-up that I need to automate the panoramic stitching process in this way, without having to use a separate controller e.g. PapyWizard or TC at extra cost and complexity.
Users browsing this forum: No registered users and 2 guests