On 26 Nov., 16:28, Tom Sharpless <[email protected]> wrote: > > Given that Hugin now does Python, it is natural to extend some of the > core functions of libpano to support numpy, and I'm glad to hear you > are doing that. This should open the Hugin platform to lots of > interesting new developments.
I've at least made a start. I suppose there might be a good deal of code in libpano which would lend itself to vectorization. I know very little of libpano yet; the place where I did my bit of vectorization resulted from my current need of mass-transforming coordinates, and when I dug into hugin's wrapping of the relevant panotools functions I found that execute_stack was my ideal target routine. The vectorization could have been done in the hugin code, but with a slight performance penalty. I've posted to the panotools-dev list to ask what they think of the idea. The vectorization of the stack execution and the interface to numpy are done at different levels, though. My modifications of libpano and hugin's panotools interface code merely introduce vectorized versions of execute_stack() and Transform::transform(), respectively, and are totally unaware of and independent from numpy. The numpy compatibility is introduced in the swig interface and is therefore only relevant to and usable from python code which imports hsi. > Since libpano13 is supposed to be an independent library, such > modifications should not depend on any supporting code in Hugin. Of > course there would be no harm in making parts of Hugin depend on the > new libpano code. The libpano code would be extended, but no existing code in libpano would be modified. On my (Linux) system, after a recompile of libpano, the new routines were instantly available to hugin, which would now depend on the new routines in libpano to do it's vectorized Transform::transform, but, again, no existing hugin code would be modified, only some new code added. The changes to libpano and hugin would not introduce dependencies to new libraries or such. The changes to hsi.i (the swig interface file defineing the python interface) introduce the ability to deal with numpy arrays. There is one new dependency here, which is from numpy.i, which is a bit of source code, so can be distributed with the source. I think the resulting python module should still be independent of numpy - and if it is passed numpy arrays as arguments, numpy would have to have been imported in the first place. So far, my approach is quite ad-hoc; it's really only for the task at hand, but I feel that having found a way here is relevant and should make further investigation easier. I also hope this will open up new avenues. Scipy provides a lot of very advanced code, and it even has a fair bit of overlap with hugin/libpano - apart from the scipy.ndimage module there are other bits which might be exploitable in panorama programming. And a lot of other interesting python modules also use numpy arrays to handle data. On the other hand I found that the panotools code might be useful for other python code - it does some things really well and may even do some things no other tool can do so easily. If this takes off, it should be a win-win situation. I sometimes toyed with the idea to just wrap libpano with swig, but I reckon that huign has added a great lot of useful code on top of libpano, and therefore I stuck with the 'wrap libhuginbase' approach. 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
