how should hugin interact with plugins?

[kfj]

Hi all!

The groundworks for a plugin interface for hugin is laid. The
interface at the software level is deliberately unstructured - meaning
that any number of hugin objects of arbitrary types can be passed to a
plugin. But the GUI currently doesn't make use of this power; it
merely allows to 'call a Python script' and passes just a single
parameter - the currently active panorama. While this can already be
useful, it is obviously very limited. Let me give you an example:

I've written a plugin that removes all control points outside the
current ROI. The plugin can be run from the command line, where I
offer a simple switch to reverse the behaviour and instead remove all
CPs inside the current ROI. This switch is obviously missing from the
current GUI interface, where you can only choose to 'run a Python
script'. So I work around it by having the Python script (the plugin)
open in an editor and changing the default, depending on what I want
to do. Not so nice.

At the same time, the plugin produces statistical information: how
many CPs it has found, how many are removed, and how many are left.
When the plugin is run standalone from the command line, this
information is printed to the console. When it's run from inside
hugin, the console output is invisible, and the only effect is the
deletion of the CPs, which can quite easily go unnoticed until much
later. Not nice either.

Now you could say, why don't you save two versions of the script under
different names. Might be done. But consider that the next plugin I
want to launch already has about half a dozen parameters. The
arithmetics clearly tell the approach to 'save each version under it's
own name' is not feasible. Just as the CPGs and the other collateral
software can be parametrized and can feed back this needs to be
possible for plugins as well.

The question is how to deal with these issues. I suspect a mechanism
similar to the one used for CPGs might be usable: passing a command
line which has %-placeholders for specific things (the panorama, an
image etc.) and fixed parameters depending on the intended use. So for
the case outlined above, you might have an entry for each version, if
you use both. But the solution isn't really satisfactory, just as I
always found the CPG interface awkward. Allowing the plugin to somehow
interact with the user would be much nicer. In fact, plugins make very
good glue code. a plugin might pop open a window offering visual
manipulation of, say, the parameters to a CPG and proceed to call the
CPG, which would be much prettier than the current state of having to
navigate all the way into the preferences dialog and edit or newly
create the desired parameter set - and much more flexible at the same
time, since I can just edit the plugin's code if the CPG changes and
don't need to compile and link.

If you're still with me here, my bit of brainstorming may have
inspired you to come up with a good solution to the problem. I'd like
to see the matter discussed before trying to go ahead and 'just do
something'. Also, I haven't really penetrated hugin's GUI (I've been
too busy doing back end stuff), so I'm not sure what protocols and
techniques would be needed to seemlessly integrate the plugins
communication with hugin's GUI.

Kay

[Bruno Postle]

On Thu 10-Mar-2011 at 07:58 -0800, kfj wrote:
>
> The groundworks for a plugin interface for hugin is laid. The
> interface at the software level is deliberately unstructured -
> meaning that any number of hugin objects of arbitrary types can be
> passed to a plugin. But the GUI currently doesn't make use of this
> power; it merely allows to 'call a Python script' and passes just
> a single parameter - the currently active panorama. While this can
> already be useful, it is obviously very limited.

> Just as the CPGs and the other collateral software can be

> parametrized and can feed back this needs to be possible for
> plugins as well.

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.

--
Bruno

[Bart van Andel]

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. 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.

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). Eventually this could even be used to "integrate" plugins in the default hugin interface (e.g. as a dockable window).

--

Bart

[kfj]

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.

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

[kfj]

On 11 Mrz., 11:40, Bart van Andel <bavanan...@gmail.com> 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

[Bruno Postle]

On Fri 11-Mar-2011 at 07:22 -0800, kfj wrote:
>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.
>
>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

[kfj]

On 11 Mrz., 23:23, Bruno Postle <br...@postle.net> 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 editor. Only when it comes to tighter intergration with
plugins, where there's real communication (interactively manipulating
data with visual feedback), the plugins would have to make the effort
to properly integrate with hugin's GUI, and a communication protocol
would have to be established.

Kay

[kfj]

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

[Bruno Postle]

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

[Bart van Andel]

On Friday, March 11, 2011 5:01:48 PM UTC+1, kfj wrote:

On 11 Mrz., 11:40, Bart van Andel <bavan...@gmail.com> 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, type, min, max, default, whatever>

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

[kfj]

On 12 Mrz., 22:31, Bruno Postle <br...@postle.net> 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

[kfj]

On 12 Mrz., 23:18, Bart van Andel <bavanan...@gmail.com> 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<name, type, min, max, default, whatever>

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

[Bruno Postle]

On Sat 12-Mar-2011 at 23:57 -0800, kfj wrote:
>On 12 Mrz., 22:31, Bruno Postle <br...@postle.net> 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

[kfj]

On 13 Mrz., 14:09, Bruno Postle <br...@postle.net> 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

[Bruno Postle]

On Sun 13-Mar-2011 at 07:52 -0700, kfj wrote:
>On 13 Mrz., 14:09, Bruno Postle <br...@postle.net> 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

[kfj]

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

[Jeffrey Martin]

do you have the full resolution pano online anywhere?

[T. Modes]

> 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

[kfj]

On 15 Mrz., 21:44, "T. Modes" <Thomas.Mo...@gmx.de> 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

[kfj]

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

[T. Modes]

Hi Kay,

you missed the point.

On 16 Mrz., 13:50, kfj <_...@yahoo.com> wrote:
> On 15 Mrz., 21:44, "T. Modes" <Thomas.Mo...@gmx.de> 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

[kfj]

On 16 Mrz., 21:00, "T. Modes" <Thomas.Mo...@gmx.de> 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

[Gnome Nomad]

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
gnome...@gmail.com
wandering the landscape of god
http://www.cafepress.com/otherend/

[kfj]

On 17 Mrz., 11:33, Gnome Nomad <gnomeno...@gmail.com> 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

[Gnome Nomad]

kfj wrote:
> On 17 Mrz., 11:33, Gnome Nomad <gnomeno...@gmail.com> 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.

[kfj]

On 18 Mrz., 08:11, Gnome Nomad <gnomeno...@gmail.com> 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

[Gnome Nomad]

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.

[kfj]

On 18 Mrz., 09:55, Gnome Nomad <gnomeno...@gmail.com> 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

[Gnome Nomad]

kfj wrote:
>
> On 18 Mrz., 09:55, Gnome Nomad <gnomeno...@gmail.com> 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!

[kfj]

On 16 Mrz., 13:50, kfj <_...@yahoo.com> wrote:

> On 15 Mrz., 21:44, "T. Modes" <Thomas.Mo...@gmx.de> 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