prototyping a scripting interface: CP distances - how to get them calculated?

[kfj]

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

[kfj]

On 6 Jan., 16:42, kfj <_...@yahoo.com> wrote:

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

Okay, the CP issue was sorted out in a parallel thread, and I
continued work on the scripting interface prototype. Today I have
managed to pull two headers into it unmodified:

panodata/Panorama.h and panodata/ControlPoint.h

This means that all object types defined at these headers' base level
(so, class Panorama and class ControlPoint) became accessible as
scripting language objects - with data members and methods, all nicely
wrapped in proxy objects in - in my case - Python.

This makes me optimistic that the others will also yield eventually
and the whole panorama infrastructure will become available to the
scripting interface. Of course the mere wrapping of the headers isn't
the whole story, but it means that only some glue code will become
necessary:

- to interface where argument type conflicts arise
- to add or take away capabilites

this is a great relief, because it means also that most likely the
interface will just happily digest any changes to the headers and all
that's needed is a recompile. And it removes manual editing as a
source of error.

I also managed to write the relevant section in CMakeList.txt to
automatically compile the shared library to be loaded by the scripting
language. Theoretically (so the SWIG docu says) this should churn out
the equivalent objects on Windows and Mac as well, which would be
almost too nice to believe...

I'll keep on putting stuff into the interface that I think might be
immediately useful. When I have a nice set together, I'll tinker a bit
and see if it works, and maybe write some glue code. If all seems well
I'll publish.

Kay