what should be in the scripting interface? please have your say!

[kfj]

Hi all!

I have set out creating a scripting interface for hugin. I envision
the process like this:

- build an interface with SWIG that scripting languages can import
- create a mechanism to use scripted content from hugin

I have already completed a feasibility test, where I have drawn in a
fair amount of data types and functionality into a SWIG interface and
built a Python module from it, with which I could do exciting things
like loading panoramas from files, accessing and modifying their
properties (like CPs and images), and writing them back to disk, now
using hugin's compiled C++ code and calling the C++ routines from
Python.

I have used SWIG 2.0.1 for the purpose - it has very comprehensive C++
support and can deal with advanced C++ features like namespaces and
templates - and it also allows to wrap strings and STL functionality
so that such objects are natuarally passed over to the scripting
language.

Nevertheless my approach so far has been ad-hoc: I picked a few likely
suspects (Panorama.h, SrcPanoImage.h, ControlPoint.h, Lens.h,
PanoramaOptions.h and PanoramaData.h, all from the panodata section)
and wrapped them whole without any intervening code, apart from some
template instantiations in the .i file and a bit of minimal tinkering
here and there. Doing this exposed my lack of knowledge of the hugin
body of code - in fact I am surprised that I managed to get as far as
I did without knowing more. So the next thing that I feel needs to be
done before I proceed is this:

- decide which part of the hugin functionality should be scriptable

I would like to have your feedback to establish this. The information
I need is basically which headers to pick (because SWIG can eat them
whole and make them into interfaces) and, optionally, what parts to
omit (because including them would be dangerous or unnecessary). In
the long run it might be desirable to specify the scripting interface
more explicitly, but if we can get away without a formal specification
and the resulting interface is usable, this would provide a usable
starting point.

Think of it as deciding on an API for the hugin functionality: at this
stage, hugin isn't involved yet; it's main() function and the GUI
aren't used, the scripting language is the boss and uses hugin's code
to do whatever the API gives it access to.

The next step, the 'mechanism to use scripted content from hugin',
would require code linked into hugin to interface with a scripting
language, enabling stuff like 'plugins'. I have a fair idea how to do
this with Python: you embed a python interpreter in the application
and make the embedded interpreter import the interface module, then
you can make it execute code and handle data from the application. In
this scenario, hugin would be the boss and drive the process, but the
interface should be the same, give or take a few administative items.

My vision is to have the scripting interface handle all interaction
with foreign code, but of course this is open to discussion. There is
a very intriguing possibility here: if the foreign code can be wrapped
and made accessible to the scripting language, and if the foreign code
uses the same data types as hugin, it should in theory become possible
to pass objects from hugin to the foreign code and back in memory.
Like, you could simply call a nona plugin from hugin to warp the
images you have already open in hugin.

But first things first. I hope to see your feedback on what you think
should be part of the interface.

Kay

