hugin plugin interface - developers please liaise

[kfj]

Hi all!

Continuing my work on interfacing hugin with Python, I have reached
another of my goals: I have figured out how to use plugins written in
Python from programs that use hugin's type corpus - or at least the
subset that is wrapped in the hugin scripting interface. This means
that there is now a possibility to call arbitrary Python code with
objects like HuginBase::Panorama, do some processing on them in Python
and return to the caller. Don't be fooled into thinking this is a mere
'execute a script file' approach: the interface maintains the object-
oriented interface, but the Python code actually accesses and
manipulates the binary data held in the C++ application. What I'd like
to do now is link this code into hugin and test it at it's destined
place. To do so, I need a good point to link it in, and some easy way
of triggering the call to Python with data from hugin.

The code to use Python is encapsulated in two C++ classes that could
either be put straight into a cpp file somewhere or be included as a
header.

I'd welcome some support from the hugin developers here. Also, I don't
intend to provide any GUI elements to deal with plugins (at least for
now), mainly because I don't have wxWidgets experience and don't know
the GUI code, but also because I feel that the GUI isn't really my
domain, I'm more of a backend programmer. Never mind the GUI, having a
breakout option to call Python for quick hacks or rapid prototyping
might be a welcome facility for the developers even without any formal
introduction of a plugin GUI. Since all the terminology for data types
and methods is identical in Python to that in C++, switching to using
Python on the data is easy.

I also need information on what to do if the Python code has modified
hugin's content. I am aware that there are mechanisms to notify the
application of such changes, and I also know that a certain protocol
has to be used to make sure all actions can be undone. What I don't
know is the precise nature of these mechanisms and how to serve them
with appropriate information. Again, help from the developers would be
welcome.

Once I've test-run the code from hugin I'll publish through the usual
channel. So far there has been so little echo to my work that I am
getting the feeling that hardly anyone actually reads my posts or is
at all interested. This is regrettable, since I am certain that my
path to Python integration is opening up very interesting new
possibilities. Let me name but a few:

- plugins can provide glue to closely cooperate with other
applications
- other code can be glued in without having to link it
- code contribution from users is made much easier
- optional functionality can be accessed on on demand
- Python code can be used to do advanced maths (see numpy, SciPy)

Kay

