Then you export the XML from that for use with different image sets shot using the same camera/lens and shooting pattern.
Of course! But: as long as the manual head reproduces the adjustment very precisely each time: you also can save a template
for not needing to have the stitcher looking for CPs each time again. Pano-photographers do that for quite a long time.
The major difference: you can use this PW-xml export in other stitchers too - as long as they can read it . .
Exporting PW-xml should be fine to have a manual head do the same as a motorized head with xml export . . which means that
the manual head mechanically needs to meet the mathematical values in the xml precisely enough (which a motorized head of high accuracy does).
That´s what i said.
AFAIK by default APP/APG uses the XML positioning data as a guide to positioning the images, it also uses CP detection plus optimisation it does not stick rigidly to the XML image co-ordinates.
So IMO the manual head need not be as precise as the most precise robotic mounts.
I would vcenture to say that no manual head can reproduce a set of image co-ordinates precisely from shoot to shoot, nor can most robotic mounts; nor is it essential unless one is aiming for (batch) stitching without CP detection.
360Precision claims this is possible with some of their manual heads along with PTGui templates but some experts disagree.
Even using xml-positioning by a robotic head a stitch needs to be optimized. No question - especially regarding somewhat higher resolution.
What 360presision claims is meant - as i see it - related to using fisheyes = low resolution. Here - with 15k x 7,5k as average size - that´s less of a problem: you simply can´t see minor errors. This surely is the "domain" of manual heads.
With resolutions of somewhat higher size, providing deep zooms - starting at about 35k x 17,5k - precision becomes very much more critical.
Anyway: precision becomes more and more important. Good (!) "robotic mounts" provide *very* high precision - by their controller´s calculations AND by the precision of their construction of mechanical parts: motors, sensors, gears and mounts.
No matter i use a Rodeon, VR2 or Panoneed (used and tested all of them intensely): their xml provides *very* precise positioning - which nevertheless needs to be optimized by the stitcher, when it comes to *real* highres.
No "robotic-head" in the world provides pixel-precise positioning mechanically which the controller calcuates mathematically - when it comes to very high resolution.
So it´s the *combination* of mathematical calculation AND mechanical realization of positioning the head - basing on this calculations.
Here indeed in theory it might be helpful to have an xml-export from an *already stitched* result - because in that case *all* steps like the controller´s math calculations + "real" positioning due to mechanical precision of a robotic head + final optimization in the stitcher for the final result comes into play
In that case the optimization step might be redundant - given the interpretation of the xml in the importer is *really" reliable and correct.
On the other hand: running a stitch with importing the head´s xml plus one step of optimization in the editor surely is the faster way . .