Crashes

Hugin still crashes on my Mac. I have been trying to stitch 6 images  
in  a straight line. It took 3 tries to get all the control points  
but it will not stitch 'em. Crashes every time. Each image is  
3024x2016. Is it possible the program cannot handle this size image?  
I have 1.25GB Ram and plenty of disk space. At this point it seems  
like a waste of my time to keep trying this. Where do I report bugs?

- Paul

Compiler versions and Hugin

I have (for the first time) had a go at compiling hugin from (today's)
cvs following Rob Park's instructions at

http://exolucere.ca/articles/compile-hugin-ubuntu

I run the unstable version of debian, updated yesterday.

I tried first with my default 4.1 versions of gcc/g++. No compilation
errors, but hugin fails:

peterg <at> barra:~$ hugin
Panorama obj created
Aborted

Following Rob's suggestion, I then tried version 3.3 of gcc/g++ which
gives:

hugin
Fatal Error: Mismatch between the program and library build versions detected.
The library used 2.6 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.4),
and your program used 2.6 (no debug,Unicode,compiler with C++ ABI 102,wx containers,compatible with 2.4).
Aborted

This is similar to the message reported by Rob, but with 102/1002
reversed and 2.5.3 replaced by 2.6 -- so I tried tried version 3.4 of gcc/g++. This gives:

peterg <at> barra:~$ hugin
Panorama obj created
Aborted

Re: Crashes

OS X Hugin & autopano-sift question

I am having a problem with autopano sift as it is invoked from Hugin 
OSX.  Autopano appears to run just fine; the "running terminal command" 
window opens, the output looks good, and the control point file is 
dumped under /private someplace.  But Hugin never seems to notice that 
autopano has finished.  The only thing I seem to be able to do is force 
quit hugin.

I'm a new Mac user from a linux background, and this feels like a "duh, 
I just don't know the key combo" problem. Any help?

- OS X 10.4 for Intel
- Hugin 0.5
- autopano-sift 2.4

I could force quit hugin, load the pto file, and blend it just fine. 
However, this seemed to have the same problem when enblend was used; 
enblend worked just fine, but hugin never came back from the child 
process and I had to force quit.

Thanks for any help

    --- Carl

Re: enblend script hangs

I'm having the same problem with my Hugin. 

Problem: scripts don't properly finish on the Intel MacBook Pro 17". Need to
force quit close windows when this happens. Enblend works, but Autopano-sift
can't return its control points to Hugin. I wonder if this is an Intel Mac
setting or something lost in translation in Rosetta (although then the
Universal version would work). 

I've tried Hugin 0.5, which works perfectly on my G5 and has this hanging
problem on the MacBook. 
I've tried the freshly compiled Universal version on the MacBook and it has
the same problem. 

The scripts that I've tried was enblend with the enblend binary in the Hugin
package. I've tried Autopano-Sift both in and out of the package with no
luck. It seems the scripts complete what they need to do but they don't give
Hugin any "I'm finished" instruction, or Hugin forgets it. 

--

-- 
View this message in context: http://www.nabble.com/enblend-script-hangs-tf1860676.html#a5163495
Sent from the hugin ptx forum at Nabble.com.

Compiler versions and Hugin

Here is some more info on the problem, any help appreciated as I don't
really know what I am doing.

peterg <at> barra:~$ gdb hugin
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /usr/local/bin/hugin 
[Thread debugging using libthread_db enabled]
[New Thread -1225292096 (LWP 2701)]
Panorama obj created

Program received signal SIGABRT, Aborted.
[Switching to Thread -1225292096 (LWP 2701)]
0xb6fe67c7 in raise () from /lib/tls/libc.so.6
(gdb) backtrace
#0  0xb6fe67c7 in raise () from /lib/tls/libc.so.6
#1  0xb6fe806b in abort () from /lib/tls/libc.so.6
#2  0xb7a574fe in wxVLogFatalError () from /usr/lib/libwx_baseu-2.6.so.0
#3  0xb7a57597 in wxLogFatalError () from /usr/lib/libwx_baseu-2.6.so.0
#4  0x08078f10 in MainFrame (this=0x89d46c0, parent=0x0, pano= <at> 0x88c88c4)
    at MainFrame.cpp:219
#5  0x0805fc23 in huginApp::OnInit (this=0x88c8840) at huginApp.cpp:297
#6  0x080613e1 in wxAppConsole::CallOnInit (this=0x88c8840)
    at /usr/include/wx-2.6/wx/app.h:87
#7  0xb7a4abe0 in wxEntry () from /usr/lib/libwx_baseu-2.6.so.0
#8  0xb7a4acb6 in wxEntry () from /usr/lib/libwx_baseu-2.6.so.0
#9  0x0805e060 in main (argc=Cannot access memory at address 0xa8d
) at huginApp.cpp:135
(gdb) 

Thanks,

	Peter

Re: enblend script hangs

I have this problem too. I've not found a fix yet.  If anyone finds a 
fix, I would love to know about it.

    --- Carl

