Missing the target

[jeremyp]

Missing the target

by jeremyp » Thu May 07, 2009 12:26 pm

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

[fma38]

by fma38 » Thu May 07, 2009 12:43 pm

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).

[jeremyp]

by jeremyp » Thu May 07, 2009 1:30 pm

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?

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?

[mediavets]

by mediavets » Thu May 07, 2009 1:56 pm

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?

[fma38]

by fma38 » Thu May 07, 2009 2:05 pm

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.

[jeremyp]

by jeremyp » Fri May 08, 2009 12:10 am

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.

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?

[fma38]

by fma38 » Fri May 08, 2009 7:02 am

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.

[jeremyp]

by jeremyp » Fri May 08, 2009 8:39 am

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

[fma38]

by fma38 » Fri May 08, 2009 8:41 am

Exactly!