![]() |
|
|
|
|
|
||||||||||
|
| User list | Rules | You are not logged in.
Hallo Andrew, please read my answer to Felix about the zenit shoot and sphares. The T&C makes for each session an xml file, which has the exact position of each image. So the stitcher doesn't need common parts in the overlapping pictures to position them, it uses the xml information when it doesn't find common informations. With a manual head, you will not have exact position informations, then you must do some tricks like you recommended, to make a stitch possible.
Offline
josefgraessle wrote:
Hallo Andrew, please read my answer to Felix about the zenit shoot and sphares. The T&C makes for each session an xml file, which has the exact position of each image. So the stitcher doesn't need common parts in the overlapping pictures to position them, it uses the xml information when it doesn't find common informations. With a manual head, you will not have exact position informations, then you must do some tricks like you recommended, to make a stitch possible.
Yes, I apprecaite that.
Unfortunately it apesrs that the Papywizard Import wizard doesn't always seem to respect the XML data. By which I mean the optimiser doesn't seem to be constrained in any way when seeking to resolve the entire pano and sometimes it will move 'featureless' images a long way from their shooting positions.
I don't know why Kolor doesn't appear to incorporate some contstraints to prevent images being moved far from the defined shooting positions.
Offline
mediavets wrote:
klausesser wrote:
mediavets wrote:
Wow - now that is really weird.Weird? Yes - at least . .
best, Klaus
PS: on my manual head i use the same "pattern" as on the Panoneed/TC combination: 6 shots @-12° and 1 Zenith.
Result: http://360impressions.de/ZuerichBar.htmlKlaus your pattern is fine.; 6-around at -12 and 1 zenith.
Except that I have often found that shooting outdoors with a manual head (no XML) that a +90 zenith shot would often bw omitted from the stitch becasue it lacked any matching features with images in the main row of 6 images.
The 'solution' presented by Hans Nyberg was to shoot the 'zenith shot at about +60-65 which covers the zenith well but when the yaw is also chosen carefully will almost always mean you can get an good link between the 'zenith' shot and the main row of 65.
Hi Andrew!
I never had this issue Hans mentioned. IF i would have it: i´d use the xml which the TC provides (on Merlin as well as on Panoneed).
....................
mediavets wrote:
But felix said that the T&C calculated that weird 6 shots at -9° + 6 shots at +1 + zenith pattern.
I can't see that that would ever be 'right'/optimal.
So how did it arise?
This is kind of crazy indeed - and the only issue i can see here is the user, sorry
I guess he´s misinterpreting things.
Josef tried to clear it, i tried to explain some things - Felix seems to prefer to stick with his ideas.
The fact all other lenses but fisheyes work well for him indicates that the TC does it´s maths right. It´s the same maths on which the fisheye calculation bases.
The fact that it works also with fisheyes for more than 400 users - i was wrong with the 200 - without issues seems not to indicate problems with calculating fisheyes.
The fact that i use the TC without any issue as well as the fact that i used it in earlier days with Canon and Nikon crop cameras and 10,5mm DX as well as 15/16mmFX fisheyes and NEVER had such an issue . . . indicates that it does it´s maths well.
The fact that the xml which the TC provides matches well in APG and PTGui also seems to indicate that it does the calculation well.
So . . . what can i say . . ![]()
![]()
best, Klaus
Offline
mediavets wrote:
Unfortunately it apesrs that the Papywizard Import wizard doesn't always seem to respect the XML data. By which I mean the optimiser doesn't seem to be constrained in any way when seeking to resolve the entire pano and sometimes it will move 'featureless' images a long way from their shooting positions.
I don't know why Kolor doesn't appear to incorporate some contstraints to prevent images being moved far from the defined shooting positions.
The import wizzard "respects" the xml-data well. But the optimizer seems to have issues using a too wide "catch-range" of CPs or whatever.
That´s nothing the TC and it´s XML can take influence in. But anyway there are methods to deal with - though i guess can be handled better.
And - to make it clear: it´s not related to the TC´s xml only!
best, Klaus
Offline
Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
|
CHOOSING KOLOR Why choose Kolor? Which solution to choose? Download a trial Where can I buy? Education |
SOFTWARE Autopano Pro Autopano Giga Panotour Panotour Pro XnView |
ACCESSORIES Training DVD Panobook PROJECTS Paris 26 Gigapixels Yosemite 17 Gigapixels |
COMMUNITY Forums YouTube channel Google+ |
COMPANY Blog About Kolor Resellers Contact Visit us |
PRESS Press center Press review TOOLS My account |
