hugin-2010.2.0_rc2 released
Bruno Postle
for creating and processing panoramic images.
A hugin-2010.2.0_rc2 (release candidate 2) tarball is available here:
https://sourceforge.net/projects/hugin/files/hugin-2010.2_beta/
This is a release candidate, i.e. The final release may be identical.
More information about this release can be found in the full ChangeLog below
and the final release notes:
http://hugin.sourceforge.net/releases/2010.2.0/
Summary of changes since 2010.2.0_rc1:
* Updated Russian translation.
* Activate autocrop on all projections.
* Don't override loaded crop factor from project file.
* Fixes incorrect masks in combination with translations parameters.
* Minor GUI, build and packaging fixes.
libpano13-2.9.17 is required, this was released on 10th September 2010.
See README, ChangeLog and INSTALL_cmake for more information.
SHA1SUM:
f0676f28cd3fbebcf4086f55af7cf09566772899 hugin-2010.2.0_rc2.tar.gz
This release is equivalent to hg branch 2010.2 -r 4431:d8ce0ba947cc
A detailed ChangeLog of every commit since 2010.2.0_rc1 follows:
2010-09-27 tmodes <tmodes>
* src/hugin_base/panodata/Mask.cpp,
src/hugin_base/panodata/Panorama.cpp:
Fixes incorrect masks in combination with translations parameters
[3076130]
[8418676e8a53]
2010-09-26 Bruno Postle <br...@postle.net>
* src/foreign/vigra/vigra_impex/CMakeLists.txt:
Fix -lpthread fix
[3936a26214ba]
* src/foreign/vigra/vigra_impex/CMakeLists.txt:
explicitly use -lpthread when available, fixes build failure on
fedora f14
[c8ed7735f41d]
2010-09-25 Bruno Postle <br...@postle.net>
* src/translations/ru.po:
Russian translation update (Alexandre Prokoudine)
[e4b691911336]
2010-09-24 tmodes <tmodes>
* src/hugin1/hugin/PanoPanel.cpp:
Enable autocrop for all projections also on pano panel
[7d8bddbbd13e]
2010-09-23 tmodes <tmodes>
* src/hugin1/hugin/GLPreviewFrame.cpp:
Activate autocrop on all projections
[efa643db4383]
2010-09-19 harryvanderwolf <hvd...@gmail.com>
* src/hugin1/hugin/xrc/assistant_panel.xrc:
set lens type wxchoice pulldown on assistant tab to correct size
[c9b073555204]
2010-09-18 harryvanderwolf <hvd...@gmail.com>
* mac/copyExtraTools.sh:
[OSX] add enblend and enfuse to copyExtraTools.sh script
[09d36ef1f80c]
2010-09-17 tmodes <tmodes>
* Merged
[3343ab49deed]
* src/hugin_base/panodata/SrcPanoImage.cpp:
Don't override loaded crop factor from project file
[ca1bbd638e77]
2010-09-15 Bruno Postle <br...@postle.net>
* ChangeLog:
update ChangeLog for likely rc1
[23e34640f870] [hugin-2010.2.0_rc1]
Tduell
On Sep 29, 8:37 am, Bruno Postle <br...@postle.net> wrote:
> Hugin is a Panorama stitcher and more. A powerful software package
> for creating and processing panoramic images.
>
> A hugin-2010.2.0_rc2 (release candidate 2) tarball is available here:https://sourceforge.net/projects/hugin/files/hugin-2010.2_beta/
I'll try to do some more testing over the next couple of days.
Cheers,
Terry
Matthew Petroff
http://www.box.net/shared/xscpvk1ad8
A 32-bit Windows installer can be found here:
http://www.box.net/shared/6exu7c7m2y
An untested Hugin 2010.2.0 rc2 build for 64-bit Windows can be found
here:
http://www.box.net/shared/2fxa9qad8t
An untested 64-bit Windows installer can be found here:
http://www.box.net/shared/oheqdj0rij
Matthew
> * src/hugin1/hugin/xrc/assistant_panel.xrc:
> set lens type wxchoice pulldown on assistant tab to correct size
> [c9b073555204]
>
> * mac/copyExtraTools.sh:
> [OSX] add enblend and enfuse to copyExtraTools.sh script
> [09d36ef1f80c]
>
> 2010-09-17 tmodes <tmodes>
>
> * Merged
> [3343ab49deed]
>
> * src/hugin_base/panodata/SrcPanoImage.cpp:
> Don't override loaded crop factor from project file
> [ca1bbd638e77]
>
> 2010-09-15 Bruno Postle <br...@postle.net>
>
> * ChangeLog:
> update ChangeLog for likely rc1
> [23e34640f870] [hugin-2010.2.0_rc1]
>
> < 1KViewDownload
Simon Oosthoek
> Hugin is a Panorama stitcher and more. A powerful software package
> for creating and processing panoramic images.
>
> A hugin-2010.2.0_rc2 (release candidate 2) tarball is available here:
> https://sourceforge.net/projects/hugin/files/hugin-2010.2_beta/
>
> This is a release candidate, i.e. The final release may be identical.
>
> More information about this release can be found in the full ChangeLog below
> and the final release notes:
> http://hugin.sourceforge.net/releases/2010.2.0/
>
>
I just tried it, it seems to work really well for me (kubuntu 10.04.1),
the only things I noticed were:
- I had an older enblend (compiled with older library), failing to run
it hung the stitch-now window completely (that's ugly from a user's
perspective)
- the GLpreview window's photometrics looks a lot darker than in the
final output. That should be more calibrated IMO.
I also have a question: what is the default optimisation that hugin does
when you first load images, generate CPs and then presto it presents the
first preview. I was unable to improve on that (apart from adding a
mask), so I'm wondering what it is that makes this a good optimisation?
Anyway, good work!
Cheers
Simon
Aron H
On Sep 29, 7:23 pm, Matthew Petroff <matt...@mpetroff.net> wrote:
> A Hugin 2010.2.0 rc2 build for 32-bit Windows can be found here:http://www.box.net/shared/xscpvk1ad8
>
> A 32-bit Windows installer can be found here:http://www.box.net/shared/6exu7c7m2y
>
> An untested Hugin 2010.2.0 rc2 build for 64-bit Windows can be found
> here:http://www.box.net/shared/2fxa9qad8t
>
> An untested 64-bit Windows installer can be found here:http://www.box.net/shared/oheqdj0rij
>
> Matthew
>
panorama. It installs and runs correctly.
Panomatic runs.
Autopano-Sift-C is version 2.5.2, which has problems, correct? I've
seen multiple suggestions to use 2.5.1 instead.
The default arguments include ' --projection %f,%v' which causes too
few CP to be detected, and should be removed.
After that fix, it works well.
Default options for blending worked. Task manager says Enblend is x64.
Matthew, are you building Enblend/enfuse x64 yourself? or one of my
builds?
I'm hoping you will look at http://wiki.panotools.org/Hugin_SDK_%28MSVC_2010%29
and put in any fixes you find!
One thing I noticed this time - Hugin doesn't do anything on the
Assistant tab to tell you it's done blending the panorama - the log
window just goes away. Is this just on Windows? Is there something
nice we could do to let the user know it's done? Perhaps opening an
Explorer window to the output location, or just adding a string below
the '3. Create Panorama' button that says 'xxx.tif successfully
created'.
Regards,
Aron
Jim Watters
> An untested 64-bit Windows installer can be found here:
> http://www.box.net/shared/oheqdj0rij
>
> Matthew
installed and noticed that because the shortcut names are the same, I now only
have links to the 64bit version.
I would like to have either a Hugin64 folder in the start menu or the names
changed so that both work after install.
--
Jim Watters
http://photocreations.ca
Matthew Petroff
> Matthew, are you building Enblend/enfuse x64 yourself? or one of my
> builds?
binaries from SourceForge.
> I'm hoping you will look athttp://wiki.panotools.org/Hugin_SDK_%28MSVC_2010%29
I used a combination of the MSVC 2010 and MSVC 2008 to create a 64-bit
build environment since I am using Visual Studio 2008 in combination
with Windows SDK 7.1. I did not have problems with building any other
dependencies except for having to manually apply patches as some of
the packages have been updated since the patches were produced.
Hugin builds fine but with a few exceptions. The translation package
does not build correctly and I had to copy freeglut_static.lib to few
locations in the hugin source for the linker to find it. I have not
had time to figure out a more permanent solution but will once I have
time.
Matthew
Yuval Levy
> One thing I noticed this time - Hugin doesn't do anything on the
> Assistant tab to tell you it's done blending the panorama - the log
> window just goes away. Is this just on Windows?
no, it's everywhere. yes, your suggestions make sense. can you please add
them to the feature request tracker [0] ?
no guarantee that anybody has time to do something about it, but having the
request filed means at least it's on the radar screen.
thanks
Yuv
[0] http://sourceforge.net/tracker/?group_id=77506&atid=550444
Aron H
On Sep 30, 12:42 pm, Yuval Levy <goo...@levy.ch> wrote:
> On September 30, 2010 10:28:04 am Aron H wrote:
>
> > One thing I noticed this time - Hugin doesn't do anything on the
> > Assistant tab to tell you it's done blending the panorama - the log
> > window just goes away. Is this just on Windows?
>
> no, it's everywhere. yes, your suggestions make sense. can you please add
> them to the feature request tracker [0] ?
https://sourceforge.net/tracker/?func=detail&aid=3078875&group_id=77506&atid=550444
Aron
> no guarantee that anybody has time to do something about it, but having the
> request filed means at least it's on the radar screen.
>
> thanks
> Yuv
>
> [0]http://sourceforge.net/tracker/?group_id=77506&atid=550444
>
> < 1KViewDownload
Henk Tijdink
I have downloaded and did a clean install of release candidate 2, 32
bit. Fiddled with it for testing. Found the following.
This release has no link for downloading autopano 1.03 of Alexander
Jenny.
That control point generator is not in the CPG folder in Hugin.
Another discrepancy is that when you go to the preference screen and
you load the defaults the path to the CPG folder is gone and Hugin
expects then the control point generators in the Hugin binary folder.
When going to the CPG tab you find then all the preferences of the not
installed CPG too (Autopano 1.03(A. Jenny) and Match 'n Shift). But
the path to the CPG folder is gone for all CPG'sl
Kind regards,
Henk Tijdink
thePanz
On Sep 30, 4:28 pm, Aron H <aron.hel...@gmail.com> wrote:
> On Sep 29, 7:23 pm, Matthew Petroff <matt...@mpetroff.net>
>
> panorama. It installs and runs correctly.
> Panomatic runs.
> Autopano-Sift-C is version 2.5.2, which has problems, correct? I've
> seen multiple suggestions to use 2.5.1 instead.
> The default arguments include ' --projection %f,%v' which causes too
> few CP to be detected, and should be removed.
> After that fix, it works well.
release.
Can you please give me the link where I can find the 2.5.1 version?
I'll fix the installer then.
In the latest installer script release (on BitBucket and soon on
SourceForge) I've fixed the Autopano-sift-C arguments.
Feel free to build the new installer with the updated script.
Cheers
ps: if someone knows how to put builds in Hugin download section of
SourceForge I'll post the latest RC2 build by Matthew.
namklim
I get to the the Stitcher tab and click Stitch now. For no apparent
reason hugin_stitch_project.exe suddenly starts claiming the whole of
a processor when it is only waiting for a file name. It just continues
that way until I'm lucky enough to be able to select the output file.
Then another long wait until I can successfully click Save. As soon as
I do so and the stitching process starts the Hugin CPU usage drops to
zero.
Bruno Postle
>
> I also have a question: what is the default optimisation that
> hugin does when you first load images, generate CPs and then
> presto it presents the first preview. I was unable to improve on
> that (apart from adding a mask), so I'm wondering what it is that
> makes this a good optimisation?
It's SmartOptimise::smartOptimize in
src/hugin_base/algorithms/optimizer/PTOptimizer.cpp
There are some heuristics and at least two passes:
First it optimises just positions, if the final panorama is 360°
then it will optimise field of view of the photos in the next step.
It looks at the spread of control points and either optimises just
'b' or 'a,b,c' lens parameters depending on this spread.
If the photos are wider than 60° then d,e will be optimised too.
It does some checks with the result of this second step, if the
v,a,b,c,d,e parameters are not credible then it backs out and
optimises the project again but with less parameters.
Looking at this code, some of the default thresholds could be
better, e.g. I think it is safe to optimise field of view if the
panorama is greater than about 150°, the a,b,c thresholds are too
high, and the d,e threshold should be a proportion of the photo
width rather than a pixel value.
A lot of this could be made into user preferences, not because users
should be continually tinkering with these settings, but there is no
other way I can think of of determining a good set of defaults.
--
Bruno
Matthew Petroff
> when you go to the preference screen and
> you load the defaults the path to the CPG folder is gone and Hugin
> expects then the control point generators in the Hugin binary folder.
have nothing to do with the installer. It does however make sense to
have the binary in the installer revert to the paths used by the
installer, so I patched the binary to do so. This updated build is
available here: http://www.box.net/shared/meeaobr9ec
I updated the default paths to the control point detectors for Windows
in hugin, and also added functionality so that hugin checks if a path
relative to hugin.exe was entered as the control point detector
executable so the new paths will work.
The patch to the hugin-2010.2.0_rc2 tarball is available here:
http://www.mpetroff.net/hugin/hugin_windows-CPG-defaults_patch_2010-09-30.diff
I would ask someone with commit access to apply the patch to the
mercurial repository, but the new paths, while better organizing the
detectors in lieu of package management, would make it more difficult
for those not using an installer. One remedy would be to create empty
folders for the various detectors when hugin is compiled so they could
be populated with detectors later if desired. Detectors in bin still
work of course, but the default paths have to be changed. Could one of
the developers please voice an option on the issue?
A patch to the installer that makes the control point detector folders
the same as the new hard coded values is available here:
http://www.mpetroff.net/hugin/installerchanges_2010-10-01.7z
Matthew
Simon Oosthoek
> On Thu 30-Sep-2010 at 12:09 +0200, Simon Oosthoek wrote:
>>
>> I also have a question: what is the default optimisation that hugin
>> does when you first load images, generate CPs and then presto it
>> presents the first preview. I was unable to improve on that (apart
>> from adding a mask), so I'm wondering what it is that makes this a
>> good optimisation?
> should be continually tinkering with these settings, but there is no
> other way I can think of of determining a good set of defaults.
>
Ok, the defaults seem to work rather well for me, but I suppose they can
be tuned even further...
AFAIK there's no way for me to choose this optimisation from the GUI in
this release, is there?
Cheers
Simon
Henk Tijdink
Installed your new version and found the following not working
properly when going back to the standard defaults.
1 In the preference screen of the control point generators is then the
absolute path C:\program files\Hugin\CPG\ folder cpg to use\cpg.exe.
When applying the standard defaults it becomes a relative path? ..\CPG
\folder cpg to use\cpg.exe.
All cpg's can handle that, except autopano of Alexandre Jenny, I have
to put the path back to the absolute path,
2 In the parameters of autopano-SIFT-C the parameter --projection %f
%v is back again.
Kind regards,
Henk Tijdink
On 2 okt, 03:07, Matthew Petroff <matt...@mpetroff.net> wrote:
> On Sep 30, 4:17 pm, Henk Tijdink <h.tijd...@gmail.com> wrote:
>
> > when you go to the preference screen and
> > you load the defaults the path to the CPG folder is gone and Hugin
> > expects then the control point generators in the Hugin binary folder.
>
> This is because the paths are hard-coded into the hugin binary and
> have nothing to do with the installer. It does however make sense to
> have the binary in the installer revert to the paths used by the
> installer, so I patched the binary to do so. This updated build is
> available here:http://www.box.net/shared/meeaobr9ec
>
> I updated the default paths to the control point detectors for Windows
> in hugin, and also added functionality so that hugin checks if a path
> relative to hugin.exe was entered as the control point detector
> executable so the new paths will work.
>
T. Modes
> The patch to the hugin-2010.2.0_rc2 tarball is available here:http://www.mpetroff.net/hugin/hugin_windows-CPG-defaults_patch_2010-0...
> I would ask someone with commit access to apply the patch to the
> mercurial repository, but the new paths, while better organizing the
> detectors in lieu of package management, would make it more difficult
> for those not using an installer. One remedy would be to create empty
> folders for the various detectors when hugin is compiled so they could
> be populated with detectors later if desired. Detectors in bin still
> work of course, but the default paths have to be changed. Could one of
> the developers please voice an option on the issue?
and use the PATH variable to find to corresponding program. But with
your patch this does not work any more.
Thomas
Bruno Postle
>>>
>>>I also have a question: what is the default optimisation that
>>>hugin does when you first load images, generate CPs and then
>>>presto it presents the first preview. I was unable to improve on
>>>that (apart from adding a mask), so I'm wondering what it is that
>>>makes this a good optimisation?
>Ok, the defaults seem to work rather well for me, but I suppose they
>can be tuned even further...
>AFAIK there's no way for me to choose this optimisation from the GUI
>in this release, is there?
You can click on the Align... button in the Assistant any time.
--
Bruno
Yuval Levy
> On Sep 30, 4:17 pm, Henk Tijdink <h.tijd...@gmail.com> wrote:
> > when you go to the preference screen and
> > you load the defaults the path to the CPG folder is gone and Hugin
> > expects then the control point generators in the Hugin binary folder.
>
> This is because the paths are hard-coded into the hugin binary and
> have nothing to do with the installer.
The hard-coded paths are just defaults in case nothing else is set in the
registry. You can set the registry from the installer, at least this is what
I did back in the 0.7.0 days. The syntax will be different with NSIS, and
there have been changes to the CP generators, but the principle is still the
same. Check out how the old InnoSetup baed installer [0] around line 214
handled it.
> It does however make sense to
> have the binary in the installer revert to the paths used by the
> installer, so I patched the binary to do so. This updated build is
> available here: http://www.box.net/shared/meeaobr9ec
why patch the binaries if it can be done with the installer by simply setting
a couple of registry entries? note: I did not look at your patch, i don't use
Windows.
Yuv
Matthew Petroff
> why patch the binaries if it can be done with the installer by simply setting
> a couple of registry entries?
and what the patch was meant to address, is what happens when the load
defaults button is pressed in settings. Hugin then overwrites the
registry with the hard coded values, values that did not work with the
paths used by the installer.
Matthew
Ken Turkowski
After a make clean and a make, it built without incident.
There were a few warnings:
----------------------------------------------------------------------------------
In file included from /Users/turk/Downloads/hugin-2010.2.0/src/foreign/levmar/misc.c:42:
/Users/turk/Downloads/hugin-2010.2.0/src/foreign/levmar/misc_core.c:566:2: warning: #warning LAPACK not available, LU will be used for matrix inversion when computing the covariance; this might be unstable at times
In file included from /Users/turk/Downloads/hugin-2010.2.0/src/foreign/levmar/misc.c:57:
/Users/turk/Downloads/hugin-2010.2.0/src/foreign/levmar/misc_core.c:566:2: warning: #warning LAPACK not available, LU will be used for matrix inversion when computing the covariance; this might be unstable at times
/Users/turk/Downloads/hugin-2010.2.0/src/foreign/levmar/lmlec.c:39:2: warning: #warning Linearly constrained optimization requires LAPACK and was not compiled!
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/algorithms/basic/CalculateOptimalROI.cpp: In member function ‘int HuginBase::CalculateOptimalROI::autocrop()’:
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/algorithms/basic/CalculateOptimalROI.cpp:334: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/MapPoints.cpp: In function ‘void map_points()’:
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/MapPoints.cpp:182: warning: deprecated conversion from string constant to ‘char*’
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/lensFunc.cpp: In member function ‘const char* lensFunc::camDesc()’:
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/lensFunc.cpp:685: warning: deprecated conversion from string constant to ‘char*’
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/lensFunc.cpp: In member function ‘const char* lensFunc::lensDesc()’:
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/lensFunc.cpp:701: warning: deprecated conversion from string constant to ‘char*’
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/find_N8_lines.cpp: In function ‘int linePts2lineList(vigra::BImage&, int, double, std::vector<std::vector<vigra::Point2D, std::allocator<vigra::Point2D> >, std::allocator<std::vector<vigra::Point2D, std::allocator<vigra::Point2D> > > >&)’:
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/find_N8_lines.cpp:664: warning: deprecated conversion from string constant to ‘char*’
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/find_N8_lines.cpp:665: warning: deprecated conversion from string constant to ‘char*’
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/find_N8_lines.cpp:666: warning: deprecated conversion from string constant to ‘char*’
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/find_N8_lines.cpp:667: warning: deprecated conversion from string constant to ‘char*’
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/lensFunc.cpp: In member function ‘const char* lensFunc::camDesc()’:
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/lensFunc.cpp:685: warning: deprecated conversion from string constant to ‘char*’
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/lensFunc.cpp:685: warning: deprecated conversion from string constant to ‘char*’
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/lensFunc.cpp: In member function ‘const char* lensFunc::lensDesc()’:
/Users/turk/Downloads/hugin-2010.2.0/src/lens_calibrate/lensFunc.cpp:701: warning: deprecated conversion from string constant to ‘char*’
ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, missing required architecture x86_64 in file
ld: warning: in /usr/lib/libwx_macud_gl-2.8.dylib, missing required architecture x86_64 in file
ld: warning: in /usr/lib/libwx_macud-2.8.dylib, missing required architecture x86_64 in file
ld: warning: duplicate dylib /usr/lib/libz.dylib
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h: In function ‘T vigra_ext::zeroNegative(T) [with T = unsigned char]’:
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h:145: instantiated from ‘void vigra_ext::transformImageIntern(vigra::triple<Iterator, Iterator, Accessor>, vigra::triple<DestIter, DestIter, DestAcc>, std::pair<DestImageIterator, DestAccessor>, TRANSFORM&, PixelTransform&, vigra::Diff2D, Interpolator, bool, AppBase::MultiProgressDisplay&) [with SrcImageIterator = vigra::ConstBasicImageIterator<vigra::RGBValue<unsigned char, 0u, 1u, 2u>, vigra::RGBValue<unsigned char, 0u, 1u, 2u>**>, SrcAccessor = vigra::RGBToGrayAccessor<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, DestImageIterator = vigra::BasicImageIterator<float, float**>, DestAccessor = vigra::StandardValueAccessor<float>, TRANSFORM = vigra_ext::RotateTransform, PixelTransform = vigra_ext::PassThroughFunctor<float>, AlphaImageIterator = vigra::BasicImageIterator<float, float**>, AlphaAccessor = vigra::StandardValueAccessor<float>, Interpolator = vigra_ext::interp_cubic]’
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h:566: instantiated from ‘void vigra_ext::transformImageInternMT(vigra::triple<Iterator, Iterator, Accessor>, vigra::triple<DestIter, DestIter, DestAcc>, std::pair<DestImageIterator, DestAccessor>, TRANSFORM&, PixelTransform&, vigra::Diff2D, Interpolator, bool, AppBase::MultiProgressDisplay&) [with SrcImageIterator = vigra::ConstBasicImageIterator<vigra::RGBValue<unsigned char, 0u, 1u, 2u>, vigra::RGBValue<unsigned char, 0u, 1u, 2u>**>, SrcAccessor = vigra::RGBToGrayAccessor<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, DestImageIterator = vigra::BasicImageIterator<float, float**>, DestAccessor = vigra::StandardValueAccessor<float>, TRANSFORM = vigra_ext::RotateTransform, PixelTransform = vigra_ext::PassThroughFunctor<float>, AlphaImageIterator = vigra::BasicImageIterator<float, float**>, AlphaAccessor = vigra::StandardValueAccessor<float>, Interpolator = vigra_ext::interp_cubic]’
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h:665: instantiated from ‘void vigra_ext::transformImage(vigra::triple<Iterator, Iterator, Accessor>, vigra::triple<DestIter, DestIter, DestAcc>, std::pair<DestImageIterator, DestAccessor>, vigra::Diff2D, TRANSFORM&, PixelTransform&, bool, vigra_ext::Interpolator, AppBase::MultiProgressDisplay&) [with SrcImageIterator = vigra::ConstBasicImageIterator<vigra::RGBValue<unsigned char, 0u, 1u, 2u>, vigra::RGBValue<unsigned char, 0u, 1u, 2u>**>, SrcAccessor = vigra::RGBToGrayAccessor<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, DestImageIterator = vigra::BasicImageIterator<float, float**>, DestAccessor = vigra::StandardValueAccessor<float>, AlphaImageIterator = vigra::BasicImageIterator<float, float**>, AlphaAccessor = vigra::StandardValueAccessor<float>, TRANSFORM = vigra_ext::RotateTransform, PixelTransform = vigra_ext::PassThroughFunctor<float>]’
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/Correlation.h:574: instantiated from ‘vigra_ext::CorrelationResult vigra_ext::PointFineTuneRotSearch(const IMAGET&, vigra::Diff2D, int, const IMAGES&, vigra::Diff2D, int, double, double, int) [with IMAGET = vigra::BasicImage<vigra::RGBValue<unsigned char, 0u, 1u, 2u>, std::allocator<vigra::RGBValue<unsigned char, 0u, 1u, 2u> > >, IMAGES = vigra::BasicImage<vigra::RGBValue<unsigned char, 0u, 1u, 2u>, std::allocator<vigra::RGBValue<unsigned char, 0u, 1u, 2u> > >]’
/Users/turk/Downloads/hugin-2010.2.0/src/hugin1/hugin/MainFrame.cpp:1446: instantiated from here
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h:55: warning: comparison is always false due to limited range of data type
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h: In function ‘vigra::RGBValue<VALUETYPE, 0u, 1u, 2u> vigra_ext::zeroNegative(vigra::RGBValue<VALUETYPE, 0u, 1u, 2u>) [with T = unsigned char]’:
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h:145: instantiated from ‘void vigra_ext::transformImageIntern(vigra::triple<Iterator, Iterator, Accessor>, vigra::triple<DestIter, DestIter, DestAcc>, std::pair<DestImageIterator, DestAccessor>, TRANSFORM&, PixelTransform&, vigra::Diff2D, Interpolator, bool, AppBase::MultiProgressDisplay&) [with SrcImageIterator = vigra::ConstBasicImageIterator<vigra::RGBValue<unsigned char, 0u, 1u, 2u>, vigra::RGBValue<unsigned char, 0u, 1u, 2u>**>, SrcAccessor = vigra::RGBAccessor<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, DestImageIterator = vigra::ImageIterator<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, DestAccessor = vigra::RGBAccessor<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, TRANSFORM = ScalingTransform, PixelTransform = vigra_ext::PassThroughFunctor<unsigned char>, AlphaImageIterator = vigra::BasicImageIterator<unsigned char, unsigned char**>, AlphaAccessor = vigra::StandardValueAccessor<unsigned char>, Interpolator = vigra_ext::interp_cubic]’
/Users/turk/Downloads/hugin-2010.2.0/src/hugin1/hugin/CPImageCtrl.cpp:587: instantiated from here
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h:66: warning: comparison is always false due to limited range of data type
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h:145: instantiated from ‘void vigra_ext::transformImageIntern(vigra::triple<Iterator, Iterator, Accessor>, vigra::triple<DestIter, DestIter, DestAcc>, std::pair<DestImageIterator, DestAccessor>, TRANSFORM&, PixelTransform&, vigra::Diff2D, Interpolator, bool, AppBase::MultiProgressDisplay&) [with SrcImageIterator = vigra::ConstBasicImageIterator<vigra::RGBValue<unsigned char, 0u, 1u, 2u>, vigra::RGBValue<unsigned char, 0u, 1u, 2u>**>, SrcAccessor = vigra::RGBAccessor<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, DestImageIterator = vigra::ImageIterator<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, DestAccessor = vigra::RGBAccessor<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, TRANSFORM = ScalingTransform, PixelTransform = vigra_ext::PassThroughFunctor<unsigned char>, AlphaImageIterator = vigra::BasicImageIterator<unsigned char, unsigned char**>, AlphaAccessor = vigra::StandardValueAccessor<unsigned char>, Interpolator = vigra_ext::interp_cubic]’
/Users/turk/Downloads/hugin-2010.2.0/src/hugin1/hugin/CPImageCtrl.cpp:587: instantiated from here
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h:67: warning: comparison is always false due to limited range of data type
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h:145: instantiated from ‘void vigra_ext::transformImageIntern(vigra::triple<Iterator, Iterator, Accessor>, vigra::triple<DestIter, DestIter, DestAcc>, std::pair<DestImageIterator, DestAccessor>, TRANSFORM&, PixelTransform&, vigra::Diff2D, Interpolator, bool, AppBase::MultiProgressDisplay&) [with SrcImageIterator = vigra::ConstBasicImageIterator<vigra::RGBValue<unsigned char, 0u, 1u, 2u>, vigra::RGBValue<unsigned char, 0u, 1u, 2u>**>, SrcAccessor = vigra::RGBAccessor<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, DestImageIterator = vigra::ImageIterator<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, DestAccessor = vigra::RGBAccessor<vigra::RGBValue<unsigned char, 0u, 1u, 2u> >, TRANSFORM = ScalingTransform, PixelTransform = vigra_ext::PassThroughFunctor<unsigned char>, AlphaImageIterator = vigra::BasicImageIterator<unsigned char, unsigned char**>, AlphaAccessor = vigra::StandardValueAccessor<unsigned char>, Interpolator = vigra_ext::interp_cubic]’
/Users/turk/Downloads/hugin-2010.2.0/src/hugin1/hugin/CPImageCtrl.cpp:587: instantiated from here
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/vigra_ext/ImageTransforms.h:68: warning: comparison is always false due to limited range of data type
/Users/turk/Downloads/hugin-2010.2.0/src/hugin1/hugin/GLPreviewFrame.cpp:54:1: warning: "DEBUG_HEADER" redefined
In file included from /Users/turk/Downloads/hugin-2010.2.0/src/hugin1/common/utils.h:27,
from /Users/turk/Downloads/hugin-2010.2.0/src/hugin1/panoinc.h:70,
from /Users/turk/Downloads/hugin-2010.2.0/src/hugin1/hugin/GLPreviewFrame.cpp:41:
/Users/turk/Downloads/hugin-2010.2.0/src/hugin_base/hugin_utils/utils.h:63:1: warning: this is the location of the previous definition
In file included from /usr/include/wx-2.8/wx/mac/glcanvas.h:4,
from /usr/include/wx-2.8/wx/glcanvas.h:60,
from /Users/turk/Downloads/hugin-2010.2.0/src/hugin1/hugin/GLViewer.h:27,
from /Users/turk/Downloads/hugin-2010.2.0/src/hugin1/hugin/GLPreviewFrame.cpp:50:
/usr/include/wx-2.8/wx/mac/carbon/glcanvas.h:49: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48)
/usr/include/wx-2.8/wx/mac/carbon/glcanvas.h:53: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48)
/Users/turk/Downloads/hugin-2010.2.0/src/hugin1/ptbatcher/PTBatcherGUI.cpp: In member function ‘virtual wxChar* BatchIPCConnection::OnRequest(const wxString&, const wxString&, int*, wxIPCFormat)’:
/Users/turk/Downloads/hugin-2010.2.0/src/hugin1/ptbatcher/PTBatcherGUI.cpp:401: warning: deprecated conversion from string constant to ‘wxChar*’
----------------------------------------------------------------------------------
The "deprecated conversion from string constant to ‘char*" can be fixed by using "const char*" in the API.
The "warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’" message is solvable by using "%ld" because it was declared as a long; some other cases might need, e.g. PRId64 from <inttypes.h>.
The "comparison is always false due to limited range of data type" message can probably be ignored.
I got a runtime error when I ran
/usr/local/Applications/Hugin.app
I got a crash window:
----------------------------------------------------------------------------------
Process: Hugin [93945]
Path: /usr/local/Applications/Hugin.app/Contents/MacOS/Hugin
Identifier: net.sourceforge.hugin
Version: 2010.2.0 ()
Code Type: X86-64 (Native)
Parent Process: launchd [141]
Date/Time: 2010-10-05 23:31:03.204 -0700
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6
Interval Since Last Report: 1350563 sec
Crashes Since Last Report: 6
Per-App Crashes Since Last Report: 4
Anonymous UUID: FCEE90EB-7F8D-4ADA-B828-0D21696306B2
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread: 0
Dyld Error Message:
Symbol not found: __ZN12wxConfigBase10ms_pConfigE
Referenced from: /usr/local/lib/libhuginbasewx.0.0.dylib
Expected in: flat namespace
in /usr/local/lib/libhuginbasewx.0.0.dylib
----------------------------------------------------------------------------------
So, it looks like
wxConfigBase::ms_pConfig
is missing.
I found it in
wx-2.8/wx/confbase.h
but it looks like it was just declared inside the class definition, but not allocated outside of the class definition. There needs to be a
wxConfigBase *wxConfigBase::ms_pConfig;
somewhere, perhaps #ifdef'ed by __APPLE__, __linux__, wxMAJOR_VERSION, wxMINOR_VERSION, wxRELEASE_NUMBER, wxSUBRELEASE_NUMBER
Give it at least one more pass before releasing. It would be nice if Hugin could run and successfully stitch a panorama.
-Ken
Ken Turkowski
usr/local/bin$ ./hugin
./hugin: error while loading shared libraries: libhuginbase.so.0.0: cannot open shared object file: No such file or directory
Tim Nugent
--
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
Bruno Postle
> /Users/turk/Downloads/hugin-2010.2.0/src/foreign/levmar/misc_core.c:566:2: warning: #warning LAPACK not available, LU will be used for matrix inversion when computing the covariance; this might be unstable at times
Hugin can be built with or without lapack, but it doesn't seem to
make much difference either way so we don't require it.
>The "deprecated conversion from string constant to ‘char*" can be fixed by using "const char*" in the API.
>
>The "warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’" message is solvable by using "%ld" because it was declared as a long; some other cases might need, e.g. PRId64 from <inttypes.h>.
>
>The "comparison is always false due to limited range of data type" message can probably be ignored.
I'm wary of fixing these at such a late stage in the release cycle
without having a specific bug that is known to effect users. Now is
a good time to fix them in the development 'trunk' though.
>I got a runtime error when I ran
> Symbol not found: __ZN12wxConfigBase10ms_pConfigE
> Referenced from: /usr/local/lib/libhuginbasewx.0.0.dylib
> Expected in: flat namespace
>So, it looks like
> wxConfigBase::ms_pConfig
> is missing.
>
>I found it in
> wx-2.8/wx/confbase.h
>but it looks like it was just declared inside the class definition, but not allocated outside of the class definition. There needs to be a
> wxConfigBase *wxConfigBase::ms_pConfig;
>somewhere, perhaps #ifdef'ed by __APPLE__, __linux__, wxMAJOR_VERSION, wxMINOR_VERSION, wxRELEASE_NUMBER, wxSUBRELEASE_NUMBER
I wonder why this hasn't been reported before, my understanding is
that the OS X build is ok.
Can the OS X builders comment on this? I'm not in a position to do
anything about it since I'm running Hugin on Linux.
--
Bruno
Harry van der Wolf
This has most probably to do with incorrect architecture versions linking against each other. wxmac28 can only be compiled as 32bit on OSX and wxmac29 is not yet supported in Hugin. wxmac28 being 32bit also means that hugin needs to be compiled as 32bit. On Snow Leopard everything is compiled as 64bit by default, also hugin and friends.
Please do a "lipo -info" on your libwxmac* libraries and also on your "libhugin*" libraries and please let us know whether I'm correct.
This "ifdef" rule is definitely not necessary.
This mismatch between 32bit and 64bit has been discussed in a two threads (1,2) regarding recent builds from users also on snow Leopard.
Before cmaking and making hugin do a complete clean of your build directory and then a:
export CFLAGS="-arch i386 -I/opt/local/include -L/opt/local/lib"
export CXXFLAGS="-arch i386 -I/opt/local/include -L/opt/local/lib"
export LDFLAGS="-L/opt/local/lib"
before doing a new cmake/make (this assumes you are using macports, for Fink change accordingly).
With regard to LAPACK: Lapack is slower than LU on OSX, probably because it is not optimized enough. After some "pushing" ;) by
Lukáš Jirkovský last year I did tests on "equal" builds with and without Lapack and I found it didn't bring anything. I also released a bundle with lapack but again, it didn't bring anything extra even though it should in theory.
Harry
1: <http://old.nabble.com/Hugin-2010.3.0-crashes-on-startup-on-OS-X-10.6.4-td29625929r0.html>
2: <http://www.mail-archive.com/hugi...@googlegroups.com/msg10355.html>
Yuval Levy
oh, got it! an ugly but functional workaround would be to store the defaults
in the preferences (windows registry) and then use the load defaults button to
take those stored values rather than the hard coded values. should work on
other systems as well and the extra bloat to the .hugin file (or the windows
registry) is not tragic. Then the installer would modify those values too,
and unless somebody fiddles with the registry (or with the .hugin file) it
should be robust enough.
Yuv
Ken Turkowski
Kornel Benko
> sudo ldconfig does the trick, on Linux.
> This should be n INSTALL_cmake.
Somehow we should manipulate post-install for debian (and maybe for rpm too)
Will try to do for debian at home.
> However, that doesn't help on the Mac:
> sudo: ldconfig: command not found
>
Don't know Mac. But a google search gives:
Q: Is there a parallel command to Linux's LDCONFIG for Mac OS X's Terminal?
A: The answer is no. But you can still configure the search path via environment variables, see dyld(1).
Since I don't have Mac, I give up here.
Kornel
Harry van der Wolf
ldconfig or something similar isn't necessary on OSX. OSX uses a completely different mechanism where the path to dependent libraries is always set as metadata in the library.
For example: when I do a "otool -L /usr/local/lib/libhuginbasewx.0.0.dylib" (the mentioned library in Kens post), I get:
/usr/local/lib/libhuginbasewx.0.0.dylib:
/usr/local/lib/libhuginbasewx.0.0.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 15.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 1742.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libwx_macu_gl-2.8.0.dylib (compatibility version 8.0.0, current version 8.0.0)
/opt/local/lib/libwx_macu-2.8.0.dylib (compatibility version 8.0.0, current version 8.0.0)
/usr/local/lib/libhuginbase.0.0.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_date_time-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_regex-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_filesystem-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_iostreams-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libpano13.2.dylib (compatibility version 3.0.0, current version 3.0.0)
/opt/local/lib/libGLEW.1.5.1.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libhuginvigraimpex.0.0.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libjpeg.8.dylib (compatibility version 9.0.0, current version 9.2.0)
/opt/local/lib/libImath.6.dylib (compatibility version 7.0.0, current version 7.0.0)
/opt/local/lib/libIlmImf.6.dylib (compatibility version 7.0.0, current version 7.0.0)
/opt/local/lib/libIex.6.dylib (compatibility version 7.0.0, current version 7.0.0)
/opt/local/lib/libHalf.6.dylib (compatibility version 7.0.0, current version 7.0.0)
/opt/local/lib/libIlmThread.6.dylib (compatibility version 7.0.0, current version 7.0.0)
/opt/local/lib/libpng12.0.dylib (compatibility version 45.0.0, current version 45.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/local/lib/libmakefilelib.0.0.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libexiv2.6.dylib (compatibility version 7.0.0, current version 7.0.0)
/opt/local/lib/libtiff.3.dylib (compatibility version 13.0.0, current version 13.4.0)
/System/Library/Frameworks/GLUT.framework/Versions/A/GLUT (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
OSX doesn't need ldconfig. Every library/binary knows exactly where to find which other dependent library.
And in case you want to change that, e.g. for a bundle, you use the install_name_tool.
Please have a look at which architectures are in your libs as mentioned in my previous post.
Harry
Andreas Metzler
> Hugin is a Panorama stitcher and more. A powerful software package
> for creating and processing panoramic images.
> A hugin-2010.2.0_rc2 (release candidate 2) tarball is available here:
> https://sourceforge.net/projects/hugin/files/hugin-2010.2_beta/
> This is a release candidate, i.e. The final release may be identical.
[...]
FWIW: Debian packages are available in experimental, works-for-me
backports for lenny in http://www.bebt.de/debian/dists/lenny/hugin-latest/
cu andreas