23degrees wrote:
> I'm having the same problem with my Hugin. 
> 
> Problem: scripts don't properly finish on the Intel MacBook Pro 17". Need to
> force quit close windows when this happens. Enblend works, but Autopano-sift
> can't return its control points to Hugin. I wonder if this is an Intel Mac
> setting or something lost in translation in Rosetta (although then the
> Universal version would work). 
> 
> I've tried Hugin 0.5, which works perfectly on my G5 and has this hanging
> problem on the MacBook. 
> I've tried the freshly compiled Universal version on the MacBook and it has
> the same problem. 
> 
> The scripts that I've tried was enblend with the enblend binary in the Hugin
> package. I've tried Autopano-Sift both in and out of the package with no
> luck. It seems the scripts complete what they need to do but they don't give
> Hugin any "I'm finished" instruction, or Hugin forgets it. 
> 
> 

Re: Compiler versions and Hugin

On 7/4/06, Peter Gawthrop <peter <at> gawthrop.net> wrote:
> Here is some more info on the problem, any help appreciated as I don't
> really know what I am doing.

I really don't know anything more about this problem than that I had
to make sure to compile hugin with the same version that compiled
wxwidgets to make it work.

If you're really stuck, try uninstalling wxwidgets and then compiling
that yourself. That way you're sure to get them both with the same
compiler since you're compiling both yourself.

--

-- 
Rob Park
http://exolucere.ca

Re: Compiler versions and Hugin

Hi Rob,

 thanks for the help and encouragement! I have spent a while getting a
 working version of hugin -- and learning a lot more about how to go
 about this sort of thing. It makes me appreciate how much Pablo and
 the hugin team have done for the panorama community.

 In fact, libwx was not the main problem. Having followed your
 instructions, using g++/gcc4.1, and extracting hugin to
 ~/Development/Photo/hugin, I find that:

 ~/Development/Photo/hugin/src/hugin/hugin

 works fine

  /usr/local/bin/hugin

  comes up with the error reported earlier - even though I have done
  sudo make install and diff reports that the files are identical.

  I can't understand why that should be -- can you?

  FWIW, I also built hugin using my own version of wx - but it has the
  same behaviour. Here is how I did it:

1. Compile your own wxwidgets.
Get wxWidgets-2.6.3.tar.gz from http://www.wxwidgets.org/
$ tar -xzf wxWidgets-2.6.3.tar.gz
$ cd wxWidgets-2.6.3
$ ./configure --with-gtk --enable-compat22
$ make
$ sudo make install

2. Make sure the new wx libs are found - edit /etc/ld.so.conf do that
   /usr/local/lib is before /usr/lib. My file is:

/lib
/usr/local/lib
/usr/lib
/usr/X11R6/lib
/usr/i486-linuxlibc1/lib
/usr/lib/mozilla
/usr/lib/atlas

3. Install hugin as Rob Parks Tutorial at
   http://exolucere.ca/articles/compile-hugin-ubuntu 
  except replace the configuration command by

$ ./configure  --with-unicode=yes --with-wxdir=/usr/local/bin

  to pick up the new location of wx.

  Best wishes,

  Peter.

From: "Rob Park" <rbpark <at> gmail.com>
Subject: Re: [ptx] Compiler versions and Hugin
Date: Wed, 5 Jul 2006 22:20:51 -0600

> On 7/4/06, Peter Gawthrop <peter <at> gawthrop.net> wrote:
> > Here is some more info on the problem, any help appreciated as I don't
> > really know what I am doing.
> 
> I really don't know anything more about this problem than that I had
> to make sure to compile hugin with the same version that compiled
> wxwidgets to make it work.
> 
> If you're really stuck, try uninstalling wxwidgets and then compiling
> that yourself. That way you're sure to get them both with the same
> compiler since you're compiling both yourself.
> 
> -- 
> Rob Park
> http://exolucere.ca

Re: Compiler versions and Hugin

Hi Peter,

Peter Gawthrop wrote:
> Hi Rob,
> 
>  In fact, libwx was not the main problem. Having followed your
>  instructions, using g++/gcc4.1, and extracting hugin to
>  ~/Development/Photo/hugin, I find that:
> 
>  ~/Development/Photo/hugin/src/hugin/hugin
> 
>  works fine
> 
>   /usr/local/bin/hugin
> 
>   comes up with the error reported earlier - even though I have done
>   sudo make install and diff reports that the files are identical.

Thanks for the comprehensive error report.

>   I can't understand why that should be -- can you?

Hmm, this happens if hugin doesn't find its data files. the data files
are located in the xrc directory, and this is searched in the current
directory, in the prefix specified during configure. If it is not found
there, hugin will try to read ~/.hugin and get the directory from there.

To manually specify the xrc directory open ~/.hugin and add the following
to the top of the file:
xrc_path=/my/install/prefix/share/hugin/xrc

However, it would be interesting to see why hugin fails to find the
directory on your machine. Can you post your
~/Development/Photo/hugin/config.h file?

Also, can you check where your installed version of hugin actually looks for
the xrc folder with:

strace hugin 2>&1 | grep xrc > t.log

ciao
  Pablo