hugin-0.8.0_rc3 released
Bruno Postle
Hash: SHA1
A hugin-0.8.0_rc3 (release candidate 3) tarball is available here:
https://sourceforge.net/project/showfiles.php?group_id=77506&package_id=311429
This is a release candidate, i.e. The final release may be identical.
Changes since 0.8.0 rc2:
* Updated German and Spanish translations.
* Fast Preview window: fix for extreme slowdown bug, fixes for
difference mode detection, crash fix.
* Fix for potential crash running celeste in wide-character locales.
* Batch Processor: verbose view appears immediately on toggling.
* Fix for stitching Makefile test in OS X
See README, ChangeLog and INSTALL_cmake for more information.
SHA1SUM: 7c2f44ab1f5711e3e4182ea442010f4750d98d1b hugin-0.8.0_rc3.tar.gz
This release is equivalent to svn 3923, links to recent hugin binary
installers for testing can be found here:
http://panospace.wordpress.com/downloads/
- --
Bruno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFKKZncFqOhwCjyCLoRAta3AKCFTlWdiVPyX/ExNnJDHwGnYawVMQCgzAsN
csmoPNkFdWJ1cyi9tgRLvCk=
=uhNs
-----END PGP SIGNATURE-----
allard
Good jobs on the bugfixes, hope the final release is near. I tried to
compile the current version on Windows, but I'm getting some error
messages which I'm guessing are due to the Lapack dependencies. My
naive approach of downloading and installing the Lapack binaries and
pointing Cmake to the 'lapack.lib' file apparently didn't work.
Any suggestions?
Allard
part of MSVC output as an example:
18>huginlevmar.lib(Axb.obj) : error LNK2001: unresolved external
symbol _sgesvd_
18>huginlevmar.lib(misc.obj) : error LNK2019: unresolved external
symbol _dgemm_ referenced in function _dtrans_mat_mat_mult
18>huginlevmar.lib(misc.obj) : error LNK2019: unresolved external
symbol _dgesvd_ referenced in function _dlevmar_pseudoinverse
18>huginlevmar.lib(Axb.obj) : error LNK2001: unresolved external
symbol _dgesvd_
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _dtrtrs_ referenced in function _dAx_eq_b_QR
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _dorgqr_ referenced in function _dAx_eq_b_QR
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _dgeqrf_ referenced in function _dAx_eq_b_QR
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _dpotf2_ referenced in function _dAx_eq_b_Chol
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _dgetrs_ referenced in function _dAx_eq_b_LU
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _dgetrf_ referenced in function _dAx_eq_b_LU
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _strtrs_ referenced in function _sAx_eq_b_QR
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _sorgqr_ referenced in function _sAx_eq_b_QR
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _sgeqrf_ referenced in function _sAx_eq_b_QR
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _spotf2_ referenced in function _sAx_eq_b_Chol
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _sgetrs_ referenced in function _sAx_eq_b_LU
18>huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _sgetrf_ referenced in function _sAx_eq_b_LU
On Jun 5, 3:19 pm, Bruno Postle <br...@postle.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> A hugin-0.8.0_rc3 (release candidate 3) tarball is available here:
>
Lukáš Jirkovský
LAPACK is only optional (and in current svn it has to be enabled
manually). If you doesn't have lapack hugin will still build and work.
It seems that quite a lot of people understand this rather small
change as "Now we have to use LAPACK" but it's not true.
Lukáš
allard
On Jun 8, 12:33 am, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
> 2009/6/8 allard <ka...@physics.leidenuniv.nl>:
because I don't know how to tell MSVC to ignore all the Lapack
dependencies. On the other hand, I did download & install the Lapack
source and libraries. If I can, I'd like to include Lapack. I have no
clue whether the actions performed by the installer of Lapack are
enough or if I need to manually compile some of that code too.
The .sln file that came with Lapack does not work in my MSVC 2009.
Tom Sharpless
LAPACK is a FORTRAN package, and Microsoft does not support FORTRAN.
On Windows, you have to use CLAPACK, a C version generated largely by
automatic translation. CLAPACK still acts like FORTRAN, though, so
you need several special headers and libraries to mediate between the
C and FORTRAN environments (you also have to get used to 1-origin
array indexing). And you need a couple of "blas" libraries that
provide the low-level arithmetic routines on which LAPACK depends
(typically the blas codes are processor-specific, for speed, but there
are generic versions too).
And as with all Windows builds, you have to deal with the fact that
you need separate debug and release versions of every library, that
must have been built with the same compiler version that builds your
app.
So you would have to do a whole lot of preparative work before you
could build Hugin with LAPACK on Windows. The resulting gain of
optimizer speed would be of little value, since stitching throughput
is hardly limited by the optimizer.
So in short, you will be much happier if you build without LAPACK.
Indeed, LAPACK should be removed from Hugin, as it offers only
trouble. There are alternative hgih performance Levenberg-Marquardt
codes in C++ (for example at AlgLib) if one really needed to tune up
the optimizer.
-- Tom
Lukáš Jirkovský
What error is it?
I don't know how MSVC handles dependencies, but it should work without
LAPACK. It's not set as required in CMakeLists.txt which means when
it's not found it does nothing. When there is a lapack library it in
only adds -DHAVE_LAPACK and necessary linker flags.
The only change in code I've done was commenting out #undef
HAVE_LAPACK in lm.h. Because HAVE_LAPACK should be undefined if cmake
doesn't find LAPACK library it doesn't change anything.
Lukáš
Lukáš Jirkovský
>
> Hi allard
>
> LAPACK is a FORTRAN package, and Microsoft does not support FORTRAN.
> On Windows, you have to use CLAPACK, a C version generated largely by
> automatic translation. CLAPACK still acts like FORTRAN, though, so
> you need several special headers and libraries to mediate between the
> C and FORTRAN environments (you also have to get used to 1-origin
> array indexing). And you need a couple of "blas" libraries that
> provide the low-level arithmetic routines on which LAPACK depends
> (typically the blas codes are processor-specific, for speed, but there
> are generic versions too).
>
> And as with all Windows builds, you have to deal with the fact that
> you need separate debug and release versions of every library, that
> must have been built with the same compiler version that builds your
> app.
>
> So you would have to do a whole lot of preparative work before you
> could build Hugin with LAPACK on Windows. The resulting gain of
> optimizer speed would be of little value, since stitching throughput
> is hardly limited by the optimizer.
>
> So in short, you will be much happier if you build without LAPACK.
>
> Indeed, LAPACK should be removed from Hugin, as it offers only
> trouble. There are alternative hgih performance Levenberg-Marquardt
> codes in C++ (for example at AlgLib) if one really needed to tune up
> the optimizer.
>
> -- Tom
Hi, Tom,
as I've said I've no idea why MSVC requires LAPACK when it's clearly
optional. Moreover in current svn LAPACK have to be enabled explicitly
so it will not use LAPACK by default even when there is a LAPACK
library installed on system.
More to the speed. LAPACK is in fact a bit slower on my machine and on
Bruno's it's much slower. This lead to the disabling the LAPACK by
default even when there are necessary libraries.
I've explained why I've added LAPACK support under the rc2
announcement. In short because it gives me a bit better (not so bad as
without LAPACK) results with one of my test panoramas and doesn't
change results with the other ones. Moreover it's recommended to use
LAPACK in LEVMAR because it's more stable than it LU-decomposition or
whatever it uses.
Guido Kohlmeyer
I built SVN3923 wich is quite the same as RC3 without any problems based
on my SDK, which does not contain any LAPACK lib.
Guido
Lukáš Jirkovský schrieb:
allard
messages I get are all similar to what I posted above, along the lines
of:
huginlevmar.lib(Axb.obj) : error LNK2019: unresolved external
symbol _spotf2_ referenced in function _sAx_eq_b_Chol
like linear algebra to me (Chol = Cholesky etc). This, and the fact
that Cmake suddenly asked me where the Lapack libraries are, is why I
assumed Lapack is the culprit for this.
But if Guido can build it without Lapack, I don't know what's going
on.
On Jun 8, 1:54 pm, Guido Kohlmeyer <d...@gekko-design.de> wrote:
> Just a note:
> I built SVN3923 wich is quite the same as RC3 without any problems based
> on my SDK, which does not contain any LAPACK lib.
> Guido
>
> Lukáš Jirkovský schrieb:
>
Lukáš Jirkovský
have you done a clean build? I've found out that it gets cached every
time. Unfortunately I don't know how to avoid this caching. You can
bypass it by removing the CMakeCache file or by running cmake with
-DENABLE_LAPACK=NO
You also must use at least svn rev 3925.
You should be able to see if LAPACK will be used in the configuration
phase. If cmake says anything about LAPACK it's bad.
Lukáš
T. Modes
> Hi Allard,
> have you done a clean build? I've found out that it gets cached every
> time. Unfortunately I don't know how to avoid this caching. You can
> bypass it by removing the CMakeCache file or by running cmake with
> -DENABLE_LAPACK=NO
>
> You also must use at least svn rev 3925.
when you are using the CMake GUI or CMake Setup you can easily delete
the cache.
Start CMakeGUI/CMakeSetup, give the path to the trunk and to the build
directory, and the select "Delete Cache", after this you can start a
fresh build with "Configure", when I remember right you have to select
"Configure" 2 or 3 times till all field are resolved (builder,
date...), finish with "Generate"
Thomas
Guido Kohlmeyer
without any cached data from CMake. This works. Following the last mails
in this thread this seems a significant point.
Guido
T. Modes schrieb:
allard
between, that did not help. I'll try again soon with a completely
emptied destination, see if that works.
allard
worked, I should have tried that first.
Lesson learned today: no more shortcuts.
Find the file at http://hugin.panotools.org/testing/hugin/Hugin_08RC3_SVN3925_Allard_W32setup.exe
Allard
Andreas Metzler
> A hugin-0.8.0_rc3 (release candidate 3) tarball is available here:
Hello,
I am getting a segfault when trying to use the crop tool in the opengl
preview. Reproducing seems to require that the OpenGL preview has
already been loaded automatically at startup, i.e. it was open the
last time hugin was used. After that I just need to click on the crop
tool to get the segfault.
This one seems to be newish, beta4 worked for me.
ametzler@argenau:/tmp/blubb$ gdb hugin
[...]
(gdb) run IMG_3381-IMG_3385.pto
[...]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf602c8d0 (LWP 9866)]
PreviewToolHelper::ActivateTool (this=0xa6a4980, tool=0x0)
at /tmp/HUGIN/hugin-0.8.0~rc3/src/hugin1/hugin/PreviewToolHelper.cpp:48
48 tool->Activate();
(gdb) bt
#0 PreviewToolHelper::ActivateTool (this=0xa6a4980, tool=0x0)
at /tmp/HUGIN/hugin-0.8.0~rc3/src/hugin1/hugin/PreviewToolHelper.cpp:48
#1 0x08155bce in GLPreviewFrame::OnCrop (this=0xa002da8, e=@0xffc99194)
at /tmp/HUGIN/hugin-0.8.0~rc3/src/hugin1/hugin/GLPreviewFrame.cpp:1057
#2 0xf74c97f1 in wxAppConsole::HandleEvent ()
from /usr/lib/libwx_baseu-2.8.so.0
#3 0xf75669ca in wxEvtHandler::ProcessEventIfMatches ()
from /usr/lib/libwx_baseu-2.8.so.0
#4 0xf7567bb4 in wxEventHashTable::HandleEvent ()
from /usr/lib/libwx_baseu-2.8.so.0
#5 0xf7567cbb in wxEvtHandler::ProcessEvent ()
from /usr/lib/libwx_baseu-2.8.so.0
#6 0xf7376f4d in wxWindowBase::TryParent ()
from /usr/lib/libwx_gtk2u_core-2.8.so.0
#7 0xf7567c59 in wxEvtHandler::ProcessEvent ()
from /usr/lib/libwx_baseu-2.8.so.0
#8 0xf736d362 in wxToolBarBase::OnLeftClick ()
from /usr/lib/libwx_gtk2u_core-2.8.so.0
#9 0xf72e2a8d in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#10 0xf6534064 in g_cclosure_marshal_VOID__VOID ()
from /usr/lib/libgobject-2.0.so.0
#11 0xf652690b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#12 0xf6539e6d in ?? () from /usr/lib/libgobject-2.0.so.0
Testdata (I know the images suck ;-):
http://www.bebt.de/tmp/testproject.tgz
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Bruno Postle
>
>I am getting a segfault when trying to use the crop tool in the opengl
>preview. Reproducing seems to require that the OpenGL preview has
>already been loaded automatically at startup, i.e. it was open the
>last time hugin was used. After that I just need to click on the crop
>tool to get the segfault.
I can reproduce this, the Crop button segfaults but only if the Fast
preview was open when hugin was started. This is probably the same
as this bug report:
http://sourceforge.net/tracker/?func=detail&aid=2801663&group_id=77506&atid=550441
--
Bruno
Andreas Metzler
[...]
> I can reproduce this, the Crop button segfaults but only if the Fast
> preview was open when hugin was started. This is probably the same
> as this bug report:
> http://sourceforge.net/tracker/?func=detail&aid=2801663&group_id=77506&atid=550441
Indeed. Sorry for the duplicate report.
Bruno Postle
>Bruno Postle <br...@postle.net> wrote:
>> I can reproduce this, the Crop button segfaults but only if the Fast
>> preview was open when hugin was started. This is probably the same
>> as this bug report:
>
>> http://sourceforge.net/tracker/?func=detail&aid=2801663&group_id=77506&atid=550441
>
>Indeed. Sorry for the duplicate report.
No thank you, this is exactly the kind of bug report we need, before
it wasn't easily reproducible.
--
Bruno