[hugin-ptx] Re: how should hugin interact with plugins?
On 16 Mrz., 13:50, kfj <_...@yahoo.com> wrote: > On 15 Mrz., 21:44, "T. Modes" wrote: > > --- > > Microsoft Visual C++ Runtime Library > > --- > > Runtime Error! > > > Program: C:\src_static\build_2010_2\INSTALL\FILES\bin\hugin.exe > This does look suspiciously like what the README for the embedding > example in the wxPython repo warns of. May I also point you to > > http://www.google.com/url?sa=D&q=http://svn.wxwidgets.org/viewvc/wx/w... > > and ask what you make of it? I take it that on Windows everything is > linked statically (I don't really understand why, but anyway) - so > maybe we can't use wxPython in plugins then? After all the plugin is > still inside the same process and not a standalone program. This issue remains unadressed. Let me quote from the README I was linking to before: 1. The most important thing is that your wx application and wxPython must use the same version and the same instance of wxWidgets. That means that you can not statically link your app with wxWidgets, but must use a dynamic library for wxWidgets. (end quote) This seems to indicate to me that it's impossible to use wxPython with hugin on Windows, since, if I understand it correctly, on Windows wxWidgets is linked statically with hugin, as the run time error that Thomas received on trying my plugin on Windows indicates. So here is my plea again: can anyone think of a way how Python should interact with hugin? This isue is pressing, because: - on Linux Python plugins can use wxPython, but only with Python <= 2.7 - on Windows wxPython won't work from Python plugins - on Mac OS, the Python module isn't even running, but I hope it might be linked dynamically If GUI access can't be provided, I'd be grateful for ideas how to let the user interact with plugins non-graphically. Can the main application provide a console-like window which can be passed to the plugin to do console-type i/o on? (like, print and read text) - with such a mechanism, we'd have the GUI element provided by hugin and the plugin could merely use appropriate write and read statements. 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
Re: [hugin-ptx] Re: how should hugin interact with plugins?
kfj wrote: On 18 Mrz., 09:55, Gnome Nomad wrote: No, definitely not a focus stack. I'm sure doing things with focus stacks would use much more memory. I was just talking about producing a 750MB panorama. I've done a couple of HDR images, I don't know if they consume memory at the rate of a focus stack. Propably less, since with exposure stacks you can look at every pixel in isolation. But don't take my word for it. At any rate, stacks with enfuse seem to be memory-intensive. Maybe enfuse is memory intensive? Haven't noticed it on ordinary stuff. Question: were you running the enfuse stage from command line? I don't remember if you said so. I had to do that once before I doubled the memory in the laptop. I did it from the command line. Maybe I could have somehow coaxed hugin into issuing the enfuse command for me, but the command line is a good friend of mine anyway, so that's the path I took ;-) I decided one time to use command-line autopano with 6MPX images at full size (no reduction). Just processing a single image used 1.9GB of memory! -- Gnome Nomad gnomeno...@gmail.com wandering the landscape of god http://www.cafepress.com/otherend/ -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 18 Mrz., 09:55, Gnome Nomad wrote: > No, definitely not a focus stack. I'm sure doing things with focus > stacks would use much more memory. I was just talking about producing a > 750MB panorama. > > I've done a couple of HDR images, I don't know if they consume memory at > the rate of a focus stack. Propably less, since with exposure stacks you can look at every pixel in isolation. But don't take my word for it. At any rate, stacks with enfuse seem to be memory-intensive. > Question: were you running the enfuse stage from command line? I don't > remember if you said so. I had to do that once before I doubled the > memory in the laptop. I did it from the command line. Maybe I could have somehow coaxed hugin into issuing the enfuse command for me, but the command line is a good friend of mine anyway, so that's the path I took ;-) 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
Re: [hugin-ptx] Re: how should hugin interact with plugins?
kfj wrote: On 18 Mrz., 08:11, Gnome Nomad wrote: A great amount of patience? Running it under FluxBox, which consumes only about 128MB of memory vs a couple meg for KDE. And not using 16-bit images. And letting the little laptop grind away on it for 10 hours ... ;-) I made mine from a series of frames I shot covering our trip into the harbor at Victoria, Canada, (on a ferry). They covered 3-5 miles of shoreline. This doesn't really sound like a focus stack to me. Are we talking about the same thing? I'm not talking about exposure blending with enblend, but focus stacking with enfuse. I think focus stacks may need more memory, because they have to look at the neighbourhood of all pixels to determine the local contrast, which is used as a weighting criterion. I know that I could have gone 8-bit but chose not to. And of course I could have chopped the thing up into several smaller partial images - there's always a way. Currently, it takes a lot of finessing to do stuff like that, and that's one reason why I'm developing the scripting interface. When I did the image I was talking about, it didn't rerally take long, but it took massive amounts of memory, and when I used larger source images, enfuse simply failed with a bad alloc. I have an idea what I could have done on top of what I did to manage with consuming less memory - alas, right now I can't try it out because the AC adapter of my laptop gave up yesterday... No, definitely not a focus stack. I'm sure doing things with focus stacks would use much more memory. I was just talking about producing a 750MB panorama. I've done a couple of HDR images, I don't know if they consume memory at the rate of a focus stack. Question: were you running the enfuse stage from command line? I don't remember if you said so. I had to do that once before I doubled the memory in the laptop. -- Gnome Nomad gnomeno...@gmail.com wandering the landscape of god http://www.cafepress.com/otherend/ -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 18 Mrz., 08:11, Gnome Nomad wrote: > A great amount of patience? Running it under FluxBox, which consumes > only about 128MB of memory vs a couple meg for KDE. And not using 16-bit > images. And letting the little laptop grind away on it for 10 hours ... ;-) > > I made mine from a series of frames I shot covering our trip into the > harbor at Victoria, Canada, (on a ferry). They covered 3-5 miles of > shoreline. This doesn't really sound like a focus stack to me. Are we talking about the same thing? I'm not talking about exposure blending with enblend, but focus stacking with enfuse. I think focus stacks may need more memory, because they have to look at the neighbourhood of all pixels to determine the local contrast, which is used as a weighting criterion. I know that I could have gone 8-bit but chose not to. And of course I could have chopped the thing up into several smaller partial images - there's always a way. Currently, it takes a lot of finessing to do stuff like that, and that's one reason why I'm developing the scripting interface. When I did the image I was talking about, it didn't rerally take long, but it took massive amounts of memory, and when I used larger source images, enfuse simply failed with a bad alloc. I have an idea what I could have done on top of what I did to manage with consuming less memory - alas, right now I can't try it out because the AC adapter of my laptop gave up yesterday... 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
Re: [hugin-ptx] Re: how should hugin interact with plugins?
kfj wrote: On 17 Mrz., 11:33, Gnome Nomad wrote: Hmm, I've created 750MB TIFFs on a 32-bit Linux system that has only 2GB of memory ... I guess Windows is different. What makes you think I'm on Windows? Im runnung Kububtu 10.10 Somebody - I guess not you! - in the thread mentioned using 32-bit Windows 7. But I did a focus stack with enfuse from three 30 megapixel 16 bit images. Well near the limit. When I used about 40 megapixels per source image it became impossible. I doubt you'd manage that with 2GB, but if you do please tell me how you did it ;-) A great amount of patience? Running it under FluxBox, which consumes only about 128MB of memory vs a couple meg for KDE. And not using 16-bit images. And letting the little laptop grind away on it for 10 hours ... ;-) I made mine from a series of frames I shot covering our trip into the harbor at Victoria, Canada, (on a ferry). They covered 3-5 miles of shoreline. By far the biggest I've ever done. -- Gnome Nomad gnomeno...@gmail.com wandering the landscape of god http://www.cafepress.com/otherend/ -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 17 Mrz., 11:33, Gnome Nomad wrote: > Hmm, I've created 750MB TIFFs on a 32-bit Linux system that has only 2GB > of memory ... I guess Windows is different. What makes you think I'm on Windows? Im runnung Kububtu 10.10 But I did a focus stack with enfuse from three 30 megapixel 16 bit images. Well near the limit. When I used about 40 megapixels per source image it became impossible. I doubt you'd manage that with 2GB, but if you do please tell me how you did it ;-) 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
Re: [hugin-ptx] Re: how should hugin interact with plugins?
kfj wrote: On 15 Mrz., 20:02, Jeffrey Martin <360cit...@gmail.com> wrote: do you have the full resolution pano online anywhere? I'll put a JPG online. It's a bit more involved than what I've written before, but I'll give you a quick explanation of what I did: first I made three differet panos (using subsets), each for one resolution and of the same band around the horizon. Then I manually enfused the three, with some contrast weight to make good use of the crisp detail in the tele shots. If the images aren't perfectly aligned, enfusing them fails and produces double images. But with the thousands of CPs I had and the very good alignment, the process succeeded. I just couldn't get the resolution very high altogether, because my 32bit system can only use 3G of memory, so that was my ceiling - I ended up with an image 15000X1983, 360 degrees hfov (could have been more if I'd gone down to 8 bit). The final image is about 1/4G in TIFF. Hmm, I've created 750MB TIFFs on a 32-bit Linux system that has only 2GB of memory ... I guess Windows is different. -- Gnome Nomad gnomeno...@gmail.com wandering the landscape of god http://www.cafepress.com/otherend/ -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 16 Mrz., 21:00, "T. Modes" wrote: > Hi Kay, > > you missed the point. > That's not a Windows only issue. This affects all OSs (also Linux). > Hugin scripting interface runs with Python 2.x and Python3. > But wxPython runs only with Python 2.x. There is no version of > wxPython for Python3. I see. Well, it wasn't my idea, really - Bruno proposed it as 'obvious'. So I thought I'd give it a try. I wish you'd mentioned this earlier. I could have saved myself reading up on wxPython for now... Looks like we need to find a different mechanism to let the plugins gather parameters, then? > > Since you have it all set up, could you do a quick test and change the > > definition of entry() to > > def entry ( pano , inside = False ) : > This runs without problems. > So it's inside wx code. Any ideas how to proceed? 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
[hugin-ptx] Re: how should hugin interact with plugins?
Hi Kay, you missed the point. On 16 Mrz., 13:50, kfj <_...@yahoo.com> wrote: > On 15 Mrz., 21:44, "T. Modes" wrote: > > > First, wxPython does currently only run with Python<=2.7. So I needed > > to install Python 2.7 and test there. > > On Linux, it's running with 2.6. I wasn't aware of this Windows issue. That's not a Windows only issue. This affects all OSs (also Linux). > > > This could also be a problem with some Linux distributions, as Lukas > > already wrote, his disto (AFAIR ArchLinux) is already using Python 3. > > But I thought there isn't a problem using 3.0? You figured it out for > Windows, and I can't see why it wouldn't run on 3.X under Linux, if > that is what's installed there. Isn't cmake just picking watever the > instaled version is and using the appropriate libraries? > Hugin scripting interface runs with Python 2.x and Python3. But wxPython runs only with Python 2.x. There is no version of wxPython for Python3. So wxPython can currently not used with Python3. > Since you have it all set up, could you do a quick test and change the > definition of entry() to > > def entry ( pano , inside = False ) : > > This should run the script without importing or using wx, always > removing the CPs from outside the ROI. If it works then, the problem > is definitely with the wx code. If it still fails, there may be > something else wrong. This runs without problems. So it's inside wx code. Thomas -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 15 Mrz., 20:02, Jeffrey Martin <360cit...@gmail.com> wrote: > do you have the full resolution pano online anywhere? I'll put a JPG online. It's a bit more involved than what I've written before, but I'll give you a quick explanation of what I did: first I made three differet panos (using subsets), each for one resolution and of the same band around the horizon. Then I manually enfused the three, with some contrast weight to make good use of the crisp detail in the tele shots. If the images aren't perfectly aligned, enfusing them fails and produces double images. But with the thousands of CPs I had and the very good alignment, the process succeeded. I just couldn't get the resolution very high altogether, because my 32bit system can only use 3G of memory, so that was my ceiling - I ended up with an image 15000X1983, 360 degrees hfov (could have been more if I'd gone down to 8 bit). The final image is about 1/4G in TIFF. Using enfuse to put the three different focal length layers together, I used a soft mask and also some exposure weight and saturation weight: enfuse --exposure-weight=.7 --saturation-weight=1 --contrast- weight=1 ... So the lo-res images shone through and I had to crisp things up a bit in the gimp, having to go 8 bit at the same time because the gimp still hasn't got it togetehr to process 16 bit. Finally I replaced the foreground with the fisheye version, because there I had plenty of double images because of the parallactic errors. Altogether the image isn't really top notch - I used a polarizer with the zoom lens, which was a mistake and made the sky funny, and the lighting conditions in the morning were quite difficult. If you want to have a look anyway, I've put a 90% JPG version online at http://ubuntuone.com/p/hxW/ This version is before doing anything else on the image, so you can judge the quality of the fusion - all content in the distance is fused, only the knoll I'm standing on, plus a bit, isn't. You'll notice that the well-lit distant mountains are sharpest. Of course the next step would be to try and retouch the haze and throw away the patchy sky for the more homogenous fisheye version, but then I'd have to mask it and you couldn't see the horizon as enfuse made it. The image is taken from the top of Pizzo Mottac in the Val Grande National Park in Piemonte, Italy. 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 15 Mrz., 21:44, "T. Modes" wrote: > First, wxPython does currently only run with Python<=2.7. So I needed > to install Python 2.7 and test there. On Linux, it's running with 2.6. I wasn't aware of this Windows issue. > This could also be a problem with some Linux distributions, as Lukas > already wrote, his disto (AFAIR ArchLinux) is already using Python 3. But I thought there isn't a problem using 3.0? You figured it out for Windows, and I can't see why it wouldn't run on 3.X under Linux, if that is what's installed there. Isn't cmake just picking watever the instaled version is and using the appropriate libraries? > But when I run your script, the script returns -10 and a message box > with -10 is an import error. So I suppose that it's wxPython importing further stuff and failing for some reason or other. I'll have a look if I can catch the exception and make it a bit more specific than the mere -10. > --- > Microsoft Visual C++ Runtime Library > --- > Runtime Error! > > Program: C:\src_static\build_2010_2\INSTALL\FILES\bin\hugin.exe > > R6034 > > An application has made an attempt to load the C runtime library > incorrectly. > Please contact the application's support team for more information. This does look suspiciously like what the README for the embedding example in the wxPython repo warns of. May I also point you to http://www.google.com/url?sa=D&q=http://svn.wxwidgets.org/viewvc/wx/wxPython/trunk/samples/embedded/RE and ask what you make of it? I take it that on Windows everything is linked statically (I don't really understand why, but anyway) - so maybe we can't use wxPython in plugins then? After all the plugin is still inside the same process and not a standalone program. > So currently it is not running. Since you have it all set up, could you do a quick test and change the definition of entry() to def entry ( pano , inside = False ) : This should run the script without importing or using wx, always removing the CPs from outside the ROI. If it works then, the problem is definitely with the wx code. If it still fails, there may be something else wrong. Thanks for your effort 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
[hugin-ptx] Re: how should hugin interact with plugins?
> 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. First, wxPython does currently only run with Python<=2.7. So I needed to install Python 2.7 and test there. This could also be a problem with some Linux distributions, as Lukas already wrote, his disto (AFAIR ArchLinux) is already using Python 3. But when I run your script, the script returns -10 and a message box with --- Microsoft Visual C++ Runtime Library --- Runtime Error! Program: C:\src_static\build_2010_2\INSTALL\FILES\bin\hugin.exe R6034 An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information. So currently it is not running. Thomas -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
do you have the full resolution pano online anywhere? -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 11 Mrz., 00:56, Bruno Postle 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
Re: [hugin-ptx] Re: how should hugin interact with plugins?
On Sun 13-Mar-2011 at 07:52 -0700, kfj wrote: On 13 Mrz., 14:09, Bruno Postle wrote: I was referring to the GUI selection, you can Ctrl-click photos in the Images tab, then the various 'action' buttons on the right hand side only operate on these photos. I would expect a plugin to work the same way. What data structure contains the information of this selection? No idea, I suspect the selection only exists at the wxwidgets level. I have previously suggested to allow plugin access via a context menu. Since the context would establish what objects the operation is intended for choosing the right type of plugin should be easy. We don't use context menus in hugin at all, do we? I think that the operations that currently perform on the selected subset might be more obviously accessed by a context menu, whereas with the current design the user may be ignorant that the button he's pressing will only affect the selected items and not the whole list. I remember people asking stuff here like how can they selectively remove CPs for certain images - selecting the images and clicking on 'remove CPs' did not occur to them naturally. Context menus in these lists of photos, and things like being able to drag them would help general usability. Though I think functions that are only available in context menus would be hidden from users who don't know they are there. -- Bruno -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 13 Mrz., 14:09, Bruno Postle wrote: > I was referring to the GUI selection, you can Ctrl-click photos in > the Images tab, then the various 'action' buttons on the right hand > side only operate on these photos. I would expect a plugin to work > the same way. What data structure contains the information of this selection? I'd like to wrap that with the SWIG interface (if I haven't already done so) so that Python can know about it. > If this selection was available as part of the data structure then > the plugin would know what to work with. However this is related to > another Hugin issue: the selection of photos isn't shared between > tabs, really if you select two photos in the Images tab, the same > photos should become selected in the Camera and Lens tab, and also > in the Crop tab. Now that we have a basic system for selecting > photos in the Fast Preview window, this selection should be > propagated to the Images tab etc... I would go as far as saying > that displaying two photos in the Control Points tab should make > these two photos selected in the other tabs. I'm not sure if I can agree to the last bit. The selections may be deliberately different depending on the current purpose. If I work on a subset of my images in a large panorama and switch to the CP editor, I would definitely not want my selection to be replaced by the two images in the CP editor. As far as the images tab and the camera and lens tab are concerned, though, I agree that the selection should be identical, and it has often bugged me that it isn't. The images tab could offer to make the selected images 'active' for stitching. And if images are selected and you open the CP editor, it could show the first two selected images rather than twice image 0. I have previously suggested to allow plugin access via a context menu. Since the context would establish what objects the operation is intended for choosing the right type of plugin should be easy. We don't use context menus in hugin at all, do we? I think that the operations that currently perform on the selected subset might be more obviously accessed by a context menu, whereas with the current design the user may be ignorant that the button he's pressing will only affect the selected items and not the whole list. I remember people asking stuff here like how can they selectively remove CPs for certain images - selecting the images and clicking on 'remove CPs' did not occur to them naturally. 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
Re: [hugin-ptx] Re: how should hugin interact with plugins?
On Sat 12-Mar-2011 at 23:57 -0800, kfj wrote: On 12 Mrz., 22:31, Bruno Postle wrote: and its user configuration, Could you explain more precisely what you mean by user configuration? I mean whatever settings are picked by the user in the plugin GUI (if any) plus any persistent settings that would be stored in the registry or ~/.hugin file. the lists of selected objects would already be present in the project data structure that is given to the plugin. Do you anticipate augmenting the Panorama object and it's members with the selection information? As far as images are concerned, the selection can already be transported with the 'active' flag, but for CPs and Masks I don't think there is currently a data structure to mark them as being somehow selected - but this could easily be added. I was referring to the GUI selection, you can Ctrl-click photos in the Images tab, then the various 'action' buttons on the right hand side only operate on these photos. I would expect a plugin to work the same way. If this selection was available as part of the data structure then the plugin would know what to work with. However this is related to another Hugin issue: the selection of photos isn't shared between tabs, really if you select two photos in the Images tab, the same photos should become selected in the Camera and Lens tab, and also in the Crop tab. Now that we have a basic system for selecting photos in the Fast Preview window, this selection should be propagated to the Images tab etc... I would go as far as saying that displaying two photos in the Control Points tab should make these two photos selected in the other tabs. -- Bruno -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 12 Mrz., 23:18, Bart van Andel wrote: > By 'display name' I mean just a name to display (e.g.) in the menu > structure. This means you can name the file e.g. kfjGBlur.py, but the > display name 'gaussian blur', as an example. I'm not familiar with Python > syntax, but the interface may look like this: I see. This makes sense. On top of what you suggest, we should take a look at localization. Hugin is a multilingual project after all, and it might be a good idea to consider providing consistent multilingual prompts for plugins as well - If hugin's interface is talking 'Kontrollpunkte' and the plugin says 'control points' this wouldn't be nice. I don't know what mechanism is used in hugin for the purpose, but I suppose there's some repository containing the set of various language strings for every entity in the UI and wxWidgets can display the localized version automatically. How could the plugin use the same mechanism? > getPluginName : string > getPluginDescription : string > getPluginParams : array I like a formal description like this. What do you think: should the plugin contain code to yield these data, or should there be an external 'manifesto' describing the plugin's capabilities? > Name is what you'd need in the menu, description maybe on mouse over, and > params are used to display the GUI (in case we decide on doing so). Min/max > may not always apply, in the case of an enumaration type, it may report the > options for a drop down list, or radio button list. Bruno has suggested we let the Python side do as much of the GUI- displaying as possible, and I think that's a good idea, since it's much easier to do in in Python. If it turns out that use of wxPython is possible without further ado from the Python side, I'd be in favour of that. I have tried using wxPython in a plugin called from hugin and it worked - the wxPython GUI elements displayed and were functional. But I'm not certain this will always be so easy - I'm on a Linux system and all my stuff is up-to-date, so it may just be lucky coincidence that my wxWidgets, wxPython, Python and Hugin are all compiled with the same compiler - and linked dynamically, which is yet another possible source of problems on Windows, where it's all linked statically. Not to mention the Mac, where we don't even have a Python interface yet, let alone a plugin interface. I'll polish my test plugin a bit and publish it, so others can see if it runs on their platform. Kay 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 12 Mrz., 22:31, Bruno Postle wrote: > How many ways of calling a plugin would there be? > > - Do stuff with the whole project > - Do stuff with the selected photos > - Do stuff with the selected control-points > - Do stuff with the selected masks > > The action would be determined by the particular plugin This would imply that the plugins have to somehow export their scope - like, are they panorama plugins, image plugins etc. I wonder what the best course would be here. One might keep the plugins separate or have some sort of 'manifesto' file describing scope, capabilities and parameters, or one might provide a mechanism inside the plugin to tell what it is and can do. > and its user configuration, Could you explain more precisely what you mean by user configuration? > the lists of selected objects would already be > present in the project data structure that is given to the plugin. Do you anticipate augmenting the Panorama object and it's members with the selection information? As far as images are concerned, the selection can already be transported with the 'active' flag, but for CPs and Masks I don't think there is currently a data structure to mark them as being somehow selected - but this could easily be added. Having a way to switch masks on or off rather than having to add or remove them might even be a nice feature for the application altogether. Putting more data into class Panorama, SrcPanoImage etc. would immediately become visible in the interface, since SWIG wraps the C++ headers and all additional data would become accessible after a simple recompile. So this course would be a convenient route, and also quite unobtrusive - all other code could simply ignore the additional data. 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
[hugin-ptx] Re: how should hugin interact with plugins?
On Friday, March 11, 2011 5:01:48 PM UTC+1, kfj wrote: > > On 11 Mrz., 11:40, Bart van Andel wrote: > > When plugins report a display name > > and a short description as well, this can also be shown in this dialogue. > If > > the plugin does not report any options, it can be run directly without > > asking anything. Note that this needn't be restricted to Python plugins. > > I don't quite understand what you mean by 'report a display name', can > you clarify? > By 'display name' I mean just a name to display (e.g.) in the menu structure. This means you can name the file e.g. kfjGBlur.py, but the display name 'gaussian blur', as an example. I'm not familiar with Python syntax, but the interface may look like this: getPluginName : string getPluginDescription : string getPluginParams : array Name is what you'd need in the menu, description maybe on mouse over, and params are used to display the GUI (in case we decide on doing so). Min/max may not always apply, in the case of an enumaration type, it may report the options for a drop down list, or radio button list. -- Bart -- 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
Re: [hugin-ptx] Re: how should hugin interact with plugins?
On Sat 12-Mar-2011 at 03:03 -0800, kfj wrote: This should make things easier as long as this tight integration isn't (yet) needed. The protocol issues still remain How many ways of calling a plugin would there be? - Do stuff with the whole project - Do stuff with the selected photos - Do stuff with the selected control-points - Do stuff with the selected masks The action would be determined by the particular plugin and its user configuration, the lists of selected objects would already be present in the project data structure that is given to the plugin. -- Bruno -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 12 Mrz., 11:24, kfj <_...@yahoo.com> wrote: > This does not seem to be the case, much as one would wish for it. Let > me point you quite specifically to the very short readme that goes > with the example files for embedding wxPython in a program using > wxWidgets. This text seems to imply that there is a close relationship > between the two and they are not independent: > > http://svn.wxwidgets.org/viewvc/wx/wxPython/trunk/samples/embedded/RE... > > please correct me if I misinterpret these data. Okay, I'll correct myself here. I think what this example aims at is using the wxPython window from C++ and vice versa, not merely opening a wxPython window by tiself to collect some data. I think I got it wrong, and just doing the latter is possible without any further paramter passing. Phew. This should make things easier as long as this tight integration isn't (yet) needed. The protocol issues still remain, so please don't disregard the remainder of my last posting. I'll keep investigating... 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 11 Mrz., 23:23, Bruno Postle wrote: > >It looks obvious, but it makes the whole show much more involved. > >First, the wxWidgets instance that's running in hugin has to be > >relayed to the plugin. The plugin has to receive this information and > >build any GUI it wants to display on hugin's wxWidgets instance. > > Does it? Surely the plugin script can launch its own Window with > wxpython and doesn't need to embed in the Hugin GUI. This does not seem to be the case, much as one would wish for it. Let me point you quite specifically to the very short readme that goes with the example files for embedding wxPython in a program using wxWidgets. This text seems to imply that there is a close relationship between the two and they are not independent: http://svn.wxwidgets.org/viewvc/wx/wxPython/trunk/samples/embedded/README.txt?view=markup please correct me if I misinterpret these data. > >The next problem is that all plugins that want to acquire parameters > >would have to import wxPython which isn't a standard module, but has > >to be installed. So there would be another library dependency, and a > >distribution distributing the Python interface would either have to > >provide wxPython or ask the user to acquire it - no problem on Linux, > >but maybe a hassle on other platforms. > > If a library is important then we'll make it a dependency. Part of > the idea of python bindings is to investigate ultimately moving the > entire Hugin GUI to wxpython. I hadn't hoped that this was part of a longer-term perspective, but I am glad to hear it, because I think that from a design viewpoint it makes a lot of sense. If we take wxPython in as an integral part, then we'll have to follow the path outlined by the embedding example anyway, so I'll look into the matter beyond the bit of diagonal reading I've done so far. Keep in mind though that I'm largely ignorant about wxWidgets and wxPython, which is one of the reasons why I am asking for opinions in the matter - I'm convinced that others in the team can judge much more competently what the implications and possibilities are, if only they contributed to the discussion. > >I also feel that forcing every plugin that merely needs a few > >parameters to write it's own GUI to acquire them is counterproductive. > > This can be modularised. If you are going to write code to > autogenerate GUIs for python scripts, it makes sense to do it all in > python. This is a good point. It makes sense to do as much of this as possible in Python, since dealing with Python objects from C++ is cumbersome. Luckily we already have a SWIG interface established and a Python module that is loaded into hugin, so the pain of moving data to and fro can be much reduced. Still the question remains of how to establish some sort of communication between a plugin and hugin. We'd need to specify a protocol. I see various possible routes: - the plugin might publish what parameters it accepts and expect to be called with them - the plugin might call back into hugin to ask for parameters - the arguments might be kept in a file to be accessed by hugin or the plugin as need arises In every case the plugin would receive the current panorama - plugins for images, masks etc. might be added later as separate entities. Some of the plugin's need for parametrization can be satisfied via the panorama. I have used information like the ROI or the 'active' state of images to modify plugin behaviour, and this fits nicely into the GUI and feels natural. It's more the type of 'on or off' flags, or the odd threshold value for an operation, a target file name, a directory - so stuff like strings and numbers - that have no obvious channel of communication. Data of these types can be easily acquired via dialog boxes, though. With the perspective of having xwPython as an integral part of hugin in the future, the parameter acquisition might be made a Python domain, but should not be left (entirely) to the plugin itself for reasons I've outlined before. Having the parameter set(s) in files has other benefits: The same settings can be used from hugin and from the plugin when it's run as a standalone script, and the parameter sets are easily shared, archived and documented - and they would be under the user's control to be handled with tools outside hugin, and allow other tools to interact with the plugins in the same way. I find these advantages quite appealing. Implementing a file-based mechanism would also be inexpensive - I'm sure I could come up with a working prototype in a coulpe of days. > Though autogenerated GUIs don't sound very appealing in usability terms. I share your reservations about auto-generated GUI content. As long as it's only a matter of a few numbers and strings - the order of magnitude of a command line - maybe the reservations could be lessened. If the parameter sets were in some sort of .ini file, the infrastructure might be a simple editor and could even be delegated to an external edit
Re: [hugin-ptx] Re: how should hugin interact with plugins?
On Fri 11-Mar-2011 at 07:22 -0800, kfj wrote: On 11 Mrz., 00:56, Bruno Postle 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. It looks obvious, but it makes the whole show much more involved. First, the wxWidgets instance that's running in hugin has to be relayed to the plugin. The plugin has to receive this information and build any GUI it wants to display on hugin's wxWidgets instance. Does it? Surely the plugin script can launch its own Window with wxpython and doesn't need to embed in the Hugin GUI. The next problem is that all plugins that want to acquire parameters would have to import wxPython which isn't a standard module, but has to be installed. So there would be another library dependency, and a distribution distributing the Python interface would either have to provide wxPython or ask the user to acquire it - no problem on Linux, but maybe a hassle on other platforms. If a library is important then we'll make it a dependency. Part of the idea of python bindings is to investigate ultimately moving the entire Hugin GUI to wxpython. I also feel that forcing every plugin that merely needs a few parameters to write it's own GUI to acquire them is counterproductive. This can be modularised. If you are going to write code to autogenerate GUIs for python scripts, it makes sense to do it all in python. Though autogenerated GUIs don't sound very appealing in usability terms. -- Bruno -- 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 11 Mrz., 11:40, Bart van Andel wrote: > What about mimicking the way Mathmap (the Gimp plugin) interacts with the > user? In other words, have the plugin report what parameters it expect > (name, type, min/max or list of possible values, default value), and display > an options dialogue based on that info. I like that idea of the plugin telling what it needs and having the GUI provide infrastructure for acquiring it. This is what I had in mind originally when I started this thread. My concept of a plugin isn't really that of a piece of software interacting repeatedly with the user, and I feel that the capability to pass parameters, see output and receive a return value would be sufficient for the purpose, just as hugin calls the CPGs and other collateral software, but these auxilliary programs don't interact with the user apart from producing console output, which is displayed in a window. > When plugins report a display name > and a short description as well, this can also be shown in this dialogue. If > the plugin does not report any options, it can be run directly without > asking anything. Note that this needn't be restricted to Python plugins. I don't quite understand what you mean by 'report a display name', can you clarify? > This approach will also help keeping the GUI consistent as every plugin will > show the same kind of interface (except for the options of course). Also, it > would allows for "presets", using predefined values for the options to run > the plugin (much like the command line options fed to the CPGs). Very good point. Think of gimp's do-again and show-again filter dialogs. You may not want to call a new-born plugin every time having to tell it to do precisely the same as last time by repeating all your input. And you may not want a sluggishly programmed piece of wxPython code messing up things. A certain degree of control over what the plugin can or cannot do is desirable. > Eventually > this could even be used to "integrate" plugins in the default hugin > interface (e.g. as a dockable window). I strongly hope that the Python interface will become an integral part of mainstream hugin. What little experience I have gathered writing and using Python plugins for hugin shows me that this is a very effective way of packaging functionality - this is precisely why everyone else is doing it, only that some have (IMHO foolishly) chosen obscure languages (like, Lisp dialects) for their plugin interfaces, while Python is so mainstream (and close to C/C++) that a lot of people can get in there straight away - and there is a great selection of Python modules ready to use inside the plugins. In many applications the plugins populate menus and it becomes irrelevant whether any particular function is executed by a plugin or a 'proper' function. In fact, to tell you the truth, I think it at least questionably to write a GUI in C++. Python is much more suited for it, and by tightly integrating hugin with Python I hope to eventually make it possible to do GUI stuff in Python and only use C/C++ for the number-crunching backend, where it excels. But for the task at hand of letting simple plugins acquire parameters, equipping them with their own GUI functionality looks like overkill, as I have pointed out in my reply to Bruno's posting. 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
[hugin-ptx] Re: how should hugin interact with plugins?
On 11 Mrz., 00:56, Bruno Postle 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. It looks obvious, but it makes the whole show much more involved. First, the wxWidgets instance that's running in hugin has to be relayed to the plugin. The plugin has to receive this information and build any GUI it wants to display on hugin's wxWidgets instance. This is possible, but it fattens the interface and makes it less transparent. Nevertheless it can be done, but it would also take a fair bit of research. I've already located code that may do the trick, see how involved it gets: http://svn.wxwidgets.org/viewvc/wx/wxPython/trunk/samples/embedded/ The next problem is that all plugins that want to acquire parameters would have to import wxPython which isn't a standard module, but has to be installed. So there would be another library dependency, and a distribution distributing the Python interface would either have to provide wxPython or ask the user to acquire it - no problem on Linux, but maybe a hassle on other platforms. I also feel that forcing every plugin that merely needs a few parameters to write it's own GUI to acquire them is counterproductive. Look at Bart's post, I think that's a more suitable idea, as it leaves full GUI control with hugin, enforces consistency and takes the burden off the plugin - after all we want to make it easy for contributors, so we can easily profit from their ideas. 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