[Pablo d'Angelo]

Hi Kay,

Am 16.01.2011 18:32, schrieb kfj:

> Once I've test-run the code from hugin I'll publish through the usual
> channel. So far there has been so little echo to my work that I am
> getting the feeling that hardly anyone actually reads my posts or is
> at all interested. This is regrettable, since I am certain that my
> path to Python integration is opening up very interesting new
> possibilities. Let me name but a few:
>
> - plugins can provide glue to closely cooperate with other
> applications
> - other code can be glued in without having to link it
> - code contribution from users is made much easier
> - optional functionality can be accessed on on demand
> - Python code can be used to do advanced maths (see numpy, SciPy)

I'm spending all my hugin time on the cpfind improvement now, so I
didn't have much time to try your python work. However, I do a lot of
python programming at work, and I really like it, and I think it would
be a great addition to hugin.

The full benefits might not be obvious to everybody, so don't let the
lack of feedback disapoint you.

I think once some examples of how to use the interface are available,
even people that could not do any hugin coding can start to contribute.

Btw. in order to make it easier for us track your work (and add
improvements etc.), it would be great if you could offer a hg branch of
it (maybe not on sourceforge, if you have issues with that, but maybe at
some other site (for example: bitbucket or so).

Sorry for not answering the tech questions, I'll do this later if nobody
jumps in.

ciao
Pablo

[Harry van der Wolf]

Hi Kay,

2011/1/16 Pablo d'Angelo <pablo....@web.de>

Hi Kay,

The full benefits might not be obvious to everybody, so don't let the lack of feedback disapoint you.

As Pablo already mentioned: This is a really technical subject.
I really like to test the new things in Hugin but I have worked with Thomas last week to get the new fast preview with the gsoc2010 panorama overview working on OSX.
Yesterday and today I spent time on the cpfind modifications by Pablo.

I'd like to spend time on your Python interface as well, but unlike Pablo I know nothing of python (next to that: unlike Pablo I know nothing of C++ either).
Note that it is a steep learning curve if you know nothing of python and you are now required to do something with the first (your python interface) and couple it to the other (hugin).
I'm not a developer. I'm a "builder".

Please give us some time. Your efforts are really appreciated.

Hoi,
Harry

[Roger Goodman]

Kay,
I read all your posts, but can not help you, as I am not a
programmer at all. From the outside, it looks like you are doing good
work, and creating a useful interface. I say, keep up the good work!
Thanks,
Roger Goodman

[Yuval Levy]

Hi Kay,

On January 16, 2011 12:32:53 pm kfj wrote:
> So far there has been so little echo to my work that I am
> getting the feeling that hardly anyone actually reads my posts or is
> at all interested.

apology for not getting back to you. I love what you are doing and look
forward for the next Hugin GUI to be Python scripted.

I am currently swamped at work (and with swamped I mean: 8am-2am with a few
short breaks in between. This week I am not even able to catch up with Hugin
on the weekend).

When this contract ends, I'll be more than happy to play with your work.

It would help if you would work within the Hg repo and publish your Hg branch.
This does not have to be through SourceForge.

I assume you branched Hugin locally on your machine with something like
hg pull
hg branch python_scripting

and that you now switch between your scriptable hugin and "mainstream with"
hg up -C python_scripting
and
hg up -C default

you can push your Hg repository anywhere there is Hg hosting.

so just tell us where you are going to push it, and we'll follow you.

keep up the good work. sorry I can't be of more help.
Yuv

[stan]

Harry,
I just downloaded Hugin 2010.4.0 and I must be having a senior moment because the CP generator got lost. Where do I go to get them again and how do you recommend I install them?
Thanks,
Stan

[Terry Duell]

Hullo Stan,

Try saving your '.hugin' file, then go to preferences > Control point
Detectors and select 'Load defaults', and see if that fixes the problem.

Cheers,
--
Regards,
Terry Duell

[Bruno Postle]

On Sun 16-Jan-2011 at 09:32 -0800, kfj wrote:
>
> Once I've test-run the code from hugin I'll publish through the
> usual channel. So far there has been so little echo to my work
> that I am getting the feeling that hardly anyone actually reads my
> posts or is at all interested. This is regrettable, since I am
> certain that my path to Python integration is opening up very
> interesting new possibilities.

Yes a python interface is very interesting.

There are some bits of the code that would benefit from being in a
language that doesn't require a 15 minute recompile with every
change - e.g. what happens when you click the Align... button.
Ultimately there could be an advantage to having the GUI elements in
python, but this would be a major change.

What we do need is to have the python interface in the Hugin tree
and built as a compile time option.

--
Bruno

[stan]

Hi Terry,
Thanks for your help. It WORKED!
I loaded "cpfind". Is this your recommended CP generator?
Thanks again,
Stan

> --
> 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 hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx

[Terry Duell]

Hullo Stan,

On Mon, 17 Jan 2011 09:37:39 +1100, stan <gree...@verizon.net> wrote:

> Hi Terry,
> Thanks for your help. It WORKED!

Good.

> I loaded "cpfind". Is this your recommended CP generator?

It is the CP Generator that is provided with Hugin, so I guess it is the
recommended one.
You probably should try some of the others to see what suits your projects
best.

[kfj]

On 16 Jan., 19:39, Pablo d'Angelo <pablo.dang...@web.de> wrote:

> I think once some examples of how to use the interface are available,
> even people that could not do any hugin coding can start to contribute.

that is the aim of the plugin interface. And things are looking great
so far; everything seems to have worked out as I hoped it would.

> Btw. in order to make it easier for us track your work (and add
> improvements etc.), it would be great if you could offer a hg branch of
> it (maybe not on sourceforge, if you have issues with that, but maybe at
> some other site (for example: bitbucket or so).

I need some time then to learn how to do that. I work on my bleeding
edge repo extract on this system, I haven't branched out, since the
changes are minimal. But I'll make an effort to figure out what I need
to do to offer a branch for testing purposes. I have a repo on
Launchpad where I usually publish my code, could I make a hugin branch
there? Please excuse my ignorance of these matters, I really haven't
taken any time to learn mercurial.

> Sorry for not answering the tech questions, I'll do this later if nobody
> jumps in.

As far as the plugin interface for hugin goes, I've boiled it down now
to a header declaring a single variadic function to call a Python
plugin; every component of hugin should be able to simply include the
header and be plugin-enabled, while all code to access the py side of
things is in a separate object file. The only requirement on the build
side is that the Python libs have to be added to the common libraries.
I have modifies CMakeList.txt files that do the trick. I just couldn't
think of a good place to put a call to a plugin for testing purposes.
But I've tested it from somewhere likely, and it seems to work.

thank you for your feedback; I appreciate you are busy with cpfind
(thumbs up)! And, after all, there's no rush, but I was wondering if
anybody out there took any notice of what I do, since there was so
little echo.

Kay

[kfj]

On 16 Jan., 20:21, Harry van der Wolf <hvdw...@gmail.com> wrote:

> I'd like to spend time on your Python interface as well, but unlike Pablo I
> know nothing of python (next to that: unlike Pablo I know nothing of C++
> either).
> Note that it is a steep learning curve if you know nothing of python and you
> are now required to do something with the first (your python interface) and
> couple it to the other (hugin).
> I'm not a developer. I'm a "builder".
>
> Please give us some time. Your efforts are really appreciated.

Harry, thank you for your feedback. Let me assure you that Python is
much easier to begin with than C++, and this is one of the resons why
I am developing the plugin interface, so that the threshold for using
the hugin body of code becomes lower. eventually, once I've
consolidated the code to integrate smoothly, I will need builder
support to port the code to all supported platforms if that is at all
feasible.

Kay

[kfj]

On 16 Jan., 21:33, Roger Goodman <rlgood...@cox.net> wrote:
> Kay,
>      I read all your posts, but can not help you, as I am not a
> programmer at all.  From the outside, it looks like you are doing good
> work, and creating a useful interface.  I say, keep up the good work!
> Thanks,
> Roger Goodman

Thank you for your encouragement! I am indeed working quite hard on
this; it's been about 8 hours daily since I started out with the
scripting interface. So a little appreciation every now and then is
well received ;-)

Kay

[kfj]

On 16 Jan., 22:06, Yuval Levy <goo...@levy.ch> wrote:

> apology for not getting back to you.  I love what you are doing and look
> forward for the next Hugin GUI to be Python scripted.

apology granted. there is actually a fair amount of progress you may
look forward to. I'll try and make it easier for everyone to access
the code.

> I am currently swamped at work (and with swamped I mean: 8am-2am with a few
> short breaks in between.  This week I am not even able to catch up with Hugin
> on the weekend).

I'm aware of your work commitment. Thank you for taking the time to
reply to my post!

> When this contract ends, I'll be more than happy to play with your work.

Looking forward to that

> It would help if you would work within the Hg repo and publish your Hg branch.  
> This does not have to be through SourceForge.

Okay, I'll take the hint. I thought this was a SF only thing somehow.
I suppose I can't get away with my Hg ignorance any more...

> keep up the good work.  sorry I can't be of more help.

you've done more than your fair share already to get me in.

Kay

[kfj]

On 16 Jan., 23:26, Bruno Postle <br...@postle.net> wrote:

> Yes a python interface is very interesting.
>
> There are some bits of the code that would benefit from being in a
> language that doesn't require a 15 minute recompile with every
> change - e.g. what happens when you click the Align...  button.  
> Ultimately there could be an advantage to having the GUI elements in
> python, but this would be a major change.

precisely! I've now had my first tastes of these new opportunities
when I was testing my plugin interface. Once the call goes into the
Python interpreter, it is dispatched further with a python script. All
of the sudden I could make a modification to the code and instantly
test it! It was like the feeling you get when you've carried a heavy
backpack all day and then take it off and walk a few steps.

> What we do need is to have the python interface in the Hugin tree
> and built as a compile time option.

I've prepared everything for this; as I've written to Pablo, the
plugin capability can be pulled into the hugin code anywhere by a mere
inclusion of a single header which introduces no further dependencies,
so switching such an inclusion on and off with a #define is easy.
Linking in or not linking in the object code to interface with Python
and the Python libraries should also be straightforward, but better
fixed by someone with more CMake experience than me.

Kay

[Pablo d'Angelo]

Hi Kay,

On 17 Jan., 11:47, kfj <_...@yahoo.com> wrote:
> On 16 Jan., 19:39, Pablo d'Angelo <pablo.dang...@web.de> wrote:
>
> > Btw. in order to make it easier for us track your work (and add
> > improvements etc.), it would be great if you could offer a hg branch of
> > it (maybe not on sourceforge, if you have issues with that, but maybe at
> > some other site (for example: bitbucket or so).
>
> I need some time then to learn how to do that.

To get you started, I just created a python_scripting branch in the
main
hugin repository. This branch also contains a "Run Python script" item
in the
Edit menu, which will open a file selector and hand the selected file
to a PythonScriptPanoCmd
Command class, which will take care about undo and proper notification
of the rest of hugin.

The code to actually run the script needs to placed in

src/hugin1/hugin/wxPanoCommand.cpp:633

To get that branch, you can do the following:

# fetch hg repo
hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin
hugin.hg
cd hugin.hg
# switch to your branch
# ATTENTION: This will remove any local changes, should there be any.
hg update -C python_scripting

Then you can add your work to this repo and perform hg commit (or hgtk
commit, if you installed tortoisehg (which is quite nice...)). to
commit your changes to the local repo (same as with bzr).

Then you can put that repo on the web. We can then easily merge your
changes into the master repo as sourceforge.
There seem to be lots of sites offering hg online repos (http://
mercurial.selenic.com/wiki/MercurialHosting). I have two repos on
bitbucket.org, it easy to set up and use so far (but I haven't done
much work there yet).

Btw. whats the reason for avoiding sourceforge?

> Please excuse my ignorance of these matters, I really haven't
> taken any time to learn mercurial.

No worries. The model behind bzr and hg is quite similar, so I don't
think there is much in the way.

Let us know if you hit any roadblocks.

ciao
Pablo

[kfj]

On 17 Jan., 12:59, "Pablo d'Angelo" <pablo.dang...@web.de> wrote:
> Hi Kay,
>
> On 17 Jan., 11:47, kfj <_...@yahoo.com> wrote:
>

> To get you started, I just created a python_scripting branch in the
> main
> hugin repository. This branch also contains a "Run Python script" item
> in the
> Edit menu, which will open a file selector and hand the selected file
> to a PythonScriptPanoCmd
> Command class, which will take care about undo and proper notification
> of the rest of hugin.

excellent. I'm currently reading up on mercurial, so hopefully I'll be
able to share my work soon.
I'll report back once I have put my code together with the branch you
have kindly provided and am content that all works as intended. If I
can't put a full repo online I could just send a patch, but I'll try
to go all the way. I just need a bit of time to digest the extra
information.

> Btw. whats the reason for avoiding sourceforge?

I was about to open an account with them. But I read their terms and
conditions. There is stuff in there which I find questionable and/or
frightening, like the passage about 'prohibited persons' which forbids
anyone from places like Cuba to access content, or section 10 about
indemnity, which informs you (all in capitals) of the severe puishment
SF is going to inflict upon you if you do or don't certain things
which I don't fully understand. That's why I am with Launchpad. If you
have time, compare the terms of use; Launchpad's sound perfectly
reasonable to me. I would have quoted the passages from SF I find
offensive, but I fear they might sue me for using their intellectual
property without permission. They probably have to have t&cs like that
as a US operation, but I shan't agree to them. Must be my European
background. It's sad, because, really, I think they're the good
guys...

Kay

[kfj]

On 17 Jan., 12:59, "Pablo d'Angelo" <pablo.dang...@web.de> wrote:
> Hi Kay,

> Let us know if you hit any roadblocks.

I have it all set up so far, but I don't know how to tell cmake to
compile my cpp file and link it to hugin. The cpp is in hugin.hg/src/
hsi, it should be compiled into an object file and linked with the
rest. In which CMakeLists.txt and where do I have to mention my source
for it to be compiled and linked? Ideally, the object should be
available to every program to link to if necessary.

Kay

[kfj]

On 17 Jan., 19:54, kfj <_...@yahoo.com> wrote:

> I have it all set up so far, but I don't know how to tell cmake to
> compile my cpp file and link it to hugin. The cpp is in hugin.hg/src/
> hsi, it should be compiled into an object file and linked with the
> rest. In which CMakeLists.txt and where do I have to mention my source
> for it to be compiled and linked? Ideally, the object should be
> available to every program to link to if necessary.

figured it out myself, it has to go into libhuginbase.so

Kay

[kfj]

It works. Thank you Pablo for your entry point! Enough for today.

Kay

[kfj]

On 17 Jan., 12:59, "Pablo d'Angelo" <pablo.dang...@web.de> wrote:

> Then you can add your work to this repo and perform hg commit (or hgtk
> commit, if you installed tortoisehg (which is quite nice...)). to
> commit your changes to the local repo (same as with bzr).

two changesets committed so far, but only locally

> Then you can put that repo on the web. We can then easily merge your
> changes into the master repo as sourceforge.
> There seem to be lots of sites offering hg online repos (http://
> mercurial.selenic.com/wiki/MercurialHosting). I have two repos on
> bitbucket.org, it easy to set up and use so far (but I haven't done
> much work there yet).

For now, I haven't put the repo online, but what I have done should be
the next-best thing: I've made a mercurial patch reflecting the
changesets needed to get the python_scripting branch up to my current
development status quo. This patch is online at

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/patch4853.gz

I made them from my two changesets 4852:bf77427fe623 and
4853:9de97bcfd3b2 by issuing the commands

hg export 4852:bf77427fe623 4853:9de97bcfd3b2 > patch4853
gzip patch4853

I hope this is just what you need and convenient enough to use. Echoes
welcome.

Kay

[Pablo d'Angelo]

Hi Kay,

Am 19.01.2011 10:04, schrieb kfj:

> hg export 4852:bf77427fe623 4853:9de97bcfd3b2> patch4853
> gzip patch4853
>
> I hope this is just what you need and convenient enough to use. Echoes
> welcome.

From http://mercurial.selenic.com/wiki/Export, it seems that hg bundle
is the preferred way for contributing changesets. I have tried to import
your changes into the sourceforge repository using hg import, I hope it
worked fine.

ciao
Pablo

[kfj]

Hi all!

First of all, thank you all for your assistance! The code is in the SF
repo all right, I made sure by going through a complete pull-up-clone-
branch-compile cycle, and it's looking just fine.

Phew... this was a major piece of work - kept me busy for a good two
weeks, every day all day. Of course a good part of the time went into
learning the tools - first I had to decide which tools to use, then I
hadn't used SWIG before, and I also had to read up a great deal about
Python/C++ integration to make it all come out nicely. I hope to see
some use of this branch and a discussion of how the new possibilities
can be turned into a benefit for the users and developers alike. Of
course it's all still very rough-and-ready, there may be bits missing
or failing here and there, but I hope the big picture is all right.

On 20 Jan., 00:38, Pablo d'Angelo <pablo.dang...@web.de> wrote:

> From http://mercurial.selenic.com/wiki/Export, it seems that hg bundle
> is the preferred way for contributing changesets. I have tried to import
> your changes into the sourceforge repository using hg import, I hope it
> worked fine.

Pablo, thank you for taking time off your busy schedule with cpfind to
help me get my code in! I think you may have misunderstood the
mercurial documentation. It says in there that 'hg bundle' is to
export merge changesets, but there weren't any merges in mine, it was
just composed of two successive changesets, applied to the branch as
created by you, each only with one parent. In this case I take it the
export command is the one to use, as I gleaned from the export
tutorial

http://mercurial.selenic.com/wiki/TutorialExport

Anyway, it worked - and since I don't expect to throw such patches at
you guys all too often and the effort to put them in doesn't seem to
be excessive, I hope this is an acceptable method for you for now. I'm
considering setting up a repo with bitbucket, as you recommended, but
I'm not there yet.

Kay

[T. Modes]

Hi Kay,

continue the accessor issue mentioned in the other thread.

The accessor functions are defined in SrcPanoImage.h, lines 117 - 172
by using macros and inclusion of image_variables.h multiple times.

Thomas

PS: hsi and hpi compiles on windows. Importing the python lib works
also. But when running a script inside hugin it return value is always
-2 and the script is not executed. Ideas?

[kfj]

On 20 Jan., 18:54, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> Hi Kay,
>
> continue the accessor issue mentioned in the other thread.
>
> The accessor functions are defined in SrcPanoImage.h, lines 117 - 172
> by using macros and inclusion of image_variables.h multiple times.

Thanks. I'm working on the issue, and I must say I'm having a hard
time - the code is quite intransparent. But I hope I'll manage to have
the accessors soon. I'll keep you all posted. It would help if I had a
technical outline of how and where precisely they are made, but maybe
I'll manage with a bit of intelligent guesswork...

> PS: hsi and hpi compiles on windows.

great.

> Importing the python lib works
> also. But when running a script inside hugin it return value is always
> -2 and the script is not executed. Ideas?

Try and run hugin from the command line and see what the python
interface says why it fails. Most likely it can't load the modules hpi
and hsi because they're not in the module path. Remember hpi.py is not
output, but handcoded and therefore lives in the hsi directory
initially - if you want all the files in one place, copy it over to
where hsi.py and _hsi.so (or whatever they're called on Windows) live
in the target directory (like, hugin.hg-build/src/hsi). I haven't yet
figured out how to tell CMake that something is just there and doesn't
have to be generated from somewhere. The code where the error
originates is in hpi.cpp. try:

export PYTHONPATH=<whatever directory your hsi.py _hsi.so and hpi.py
are in>
<path to hpi-linked hugin>/hugin

I have also put more up-to-date documentation in README.hsi in the hsi
directory, if you need to read up on what does what, but of course I'm
always happy to help here.

Kay

[kfj]

On 20 Jan., 21:34, kfj <_...@yahoo.com> wrote:
> On 20 Jan., 18:54, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
>
> > Hi Kay,
>
> > continue the accessor issue mentioned in the other thread.
>
> > The accessor functions are defined in SrcPanoImage.h, lines 117 - 172
> > by using macros and inclusion of image_variables.h multiple times.

Hi Thomas!

I think I've finally understood the code. I suppose it'll be best to
mess with the code a bit - as I said earlier, SWIG can either include
one level or all levels, two levels would be just what's needed. I can
probably make a modified version of SrcPanoImage.h that does the
trick, or some such manoevre... Partial preprocessing might do the
trick. I'll have good hard look at it tomorrow and call it a day now

Kay

[T. Modes]

Hi Kay,

> Try and run hugin from the command line and see what the python
> interface says why it fails. Most likely it can't load the modules hpi
> and hsi because they're not in the module path. Remember hpi.py is not
> output, but handcoded and therefore lives in the hsi directory
> initially - if you want all the files in one place, copy it over to
> where hsi.py and _hsi.so (or whatever they're called on Windows) live
> in the target directory (like, hugin.hg-build/src/hsi). I haven't yet
> figured out how to tell CMake that something is just there and doesn't
> have to be generated from somewhere. The code where the error
> originates is in hpi.cpp. try:
>
> export PYTHONPATH=<whatever directory your hsi.py _hsi.so and hpi.py
> are in>
> <path to hpi-linked hugin>/hugin
>

Thanks for you help.

I finally got it to run. There were some errors in hpi.py (fixed in
repository).

Thomas

[kfj]

On 20 Jan., 22:03, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> Thanks for you help.
>
> I finally got it to run. There were some errors in hpi.py (fixed in
> repository).

Oops... sorry for the glitch. Most embarassing. Your corrections are
correct ;-) I should have checked more thoroughly...

But you got it to run? On Windows? That would be good news indeed,
because there are so many Windows hugin users out there, and I was
secretly afraid of subtle differences in SWIG and Python that might
make my code useless there. Great relief, big thumbs up to you! I'm
still struggling with the accessor functions. I just can't get SWIG to
process these macros, so what I've decided upon now is the following:

I'll generate the required i-file code (so, code for SWIG) by means of
a Python script. If what's desired is a Python interfcae, there ought
to be Python on the machine where the stuff is compiled. I'll write
the script so that it grabs image_variables.h, processes that and
produces a separate i-file, which then gets %included into the main i-
file. That way, whenever image_variable.h changes, the accessor i-file
can be triggered to be regenerated automatically with a bit of cmake
magic. I'll report when the script is ready.

Kay

[kfj]

On 21 Jan., 11:39, kfj <_...@yahoo.com> wrote:

> ... I'll generate the required i-file code (so, code for SWIG) by means of
> a Python script....

... hmmm ... that didn't work out either. So I've now settled on the
following aproach (which works but isn't very elegant):

- I've taken the section in SrcPanoImage.h which defines the accessors
and the protected members by means of macro expansions and saved it as
hsi_SrcPanoImage_accessor_macros.h
- I've preprocessed this section separately: gcc -E
hsi_SrcPanoImage_accessor_macros.h > xx
- I've copied SrcPanoImage.h to hsi_SrcPanoImage.h and replaced the
macro section with the preprocessed data in xx
- now in hsi.i, I %include this modified header

At least the process is easily repeatable and might even be automated.
With this modification now all the accessor functions are wrapped in
Python's SrcPanoImage type. I haven't checked if all returns from
these functions actually produced wrapped types as well, but the
samples I've tried worked fine.

I've modified Thomas' CMakeList.txt code to generate swigpyrun.h in
the source tree instead of the target tree, but I still haven't
figured out how to have it made automatically initially - I can get
only get it to be created if I explicitly call make 'hsi_header'.

I'll put a patch online today or tomorrow and post when I've done so.

Kay

[T. Modes]

Hi Kay,

>But you got it to run? On Windows? That would be good news indeed,
>because there are so many Windows hugin users out there, and I was
>secretly afraid of subtle differences in SWIG and Python that might
>make my code useless there.

Yes, it works. It has only a minor glitch. The output of the print
command is not shown (a fear something similiar for an input
function). But modifications to the pano object occur and appear also
in hugin.

On 21 Jan., 18:58, kfj <_...@yahoo.com> wrote:
> On 21 Jan., 11:39, kfj <_...@yahoo.com> wrote:
>
> > ... I'll generate the required i-file code (so, code for SWIG) by means of
> > a Python script....
>
> ... hmmm ... that didn't work out either. So I've now settled on the
> following aproach (which works but isn't very elegant):
>

What's with the following idea:
Put all for SWIG unnecessary includes into #ifndef SWIG and then run
swig with includeall?
Can swig run with includeall on a single file or have we to modify all
files in this case?

> - I've preprocessed this section separately:  gcc -E
> hsi_SrcPanoImage_accessor_macros.h > xx

That will not work on windows, because we are using an other compiler.

> I've modified Thomas' CMakeList.txt code to generate swigpyrun.h in
> the source tree instead of the target tree, but I still haven't
> figured out how to have it made automatically initially - I can get
> only get it to be created if I explicitly call make 'hsi_header'.

That's a bad idea. We configured cmake so that all files are generated
in the target tree to keep the source tree clean. So what's the reason
for generating in the source tree?

Thomas

[kfj]

On 21 Jan., 18:58, kfj <_...@yahoo.com> wrote:

> I'll put a patch online today or tomorrow and post when I've done so.

The new patch is now online at

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/patch4878.gz

This has the accessor code for class SrcPanoImage and some cosmetic
changes

Kay

[T. Modes]

Hi Kay,

On 22 Jan., 10:08, kfj <_...@yahoo.com> wrote:
> The new patch is now online at
>

> http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/patch48...

>
> This has the accessor code for class SrcPanoImage and some cosmetic
> changes

I commited a slightly modified version of your patch.
Some comments about the changes:
1.) If you create swigpyrun.h in the source tree, it can happen (as in
your patch) that you pull in this file into the repository and
therefore the version management. An automatic created file should not
be in version management. So I removed this part.
2.) There is no need for 2 versions of PanoramaVariable.h. The little
difference for hugin and swig can easily achieved by an ifndef. So
there is only one version and you don't handle with synchronisation of
2 versions of the same file.

Thomas

[kfj]

On 22 Jan., 11:16, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> > I've modified Thomas' CMakeList.txt code to generate swigpyrun.h in
> > the source tree instead of the target tree, but I still haven't
> > figured out how to have it made automatically initially - I can get
> > only get it to be created if I explicitly call make 'hsi_header'.

> That's a bad idea. We configured cmake so that all files are generated
> in the target tree to keep the source tree clean. So what's the reason
> for generating in the source tree?

> I commited a slightly modified version of your patch.
> Some comments about the changes:
> 1.) If you create swigpyrun.h in the source tree, it can happen (as in
> your patch) that you pull in this file into the repository and
> therefore the version management. An automatic created file should not
> be in version management. So I removed this part.

swigpyrun.h is input. It is included by hpi_classes.h which is in turn
included by hpi.cpp. This is why it is needed in the source tree. It's
needed in the making of the hpi object code which is then linked into
libhugin.so, but is irrelevant further down the road and does not
belong to the output. But it should be generated anew every time the i-
file is processed, to reflect possible changes in the SWIG-generated
data structure.

> 2.) There is no need for 2 versions of PanoramaVariable.h. The little
> difference for hugin and swig can easily achieved by an ifndef. So
> there is only one version and you don't handle with synchronisation of
> 2 versions of the same file.

I felt this was the cleaner solution while hsi is still under
development. Initially I was doing it with an #ifdef, but the
difference can easily be seen by running diff on the two versions.
Please consider, that every change to hugin header files triggers a
major recompile, which takes a long time, and if the changes only
affect hsi/hpi, this is a total waste of time. Once everything is
stable, reverting to switching by #ifdef is a snap. As a temporary
measure, it allows quick changes to the headers going into hsi and
leaving the rest as it is. Also, I feel that ideally at least the
changes to ImageVariable.h could beome unnecessary - I think it's safe
to include default constructors for the classes, and I hope to get the
PrintVariable class to work, so for this one there wouldn't be a need
for different versions. If you insist, though, we can revert to the
#ifdef _Hugin_SCRIPTING_INTERFACE solution I was using before.

to reply to your previous post concerning your getting it to run on
windows:

> Yes, it works. It has only a minor glitch. The output of the print
> command is not shown (a fear something similiar for an input
> function). But modifications to the pano object occur and appear also
> in hugin.

did you start hugin from the command line? If not, there's no way you
can see anything, the prints just go into thin air. The affectiveness
of the modifications to the panorama are the main thing; the print
statements in hpi.py and demo_plugin.py are only as a quick proof that
something goes wrong or right. But hugin must be started in a console
window to see them.

concerning the accessors:

> What's with the following idea:
> Put all for SWIG unnecessary includes into #ifndef SWIG and then run
> swig with includeall?
> Can swig run with includeall on a single file or have we to modify all
> files in this case?

you can't activate 'include all' for just one header file. To achieve
this effect, it would be possible to make a separate i-file for the
accessors, create another python module from that and load that when
hsi is loaded. This separate i-file can be processed with different
options like --include-all. The problem is that SrcPanoImage.h
includes tons of other headers, which would all be pulled in and
wrapped with --include-all if SRCPanoImage.h was %included whole by
the i-file. This is certainly not what we want. What may be possible
is to put the accessor macros into a separate header which can be
%included by a separate i-file with --include-all to just generate the
accessors. SrcPanoImage.h could also include this header, and
everything should work both ways. I'll investigate and make a
proposition if it's feasible.

> > - I've preprocessed this section separately: gcc -E
> > hsi_SrcPanoImage_accessor_macros.h > xx

> That will not work on windows, because we are using an other compiler.

I'm confident that every C++ compiler in existence offers separate
precompilation. But as stated in the previous section I will try and
find a solution to avoid this. I do feel it's a bit of a side issue,
though - I've already spent a fair amount of time getting the accessor
functions to run and I feel the time would be better spent in testing
if they do what they're supposed to do. Anyway, I'll try and avoid the
separate preprocessing step, but for now you can let hsi.i %include
hsi_SrcPanoImage.h and have the accessors - all other code still uses
the unmodifies SrcPanoImage.h and is unaffected by any
experimentation.

Kay

[T. Modes]

Hi Kay,

> swigpyrun.h is input. It is included by hpi_classes.h which is in turn
> included by hpi.cpp. This is why it is needed in the source tree. It's
> needed in the making of the hpi object code which is then linked into
> libhugin.so, but is irrelevant further down the road and does not
> belong to the output. But it should be generated anew every time the i-
> file is processed, to reflect possible changes in the SWIG-generated
> data structure.

It's not needed in the source tree. The compiling and linking work
also if the file is in the build tree (when the paths are configured
right). So it works e.g. with hugin_config.h, where some platform/user
specific things are defined. So no need to generated in the source
tree with all implications.

>
> > 2.) There is no need for 2 versions of PanoramaVariable.h. The little
> > difference for hugin and swig can easily achieved by an ifndef. So
> > there is only one version and you don't handle with synchronisation of
> > 2 versions of the same file.
>
> I felt this was the cleaner solution while hsi is still under

> development. </snip>

Ok, I did not see this point.

> > Yes, it works. It has only a minor glitch. The output of the print
> > command is not shown (a fear something similiar for an input
> > function). But modifications to the pano object occur and appear also
> > in hugin.
>
> did you start hugin from the command line? If not, there's no way you
> can see anything, the prints just go into thin air. The affectiveness
> of the modifications to the panorama are the main thing; the print
> statements in hpi.py and demo_plugin.py are only as a quick proof that
> something goes wrong or right. But hugin must be started in a console
> window to see them.

Yes, also tested on console, but this does not help because the
console works in an other way than on unix.

> > > - I've preprocessed this section separately:  gcc -E
> > > hsi_SrcPanoImage_accessor_macros.h > xx
> > That will not work on windows, because we are using an other compiler.
>
> I'm confident that every C++ compiler in existence offers separate
> precompilation. But as stated in the previous section I will try and
> find a solution to avoid this.

I finally found a solution to automatically create the preprocessed
file and input it into the swig process. So there is no need to fiddle
by hand with the preprocessing and there are not 2 version of the same
file which needs to be in sync (commited in 25f830e2d143).
So you can further testing now.

Thomas

[T. Modes]

I added also an installer for windows in CMake. The lines for unix are
prepared by comment out because I don't know in which directories the
files should go on unix.

Thomas

[kfj]

On 22 Jan., 16:05, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> I finally found a solution to automatically create the preprocessed
> file and input it into the swig process. So there is no need to fiddle
> by hand with the preprocessing and there are not 2 version of the same
> file which  needs to be in sync (commited in 25f830e2d143).
> So you can further testing now.

Excellent. I'll have a look at your solution when I get round to it,
if not tonight then tomorrow. I'll report back and tell you how it
works here. Thank you for your cooperation! So by now you should have
the thing running, accessor functions and all? Congratulations!

Kay

[kfj]

On 22 Jan., 16:05, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> I finally found a solution to automatically create the preprocessed
> file and input it into the swig process. So there is no need to fiddle
> by hand with the preprocessing and there are not 2 version of the same
> file which  needs to be in sync (commited in 25f830e2d143).
> So you can further testing now.

Your solution absolutely does the trick. I'm no good at cmake, and
seeing what you did with it I'm duly impressed. I feel this is a nice
and clean solution now; it worked on my Ubuntu system, just a tiny
error in CMakeLists.txt - the directive for the gcc preprocessor is -E
and not /E. And all automatic, as it should be! Well done :-)

Kay

[T. Modes]

Hi Kay

> Your solution absolutely does the trick. I'm no good at cmake, and
> seeing what you did with it I'm duly impressed. I feel this is a nice
> and clean solution now; it worked on my Ubuntu system, just a tiny
> error in CMakeLists.txt - the directive for the gcc preprocessor is -E
> and not /E. And all automatic, as it should be! Well done :-)
>

Nice to hear that it works also on unix. I fixed the minor error.

Thomas

[kfj]

On 23 Jan., 09:16, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> Nice to hear that it works also on unix. I fixed the minor error.

Hi Thomas!

Do you know if anyone has tried the thing out on MacOS? Now that the
compile is running quite smoothly it would be nice to be confident it
will run on all three platforms.

Kay

[kfj]

Hi group!

I've continued working on hsi/hpi and feel it's time for another
patch:

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/patch4900.gz

I hope the round number is a good omen!
I've rewritten the CMakeLists.txt, thanks for help from T. Modes and
Kornel Benko for help! I am using a slightly different approach to
precompiling the headers which produce accessor code for image
variables which, I think, is more obvious. The CMakeLists.txt now also
has all dependencies of the SWIG interfcae code. And it's probably
nicer to read as well.... ;-)

