Let's agree to disagree?
Of course! Anytime!
For me it hinges on your asertion that there is only one otpimal pattern to shoot aspehre with a particulat combination of sensor size/lens/camera orienattion. I don't agree.
I see. But from the geometrical sight itÂ´s reality! There is ONE NPP. So there is ONE setting for it. So there is ONE optimal configuration for camera/lens on the head. So there is ONE decision to make related the the overlap.
Choosing, letÂ´s say, 25% then there is ONE ideal pattern to match the sphereÂ´s geometry. The closer the shooting pattern is to this mathematical/geometrical pattern the less effort the stitcher has.
As for useability - I've never proposed replacing the existing T&C controllers automatic calculating modes; I would just wish to add the option of using Papywizard XML format custom presets for those members of the awkward squad who would like to be able to use a shooting pattern of their own devising for whatever reason. If as Josef suggests this would be easy to implement why not just do it?
The TC is a very small device. Though it has lots of fuctions. But it has limited memory. The memory is used for 50 camera/lens configurations, time-stamp, xml files for being exportet and some. I donÂ´t know how much is left for in fact needless functions - Josef must decide that.
In my eyes itÂ´s more important to store a sufficiet amount of xml from the shootings, timing, cameras/lenses and so on and - most important: valuable and variable functionality like nearly endless bracketing, wait-times, sensors for vibrating, electronic bubble-level, switchable 1 and 4 Newton-meter and some cute things. And not to forget: variable speed-mode with xml writing.
You might find it a 'pain' to create custom presets, and no-one would wish to force you to do so; but those really who want to use one would of course be willing to do it.
IÂ´d name it "priorities".
As for selecting custom presets during a shoot - I don't feel that woudl be complex. I envisage all my required persts would be pre-installed on the T&C controller and I'd just select the one I wanted from a list.
The precision of custom preset shooting pattern would be no more or less precise in terms of positioning than an automatically calculated shooting pattern. The custom pattern might be '####' but that's not the same as precision of positioning. Is it the moral duty of a robotic pano head manufacturer to prevent users from behaving iin ways you consider foolish?
Adding a new lens to a system would not be an issue. In the first instance the user could use the automatically calculated pattern. Later if desired he/she could develop a custom preset.
When did you make a preset for 50-200 image-sphere the last time?
Let's revisit the Andy Cochrane scenario, this time from a marketing perspective. Rightly or wrongly he wanted to be able to shoot a certain pattern using a robotic pano head with a T&C controller. He can't do that with the T&C controller so he's considering going (back) to using a less convenient manual pano head.
Honestly: he COULD have done it. I myself did it several times: he just would have to tilt the camera on itÂ´s screw. You see: using a fisheye and especially an 8mm one means you donÂ´t need an xml file for positioning at all. The angle is wide enough always to see anything in the picture. Agree? I think so.
My experience is that APG did a perfect stitch with this tilt. BUT: using a fullframe-camera with 8mm lens tilted on a Merlin means just enlarging the Merlins base even more!! It doesnÂ´t do ANY good!
The Merlin definitely isnÂ´t the real thing when you use an 8mm on a fullframe . . . customized pattern or not: you always have that very huge base limiting your down-angle when you use such a short lens.
Tilting the camera only shows more of the base instead of more of the ground.
Every experienced user knows that - and uses other combinations.
If I was in the market for another better robotic pano head I too would like to be able to choose one of two different particular patterns which work for me to shoot spheres with one my camera/lens setups.
Now there may be many more people considering a robotic pano head who have previously developed workflows based on a particular shooting pattern that works for them with a manual pano head.
If they discover that the Panogear/Merlin+T&C controller and/or the Panoneed+T&C controller cannot reproduce their familar shooting pattern(s) they may well look elsewhere.
If they think this way would mean they donÂ´t really know how things really work . . . they have the opportunity to learn. Holding on tight to procedures which became overcome isnÂ´t very wise!
Josef decided to add the speed-mode - ok. I told my opinion several times regarding it . . .
:cool: Typical for Josef: he designed it very, very elaborated with impressing features - without
lifting the price by selling it only as an option.
That's a sale lost when if the option existed of using Papywizard XML format custom presets on T&C controllers you would have been able to get a sale.
I guess people buying a TC controller want to shoot panos. In a way they couldnÂ´t do before so easily and effortlessly. I donÂ´t think they want to hazzle around customizing pre-sets when itÂ´s done already by the
TC in a perfect way. They just have to combine the right devices - using a Merlin with an 8mm fisheye on a fullframe definitely doesnÂ´t represent an appropriate combination because of the Merlins huge base.
And honestly: another pattern wouldnÂ´t change that. Andy could find out by tilting the camera on the screw - he will see that nothing gets better besides the base gets even bigger.
So: my view of things is from the angle of an intense all-day user who is used to do rather complicated things with pano-devices. So i think i have a clear view on what is possible to do, what is clever to do . . and what
is not so clever to do - because i did it already and know the results . . . . .
It may well be when they came to use their new robotic head + T&C controller they'd find they preferred using the automaticaly calculated mode but they would never get to find out because they'd have rejected the head during pre-purchase research because it couldn't reproduce a shooting pattern they were familiar with.
If, as it seems, it is relatively simple to implement a feature to enable the use of Papywizard XML format custom presets which would overcome such objections from potential purchasers then from a marketing perspective it would seem sensible to do it.
Yes - maybe. But i donÂ´t think so - usually people are clever enough to find out what they REALLY need. And being able to get that for an appropriate price will make them decide clever also.
I discussed with Joef to implement different kinds of starting a shoot: initial spinning left or right, starting with the ground or in the sky and so on. Those items really are important - i realized it when shooting on a construction site:
there were moving cranes. They used to stop for some minutes - but i never knew WHEN. So i needed to start the pano up in the sky - where the canes move instead of starting with the ground as usual.
Georg mentioned being able to choose the initial direction of panning - start with left-pan or right-pan - due to people aproaching or cloud moving.
All this quick changes of the headÂ´s behavior for matching an actual situation woudnÂ´t be possible to change when you use a pre-defined, customized preset!! YouÂ´re not able to decide in seconds whatÂ´s the best way.
This are only a few points that indicates the rather theory-oriented than practical perspective of your arguments, Andrew.
best to you, Klaus
P.S.: i guess i sometimes mixed Merlin- and Panoneed versions of the TC . . .