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