I also made efforts to consolidate the code, put in support for C++
fstreams and updated the README file, which is also available
separately at

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/README.hsi

if anyone cares just to get an idea about the project without actually
downloading the code. In the source code, there's a demonstration of
the curious crash I experience on my system (Kubuntu 10.10 / Python
2.6) if any of the C++ code outputs to cerr - and a remedy I found
effective against the problem, again on my system. I'd be curious to
hear if anyone can reproduces this. There's more on the issue in

http://groups.google.com/group/hugin-ptx/browse_thread/thread/51bd6ca9ced92fc8#

... sorry, I just noticed I actually left the call to 'import vaccine'
in hpi.py - but it gets built anyway and should do no harm. Please let
me know if and when the patch makes it into the python_scripting
branch. As ever, I'd welcome comments and criticism.

Kay

[T. Modes]

Hi Kay,

> I've rewritten the CMakeLists.txt, thanks for help from T. Modes and
> Kornel Benko for help! I am using a slightly different approach to
> precompiling the headers which produce accessor code for image
> variables which, I think, is more obvious. The CMakeLists.txt now also
> has all dependencies of the SWIG interfcae code. And it's probably
> nicer to read as well.... ;-)

There were some more changes in the code necessary:
The MSVC compiler does not support the -o switch. So using
redirection.
There was missing a statement: SET_SOURCE_FILES_PROPERTIES(${out}
GENERATED)

bogous and vaccine needs to be link against ${PYTHON_LIBRARIES}

> if anyone cares just to get an idea about the project without actually
> downloading the code. In the source code, there's a demonstration of
> the curious crash I experience on my system (Kubuntu 10.10 / Python
> 2.6) if any of the C++ code outputs to cerr - and a remedy I found
> effective against the problem, again on my system. I'd be curious to
> hear if anyone can reproduces this. There's more on the issue in
>

> http://groups.google.com/group/hugin-ptx/browse_thread/thread/51bd6ca...
>

On windows the bogous project works fine:

