On 7 Jan., 01:37, Pablo d'Angelo <[email protected]> wrote:
> > Bruno, thank you for your advice. I have started out on a new project > > towards the goal of eventually providing a scripting interface for > > hugin, > that would be really nice! I once tried with boost::python, but I hit > some strange roadblocks, which prevented me from creating a useful > interface... I looked into using Boost and bjam, and I also considered pyrex and Cython. SWIG won out in the end, even though there are a few valid points of criticism. The situation we're facing here is interfacing with a complete preexisting software, so we don't want to create scripting language modules from scratch, but we want to wrap the existing code to become accessible to the scripting language - and, eventually, to enable the scripting language to accept hugin data types to enable the creation of plugins and the use of the scripting 'glue' to pass hugin objects around in-memory. SWIG has quite extensive support for C++ as well: http://www.swig.org/Doc1.3/SWIGPlus.html#SWIGPlus It seems to be a mature and widely-used software, and, as I pointed out, it's well-documented, so well indeed that it took me only half a day to get a prototype Python module up and running that linked in whatever hugin functionality a program from the 'tools' section would access - and that includes the time it took me to convince cmake to build the module (sigh). > I don't think there is a ready made function for computing the distances > inside the hugin source. The distances can also be computed using the > PTools::Transform objects (transform both points from input image > coordinates into panorama space equirect and compute the great circle > distance (haversine formula) there. Note that the distances depend on > the output image projection and size. I feel I've opened a can of worms here. The problem is this: If you are creating a 'proper' panorama, where the model of a central viewpoint and a surrounding pano sphere applies, calculating the distance on a great circle on the pano sphere is the correct way to go. This can obviously be achieved (and cpclean does it that way) by setting the output projection to equirect and taking it from there. But what about mosaics? Imagine a mosaic of a 100m wall full of graffiti. Obviously, you want to measure CP error as standard flat distance sqrt(x*x+y*y) here. So you'd have to measure your distance from coordinates on the output rectilinear image, and the approach to just convert to equirect and use that for distance calculation would yield totally wrong results. Apart from the output projection being set to rectiliniear and the X, Y and Z parameters hinting in that direction, there isn't really a clear indication that the output is a mosaic (correct me if I'm wrong) and the underlying engine is blissfully unaware of the distinction. 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
