 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | You are not logged in.
I noticed with certain presets papywizard seems to miss the target or overshoot in the GUI when moving between shooting positions. Some of my presets (e.g. those involving moving both axes at the same time) are worse than others. This is with and without the alternate drive.
Does this mean it is not accurately finding each position? Anyone else seeing this phenomenon?
Cheers,
Jeremy
Offline
What do you mean by 'miss the targer'? It does not stop at the correct position? What is the error? And what is the overshoot value?
Which version of Papywizard are you running? The 2.1.6, with the alternate drive feature? Could you try to disable it, and see if it wroks better? Also try to adjust the inertia angle (increase it if it overshoots, decrease it if it undershoots).
Offline
fma38 wrote:
What do you mean by 'miss the targer'? It does not stop at the correct position? What is the error? And what is the overshoot value?
There is no error thrown but it looks to not visually lie on the correct position in the GUI. Is there a way to tell where it actually stops?
fma38 wrote:
Which version of Papywizard are you running? The 2.1.6, with the alternate drive feature? Could you try to disable it, and see if it wroks better? Also try to adjust the inertia angle (increase it if it overshoots, decrease it if it undershoots).
Latest version but this happened in 2.0.0 as well. I tried with and without alternate drive and also tried turning up the inertia angle. Maybe my Orion head is playing up?
Offline
I can't imagine this would affect the quality of the stitch? Does it?
Did you compare the co-ordinates recorded in the data file with the co-ordinates specified in the preset definition?
Offline
Oh, don't worry, it is only a GUI issue (rounded values)! Even if there is no final control on the position, I never saw an error larger than 0.1°, which is much smaller than the mechanical accuracy, anyway.
Offline
mediavets wrote:
I can't imagine this would affect the quality of the stitch? Does it?
Yep, I plan to set up an automatic stitch mode on our render farm. We regularly capture many full sphere HDR maps and they can be stitched automatically using the coordinates from the preset (without feature matching). While not perfect they are generally suited for our requirements (lighting / reflection in CG). The more accurate the capture positions the better.
fma38 wrote:
Even if there is no final control on the position, I never saw an error larger than 0.1°, which is much smaller than the mechanical accuracy, anyway.
That's good to know. Is the goto function ensured to land on the requested position regardless of inertia? I mean will it go back if it did overshoot?
Offline
The Merlin internal closed loop positionning (default drive method) accuracy is less than 0.1° (but keep in mind that the mechanical accuracy is 0.3-0.5°). So, no problem.
When using the alternate drive method, I first move in manual, controlling the position (this is where the inertia is used, to know when to stop). Then, I start a final positionning, using the Merlin internal goto function.
So, in every case, it is accurate.
Try to set a small/high value for the inertia: you will see the overshoot/undershoot, and then the head will go to the final position at a very low speed.
Offline
fma38 wrote:
Try to set a small/high value for the inertia: you will see the overshoot/undershoot, and then the head will go to the final position at a very low speed.
Ah ok so the point of getting a good value for "inertia" is to minimise traversal time.
Thanks for explaining 
Offline
Exactly!
Offline
