On 12 Jan., 20:08, Pablo d'Angelo <[email protected]> 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 -- 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