Python 2.7.1 (r271:86832, Dec 5 2010, 12:04:08) [MSC v.1500 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import bogous
>>> bogous.use_cerr()
hallohallo
>>>

So I commited the changes to repository with the following addtional
changes:
I removed the bogous and vaccine project.
I renamed the folder the hugin_script_interface to better match the
existing folder structure.

Thomas

PS: In Python I can run "import hsi" and then modify the panorama
object. But the hugin python interface does not work correctly. It
crashes hugin when running a script that works when running directly
in python.
PPS: In demo_plugin.py and hpi.py the removed function pano_open is
still used. This needs to be rewritten with the modified syntax.
PPPS: Is the file hsi.cpp still needed? It seems that it is not used
any more.

[T. Modes]

> PS: In Python I can run "import hsi" and then modify the panorama
> object. But the hugin python interface does not work correctly. It
> crashes hugin when running a script that works when running directly
> in python.

After more testing I found the culprit: pano.setImage(0,img)
When calling from python directly it works. But when the command is
used inside hugin, hugin is crashing.

[kfj]

On 28 Jan., 20:05, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> There were some more changes in the code necessary:
> The MSVC compiler does not support the -o switch. So using
> redirection.

I was wondering before why you had used redirection. please excuse my
ignorance of MSVCs workings.

> There was missing a statement: SET_SOURCE_FILES_PROPERTIES(${out}
> GENERATED)

ooops... thank you for checking it out on windows! I assumed that
since now the ${out} file isn't made from thin air, like swigpyrun.h,
but rather results from an input file, ${in}, GENERATED wasn't
adequate. And it worked fine here without the GENERATED. Are you sure
it's necessary?

> bogous and vaccine needs to be link against ${PYTHON_LIBRARIES}

this may be so on Windows because, if I'm not mistaken, all linking on
Windows is static. I suppose you got a linker error? Since on Linux
all libs are linked dynamically, nothing happens since neither of the
two actually calls any Python code. I deliberately stripped away all
linked libraries to demonstrate that the problem does result fron
linking in huginbase, which is the only difference between the two:
bogous links to it, vaccine doesn't.

> On windows the bogous project works fine:
>
> Python 2.7.1 (r271:86832, Dec  5 2010, 12:04:08) [MSC v.1500 32 bit
> (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> import bogous
> >>> bogous.use_cerr()
> hallohallo

I thought it might. Since the memory fault actually occurs in the gcc
C library on Kubuntu, this comes as no surprise. Thanks for checking!

> So I commited the changes to repository with the following addtional
> changes:

Thank you. I'll download it back promptly, do a test cycle and report
back once I've established all is well on the Ubuntu side.

> I removed the bogous and vaccine project.

You could have left the two things in, I would have liked to hear if
anyone else using gcc could have reproduced the problem. Since this
isn't the main branch, noone is likely to be bothered by them, since
whoever ventures into this territory is bound to be of the intended
audience: developers. Sorry I left the call to import vaccine in
hpi.py accidentally, I hope this wasn't a problem.

> I renamed the folder the hugin_script_interface to better match the
> existing folder structure.

fine with me. I only used the short 'hsi' because I go there so
often... ;-)

> PPS: In demo_plugin.py and hpi.py the removed function pano_open is
> still used. This needs to be rewritten with the modified syntax.
> PPPS: Is the file hsi.cpp still needed? It seems that it is not used
> any more.

another oops.. I'll replace it with the code that does the same - I
took the function out because I wanted to slim the interface to it's
bare essence. The code would be

p = hsi.Panorama()
ifs = hsi.ifstream(sys.argv[1])
p.readData(ifs)

and, if you care to - pano_open did this -

calcCtrlPointErrors(p)

plus a bit of error checking.
I'd plain forgotten the demo plugin can also be used from the command
line - the call to pano_open only occurs in that part. That's
interpreted languages for you - you're free to call something that
doesn't exist and it only fails at runtime.

> > PS: In Python I can run "import hsi" and then modify the panorama
> > object. But the hugin python interface does not work correctly. It
> > crashes hugin when running a script that works when running directly
> > in python.

> After more testing I found the culprit: pano.setImage(0,img)
> When calling from python directly it works. But when the command is
> used inside hugin, hugin is crashing.

This must be in code you added to the demo plugin to check out if it
works. It's neither in the demo plugin I uploaded nor in the one in
the repo. I'll investigate. It'd help if you'd post your plugin, so I
can get an idea what happens before it goes wrong.

Kay

[kfj]

Sorry, I didn't spot the PPS after your signature until I'd sent off
my reply:

> PPS: In demo_plugin.py and hpi.py the removed function pano_open is
> still used. This needs to be rewritten with the modified syntax.

Another bit which isn't usually used - it was a little test to run
hpi.py from the command line. The python code theat bit tries to call
isn't even there anymore. safe to delete the part starting with

# the remainder is a tiny unit test :-)

> PPPS: Is the file hsi.cpp still needed? It seems that it is not used
> any more.

and, indeed, hsi.cpp is no longer needed. I had left it initially
because it shows that additional code can easily be put into the SWIG
module, but I felt anyone who'd likely touch the code would know that
anyway, and the less files there are the less can go wrong. So I threw
it out. I did hg remove before the commit in my repo before I made the
patch, but I think if you just put in the patch your end, if you still
have the file hsi.cpp in your source tree it's not thrown out
automatically. Only guessing, I'm still new to mercurial.

Kay

[kfj]

I tried here (and, btw, with the downloaded and built-from scratch
code from the mercurial repo, which builds and works fine so far). It
put this code into demo_plugin.py:

def entry ( pano ) :
...
img = hsi.SrcPanoImage ( '/home/kfj/Bilder/2010_10_14/
IMG_0061.tif' )
pano.setImage(0,img)

And it works as intended. I suspect you might have just opened the
image by writing:

img = SrcPanoImage ( 'whatever' )

Which may work if you have previously done an

import * from hsi

but if demo_plugin doesn't import * from hsi, you have to use the
qualified name:

img = hsi.SrcPanoImage ( 'whatever' )

just guessing... and what sort of crash do you get? just an exception
in python or a proper crash of the hugin application?

Kay

[T. Modes]

> just guessing... and what sort of crash do you get? just an exception
> in python or a proper crash of the hugin application?

I get a proper crash of hugin.
I'm using an own script to test, because the print in the demo goes to
nowhere on windows. The scripts contains the following lines:

def entry ( pano ) :

img=pano.getImage(0)
img.setYaw(90)
pano.setImage(0,img)

This works only in Python, but not in Hugin -> crash.

When replacing pano.setImage with pano.setSrcImage it works in Hugin.
Maybe some problem with std::size_t?

Also tried your snippet:

def entry ( pano ) :

img=hsi.SrcPanoImage("c:/path/bild.jpg")
pano.setImage(0,img)

Runs fine in Python but crashs in hugin.

Thomas

[kfj]

On 29 Jan., 12:05, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> I get a proper crash of hugin.
> I'm using an own script to test, because the print in the demo goes to
> nowhere on windows. The scripts contains the following lines:

> ...

Just some more questions before I ask you to launch the degugger:

- did it work before my last patch?
- are you sure you have a pano open when calling from hugin?
- did you compile with -DCMAKE_BUILD_TYPE=Debug? maybe you have the
same problem I have here with the DEBUG macros that print to cerr.

since you can't see prints from the python script in Windows, you may
want to just write stuff to a file instead. This is easy in Python,
just do f = open ( 'myfile' , 'w' ), then you can write to the file
like f.write( '%d %s\n' % ( 6 , 'poatoes' ) ) - this way you can at
least check what your variable img contains, in case that's the
problem, and see more precisely the program crashes. If that doesn't
get you anywhere, you'll have to fire up the degugger and track down
where the crash happens.

Kay

[kfj]

On 29 Jan., 12:05, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> def entry ( pano ) :
>         img=pano.getImage(0)
>         img.setYaw(90)
>         pano.setImage(0,img)

It definitely works here from hugin just like this.

> When replacing pano.setImage with pano.setSrcImage it works in Hugin.
> Maybe some problem with std::size_t?

very puzzling. But I'd be surprised if it was a type conversion
problem - SWIG is very clever doing this correctly. What I did notice
is that the declaration of setImage() actually expects an image by
value and not by reference like setSrcImage(). Maybe that's a problem.

> Also tried your snippet:
> def entry ( pano ) :
>         img=hsi.SrcPanoImage("c:/path/bild.jpg")
>         pano.setImage(0,img)

you sure the path notation with slashes (instead of backslashes) can
be used like that from the GUI?

Kay

[T. Modes]

Hi Kay,

> Just some more questions before I ask you to launch the degugger:
>
> - did it work before my last patch?

I thought, it worked. But tested again, it did not work before your
last patch.

> - are you sure you have a pano open when calling from hugin?

I'm sure, that a pano is open.

> - did you compile with -DCMAKE_BUILD_TYPE=Debug? maybe you have the
> same problem I have here with the DEBUG macros that print to cerr.
>

Compiled as release version.

When I comment out the line with setImage it works. Also only

def entry ( pano ) :
img=pano.getImage(0)
img.setYaw(90)

But this reveals an other bug (or if this a feature). getImage returns
a const/read only SrcPanoImage. But in the scripting interface I can
modify the SrcPanoImage. I don't know if this can have side effects
when using as read/write object in Python.

Thomas

[kfj]

On 29 Jan., 16:18, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

Okay, I can't think of anything else. You'll have to debug it. Once
you have the stack trace, we can have a look at where the actual crash
occurs and take it from there.

> When I comment out the line with setImage it works. Also only
> def entry ( pano ) :
>         img=pano.getImage(0)
>         img.setYaw(90)

> But this reveals an other bug (or if this a feature). getImage returns
> a const/read only SrcPanoImage. But in the scripting interface I can
> modify the SrcPanoImage. I don't know if this can have side effects
> when using as read/write object in Python.

Of course it can have side effects if the C++ assumes it's object is
'safe' and a nasty bit of Python code gives a damn about it and
changes stuff it's not supposed to change. This is why, ideally, we'd
have an API to hugin on which we could base a stringently defined
scripting interface. No luck here. Just a bunch of freaks trying to
coerce hugin's C++ headers into a usable Python interface. But we
might be lucky and the approach does work out in the end. I have
mentioned that you'll have every opportunity to shoot yourself in the
foot with the code. If it's just a matter of avoiding some methods in
favour of others, so be it. I only fear that the problem you describe
hints at some fundamental problem that exists in Windows and not in
Linux and that needs to be adressed.

I've spent maybe 10% of the time I spent on this project on writing
code, the remainder was mainly reading up stuff. I admit I did not
read about what SWIG does on Windows, or what has to be done on the
Windows Python side to ensure everything runs smoothly. In a way, the
Windows implementation of hsi/hpi is a port - I've written the Linux
code as portable as I could, and it even compiles unmodified and most
of it seems to work. The last bit of finetuning has to be done on the
Windows side by a Windows programmer, and then maybe it turns out that
what I wrote isn't 100% portable after all, but from this end I could
only come up with guesswork.

IFAIK the const declaration will only have an effect inside the C++
code - insofar as a const can't be assigned to in C++ (unless you
cast). SWIG translates the reference into a pointer. The pointer
itself just points to the object - the object lives in ordinary memory
which is in no way different whether the object or the pointer to it
are declared const or not. Since Python refers to the object via a
pointer, it can manipulate the data. If you want a more in-depth
discussion of const and SWIG, maybe the SWIG documentation '5.2.4 A
brief word about const' and '6.27 A brief rant about const-
correctness' is helpful.

Anyway, the code of setImage is a bit strange:

void setImage(std::size_t nr, SrcPanoImage img)
{
setSrcImage(nr, img);
};

So it receives a SrcPanoImage by value. Next it calls a function that
takes a reference to this image, which proceeds to copy the image
variables into the target image. Why setImage() doesn't take a const
SrcPanoImage& in the first place is a mystery to me...

So this is how it goes - as one of our esteemed colleagues always
finishes his posts: in theory there is no difference between theory
and practise, in practise there is. It's just like that with multi-
platform programming. In theory there shouldn't be a differnce between
Linux and Windows...

Sorry I can't be more helpful. I don't even have MSVC, when I still
used Windows, I did all C++ programming with cygwin or minGW. But I'll
gladly look at whatever debugging results you come up with. Just 'it
crashes' isn't enough information to go by. I really want this thing
to take off, and having it run on Windows is a part that's necessary,
even though I'd gladly do without Windows altogether. I just can't
help so well on the Windows side of things, much as I'd like to.

Kay

[kfj]

On 29 Jan., 17:45, kfj <_...@yahoo.com> wrote:

> Okay, I can't think of anything else. You'll have to debug it. Once
> you have the stack trace, we can have a look at where the actual crash
> occurs and take it from there.

Having slept over the matter, I can think of some more things. First
we must be sure that all components used are compatible. After all
there's four things involved:

- hugin
- SWIG
- Python
- MSVC

In the Linux world, things tend to integrate more easily because
everything is built with gcc and updates come when they're ready, for
free. Using Windows, there are some pitfalls to be avoided, and there
are also differences to accepted standards.

The first bit concerns Python. This is what actually made me think
along these lines: I noticed from a bit of output you'd copied from a
python interpreter session that you were using Python 2.7. That is
quite recent, and though it should be compatible with the previous 2.X
versions, there might be subtle differences. When CMake finds the
Python Libs, I think it says which version it has found and is linking
against. We should be sure these are of the same Python Version.

Then I thought some more and it occured to me that the problems
surface when using ebmbedded Python, namely when using hpi from hugin.
Embedding hugin effectively links a Python interpreter into hugin, and
again we must be sure it's the same version that we use otherwise.
More so, we have to be sure that it has been compiled using the same
Version of MSVC as the one we've used to compile the SWIG module with
(and, ideally, the same we're compiling hugin with). In section 4.1 of
the Python document 'Extending and Embedding the Python Interpreter'
it is stated that:

"To build extensions using these instructions, you need to have a copy
of the Python sources of the same version as your installed Python.
You will need Microsoft Visual C++ “Developer Studio”; project files
are supplied for VC++ version 7.1, but you can use older versions of VC
++. Notice that you should use the same version of VC++that was used
to build Python itself."

So, to make a long story short, everything should be compiled with the
same version of MSVC and all Python parts should be of the same python
version. The Python interpreter, when fired up, should tell you what
version it's been built with.

The second bit I found was from the SWIG documentation. It states:

"3.4 Microsoft extensions and other Windows quirks

A common problem when using SWIG on Windows are the Microsoft
function calling conventions which are not in the C++ standard. SWIG
parses ISO C/C++ so cannot deal with proprietary conventions such as
__declspec(dllimport), __stdcall etc. There is a Windows interface
file, windows.i, to deal with these calling conventions though. The
file also contains typemaps for handling commonly used Windows
specific types such as __int64, BOOL , DWORD etc. Include it like you
would any other interface file, for example:

%include <windows.i>

__declspec(dllexport) ULONG __stdcall foo(DWORD, __int32);"

This might be worth a try.

Okay, that's all I can think of for now - I'm not familiar with MSVC,
that's why I can't be more specific, but maybe the difficulties that
have surfaced with the embedded Python in hpi stem from here.

Kay

[T. Modes]

Hi Kay

the versions should match.
Python 2.7 (includes, libs, dll installed with same package, no other
version installed)
Python 2.7 is compiled with MSVC9, as I compile my hugin version

Sorry, I was not successful to provide a backtrace.
When running Hugin with debug the import of the module fails (paths
were modified, so it should find the module). So the script is never
executed.

>  A common problem when using SWIG on Windows are the Microsoft
> function calling conventions which are not in the C++ standard. SWIG
> parses ISO C/C++ so cannot deal with proprietary conventions such as
> __declspec(dllimport), __stdcall etc. There is a Windows interface
> file, windows.i, to deal with these calling conventions though. The
> file also contains typemaps for handling commonly used Windows
> specific types such as __int64, BOOL , DWORD etc. Include it like you
> would any other interface file, for example:
>
> %include <windows.i>
>
> __declspec(dllexport) ULONG __stdcall foo(DWORD, __int32);"
>

I will try it.

Thomas

[kfj]

On 30 Jan., 11:14, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> Hi Kay
>
> the versions should match.
> Python 2.7 (includes, libs, dll installed with same package, no other
> version installed)
> Python 2.7 is compiled with MSVC9, as I compile my hugin version

Another hope shattered :(

> Sorry, I was not successful to provide a backtrace.
> When running Hugin with debug the import of the module fails (paths
> were modified, so it should find the module). So the script is never
> executed.

that is odd. I'll try building a debug version here on Ubuntu and see
if I experience similar problems. It might be necessary to enable
debugging on the Python side:

"Compiling the interpreter with the Py_DEBUG macro defined produces
what is generally meant by “a debug build” of Python. Py_DEBUG is
enabled in the Unix build by adding --with-pydebug to the configure
command. It is also implied by the presence of the not-Python-specific
_DEBUG macro. When Py_DEBUG is enabled in the Unix build, compiler
optimization is disabled."

This refers to Unix, but may be the same or similar on Windows.

> >  A common problem when using SWIG on Windows are the Microsoft
> > function calling conventions which are not in the C++ standard.

...
> I will try it.

I appreciate your tenacity. I feel we might want some help. I'm sure
someone has been here before and there's a solution waiting for the
problem. If none cometh forth, let's start a new thread with a call
for help. In the meanwhile, I think we shouldn't spend too much effort
trying to chance a solution. Let's focus on what works and play with
that for a while to see if the problem is maybe just the one sore spot
and everything else is okay. I propose that as a workaround you change
the declaration and definition of the 'culprit' function to accept a
const SrcPanoImage &.

Kay

[kfj]

On 30 Jan., 11:14, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> Sorry, I was not successful to provide a backtrace.
> When running Hugin with debug the import of the module fails (paths
> were modified, so it should find the module). So the script is never
> executed.

Must be a Windows problem. Here on Ubuntu the debug version does
precisely what the RelWithDebInfo version I usually make does.

Kay

[T. Modes]

Hi Kay,

the %include <window.i> did not help.

>I propose that as a workaround you change
> the declaration and definition of the 'culprit' function to accept a
> const SrcPanoImage &.

Done. Now it works.

Also added first Python 3 support. It's working here.

Thomas

[kfj]

On 30 Jan., 15:51, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> >I propose that as a workaround you change
> > the declaration and definition of the 'culprit' function to accept a
> > const SrcPanoImage &.
>
> Done. Now it works.

Excellent. I'm currently thinking about a way to create a test script
to go through as many object types and methods as possible to identify
any other problem children. But I'd also happily run any prototype
plugins or hsi-using scripts you may have come up with here on my
system to see if what works your end works here as well.

I still haven't heard anything from the Mac front. Maybe scripting
isn't typical behaviour among Mac users, but since the branch is set
up to build without any manual intervention, maybe an intrepid soul
dares compile it on Mac OS. Eventually, once hsi/hpi has made it to
mainstream (as I hope it will) they should after all benefit from the
same plugins as the rest. Do you know who does the Mac building stuff
and would be prepared to give the python_scripting branch a spin?

> Also added first Python 3 support. It's working here.

Wow, you've gone further than I have! This bit is probably easier on
Windows, since Python isn't deeply interwoven with the operating
system - you have a neat parcel Python 3.X and can stay within that
context. Here on Ubuntu, 2.6 is part of the system, and I'd have to do
some figuring out how to prevent everything in the build process to
accidentally grab 2.6 stuff when I want to build for 3.X.

Well done. I actually started out learning Python 3.X when I got to
learn Python, but later on I found that a lot of stuff I was
interested in wasn't available yet for 3.X. But 2.6 and 2.7 are quite
close to 3.X. I think the Python people would like to move on, but
with a huge code base in 2.X and some fundamental differences there's
a good deal of intertia.

Kay

[kfj]

Hi group!

I've put online another patch for the hugin_scripting branch at my
bazaar repo, plus an updated readme file. This time there wasn't so
much change - it's more consolidation. I did rewrite hpi.py, though,
and hope it'll perform well now, no matter if the plugin is loaded as
a module or executed unconditionally.

I extended the demo plugin to demonstrate applying orientations to an
eight-shot sequence, and I wrote another one which keeps at most five
'best' control points for each image pair.

I also put in two SWIG interfaces, 'bogous.i' and 'vacine.i' which
demonstrate a problem I have on my system (Kubuntu 10.10 + Python 2.6)
and haven't been able to resolve. T. Modes has established that
Windows isn't affected, but noone seems to have checked on Linux so
far - I hope this time it isn't thrown out of the branch after the
patch is integrated. Apart from demonstrating my problem with hugin's
use of cerr when used from hsi, these files are harm- and useless and
should vanish later on.

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/patch4906.gz
http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/README.hsi

Kay

[T. Modes]

Hi Kay,

On 4 Feb., 18:47, kfj <_...@yahoo.com> wrote:
> Hi group!
>
> I've put online another patch for the hugin_scripting branch at my
> bazaar repo, plus an updated readme file. This time there wasn't so
> much change - it's more consolidation. I did rewrite hpi.py, though,
> and hope it'll perform well now, no matter if the plugin is loaded as
> a module or executed unconditionally.

Commited after some changes.
* Don't misuse configure_file for installing files. Use the install
command instead.
* Your patch contains a lot a line, where only the line ending were
changed. -> Unified
* Some changes in your patch were already in the repo. You did not
provide a patch against the head of the python branch.

Also it would be nice, if one commit/changeset/patch would only
address one issue. Putting all changes into one changeset is not
recommended when using version management. This makes it harder to
track changes and to find bug.

>
> I extended the demo plugin to demonstrate applying orientations to an
> eight-shot sequence, and I wrote another one which keeps at most five
> 'best' control points for each image pair.

top_five.py is working here (standalone and in hugin).

>
> I also put in two SWIG interfaces, 'bogous.i' and 'vacine.i' which
> demonstrate a problem I have on my system (Kubuntu 10.10 + Python 2.6)
> and haven't been able to resolve. T. Modes has established that
> Windows isn't affected, but noone seems to have checked on Linux so
> far - I hope this time it isn't thrown out of the branch after the
> patch is integrated. Apart from demonstrating my problem with hugin's
> use of cerr when used from hsi, these files are harm- and useless and
> should vanish later on.

See my above comments. For this issue it is better if you provide a
patch which contains only the interface bogous/vaccine, maybe with a
readme. Then it would be easier for someone else to apply your patch
and give feedback/solution.

Thomas

[kfj]

On 5 Feb., 12:06, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> Commited after some changes.
> * Don't misuse configure_file for installing files. Use the install
> command instead.

Okay. I'm just now sure about how to go on about the installing on
Linux. So far I'm just keeping the python modules and plugins in my
target directory and put my PYTHONPATH variable to point to it. But
really, the module should go to the system module path and the plugins
should live in a dedicated plugin directory. I'd like some feedback on
the issue, and I certainly don't want to just shove stuff into paths
outside hugin's tree without due consideration. Would someone of the
developers working on Linux please comment on the issue?

> * Your patch contains a lot a line, where only the line ending were
> changed. -> Unified

Sorry for that. On Linux, every line ends with a newline character and
nothing else. I don't know how other line endings made it into my
code, I'll do my best to avoid this in the future. What standard do
you use in the hugin repo? Do I have to put in carriage returns?

> * Some changes in your patch were already in the repo. You did not
> provide a patch against the head of the python branch.

Again, sorry. I'm not sure how this happened. I drew a fresh clone
once the patch was integrated, then modified that, and finally created
the patch after a commit. Do I have to do more than that? Should I
fetch a clean clone just before I patch, carry over my modifications
to it and make the patch from that?

> Also it would be nice, if one commit/changeset/patch would only
> address one issue. Putting all changes into one changeset is not
> recommended when using version management. This makes it harder to
> track changes and to find bug.

I wanted to kep the work load low for you guys who have to put the
patch into the SF repo. Seems this backfired. But now I'm quite
content that the groundwork is laid, and I'm going to slow down anyway
and do a bit of something else too. So I'll do my best to stick to the
one-patch-per-issue paradigm from now on.

> > I also put in two SWIG interfaces, 'bogous.i' and 'vacine.i' which
> > demonstrate a problem I have on my system (Kubuntu 10.10 + Python 2.6)
> > and haven't been able to resolve

> ...

> See my above comments. For this issue it is better if you provide a
> patch which contains only the interface bogous/vaccine, maybe with a
> readme. Then it would be easier for someone else to apply your patch
> and give feedback/solution.

That's a good idea. I'm still new to Mercurial, and I'll take a while
until I can use it proficiently. Please bear with me. Thanks again for
your prompt response and for integrating my patch into the repo!

Kay

[kfj]

On 5 Feb., 12:06, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> Hi Kay,

> * Your patch contains a lot a line, where only the line ending were
> changed. -> Unified

Thomas, when I now look into the hugin_scripting_interface directory,
there is a file 'top_five3.py', which is obviously a modified version
of top_five.py - needed, because there is no way to pass parameters
from hugin (yet). Now this file has CR and LF, the CRs showing up as
liitle blue '^M' in vi if I open it there. Maybe you edited it with a
Windows editor? Because my top_five.py has no CRs in it. Please advise
me on what the hugin standard is - Unix newlines or DOS CRLFs.

Kay

[Lukáš Jirkovský]

Hello Kay,
Sorry I didn't get to this earlier. I must say I'm impressed by your
work. It's a great thing to have scripting interface for quick
prototyping. Unfortunately I can't test it because the computer I use
for development is nonfunctional.

I find it very nice that you and Thomas think about supporting Python
3. Most of the software out there doesn't care about Python 3 very
much and so packaging for Arch Linux is unnecessarily difficult (Arch
uses Python 3.1 as a default Python version).

On 5 February 2011 12:37, kfj <_k...@yahoo.com> wrote:
> On 5 Feb., 12:06, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
>
>> Commited after some changes.
>> * Don't misuse configure_file for installing files. Use the install
>> command instead.
>
> Okay. I'm just now sure about how to go on about the installing on
> Linux. So far I'm just keeping the python modules and plugins in my
> target directory and put my PYTHONPATH variable to point to it. But
> really, the module should go to the system module path and the plugins
> should live in a dedicated plugin directory. I'd like some feedback on
> the issue, and I certainly don't want to just shove stuff into paths
> outside hugin's tree without due consideration. Would someone of the
> developers working on Linux please comment on the issue?
>

I'd go for ${LIBDIR}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages/hugin

>> * Your patch contains a lot a line, where only the line ending were
>> changed. -> Unified
>
> Sorry for that. On Linux, every line ends with a newline character and
> nothing else. I don't know how other line endings made it into my
> code, I'll do my best to avoid this in the future. What standard do
> you use in the hugin repo? Do I have to put in carriage returns?

Hugin uses Unix line endings.

>> * Some changes in your patch were already in the repo. You did not
>> provide a patch against the head of the python branch.
>
> Again, sorry. I'm not sure how this happened. I drew a fresh clone
> once the patch was integrated, then modified that, and finally created
> the patch after a commit. Do I have to do more than that? Should I
> fetch a clean clone just before I patch, carry over my modifications
> to it and make the patch from that?

If I understand that you're doing clone whenewer you want to change
the code? If yes, I suggest following worflow:
1. clone the repository from source forge (only first time)
2. change to branch python_scripting (only first time)
3. "hg pull -u" to update to the newest changeset, if there was a
conflict, run "hg merge"
4. do some work
5. commit, optionally GOTO 3.
6. "hg bundle" or "hg export -r REV…" and send patch/bundle to be integrated
7. GOTO 3

Lukas

[kfj]

On 5 Feb., 13:10, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
> Hello Kay,
> Sorry I didn't get to this earlier. I must say I'm impressed by your
> work.

Thank you. I feel flattered ;-)

> It's a great thing to have scripting interface for quick
> prototyping. Unfortunately I can't test it because the computer I use
> for development is nonfunctional.

Hope you're up and running soon. So far I think that Thomas has been
the only one touching the new branch, and I'd wish for more feedback
and better integration with hugin.

> I find it very nice that you and Thomas think about supporting Python
> 3. Most of the software out there doesn't care about Python 3 very
> much and so packaging for Arch Linux is unnecessarily difficult (Arch
> uses Python 3.1 as a default Python version).

If I understand the workings of the cmake code rightly, it will build
the appropriate code for whatever Python it finds libraries for. So if
your system has 3.X, the module should be 3.X as well. SWIG generates
code that is universally compatible. This approach is wise, since on
Linux Python and the OS are quite intimately interwoven, and you might
as well just go for the type of module that works with your default
version. Indeed I haven't given much thought to the possibility of
compiling it to use 3.X on my system, even though I'm sure cmake can
be made to do so.

> I'd go for ${LIBDIR}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages/hugin

I'll give that a shot, and if it works nicely I'll recommend it for
general use.

> Hugin uses Unix line endings.

Fine. I thought so. You know, if you edit stuff on Windows, it sneaks
those silly carriage returns in before you know it... Some editors do
at least allow you to keep them out or do so automatically when the
input is UNIX style.

> If I understand that you're doing clone whenewer you want to change
> the code? If yes, I suggest following worflow:
> 1. clone the repository from source forge (only first time)
> 2. change to branch python_scripting (only first time)
> 3. "hg pull -u" to update to the newest changeset, if there was a
> conflict, run "hg merge"
> 4. do some work
> 5. commit, optionally GOTO 3.

> 6. "hg bundle" or "hg export -r REV..." and send patch/bundle to be integrated
> 7. GOTO 3

I do it slightly differently: I have a direct clone of the SF repo,
which I keep clean and only get to the latest standard by doing

cd hugin.hg
hg pull
hg up

in it's root directory. I need that branch to have a build of the
latest default branch handy for testing and for reference. Once I have
the latest changes, I clone the clean clone to a working version, say

cd ..
hg clone hugin.hg work.hg
cd work.hg

Then I update to the python_scripting branch

hg up -C python_scripting

since I do that just after my last patch has been inserted, I now have
the status quo, as applied by the insertor of the patch. Now I work on
this body of code until I'm satisfied. Then I commit and generate the
patch:

hg commit
hg export XXXX > patchXXXX
gzip patchXXXX

and put the patch online in my bazaar repo to be picked up.

I thought that even if someone else also modifies the branch in the SF
repo, since my patch only contains a single changeset's worth, and
only has one ancestor, since I don't merge anything, using hg export
would be the adequate mechanism. Please correct me if I'm doing it
wrongly.

Kay

[Lukáš Jirkovský]

> If I understand the workings of the cmake code rightly, it will build
> the appropriate code for whatever Python it finds libraries for. So if
> your system has 3.X, the module should be 3.X as well. SWIG generates
> code that is universally compatible. This approach is wise, since on
> Linux Python and the OS are quite intimately interwoven, and you might
> as well just go for the type of module that works with your default
> version. Indeed I haven't given much thought to the possibility of
> compiling it to use 3.X on my system, even though I'm sure cmake can
> be made to do so.

I understand it exactly the same. It was a nice surprise to me to see
support for both major versions of Python.

You may want to do "hg pull -u" (or "hg pull & hg up") after commit to
make sure nothing has changed in the repo meanwhile (hehe, I omitted
it in my suggested work flow too). Otherwise you should have no
problems.

Lukas

[kfj]

On 5 Feb., 16:49, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:

> You may want to do "hg pull -u" (or "hg pull & hg up") after commit to
> make sure nothing has changed in the repo meanwhile (hehe, I omitted
> it in my suggested work flow too). Otherwise you should have no
> problems.

So if I do the "hg pull -u" after having commited my changes (to my
local clone), it won't undo the changes I've just commited? Bear in
mind I don't write to the SF repo, I only read from there and then put
online my patch to be hopefully picked up - Thomas has been so kind to
pick up, check and integrate the last few patches.

Kay

[Lukáš Jirkovský]

Everything will be preserved. The reason why to do hg pull before
creating patch is that you will be able to determine whether some
conflicting change has been committed to the upstream repository or
not. If there is such change mercurial will run merge. Merge is often
completely automatic but in case of problems it will run merge tool as
specified in [1] (I suggest KDiff3 or Diffuse).

[1] http://mercurial.selenic.com/wiki/MergeProgram#How_Mercurial_decides_which_merge_program_to_use

Lukas

[T. Modes]

Hi Kay,

maybe for your use case mercurial queue extention would be a better
alternative instead of fiddling with mercurial commits. So your
changes live in the mercurial queue and you can normal pull the
current state from the main repo.

Concerning line endings: The unix line endings are preferend. But
there are several files in the repo which are using windows line
endings.

Thomas

[kfj]

On 6 Feb., 13:01, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> Hi Kay,
>
> maybe for your use case mercurial queue extention would be a better
> alternative instead of fiddling with mercurial commits. So your
> changes live in the mercurial queue and you can normal pull the
> current state from the main repo.

hmm... I looked into the documetation for queue extensions and it
seems much more involved than what I do now. I think I'll keep on
doing the commit-export routine. But thanks for the tip, maybe later
on it'll turn useful. It looks to me as if your end it wouldn't make a
difference how I arrived at the patch I put online - you'd still have
to import it and do a merge if someone else has also done changes in
the meantime.

> Concerning line endings: The unix line endings are preferend. But
> there are several files in the repo which are using windows line
> endings.

which files would be the ones with Windows endings? Because I don't
wast to step on anyones toes. Maybe there is a way to tell Mercurial
to just ignore white space? If you make patches with diff, you can
tell it to do just that. But of course it would be cleaner to have a
project-wide policy to just use UNIX newlines, as Lukáš Jirkovský has
said is the case anyway.

Kay

[kfj]

Hi all!

I've added install targets for Linux to CMakeLists.txt which work on
my system and I hope they work on other Linux platforms too.

Thomas, I noticed that you had provided slightly modified xxxx3.py
files which were meant for python 3.X. The only difference I saw was
that these files used print as a function. There is a mechanism to use
print as a function in pre-3.X code, you do this by using a 'future
import'. So I have dropped the versions which used print statements in
favour of your use of print functions and modified hpi.py to do the
future import, right at the beginning of the file. This is why the
xxxx3.py files have gone - the code should be compatible for 2.X and
3.X now. I hope you don't mind - I should have done this from the
beginning. The only situation where this would be problematic is with
very old Python 2.X versions that don't recognize the future import,
but they should be well obsolete.

Finally I took the liberty to enter myself in authors.txt as author of
the python interface, where I was listed as having provided bug fixes
- which is true, but I felt this was more like it ;-)

The patch - and I hope there are no untoward problems with it now like
stray Windows line endings and repetitions of previous patches - is,
as ever, at my bazaar repo, together with a slightly modified readme:

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/patch4943.gz
http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/README.hsi

Kay

[T. Modes]

Hi Kay,

> Thomas, I noticed that you had provided slightly modified xxxx3.py
> files which were meant for python 3.X. The only difference I saw was
> that these files used print as a function.

The other difference is the function execfile, as you have fixed.

> The patch - and I hope there are no untoward problems with it now like
> stray Windows line endings and repetitions of previous patches - is,
> as ever, at my bazaar repo, together with a slightly modified readme:

Commited after some more changes to the source code - removed loading
of module hpi3. And also some little changes to cmake to remove the
installing of the removed file.

Concerning the install paths: the last else switch is not only for
MacOS. On Unix the libs can be installed in a private lib dir or in
the system-wide lib path (as far as I understand it).
But this part needs to be checked/tested by someone on Unix.

Thomas

[kfj]

On 9 Feb., 20:23, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

> The other difference is the function execfile, as you have fixed.

I didn't even notice you had changed that - I just took your xxx3.py
files. But I tested on my system with 2.6 and it worked, so it's fine.
Have they taken execfile out of 3.X?

> Commited after some more changes to the source code - removed loading
> of module hpi3. And also some little changes to cmake to remove the
> installing of the removed file.

Thank you for your prompt response, yet again! Of course, now that you
mention it - there was this conditional compile in hpi_classes.h

#if PY_MAJOR_VERSION>=3
hpi_module = load_module ("hpi3");
#else

which I'd quite forgotten about. Good thing you check up on me.

> Concerning the install paths: the last else switch is not only for
> MacOS. On Unix the libs can be installed in a private lib dir or in
> the system-wide lib path (as far as I understand it).
> But this part needs to be checked/tested by someone on Unix.

So we can leave it as it is until someone complains ;-)

I'll go through the usual re-import routine, but since the changes
were minor, I'll not comment unless anything goes wrong.

Kay

[kfj]

Hi group!

I've been busy with the first large Python script using hsi, so there
hasn't been much change to hsi itself in the meantime. Working on my
program I noticed I had omitted Mask.h from the interface, and I
needed masking. So I put it in the interface, together with a template
instatiation for MaskPolygonVector, which is the container in which
mask groups for images are passed around.

I also changed a few return codes in hpi to avoid potential confusion
about which part produces an error.

The changes are contained in a patch which I have put into my bazaar
repo, hoping that it will go the way of it's predecessors, which have
been integrated into the main repo by T. Modes.

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/patch4980.gz

Apart from that, and my (exciting, new :-) script a tale of woe from
the Mac front. Harry managed to introduce some slight modifications
into the interface which resulted in it compiling on Mac OS, but he
failed to generate a usable Python module - probably some sort of
linking or compiler parameter error which he couldn't track down - if
you're interested, have a look at the relevant thread:

http://groups.google.com/group/hugin-ptx/browse_thread/thread/8f8c0382e5b92ab6#

Harry proposed to 'go ahead' with it, never mind the Mac problems.
What would that mean? I feel that 'my' side of the code, i.e. the
scripting interface and the plugin access mechanism, might simply be
considered in beta state from now on. There isn't much else I can
think of doing for now, the code seems good enough, and while using it
big time in my (new, exciting ;-) script there weren't any untoward
errors or problems - all performed as intended. But I have moaned
before about this being only part of the work: What hugin's UI offers
to make use of plugins is very meagre indeed: You can choose a python
plugin and run it. The plugin will receive the current panorama as
it's sole parameter and when it's done the UI is made aware of the
changed state. There is no

- passing of other parameters
- treatment of errors
- display of mesages the plugin might want to relate
- other way to access a plugin than via a single menu entry

Let me compare this to what the plugin interface can or could do:

- The plugin interface can handle pasing of arbitrary combinations of
all types of parameters hsi knows (and that's many)
- Python's exception handling is very advanced - if there was an error
condition and an interface to pass the error on, hugin could be
notfied of success/failure of the operation
- Python programs tend to print to the console to communicate. A
mechanism to display these communications to the hugin user in a
window like those displayed for the communications of the CPGs,
warpers and stitchers would be a nice feature
- plugins are usually made for specific data. There might be image
plugins, or plugins working on image groups, or control points, etc.
etc.. So ideally plugins should be called from the contect menu and
only those plugins that make sense in a given context should be
presented as choice.

Yet again, I ask: developers, liaise. Please don't expect of me to do
it all. I'm not a GUI person, really, and I've spent a great deal of
effort getting the backend right. Maybe someone else could look at the
goodies I've stacked up and think of a clever way of enabling people
to use them?

Then there is an issue I'd like to have considered by the group: the
hsi python module could be considered a library, since it can do hugin-
ish stuff outside hugin, probably linking in a few shared libraries,
but if it was linked statically, not even that. A lot of hugin's code
is GPLed. Is there a problem with that? What license should hsi/hpi
be? So far, I've GPLed all my code contributions. If the hsi module
should become part of the binary distros should we consider putting
the module under a less restrictive license to allow wider use (which
would imply having to gain a lot of permissions from contributors
having contributed GPLed code) or should we stick to GPL and it's
viral nature?

And one more thing: I'd like to see a discussion about a perspective
for merging the python_scripting branch back into the mainstream.
Thomas and I have made a good effort to parametrize everything in
cmake and make the scripting capability a compile-time option. The
intersections with other code are minimal and well #ifdeffed.

Kay

[T. Modes]

Hi Kay,

>
> I also changed a few return codes in hpi to avoid potential confusion
> about which part produces an error.

Is there some list, what each error code means? So we could add more
meaningfull messages for users/new python developers, if the script or
script interface fails. Currently they are only numbers, which does
not say to much without looking into different places of the source.

>
> The changes are contained in a patch which I have put into my bazaar
> repo, hoping that it will go the way of it's predecessors, which have
> been integrated into the main repo by T. Modes.
>

Commited.

Thomas

[kfj]

On 26 Feb., 13:30, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
> Hi Kay,
>
>
>
> > I also changed a few return codes in hpi to avoid potential confusion
> > about which part produces an error.
>
> Is there some list, what each error code means? So we could add more
> meaningfull messages for users/new python developers, if the script or
> script interface fails. Currently they are only numbers, which does
> not say to much without looking into different places of the source.

Thank you for the commit, Thomas. Really, none of the errors I worked
on should occur under normal circumstances. But now, with the number,
anyone can instantly locate them in the code to track down what went
wrong. There is a pattern, though:

- errors in the minus twenties come from hpi.cpp and indicate a
problem in the interface
- errors in the minus tens come from hpi.py and result from problems
with the plugin
- the plugin itself should return 0 if all is well or a small number
on error

If you want I can make a more detailed list, but I'd like to wait
until we have decided how the plugin interface should be anchored in
the main body of code. You may have read the remainder of my post,
where I ask how this should be done, and I feel any formal
specification at this point in time would be overkill. Once we've
decided on the integration, a proper method to exchange messages,
errors and data can be implemented.

Kay

[Bruno Postle]

On Fri 25-Feb-2011 at 08:33 -0800, kfj wrote:
>
>Yet again, I ask: developers, liaise. Please don't expect of me to do
>it all. I'm not a GUI person, really, and I've spent a great deal of
>effort getting the backend right. Maybe someone else could look at the
>goodies I've stacked up and think of a clever way of enabling people
>to use them?

Sorry, I haven't had time to look into this. I think initially the
python interface would be useful even if it presents as a menu of
functions that don't take any parameters. i.e. it can be merged
more-or-less in the state it is in.

>Then there is an issue I'd like to have considered by the group: the
>hsi python module could be considered a library, since it can do hugin-
>ish stuff outside hugin, probably linking in a few shared libraries,
>but if it was linked statically, not even that. A lot of hugin's code
>is GPLed. Is there a problem with that?

Please use 'GPL version 2 or later', this makes it easier to ship
with Hugin. Are you concerned about how this effects the license of
potential 3rd party plugins?

>And one more thing: I'd like to see a discussion about a perspective
>for merging the python_scripting branch back into the mainstream.
>Thomas and I have made a good effort to parametrize everything in
>cmake and make the scripting capability a compile-time option. The
>intersections with other code are minimal and well #ifdeffed.

I would like to see the current Hugin 'trunk' move to a 2011.0.0
release branch as soon as possible. So the python interface should
then be merged so that it goes into the next release after that.

--
Bruno

[kfj]

On 27 Feb., 00:05, Bruno Postle <br...@postle.net> wrote:

> Sorry, I haven't had time to look into this.

You are missing out. I had hoped that you'd be more interested in my
project, being of the scripting kind yourself. Let me point out that
SWIG, which I use to generate the Python interface, can generate
interfaces for other languages as well (something like two dozen),
among them perl. I had suspected you'd start playing with the SWIG
code to let it make a perl interface - I made a feeble attempt to do
so, but knowing nothing of perl I gave up at the first hurdle...

> I think initially the
> python interface would be useful even if it presents as a menu of
> functions that don't take any parameters

apart from the currently active panorama, that is. But it's a severe
limitation. For example now I'm working on a plugin that works on
image pairs. I either have to hardcode the image numbers into the
script, write GUI code myself to let a window pop up to ask for them,
or require the user to make the desired images 'active' and
'deactivate' the others. This is not nice. The clean way would be for
the user to highlight the images in question in the image tab and then
call the plugin from the contect menu.

> i.e. it can be merged
> more-or-less in the state it is in.

I think so as well. Just today I thought about how I could modify it
so that all dependencies to the hsi python module are removed from
hugin itself. This would mean a totally neutral python interface, and
the conversion of C++ pointers into python objects would be done by
code outside hugin. This change of design would mean that

- other people would be free to write their own python modules rather
than having to rely on hsi
- hugin would merely be extended by a dependency on python (maybe not
even a run-time dependency, the way I think it can be done is only
require python if the plugin interface is actually used) and not be
dependent on hsi

I feel that this might make the introduction into the mainstream even
less of a concern. I'll look into the matter and report back, with a
bit of luck the changes should be small (couple of days)

> >Then there is an issue I'd like to have considered by the group: the
> >hsi python module could be considered a library, since it can do hugin-
> >ish stuff outside hugin, probably linking in a few shared libraries,
> >but if it was linked statically, not even that. A lot of hugin's code
> >is GPLed. Is there a problem with that?
>
> Please use 'GPL version 2 or later', this makes it easier to ship
> with Hugin.  Are you concerned about how this effects the license of
> potential 3rd party plugins?

What I mean is this: hsi, the python module that is generated by SWIG
and contains the hugin functionality, can be imported by any python
script that cares to do so. It's like loading a shared library from an
executable program, in fact, technically, this is just what happens.
But the code that finds it way into the script via this route is
GPLed. Therefore, if I understand things rightly, the module would
have to make itself known as GPL software, prohibit closed-source
users to import it and point a way to it's sources, plus whatever
other requirements the GPL imposes. This is why libraries are often
put under LGPL or a similar less restrictive license, so that anyone
can use them with their code, even if they're commercial. I don't want
to infringe upon the rights of any of the hugin contributors by
opening up a route of access to their code that goes against their
licensing of it. This is why I want the issue discussed. I think the
ideal solution would be if the developers who have contributed code
that is exposed via hsi might modify their licensing to allow use of
their code via hsi under a less restrictive license, but if this is
not feasible I want to be certain that all requirements are met to
satisfy the contributors' current licensing under GPL.

> >And one more thing: I'd like to see a discussion about a perspective
> >for merging the python_scripting branch back into the mainstream.
> >Thomas and I have made a good effort to parametrize everything in
> >cmake and make the scripting capability a compile-time option. The
> >intersections with other code are minimal and well #ifdeffed.
>
> I would like to see the current Hugin 'trunk' move to a 2011.0.0
> release branch as soon as possible.  So the python interface should
> then be merged so that it goes into the next release after that.

Sadly, the Python scripting project is slightly stalled currently.
This is due to the Mac side of things - Harry couldn't get it to run,
went away on a holiday and noone else took over. The Linux and Windows
side seems fine and ready to be merged. Harry said to go ahead,
though, never mind the Mac problems. So I hope that maybe we'll soon
have hpi in 'bleeding edge' mainstream and that it can maybe be part
of the next release.

Kay

[kfj]

On 27 Feb., 09:25, kfj <_...@yahoo.com> wrote:

> Just today I thought about how I could modify it
> so that all dependencies to the hsi python module are removed from
> hugin itself. This would mean a totally neutral python interface, and
> the conversion of C++ pointers into python objects would be done by

> code outside hugin. This change of design would mean that...

hmmm... I'll eat my words here and state that having looked into the
matter, the current implementation is the best way. So I won't change
the hpi implementation - and, after all, it does what it's supposed to
do.

I did something else today: in a clean, fresh clone I merged the
python_scripting branch back into the trunk. There were minor
conflicts in three files which were trivial to sort out, and a bit of
code had to be changed in the interface because some headers had moved
or disappeared. No big deal at all. Afterwards I was rewarded with a
Python enabled version of bleedig edge. This is nice, it runs much
more smoothly than whatever was the base for the python_scripting
branch. One thing that puzzled me, though, was that I could only
compile with either BUILD_HSI=ON or =OFF and not compile the other
version later by changing the flag; it would just maintain everything
was built already and not reflect the change of the flag. To be sure
the compile switch worked I checked each setting on a separate clone,
and both versions performed as expected. I hope the python_scripting
branch can be merged back soon before the divergence becomes greater.
The compile switch off allows creation of non-hsi hugin as before, and
with it on, the resulting compile is on the same patch level as trunk.
Sounds like a win-win situation to me ;-)

Kay

[Bruno Postle]

On Sun 27-Feb-2011 at 00:25 -0800, kfj wrote:
>
> You are missing out. I had hoped that you'd be more interested in my
> project, being of the scripting kind yourself.

I think it going to be very useful and want to play with it (and even
learn some python), but am very limited with time at the moment.

> Let me point out that SWIG, which I use to generate the Python
> interface, can generate interfaces for other languages as well
> (something like two dozen), among them perl. I had suspected you'd

> start playing with the SWIG code to let it make a perl interface.

Actually I think python is the right language to be using here,
since Hugin needs to work on all platforms I expect that the Windows
installer will include a pythin interpreter.

>> Please use 'GPL version 2 or later', this makes it easier to ship
>> with Hugin.  Are you concerned about how this effects the license of
>> potential 3rd party plugins?
>
>What I mean is this: hsi, the python module that is generated by SWIG
>and contains the hugin functionality, can be imported by any python
>script that cares to do so. It's like loading a shared library from an
>executable program, in fact, technically, this is just what happens.
>But the code that finds it way into the script via this route is
>GPLed. Therefore, if I understand things rightly, the module would
>have to make itself known as GPL software, prohibit closed-source
>users to import it and point a way to it's sources, plus whatever
>other requirements the GPL imposes.

We would want people to write their own scripts and not care about
this stuff so long as they didn't distribute them.

Hugin is GPL, and changing this (other than to version 3) isn't ever
going to be practical given the number of contributors. I don't
think having the plugin interface code as LGPL would make any
difference to anyone writing plugins.

>Sadly, the Python scripting project is slightly stalled currently.
>This is due to the Mac side of things - Harry couldn't get it to run,
>went away on a holiday and noone else took over. The Linux and Windows
>side seems fine and ready to be merged. Harry said to go ahead,
>though, never mind the Mac problems. So I hope that maybe we'll soon
>have hpi in 'bleeding edge' mainstream and that it can maybe be part
>of the next release.

Now that 2011.0.0 has branched, this can happen.

--
Bruno

[kfj]

On 27 Feb., 23:00, Bruno Postle <br...@postle.net> wrote:

> >What I mean is this: hsi, the python module that is generated by SWIG
> >and contains the hugin functionality, can be imported by any python
> >script that cares to do so. It's like loading a shared library from an
> >executable program, in fact, technically, this is just what happens.
> >But the code that finds it way into the script via this route is
> >GPLed. Therefore, if I understand things rightly, the module would
> >have to make itself known as GPL software, prohibit closed-source
> >users to import it and point a way to it's sources, plus whatever
> >other requirements the GPL imposes.
>
> We would want people to write their own scripts and not care about
> this stuff so long as they didn't distribute them.

I don't quite follow your train of thought here. What do you mean by
"so long as they didn't distribute them"? Certainly there would be no
problem distributing the scripts and plugins themselves, since they
only import (use) hsi, but don't contain it. The hsi module would only
be available legally when packaged with hugin binaries (if we decide
to distribute it with hugin) or self-compiled, or from third parties
who honour the GPL. There can't be any problem publishing scripts that
merely use GPLed software.

> Hugin is GPL, and changing this (other than to version 3) isn't ever
> going to be practical given the number of contributors.  I don't
> think having the plugin interface code as LGPL would make any
> difference to anyone writing plugins.

I take your point. This means that the only channel to obtain the hsi
module will be from sources that acknowledge and honour the GPL
licensing of the module - like if it were distributed along with
hugin. I think that's probably fair enough and shouldn't be too much
of an obstacle to aspiring hsi users. The module itself doesn't do any
i/o though and can't communicate it's license status. Is that okay
with the GPL? Does there have to be some mechanism to display the
license or is it enough to have a LICENSE file with the distribution?

> > ...Harry said to go ahead,

> >though, never mind the Mac problems. So I hope that maybe we'll soon
> >have hpi in 'bleeding edge' mainstream and that it can maybe be part
> >of the next release.
>
> Now that 2011.0.0 has branched, this can happen.

Excellent. You may have seen my second posting where I described my
experience with merging the branch back. It seems painless, but I only
tested it on Linux, so there may be obstacles I'm not aware of. Would
it be useful if I did the merge again at some convenient point in time
and uploaded the patch? After all, I've done it once and I know the
interfece best.

Kay

[Bruno Postle]

On Mon 28-Feb-2011 at 01:09 -0800, kfj wrote:
>On 27 Feb., 23:00, Bruno Postle <br...@postle.net> wrote:
>
>> >What I mean is this: hsi, the python module that is generated by SWIG
>> >and contains the hugin functionality, can be imported by any python
>> >script that cares to do so. It's like loading a shared library from an
>> >executable program, in fact, technically, this is just what happens.
>> >But the code that finds it way into the script via this route is
>> >GPLed. Therefore, if I understand things rightly, the module would
>> >have to make itself known as GPL software, prohibit closed-source
>> >users to import it and point a way to it's sources, plus whatever
>> >other requirements the GPL imposes.
>>
>> We would want people to write their own scripts and not care about
>> this stuff so long as they didn't distribute them.
>
>I don't quite follow your train of thought here. What do you mean by
>"so long as they didn't distribute them"?

Oops, I was responding to the idea that the plugin interface would
enforce the GPL in plugins programatically, but maybe that wasn't
what you were saying.

Any plugins that were distributed with Hugin would need to be GPL
too, or some more liberal license.

> The module itself doesn't do any i/o though and can't communicate
> it's license status. Is that okay with the GPL? Does there have to
> be some mechanism to display the license or is it enough to have a
> LICENSE file with the distribution?

It isn't necessary to display the license in the GUI, Hugin does
this but it is more of an advocacy/education thing.

> Excellent. You may have seen my second posting where I described
> my experience with merging the branch back. It seems painless, but
> I only tested it on Linux, so there may be obstacles I'm not aware
> of. Would it be useful if I did the merge again at some convenient
> point in time and uploaded the patch?

If you are working with HG, you should be able to just pull updates
from the 'default' branch and never worry that your branch is
diverging.

The main worry we have about merging new features into the 'trunk'
is that in the past we have merged unfinished stuff that then held
up a release for months - Either the new feature needs to be
complete, or it needs to be unobtrusive.

--
Bruno

[kfj]

On 28 Feb., 22:54, Bruno Postle <br...@postle.net> wrote:

> If you are working with HG, you should be able to just pull updates
> from the 'default' branch and never worry that your branch is
> diverging.

I do worry about 'my' branch diverging. There are some bugs in the
python_scripting branch that have been in it since it was started by
Pablo. I have so far made an effort to only do hg exports from my
local copy, basing my changesets on a pull from the SF repo with my
newest changes committed to that. Maybe I'm suffering from a
misconception here. Can I just merge the default branch into the
python_scripting branch to bring it up-to-date with the default
branch? I'd then have to do an hg bundle to export the changeset
resulting from two parents, but the python_scripting branch would be
up-to-date again. I wanted to keep it simple, but maybe I did the
wrong thing and it's my fault having let the branches diverge so far.
Please excuse my ignorance in these matters, I still haven't totally
gotten my head round mercurial.

Kay

[kfj]

Hi all!

To keep the python_scripting branch in sync with the default branch, I
have merged the default branch into the python_scripting branch,
taking in all changes since the python_scripting branch forked off. I
had to change a very small amount of code to reflect that some headers
have disappered or moved in the default branch, but it was all rather
unproblematic.

Once I had the merge done and run a compile cycle and a brief test of
the resulting binary, I comitted and produced a mercurial bundle based
on the parent changesets of my new status quo by executing:

hg bundle -t none -r 5080 --base 4982 --base 5078 bundle5080

deliberately uncompressed, based on the two parents, reflecting my tip
revision 5080 and named aptly.
I hope I did everything right, to verify I made another clone and
executed (in it's root directory, to where I copied the bundle)

hg unbundle bundle5080

after that, when I did the usual

hg update -C python_scripting

the hugin_script_interface contained the new file versions, so I'm
quite confident the bundle does what I want it to do. I uploaded the
bundle to my bazaar repo:

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/bundle5080

I hope it finds it's way via the usual route, even though everyone's
busy with the current release. And, having synchronized
python_scripting with the default branch, I hope to make it even
easier to merge python_scripting back into the default branch, should
this be desired.

Kay

[kfj]

Hi all!

Noone took notice of my previous post - I suppose very few people are
looking at this thread anyway and Thomas seems to be offline. Maybe
someone else can pick up my bundle and put it into the SF repo? For
me, the Python interface works, and I've hardly modified it in the
last weeks even though I'm using it on a daily basis. It seems like
the project is slowly fading into oblivion and I'm it's only user. I
had hoped that somehow the Mac problems could be sorted out, but noone
seems bothered enough or capable to figure out why Harry can't get it
to run on the Mac. I'd like to go ahead now. I could do with some
help. It would be nice if the public could gain easier access to it
than having to compile it themselves. Anybody out there?

Kay

[Gerry Patterson]

Kay,

I haven't been following this thread but I would like to ensure this doesn't fade away as I see real benefit in an external interface such as this.

Can you email me offline to bring me up to speed and I'll work with you to get it into the repo.

Best regards,

Gerry

[T. Modes]

On 8 Mrz., 10:41, kfj <_...@yahoo.com> wrote:
> Hi all!
>
> Noone took notice of my previous post - I suppose very few people are
> looking at this thread anyway and Thomas seems to be offline.

And noone looks into the repository. The bundle was pushed some days
ago. But it seems to be easier to write mails.

Thomas

[Bruno Postle]

On Tue 08-Mar-2011 at 01:41 -0800, kfj wrote:
>
> For me, the Python interface works, and I've hardly modified it in
> the last weeks even though I'm using it on a daily basis. It seems
> like the project is slowly fading into oblivion and I'm it's only
> user.

I really would like to use it and see what I can do, but I'm aware
that there are some deadlines approaching and that these have
priority. I suspect that most 'development time' at the moment is
working towards getting the 2011.0.0 release out.

--
Bruno

[kfj]

On 9 Mrz., 19:37, Bruno Postle <br...@postle.net> wrote:

> I really would like to use it and see what I can do, but I'm aware
> that there are some deadlines approaching and that these have
> priority.  I suspect that most 'development time' at the moment is
> working towards getting the 2011.0.0 release out.

If you're on one of the supported platforms, all you need is SWIG and
Python and compile the python scripting branch. It shouldn't be hard.
But if you just want a technical outline, have a look at the file
README.hsi - either from the branch or from my bazaar repo at

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/README.hsi

This may be more instructive than building it, because so far there is
hardly any software around using it.

Kay

[kfj]

Yes, sorry, Thomas. I didn't notice until later. Until now you'd
always dropped a brief line to say everything was okay and you did it
(if it was you after all). I apologize. I should have checked. Don't
be angry.

Kay

[kfj]

On 9 Mrz., 19:37, Bruno Postle <br...@postle.net> wrote:

> On Tue 08-Mar-2011 at 01:41 -0800, kfj wrote:

> > For me, the Python interface works, and I've hardly modified it in
> > the last weeks even though I'm using it on a daily basis.
>

> I really would like to use it and see what I can do, but I'm aware
> that there are some deadlines approaching and that these have
> priority.  I suspect that most 'development time' at the moment is
> working towards getting the 2011.0.0 release out.

Well, Bruno, I suppose you're not the only one busier with something
else. So, just to remind every one, nothing much is happening with the
Python interface. Let me give you a brief status update on the current
issues:

- still nothing at all on Mac OS. Would a Mac programmer please come
forward and help compile the Python module?

- another issue that's been discussed but not solved is how Python
plugins could be given GUI access. Using wxPython from plugins works
on Linux with Python <= 2.7 but not Python 3.X, and not at all on
Windows, quite probably because wxWidgets is linked statically there.

On the positive side, the Python scripting interface (hsi) seems to be
running just fine on Linux and Windows. This means that Python
programs can use pretty much all of hugin's backend functionality.
I've writtten a very long involved Python program doing just that.
It's great. And it can be called from hugin, it's only the GUI sharing
that isn't yet happening.

The GUI issue affects the hugin plugin interface (hpi). Nothing is
wrong with the hugin scripting interface (hsi) apart from the missing
Mac port. I wonder if it might not help progress on the Python front
if binaries of the Python module were offered for download for Linux
and Windows? I find the Python interface immensely useful, as it
allows me to access most of hugin's functionality from Python. Being
able to call Python plugins from hugin is a nice-to-have extra and
mostly works, and GUI access from Python is another nice-to-have
thing, but waiting for it to materialize before distributing the
Python module seems silly.

If interested parties could get easy access to the Python module, the
body of hsi code might grow, at the same time uncovering issues that
have not surfaced yet. On Linux, getting the module is reasonably
straightforward, but requires compilation of a specific hugin branch.
On Windows, this is probably more involved. Offering the binaries
would lower the threshold. Is this feasible? Would it be necessary to
offer a complete 'hugin with Python capability' bundle or would it be
enough to merge the python_scripting branch into default and make
BUILD_HSI = ON the default, so hugin and collateral software would be
the same throughout - would the resulting binaries run on systems
without Python? I've written hpi (the hugin plugin interface) so that
embedded Python is only initialized if the interface is used. I'm not
sure what happens on a system without Python, or with the wrong
version, but when I wrote it I hoped that the code would simply
produce an error if Python wasn't available, returning an error code.
Has anyone tried? This would be easy on Windows, where Python is
optional. The test would be to run hugin built from the
python_scripting branch with Python uninstalled and see what happens
when calling a plugin. If it merely says something like 'script return
-X' this would mean it' safe. Maybe the presence of Python could be
detected, and if it's missing the plugin call could be grayed out? I'd
welcome your comments.

Kay

Kay

[Roger Goodman]

Kay,
I have Windows XP, without Python installed, and would be willing
to test what happens, but I would need a compiled Windows binary to get
started. I don't have a compiler on my system, so I won't be building
hugin from scratch.....
Roger

[kfj]

On 20 Mrz., 12:22, Roger Goodman <rlgood...@cox.net> wrote:

>      I have Windows XP, without Python installed, and would be willing
> to test what happens, but I would need a compiled Windows binary to get
> started.  I don't have a compiler on my system, so I won't be building
> hugin from scratch.....

Thank you! I don't have Windows, but Thomas has built the
python_scripting branch successfully on Windows, so maybe he can put
his build online somewhere for you to download and try.

Kay

[Yuval Levy]

Hi Kay,

On March 20, 2011 05:40:02 am kfj wrote:
> you're not the only one busier with something
> else. So, just to remind every one, nothing much is happening with the
> Python interface.

I am one of those guilty with not participating in your effort, although I
find it important and laudable.

The time I am putting into Hugin now goes toward the 2011.0 release, and this
is, in a sense, a contribution to the Python interface, because once 2011.0 is
out the door we can integrate the Python interface into the main codeline and
give it the extra attention it deserves.

I would suggest that you sign up as a Google Summer of Code mentor when Habi
launches the call for mentors; and I hope we can find a student to work on the
Python interface with your guidance.

> - still nothing at all on Mac OS. Would a Mac programmer please come
> forward and help compile the Python module?

My understanding is that the Python module must be activated at build time.
As long as it is not activated, the python_scripting branch builds and works
on Mac OSX too, just without the Python functionality. Is this correct?

If yes, this should not hinder you or anybody else from making progress on
Python scripting and integrating it in the main codeline.

Sooner or later, somebody on the Mac OSX side of things will feel an itch to
scratch. You can ignore it for now.

> - another issue that's been discussed but not solved is how Python
> plugins could be given GUI access. Using wxPython from plugins works
> on Linux with Python <= 2.7 but not Python 3.X, and not at all on
> Windows, quite probably because wxWidgets is linked statically there.

I have skimmed over the discussion and I like both suggested solutions.

I am afraid that for now we can't count on the combination of wxPython and
Python 3.0.

http://groups.google.com/group/wxpython-users/t/59d9f9b5e3adf513

http://docs.python.org/dev/howto/cporting.html

Python 2.7 will be supported for years to come, but if I recalled correctly
from my skimming of all the back and forth, there was an issue with using
Python 2.7?

I like both ideas expressed: the MathMap-like interface, simple, pragmatic,
unified; and the completeness of a wxPython solution. Both have advantages
and disadvantages, and both raise questions.

MathMap-like: some plug-in may need additional user-input / interaction. How
would that happen? wxPython linked from the plugin, external and oblivious to
Hugin?

What I like about wxPython is that eventually we can move more and more parts
of the Hugin interface from C++ to Python, making it more accessible for users
to customize/improve/contribute.

> On the positive side, the Python scripting interface (hsi) seems to be
> running just fine on Linux and Windows.

I am sorry I have not had time to test it but it is positive news indeed.

> it's only the GUI sharing that isn't yet happening.

how critical is GUI sharing?

> I wonder if it might not help progress on the Python front
> if binaries of the Python module were offered for download for Linux
> and Windows?

Sure it would. Once the 2011.0 release is out of the door and the
python_scripting branch is merged, the Hugin PPA's nightly will offer binaries
for download, at least for Ubuntu. Currently the Hugin PPA nightlies are
broken (for another, trivial but time consuming reason); and a change is
discussed that would provide nightlies not only of the main codeline, but also
of all development codelines. Too late for python_scripting, but will
definitely help monitoring progress and advanced testing for the GSoC2011
branches. At least on Ubuntu (and it would probably be only one series, not
all supported series).

Sorry if we are not following you as fast as you would like.

> I find the Python interface immensely useful, as it
> allows me to access most of hugin's functionality from Python. Being
> able to call Python plugins from hugin is a nice-to-have extra and
> mostly works, and GUI access from Python is another nice-to-have
> thing, but waiting for it to materialize before distributing the
> Python module seems silly.

Agree. Let's integrate the Python interface as-is asap after 2011.0 and look
at the nice-to-have extras such as the ability to call Python plugins from
Hugin, and GUI access from Python, later on.

> If interested parties could get easy access to the Python module, the
> body of hsi code might grow, at the same time uncovering issues that
> have not surfaced yet.

Yes, the faster we add this to the main release line, the sooner we'll find
and clean rough edges and attract additional contributors.

> On Linux, getting the module is reasonably
> straightforward, but requires compilation of a specific hugin branch.

The specific branch requirement will fall very soon after 2011.0 is out the
door.

> On Windows, this is probably more involved. Offering the binaries
> would lower the threshold. Is this feasible? Would it be necessary to
> offer a complete 'hugin with Python capability' bundle or would it be
> enough to merge the python_scripting branch into default and make
> BUILD_HSI = ON the default, so hugin and collateral software would be
> the same throughout - would the resulting binaries run on systems
> without Python? I've written hpi (the hugin plugin interface) so that
> embedded Python is only initialized if the interface is used. I'm not
> sure what happens on a system without Python, or with the wrong
> version, but when I wrote it I hoped that the code would simply
> produce an error if Python wasn't available, returning an error code.
> Has anyone tried? This would be easy on Windows, where Python is
> optional. The test would be to run hugin built from the
> python_scripting branch with Python uninstalled and see what happens
> when calling a plugin. If it merely says something like 'script return
> -X' this would mean it' safe. Maybe the presence of Python could be
> detected, and if it's missing the plugin call could be grayed out? I'd
> welcome your comments.

Python is Free software so there is no obstacle to distribute Python with the
Hugin installer. I would not bother too much about detecting, making
exceptions, or other things to make Python "optional". The switch is in the
CMake build, and when built with BUILD_HSI = ON Python becomes a mandated
dependency of Hugin.

This leaves builders and distributors on platforms without package manager
(Windows and OSX) two choices: Build a version of Hugin with HSI and add
Python to the installer/bundle; or build a version of Hugin without HSI and
don't add Python to the mix.

Thank you for your contribution and your patience, Kay!
Yuv

[Bruno Postle]

On Sun 20-Mar-2011 at 02:40 -0700, kfj wrote:
>
>- another issue that's been discussed but not solved is how Python
>plugins could be given GUI access. Using wxPython from plugins works
>on Linux with Python <= 2.7 but not Python 3.X, and not at all on
>Windows, quite probably because wxWidgets is linked statically there.

I'm not sure that the Windows Hugin package absolutely has to be
statically linked, this may just be the most convenient way to do it
up until now.

>On the positive side, the Python scripting interface (hsi) seems to be
>running just fine on Linux and Windows. This means that Python
>programs can use pretty much all of hugin's backend functionality.
>I've writtten a very long involved Python program doing just that.
>It's great. And it can be called from hugin, it's only the GUI sharing
>that isn't yet happening.

As I understand, currently plugins can only be run without any
user configuration, since adding a GUI is appearing problematic.

An intermediate solution would be to accept that, for the time
being there isn't going to be any GUI configuration and add the
plugins to Hugin in multiple places.

e.g. plugins that operate on the project as a whole can go in the
the main menu. Plugins that operate on a selection of photos
can go in a pull-down menu on the Images tab, etc...

Would this restrict the functionality too much?

--
Bruno

[kfj]

On 20 Mrz., 18:56, Yuval Levy <goo...@levy.ch> wrote:

> I would suggest that you sign up as a Google Summer of Code mentor when Habi
> launches the call for mentors; and I hope we can find a student to work on the
> Python interface with your guidance.

I understand that this would be helpful, but I will not be available
so much during the summer. This is why I called it my 'winter of
code'. In summer I spend more time in the italian Alps trekking and
doing photography. I have also pushed aside all other interests during
this winter in favour of the hugin Python interface, and I definitely
want to do some GIS programming during the summer.

I have made an effort to liberally comment everything and hope my code
is clear and concise, so I hope that my absence won't be a problem.
When the gsoc proposals were discussed, Thomas commented that as far
as the Python interface is concerned we have the basic functionality
up and running - as I understood it he felt it wasn't necessary to
propose it for gsoc, because it's there already. I haven't looked into
the proposals later on to see what actually was proposed in the end.

The question is, do we want to put much more effort in? I've tried to
get it all done with minimal overhead - mostly wrapped the headers
instead of hand-writing the interface, kept the call interface so
general that it can handle any parameter constellation - and in
retrospect I think this course of action was wise. It can stay as it
is without much modification (the parameter passing and GUI access
remaining an open issue but not a show-stopper) until someone finds a
very good reason to change it fundamentally.

> My understanding is that the Python module must be activated at build time.  
> As long as it is not activated, the python_scripting branch builds and works
> on Mac OSX too, just without the Python functionality.  Is this correct?

The way I've set it up, the python_scripting branch should compile to
exactly the same result if the BUILD_HSI switch is off at compile-
time. I've last merged default into python_scripting a couple of weeks
ago and I can do it again before it's merged into default so the
latter merge becomes trivial.

On top of that I've hopes that it may be possible to compile with
BUILD_HSI=ON and use the resulting binary even if Python isn't
available; the interface works so that the first actual call to run a
plugin activates the interface, so if the interface has dangling
references, they would do no harm - if unused, noone would notice, and
if used, the activation should fail gracefully. But I'm not sure. In a
statically linked system, having dangling references may not be
possible. That's why I asked for a Windows binary to be put online, so
that Roger, who has offered to do so, can try what happens on a system
without Python.

> If yes, this should not hinder you or anybody else from making progress on
> Python scripting and integrating it in the main codeline.

I've made an effort to make it as unobtrusive as possible. I'm
confident noone will notice it's there unless they want to use it, but
I can only test on Linux.

> Sooner or later, somebody on the Mac OSX side of things will feel an itch to
> scratch.  You can ignore it for now.

Indeed. I hope that once plugins and standalone hsi aplications start
appearing the Mac OS faction will become envious and start scratching
the itch.

> > - another issue that's been discussed but not solved is how Python
> > plugins could be given GUI access. Using wxPython from plugins works
> > on Linux with Python <= 2.7 but not Python 3.X, and not at all on
> > Windows, quite probably because wxWidgets is linked statically there.
>
> I have skimmed over the discussion and I like both suggested solutions.
>
> I am afraid that for now we can't count on the combination of wxPython and
> Python 3.0.

Even though there are some systems where Python 3.X is already the
standard, I think most systems still use 2.X. I'd say the main reason
is the incompatible change to the module import mechanism which makes
it impossible for 3.X code to import 2.X modules. There is a huge body
of code out there which runs on 2.X, and I suppose quite a few of
these modules have been made by people just like us who just about
managed to invest the resources to do it and have moved on since - to
go 3.X, someone has to touch the code again and get it to work on 3.X,
and the older the code and the more involved, the more difficulties
arise. This extends to very central and highly useful modules.

On the other hand, parallel installations aren't usually a problem, so
if need be, systems with 3.X might install 2.X as well and use that to
run plugins with GUI. The interface itself, thanks to Thomas' effort,
is 3.X able.

> I like both ideas expressed:  the MathMap-like interface, simple, pragmatic,
> unified; and the completeness of a wxPython solution.  Both have advantages
> and disadvantages, and both raise questions.

Bruno pointed out that it would be wise to do as much of the GUI stuff
as possible in Python, and I agree. If there is a problem using
wxPython, maybe we could think of an object written in C++ that uses
wxWidgets C++ code to offer the parameter acquisition. We have a swig
interface already, so if we'd pass that object to the Python side, it
could use it to do the needful. Just an idea. But ultimately,
wxWidgets would be the best. Bruno has assured me that it might be
made part of the packet, and for simple tasks even inexperienced users
could get away with a bit of copying and pasting from a good example.
The availability issue remains.

> MathMap-like: some plug-in may need additional user-input / interaction.  How
> would that happen? wxPython linked from the plugin, external and oblivious to
> Hugin?

The design would be, I suppose, quite expensive. If someone came forth
willing to do it, it might beome a cherished asset, but it would
require a good deal of effort.

> What I like about wxPython is that eventually we can move more and more parts
> of the Hugin interface from C++ to Python, making it more accessible for users
> to customize/improve/contribute.

I agree. My dream scenario, actually. Make hugin a Python application
with all the power that comes from an interpreted language, and have a
fast C++ backend for number-crunching. And Bruno has emitted signals
that I might not be the only one dreaming along these lines.

> how critical is GUI sharing?

GUI sharing in itself is actually not critical. But what I feel is
critical is parametrization of the plugins. There are different
approaches possible, and they aren't mutually exclusive, but a
standard way would be best, and this should be via a GUI. Where that
is impossible, configuration files can be used.

> > I wonder if it might not help progress on the Python front
> > if binaries of the Python module were offered for download for Linux
> > and Windows?
>
> Sure it would.  Once the 2011.0 release is out of the door and the
> python_scripting branch is merged, the Hugin PPA's nightly will offer binaries
> for download, at least for Ubuntu.  Currently the Hugin PPA nightlies are
> broken (for another, trivial but time consuming reason); and a change is
> discussed that would provide nightlies not only of the main codeline, but also
> of all development codelines.  Too late for python_scripting, but will
> definitely help monitoring progress and advanced testing for the GSoC2011
> branches.  At least on Ubuntu (and it would probably be only one series, not
> all supported series).

I was hoping for the PPAs. I have a suspicion that Linux users might
be more interested in hsi/hpi than others anyway, since Python is
already on their systems and they may be more script-inclined than
others.

> Sorry if we are not following you as fast as you would like.

I was just trying to get everything afloat as best as I can before I
become less available during the summer.

> > I find the Python interface immensely useful, as it
> > allows me to access most of hugin's functionality from Python. Being
> > able to call Python plugins from hugin is a nice-to-have extra and
> > mostly works, and GUI access from Python is another nice-to-have
> > thing, but waiting for it to materialize before distributing the
> > Python module seems silly.
>
> Agree.  Let's integrate the Python interface as-is asap after 2011.0 and look
> at the nice-to-have extras such as the ability to call Python plugins from
> Hugin, and GUI access from Python, later on.

Seems like a good plan. When is after 2011.0? I'll be here for another
two weeks or so, after that on and off. I'll try to put everything in
order before I'm off - go over the documentation, publish my large
Python program, merge default in once more.

> The specific branch requirement will fall very soon after 2011.0 is
out the
> door.

Great.

> Python is Free software so there is no obstacle to distribute Python with the
> Hugin installer.  I would not bother too much about detecting, making
> exceptions, or other things to make Python "optional".  The switch is in the
> CMake build, and when built with BUILD_HSI = ON Python becomes a mandated
> dependency of Hugin.

You have to detect what's there. On Linux systems, there is one
version that's part of the system, and you can't just simply install
something else unless you know what you're doing and don't produce
conflicts with the system status quo. I lack the experience to tell
what would need to be done in which environment, and what is least
obtrusive and most straightforward. I hope my code is defensive enough
to play well with whatever method is chosen utimately.

Kay

[kfj]

On 21 Mrz., 00:40, Bruno Postle <br...@postle.net> wrote:
>
> >- another issue that's been discussed but not solved is how Python
> >plugins could be given GUI access. Using wxPython from plugins works
> >on Linux with Python <= 2.7 but not Python 3.X, and not at all on
> >Windows, quite probably because wxWidgets is linked statically there.
>
> I'm not sure that the Windows Hugin package absolutely has to be
> statically linked, this may just be the most convenient way to do it
> up until now.

When I started looking into hugin's code last autumn, I was still
running a Windows system. I was doing my C/C++ programming using msys/
minGW, and I managed to compile libpano with it, but failed with
hugin, because I tried to follow the linl-statically-on-Windows
paradigm. It was frustrating. All the libraries were there to be
dynamically linked, I had a gnu compiler, but I got stuck trying to
compile stuff like openEXR on minGW. Eventually I gave up on it and
migrated to Linux for good, to start with a big sigh of relief and no
desire ever to go back. But if someone with more knowledge of hugin's
code base and of cmake came and ported hugin to minGW using the same
dynamic linking as on Linux, we might gain immensely:

- We'd be using the same compiler on all platforms
- We'd be rid of MS's closed-source compiler with all it's
idiosyncracies
- We could use the readily available DLLs on Windows

Since I've not followed it through when still on windows, I may not
see the full picture, but there is promise along these lines. But I am
not doing it.

> >On the positive side, the Python scripting interface (hsi) seems to be
> >running just fine on Linux and Windows. This means that Python
> >programs can use pretty much all of hugin's backend functionality.
> >I've writtten a very long involved Python program doing just that.
> >It's great. And it can be called from hugin, it's only the GUI sharing
> >that isn't yet happening.
>
> As I understand, currently plugins can only be run without any
> user configuration, since adding a GUI is appearing problematic.

I'm trying to implement a mechanism using configuration files for
platforms where using wxPython is not an option. This looks feasible
and may be a bridge technology.

> An intermediate solution would be to accept that, for the time
> being there isn't going to be any GUI configuration and add the
> plugins to Hugin in multiple places.

> e.g. plugins that operate on the project as a whole can go in the
> the main menu.  Plugins that operate on a selection of photos
> can go in a pull-down menu on the Images tab, etc...

I think we aren't clear yet how to integrate the plugins into the GUI.
So far, you can choose a Python file to be executed as a plugin - the
individual plugins aren't listed as menu items. If tighter integration
is desired, so that eventually the distinction of calling a C++
routine and calling a Python plugin becomes invisible, other
mechanisms than the current 'call a Python script' have to be
established. I have worked with what I was offered as best as I could.
I don't really feel inclined to learn wxWidgets on top of everything
else to write code for the hugin side of things. I hope to find people
from the hugin developer team to come up with propositions and
prototypes (that's why this thread is called 'developers liaise') -
and I'm happy to play and modify the Python interface to be accessed
in different ways. What I don't want to do is design and write the GUI
side of the plugin interface. I'm more the backend type.

> Would this restrict the functionality too much?

I always thought that having different types of plugins, called from
different contexts, would be a good idea, and I thought that a context
menu call would be the most natural way of achieving this. On the
Python side, the call signature can be analyzed to determine what
parameters have been passed and make sure that the plugin in question
is compatible with the parameters at hand. I hope to see experimental
branches forking off demonstrating various ways of dealing with the
issue, so we can play and learn what is best.

Kay

[David Haberthür]

Hey Kay

> I would suggest that you sign up as a Google Summer of Code mentor when Habi
> launches the call for mentors; and I hope we can find a student to work on the
> Python interface with your guidance.

I just did: <https://groups.google.com/d/topic/hugin-ptx/qkDQMOMfIXI/discussion>.
The call for mentors is online and can be acted upon.

>> - still nothing at all on Mac OS. Would a Mac programmer please come
>> forward and help compile the Python module?

I am not a programmer, but an avid user. And I have to say that
currently I don't feel the need to interface with hugin through
Python. From my perspective I am agreeing with Yuv. Ignore "us" for
the moment, of course only if noone else speaks up.

The replies in this thread show that you're doing a very welcome job.
Take that as an incentive and go on with Linux and Windows.

Habi

[David Haberthür]

Hey Kay

On Mon, Mar 21, 2011 at 10:12, kfj <_k...@yahoo.com> wrote:
> On 20 Mrz., 18:56, Yuval Levy <goo...@levy.ch> wrote:
>
>> I would suggest that you sign up as a Google Summer of Code mentor when Habi
>> launches the call for mentors; and I hope we can find a student to work on the
>> Python interface with your guidance.
>
> I understand that this would be helpful, but I will not be available
> so much during the summer. This is why I called it my 'winter of
> code'. In summer I spend more time in the italian Alps trekking and
> doing photography. I have also pushed aside all other interests during
> this winter in favour of the hugin Python interface, and I definitely
> want to do some GIS programming during the summer.

Sorry, I have not read this far in the thread before my reply. Sounds
like a great and interesting summer :) We'll see if a student
nonetheless wants to pick up your pieces (or more like grab the thing
afloat :)

Just out of personal curiosity, what GIS are you working on/for (I've
got a friend in the GIS-"scene").

Habi

[kfj]

On 23 Mrz., 11:49, David Haberthür <david.haberth...@gmail.com> wrote:
> Hey Kay

> Sorry, I have not read this far in the thread before my reply. Sounds
> like a great and interesting summer :) We'll see if a student
> nonetheless wants to pick up your pieces (or more like grab the thing
> afloat :)

Grab the thing afloat is hopefully more like it. When I'm online, I'll
gladly help, but I won't be available continuously, so I feel I
wouldn't make a good mentor.

> Just out of personal curiosity, what GIS are you working on/for (I've
> got a friend in the GIS-"scene").

I'm using Quantum GIS (QGIS) - and GRASS. I'm only using it for my
personal pleasure so far. I haven't done so much along these lines
yet, and it's a huge topic to get one's head round. It all started out
when I had collected a good amount of maps for my favourite trekking
area (the Val Grande National Park in Piemonte, Italy) - historic,
recent and satellite imagery, and wondered how I could compare them.
So I needed a tool to get them to a common projection and georeference
them. Next I got a GPS and started putting my own tracks in, then I
got into DEMs and making my own maps. I want to work on the GPS data
and play with them with a bit of statistics to reconstruct some of the
derelict trail system in the area. This is difficult, because the area
is very rugged and often the GPS signal is feeble. Ulimately I want to
upload the data to OSM.

The funny thing is that it's not that different from panography - you
deal with a spherical surface and it's projections into the plane.
Only that those geographers have it down to a tee - to them, of
course. it's not a spherical surface but something much more complex
(looks like an exotic fruit if you exaggerate the elevations). It even
made me think if we couldn't use some of the GIS code (they're using
Python a lot as glue code, shouldn't be too hard) - they've also got
very nice and precise transformations, interpolations and projections,
and good tools to visualize huge muti-layered tiled images with vector
data thrown on top... - all FOSS. Makes me envious at times when for
panoramas all I can do is run FSPViewer under wine in a window 1/2 the
size of my screen because openGLView won't even run on my machine...

Kay

[Yuval Levy]

On March 23, 2011 11:46:21 am kfj wrote:
> When I'm online, I'll
> gladly help, but I won't be available continuously, so I feel I
> wouldn't make a good mentor.

OK, so not a primary mentor. Still, I suggest you join the mentors when Habi
sends out the invitation, so you get to give your two cents on the selection
of the students and on the evaluation of their work. Plus, you'll get a
Google T-Shirt ;-)

I am confident that you'll make an excellent mentor, even if you won't be
available all of the time.

> I'm using Quantum GIS (QGIS)

AFAIK it uses PyQt, the sole GUI framework known to me that already has
support for Python 3. PySide is in the making and is likely to come in
earlier than wxWidgets. But then this would bring about the old debate of Qt
vs. wxWidgets...

Yuv

[Yuval Levy]

On March 21, 2011 05:39:52 am kfj wrote:
> On 21 Mrz., 00:40, Bruno Postle <br...@postle.net> wrote:
> > I'm not sure that the Windows Hugin package absolutely has to be
> > statically linked, this may just be the most convenient way to do it
> > up until now.
>

> if someone with more knowledge of hugin's
> code base and of cmake came and ported hugin to minGW using the same
> dynamic linking as on Linux, we might gain immensely

back in 2006/7 it was DLL-hell. Static linking was not only convenient: IIRC
only magicians with mystical connection were able to get a dynamically linked
Hugin work, and it would be frail on the users system (read: disappearing DLL
and other funny things).

I don't know if with the current crop of Windows O/S things have improved with
regard to the protection of DLL and other installed files. Definitely worth a
try, if somebody out there wants to try.

This was all with MSVC. minGW is another set of problems. There have been a
few people who have tried over the year, this list archives is full of
reports, partial successes and frustrations. It is not known to me that
anybody has succeeded building Hugin with minGW in the past three years. Yes,
it would have great benefit, but somebody must be really determined to get it
done.

Yuv

[kfj]

On 26 Mrz., 03:07, Yuval Levy <goo...@levy.ch> wrote:
> On March 23, 2011 11:46:21 am kfj wrote:
>
> > When I'm online, I'll
> > gladly help, but I won't be available continuously, so I feel I
> > wouldn't make a good mentor.
>
> OK, so not a primary mentor. Still, I suggest you join the mentors when Habi
> sends out the invitation, so you get to give your two cents on the selection
> of the students and on the evaluation of their work.

No. I'm very conscientious. I do not want to commit to anything at the
moment, not even some sort of 'secondary' mentorship, because I'd
still feel responsible and that's precisely what I don't want over the
summer. I'm taking a holiday.

I've been working a fair part of every day for the last three months
for hugin. Part of this was coding - a great part of it coding script
and plugin code, another great part trying to get a discussion going
about how to proceed, which has been very time-consuming, and a third
part where I have made an effort to make the code transparent, comment
it well and write documentation to go with it, so that anyone can pick
it up and figure it out. I want to leave it at that for now and have a
break. My offer is to help if help is needed when I'm about, and
that's it. I feel I have helped already, it's all there in the code,
the comments and the documentation.

> Plus, you'll get a Google T-Shirt ;-)

No, not even then.

> > I'm using Quantum GIS (QGIS)
>
> AFAIK it uses PyQt, the sole GUI framework known to me that already has
> support for Python 3. PySide is in the making and is likely to come in
> earlier than wxWidgets. But then this would bring about the old debate of Qt
> vs. wxWidgets...

What I found more interesting than the GUI side is the use of plugins,
which are used for a lot of stuff. I was musing whether it wouldn't be
possible to use some of their code for hugin. But that's future stuff.
First hsi/hpi has to be established and the interface question solved,
then we can start actually picking interesting bits from the vast
Python module universe to add functionality to hugin which is not
encumbered by DLL hell and doesn't have to be linked to it either.

> back in 2006/7 it was DLL-hell.  Static linking was not only convenient:  IIRC
> only magicians with mystical connection were able to get a dynamically linked
> Hugin work, and it would be frail on the users system (read: disappearing DLL
> and other funny things).

> I don't know if with the current crop of Windows O/S things have improved with
> regard to the protection of DLL and other installed files. Definitely worth a
> try, if somebody out there wants to try.

I think things have changed quite a bit since then, though I can't
think right now what the relevant article was that made me think that.
I have the suspicion that getting cmake to compile a minGW version is
difficult because the distinction between 'compiling for/on a Windows
platform' and 'using MSVC' is blurred. Anyway, I can't be bothered to
look at Windows now that I've finally made the move to Linux.

> This was all with MSVC.  minGW is another set of problems.  There have been a
> few people who have tried over the year, this list archives is full of
> reports, partial successes and frustrations.  It is not known to me that
> anybody has succeeded building Hugin with minGW in the past three years.  Yes,
> it would have great benefit, but somebody must be really determined to get it
> done.

Sometimes it makes me want to extract a streamlined version from the
current body of code that runs exclusively on Linux and is
unencumbered by platform issues (I know you'll sympathize with the
notion). As a playground for innovation, without all the read tape
along the lines of 'you can't do that because on <...>, lib<...> is
only available up to 17.33b. I had the feeling a lot of (not only my)
time went into trying to find a compromise between new code and the
byzantine status quo. It might have been cleaner to go through with
the innovation in a coherent testbed, getting it to a good working
status and then porting it to the specific platforms, rather than
having to develop for all platforms at once.

Everyone can run Linux since it's free. It'd even be quite feasible to
have a virtual machine ready with all the needed development tools,
libraries and documentation so all it'd take would be to install
VirtualBox and have a standardized hugin development environment right
away. I found it awkward trying to remotely diagnose difficulties
people had trying to get my code to run on systems I have no access
to. What am I to do if I'm told: 'it does not work. It says 'unknown
error 2237'. (or such). I feel the multi-platform complexity is a real
problem. Trickle down from a reference platform might be more
effective.

Kay