Warped Overlap Analysis not working

138 views
Skip to first unread message

Kornel Benko

unread,
Dec 16, 2013, 3:49:12 PM12/16/13
to hugin

I tried to use 'Warped Overlap Analysis' with the latest hugin version.

To my surprise it does not work any more.

 

The output at the console window was:

...

run python script: /usr/local/share/hugin/data/plugins/woa.py

hpi: accessing plugin file /usr/local/share/hugin/data/plugins/woa.py

matching pair (0, 1) failed with TypeError: "__init__() takes exactly 1 argument (2 given)"

stack traceback:

File "/usr/local/share/hugin/data/plugins/woa.py", line 1751, in process_image_set

cps_added = cps_from_overlap ( pano , *pair )

File "/usr/local/share/hugin/data/plugins/woa.py", line 1535, in cps_from_overlap

wi0 = hsi.SrcPanoImage ( nona_output[0] )

matching pair (0, 2) failed with TypeError: "__init__() takes exactly 1 argument (2 given)"

stack traceback:

File "/usr/local/share/hugin/data/plugins/woa.py", line 1751, in process_image_set

cps_added = cps_from_overlap ( pano , *pair )

File "/usr/local/share/hugin/data/plugins/woa.py", line 1535, in cps_from_overlap

wi0 = hsi.SrcPanoImage ( nona_output[0] )

matching pair (1, 2) failed with TypeError: "__init__() takes exactly 1 argument (2 given)"

stack traceback:

File "/usr/local/share/hugin/data/plugins/woa.py", line 1751, in process_image_set

cps_added = cps_from_overlap ( pano , *pair )

File "/usr/local/share/hugin/data/plugins/woa.py", line 1535, in cps_from_overlap

wi0 = hsi.SrcPanoImage ( nona_output[0] )

hpi: plugin terminated with exit code 0

hpi: terminating with exit code 0

Python interface returned 0

...

 

The relevant woa.py is really the one from hugin source, so apparently the API changed but the script

is not committed yet.

 

Kornel

 

signature.asc

kfj

unread,
Jan 16, 2014, 5:02:44 AM1/16/14
to hugi...@googlegroups.com


On Tuesday, December 17, 2013 2:19:12 AM UTC+5:30, kornel wrote:

I tried to use 'Warped Overlap Analysis' with the latest hugin version.

To my surprise it does not work any more.

 


The relevant woa.py is really the one from hugin source, so apparently the API changed but the script

is not committed yet.

 


Hi Kornel! Just spotted this now, quite accidentally. I had a look at the constructor for SrcPanoImage, and indeed the latest version uses a constructor without arguments instead of the old SrcPanoImage(const std::string &filename), and I haven't been able to figure out quickly how an SrcPanoImage can be made from an image file, now. Do you have any idea (or anyone else reading this)? I suppose there must be some readImageData() method or so somewhere? This is surely the source of the error. hsi automatically adapts to all API changes (swig just eats the headers, no matter what they contain), but of course the scripts can't.

Kay

Kornel Benko

unread,
Jan 16, 2014, 5:21:55 AM1/16/14
to hugi...@googlegroups.com

Am Donnerstag, 16. Januar 2014 um 02:02:44, schrieb kfj <_k...@yahoo.com>

Sorry Kai, to my shame I was not able to find it. I don't understand python/hsi that much.

 

Kornel

signature.asc

kfj

unread,
Jan 16, 2014, 7:13:24 AM1/16/14
to hugi...@googlegroups.com


On Thursday, January 16, 2014 3:51:55 PM UTC+5:30, kornel wrote:

Am Donnerstag, 16. Januar 2014 um 02:02:44, schrieb kfj > Hi Kornel! Just spotted this now, quite accidentally. I had a look at the

> constructor for SrcPanoImage, and indeed the latest version uses a

> constructor without arguments instead of the old SrcPanoImage(const

> std::string &filename), and I haven't been able to figure out quickly how

> an SrcPanoImage can be made from an image file, now. Do you have any idea

> (or anyone else reading this)? I suppose there must be some readImageData()

> method or so somewhere? This is surely the source of the error. hsi

> automatically adapts to all API changes (swig just eats the headers, no

> matter what they contain), but of course the scripts can't.

>

> Kay

>

 

Sorry Kai, to my shame I was not able to find it. I don't understand python/hsi that much.


What I am referring to is hugin's C++ code, it's from
 

src/hugin_base/panodata/SrcPanoImage.h


the old constructor (it was in line 215) took a const std::string &filename as parameter, the new one (now in line 203) takes no parameters, as you can see in


http://sourceforge.net/p/hugin/hugin/ci/default/tree/src/hugin_base/panodata/SrcPanoImage.h


 Swig, which generates the hsi python module, merely processes this header, amongst others, and makes python code which mimicks the C++ code. So if the C++ code changes, the interface changes automatically, and woa, which relies on being able to construct an ScrPanoImage from an image file, fails.


Kay

Kornel Benko

unread,
Jan 16, 2014, 7:53:30 AM1/16/14
to hugi...@googlegroups.com

Am Donnerstag, 16. Januar 2014 um 04:13:24, schrieb kfj <_k...@yahoo.com>

There is this macro in SrcPanoImage.h:

#define image_variable( name, type, default_value ) \

type get##name() const { return m_##name.getData(); }

#include "image_variables.h"

while in image_variables.h the call to it:

image_variable( Filename, std::string, "" )

should expand to:

getFilename() const { return m_Filename.getData(); }

 

 

Is that what you are alooking for?

 

Kornel

 

signature.asc

kfj

unread,
Jan 17, 2014, 1:53:50 AM1/17/14
to hugi...@googlegroups.com


On Thursday, January 16, 2014 6:23:30 PM UTC+5:30, kornel wrote:

 

There is this macro in SrcPanoImage.h:

#define image_variable( name, type, default_value ) \

type get##name() const { return m_##name.getData(); }

#include "image_variables.h"

while in image_variables.h the call to it:

image_variable( Filename, std::string, "" )

should expand to:

getFilename() const { return m_Filename.getData(); }


No, I think this macro is to find out the file name if you have a SrcPanoImage already. What I am looking for is a way to create an SrcPanoImage from a file. In the previous version, you could call SrcPanoImage's constructor with a filename as it's sole argument. The file was opened, read, analyzed and you had an SrcPanoImage to work with. Now the constructor does not take any arguments any more. So you can contruct an SrcPanoImage, but it can't have any content yet, since you can't tell which file to contruct it from. So I suspect that there must me a mechanism like:

SrcPanoImage myImage ;
ifstream f ( "image.tif" ) ;
myImage.readData ( f ) ;

Pano objects need this clumsy mechanism: You have to create the Pano onject, then create an ifstream from the PTO file and finally call the Pano object's readData method, passing it the stream object. So I suppose it might be similar with SrcPanoImage now, but I'm only guessing.

I'll start a new thread. Quite probably noone gives a damn if woa works or not, and this thread will just go on without anyone in the know looking into it.

Kay

kfj

unread,
Jan 19, 2014, 7:38:22 AM1/19/14
to hugi...@googlegroups.com
I posted a patch (in the other thread about SrcPanoImage's constructor) which fixes woa, and pulls up all plugins to API level 2014.1

Kay
Reply all
Reply to author
Forward
0 new messages