Hi all!
I've started investigations towards a scripting interface for hugin.
At first, I want to make an interface that can be loaded by the
scripting language as a module and offers facilities to interact with
a panorama.
I have written some experimental glue code dealing with control
points. The code loads a panorama (now using class Panorama's
readData(prjfile) method) and exposes the control points and their
metrics via a bunch of C++ routines. These are wrapped in a SWIG i-
file and the resulting module (I've made one for - guess - Python) is
imported and called by the scripting language.
So far this works fine; the Panorama class opens the pto, all the CPs
are there and acessible, I get their number and coordinates - but I
don't get the 'distance', or 'error' of the control points. If I open
the pto in hugin and have a look at the list of CPs, there they all
are with their errors. So I suppose I have to call some function to
fill the .error member in the ControlPoint objects, because whichever
CP I access, it's always zero.
I tried calling pano.updateCtrlPointErrors(), but that didn't help. I
looked around in Panorama.h for clues, and found a very puzzling
section:
// -- script interface --
/** read after optimization, fills in control point errors.
*
* @param set of image numbers that where used during by
* printPanoramaScript().
* @param vars will be set the the optimzied variables
* @param ctrlPoints will contain the controlpoints, with
distance
* information
*
* @return false on error (could not read optimizer output,
parse error)
*/
[maybe someone could give these comments a bit of TLC?]
so, read what? It sounds like it might be the thing I want done, but
where is the routine to do it? The next methods in line are
void parseOptimizerScript(std::istream & i,
const UIntSet & imgs,
VariableMapVector & imgVars,
CPVector & ctrlPoints) const;
/// create an optimizer script
void printPanoramaScript(std::ostream & o,
const OptimizeVector & optvars,
const PanoramaOptions & options,
const UIntSet & imgs,
bool forPTOptimizer,
const std::string & stripPrefix="")
const;
/// create the stitcher script
void printStitcherScript(std::ostream & o,
const PanoramaOptions & target,
const UIntSet & imgs) const;
which don't really look as if they had anything to do with the comment
preceding them.
It would be nice if I could actually access the distance information,
since then I could already use my module productively to do sensible
things based on CP distance. (you may have noticed my top_cps_only
python script, where I also don't have access to the distance
information, because it's not stored in the pto file, so the quick-
shot method I used there isn't really correct)
Regardless of that, I feel that my experiments with SWIG so far are
very encouraging - it took me less than a day to piece together a
working prototype without any previous knowledge of the tool. The
promise is great:
It can generate interfaces for many different scripting languages, so
I could have my python interface, but if someone else wanted one for
LISP or Ruby or whatever, they should be able to get it quite easily.
Also, SWIG seems to function with Linux, MacOS and Windows.
Kay
--
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