[Pablo d'Angelo]

Hi Kay,

Am 10.01.2011 12:39, schrieb kfj:
> I have set out creating a scripting interface for hugin.

Great, I think that hugin can benefit greatly from such an interface,
both for custom utilities, as well as quick prototyping of new ideas.

> So the next thing that I feel needs to be done before I proceed is this:
>
> - decide which part of the hugin functionality should be scriptable

In addition to the basic Data model (as you seem to have done already),
the algorithms in hugin_base/algorithms might be useful for scripting
workflows. Here, maybe only the static driver functions are required in
the scripting language as the multi step approach (custruct algorithm
object, call runAlgorithm() & get the results out of the object) is
probably quite a hassle when writing scripts.

Btw. is your code available in some repo? Maybe a new hugin_scripting
branch would be a good idea.

> The next step, the 'mechanism to use scripted content from hugin',
> would require code linked into hugin to interface with a scripting
> language, enabling stuff like 'plugins'.

That would be especially helpful for customizing workflows etc. If the
integration also extends to wxPython, new GUI functionality could be
quite easily prototyped or even implemented in python.

ciao
Pablo

[kfj]

On 12 Jan., 20:08, Pablo d'Angelo <pablo.dang...@web.de> wrote:

> In addition to the basic Data model (as you seem to have done already),
> the algorithms in hugin_base/algorithms might be useful for scripting
> workflows. Here, maybe only the static driver functions are required in
> the scripting language as the multi step approach (custruct algorithm
> object, call runAlgorithm() & get the results out of the object) is
> probably quite a hassle when writing scripts.

It would be most helpful if you could point to specific header files
and routines therein that you would like to see wrapped. I'll have a
look at hugin_base/algorithms and see if anything appeals and yields
easily. I also thought to maybe wrap stuff in the PT interface, what
do you think? The data model is indeed fairly well covered by now -
all functionality from the following headers is in the interface:

SrcPanoImage.h
PanoramaVariable.h
PanoramaOptions.h
ControlPoint.h
Panorama.h

when I say all functionality, I mean that all classes and other data
types are available as proxies in the target language (currently only
Python, but I suppose I could easily churn out a perl one, and a few
others for that matter) and all methods of the classes can be called.
Of course this is all quite a lot and I haven't had time to test it
thoroughly, but since the process is mainly automatic I am quite
convinced it'll all work nicely. The current status quo with the above
headers covered feels like a milestone to me, and I'll go over the
data now for a bit and then publish.

> Btw. is your code available in some repo? Maybe a new hugin_scripting
> branch would be a good idea.

I don't have and don't want a sourceforge account, so I'll publish via
the same route as I have published my other Python material. So far
I've GPL'd everything, so if it's well received there's no problem for
it to be copied into the hugin distro channels. Intergrating the stuff
into the hugin source tree is straightforward, it's all in a separat
folder and the master CMakeList.txt only needs to include that folder,
from there it's almost automatic, only one of the headers is modified
slightly in a compatible manner, but maybe I can work around the
issues there and somehow wrap it unmodified. I'll probably also put
the binaries for the Python modules online, that'd be Kubuntu 10.10
and Python 2.6. I haven't been willing (Windows) or able (Mac OS) to
do tests on other systems, but SWIG 2.0.1 is source-distributed to all
these platforms, Python is available for all of them, and CMake also.

> > The next step, the 'mechanism to use scripted content from hugin',
> > would require code linked into hugin to interface with a scripting
> > language, enabling stuff like 'plugins'.
>
> That would be especially helpful for customizing workflows etc. If the
> integration also extends to wxPython, new GUI functionality could be
> quite easily prototyped or even implemented in python.

It all looks very promising. I even have dreams of 'floating' the
Python stuff and make it quite feasible to run the show with Python
(so, have the main() there and use the C++ as a backend for time-
critical stuff). The great difference using a scripting language is
that you don't have to compile and link; the access is practically
instantaneous.

Kay

[kfj]

On 12 Jan., 20:08, Pablo d'Angelo <pablo.dang...@web.de> wrote:

> Btw. is your code available in some repo? Maybe a new hugin_scripting
> branch would be a good idea.

Have a look at

http://groups.google.com/group/hugin-ptx/browse_thread/thread/ab1f0df18aaa247d#

I put the stuff online today.

Kay

[kfj]

On 12 Jan., 20:08, Pablo d'Angelo <pablo.dang...@web.de> wrote:

> Hi Kay,

> In addition to the basic Data model (as you seem to have done already),
> the algorithms in hugin_base/algorithms might be useful for scripting
> workflows. Here, maybe only the static driver functions are required in
> the scripting language as the multi step approach (custruct algorithm
> object, call runAlgorithm() & get the results out of the object) is
> probably quite a hassle when writing scripts.

I actually like the OOP approach, and most of the headers yield
nicely. After all Python is an OOPL and so the handling in Python is
just as comfortable as in C++. If I understand correctly what you mean
by 'wrapping the static driver functions', I reckon it's much easier
just wrapping whole headers instead of trying to pick stuff out - I
wouldn't even know how to start such a thing.

Today I included the majority of headers from the algorithms section,
only omitting those which wouldn't yield straight away:
NonaImageStitcher.h and ImageGraph.h

Today I also included the headers from the PT interface, namely:

hugin_base/panotools/PanoToolsInterface.h
hugin_base/panotools/PanoToolsOptimizerWrapper.h
hugin_base/panotools/PanoToolsUtils.h

And the remaining headers from panodata, except those from here that
wouldn't yield straight away either: ImageVariableGroup.h
StandardImageVariableGroups.h and ImageVariableTranslate.h

By now, these classes are in the interface (some only as dummies
without methods, the remainder should sport all the methods they have
in C++):

AlignInfoWrap
BaseSrcPanoImage
SrcPanoImage
CPVector
CPoint
CPointVector
CalculateImageOverlap
ControlPoint
DestPanoImage
DocumentData
FDiff2D (dummy)
ImageVector
Lens
LensVarMap
OptimizeVector
PanoramaAlgorithm
AssistantMakefilelibExport
CalculateCPStatistics
CalculateCPStatisticsError
CalculateCPStatisticsRadial
CalculateFOV
CalculateFitPanorama
FitPanorama
CalculateMeanExposure
CalculateOptimalROI
CalculateOptimalScale
SetWidthOptimal
CenterHorizontally
ComputeImageROI
PTOptimizer
AutoOptimise
SmartOptimise
PanoramaMakefilelibExport
RotatePanorama
StraightenPanorama
TimeConsumingPanoramaAlgorithm
PhotometricOptimizer
SmartPhotometricOptimizer
PointSampler
AllPointSampler
RandomPointSampler
StitcherAlgorithm
FileOutputStitcherAlgorithm
NonaFileOutputStitcher
ImageStitcherAlgorithm
TranslatePanorama
PanoramaData
ManagedPanoramaData
Panorama(ManagedPanoramaData, DocumentData)
PanoramaDataMemento
PanoramaMemento
PanoramaObserver
PanoramaOptions
Point2D (dummy)
Size2D (dummy)
SmartOptimizerStub
SwigPyIterator
Transform
UIntSet
UIntVector
Variable
LensVariable
LinkedVariable
VariableMap
VariableMapVector
tm (dummy)

The thing has fattened up nicely, but I'll play with it for a while
before I update the files in my repo. When I put it in initially
yesterday I forgot a file, but I fixed it this morning (rev. 18). I'll
post on the other thread

http://groups.google.com/group/hugin-ptx/browse_thread/thread/ab1f0df18aaa247d#

when the latest version is up.

Kay

[john doe]

How about an integration with hugin and batch mode?

--
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 hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[kfj]

On 16 Jan., 02:30, john doe <guerrerodelu...@gmail.com> wrote:
> How about an integration with hugin and batch mode?

Please be more specific. What do you mean? Of course it's integrated
with hugin, that's the whole point. Do you mean it should be able to
trigger the batch processor?

Kay