On 11 Mrz., 00:56, Bruno Postle <br...@postle.net> wrote: > I think the solution is obvious: plugins that don't require input or > provide output can work as they do currently. Any other plugins > need to use wxPython to provide a GUI.
After a longish discussion I have modified one of my plugins to use wxPython to display a small dialog, and I offer it for download from my bazaar repo in the hope it will be tested on other platforms. Here (Kubuntu 10.10) it's running fine, but, as I've pointed out previously, here everything is compiled and by the same compiler and linked dynamically. I'd be especially curious to see if it runs on Windows. To run it, you'll obviously have to have compiled the python_scripting branch with BUILD_HSI set ON, and as the plugin uses wxPython, you'll have to get that package as well. The plugin can be downloaded from: http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/crop_cp.py I initially wrote the script because I had a large mountaintop panorama taken without tripod (only had a Leki stick) and three different focal lengths - my Samyang fisheye for the 360X180, 1 row of 360 degrees around with 18mm portrait, and closeups of special stuff with 55mm. The panorama had lots of parallactic error in the close vicinity, but I didn't care about that. By choosing a ROI around the horizon I could exclude most of the grassy knoll I was standing on and only use CPs where parallax was not an issue. The stitcher produced a very nice flawless horizon and hushed up the parallactic errors elsewhere, just what I wanted. I had tons of CPs all over because I was using another (much more involved) script of mine I haven't yet published - this script calculates the overlaps between all or some images, mask non- overlapping image parts, warps the overlapping parts and generates CPs from the warped images, resulting in many very good CPs even for those situations when the ordinary CPGs have difficulties (like, matching the edge of a fisheye shot with a 55mm image). Even after removing the CPs where parallax was an issue, I was left with, on average, a couple of hundred CPs for each image pair, so cohesion was so tight I could optimize lens parameters from the panorama event though I only had CPs in a narrow band near the horizon, and I came out with very sensible lens correction coefficients and an average CP distance of 1.17 (standard deviation .97), which I thought remarkably good for a near- freehand pano with three different focal lengths. With the crop_cp plugin all I had to do was crop away the sky and the floor in the openGL preview and then run the plugin once with the default setting to remove CPs outside the ROI. I proceeded to pick some small areas which, even though close to the horizon, still had parallactic error because they were nearby, and called the plugin for them with the setting to remove CPs inside the ROI. Then I chose the ROI I wanted for the actual output, stitched, and out came a very nice panorama indeed. Comments welcome. 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx