The optimizer tries to modify the projection so that the distance between
the projected legs is minimized. It doesn't look at the image content
at all, it only works on the control point coordinates and their
projected positions.
*Yes, my understanding of panotools/hugin is good enough to understand that
optimizer only works with CPs, and i do understand pretty well what you
mean with legs. But since there are many CPs couples and only one single
optimal configuration of parameters to be extracted by optimizer, i was
guessing the optimizer attempts to minimize a global function of single
errors (like sum), and my advice was to add to that function the distances
(= absolute value of difference) of images' parameters from their coarse
expected positions, multiplied for a weight. *
*Please, understand that I do not expect the optimizer to work _exactly_
like this, but i expect i can think this way and still do a good
approximation of what actually happens overall.
E.g. at the end of an optimization process let error function like sum of
unsigned legs be 10. Let's say one of the images has been rolled -2° from
expected coarse position and had yaw added 0.5 to make it fit better; let's
our weights be all 1 for simplicity: new error should be 10+1*|-2|+1*|0.5|
= 12.5. Trying to minimize this means trying to reduce legs overall while
trying not to move images too far from where they're expected to be.
If two very similar optimal solutions are possible, the optimizer will
chose just the one in which images positions are more or less those
expected. This would GREATLY improve experience of those like me using
robotic heads, and would still represent a great tool for everyone, since
anyone is able to manually place images, even if with reduced precision: it
would act as a hint to the optimizer, and would make it work well where a
small amount of CPs is available.*
panotools scripting, again, is the answer. And if you're python-
literate, you may also want to have a look at
http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/README.parse_pto
http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/parse_pto.py
While - as a developer - I appreciate reference code, i don't fully
understand how linked sources could help me: the first request i made, was
to be able to make the _optimizer_ bind an image parameter to that of
another plus a small amount (the same way now i can bind an image parameter
to the exact same value of that belonging to another image), not to take a
pto and generate another with said displacement.
I have a strong background in C/C++ Java and C# to name a few, but i never
used Pyton (and I'm just a little more than a promising bash-script newbie
:) ), so even if i'm able to understand the code, i could never start a
project from scratch or modify complex code; however I took a look at
panotools source, and saw a lot of C so i guess it's worth a try: if anyone
would like to suggest where to take a look to find code relevant to
previous discussion, you're always welcome.
If different methods/workaround are already available, please, let me know:
I have access to Linux, Windows and OSX, but I'm currently using a Ubuntu
10.04 32bit as my main panorama production machine.
Thanks again for giving me your time!
Giancarlo
--
You received this message because you are subscribed to the Google Groups
Hugin and other free panoramic software group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
