It's the first new release in a while and has quite a few improvements and I think some dependancy changes as well. Won't be a trivial version bump I don't think.
Created attachment 92733 [details] hugin-0,6.ebuild file Here is an initial version of an ebuild for hugin-0.6. This is basicaly the hugin-0.5 ebuild with some small changes. To get this to work boost now needs to be build with the use="threads" otherwise the hugin build will fail. One of Hugins new features is that it will take advantage of more than one processor. This makes stiching and previews much faster on machines with dual core processors or with more than one processor. With boost emerged with use="thread" this ebuild will build and install hugin 0.6. The only testing I have done so far is to emerge hugin and to see if it would run (it does). I have not done any stitches with this version yet. But I have been running CVS (from about a month ago) and this was working fine so I don't think 0.6 will have any problems. I am running on an amd64 machine and I think that when 0.6 goes into the portage tree is should be marked ~amd64, ~x86 and ~ppc just like 0.5 is now. I also think 0.5 should be marked amd64, x86 and ppc at this time.
This ebuild worked for me, also used it to stitch one 360 degree picture and it seems to work fine.
also according to mailing list announcement "This release works best with panotools version 2.8.4."
by that he means: media-libs/libpano12-2.8.4 which is already set to that version...sorry I was mixing up pano with autopano
autopano-sift integration is broken in hugin 0.6, it was fixed the 2006-07-25 We are waiting a possible 0.6.1 version with autopanosift ok.
Just curious, as I am going to do a few panoramas from my holidays tonight. Is it a bug with autopano-sift integration? Or is it a bug with importing the pto file generated from autopano-sift? I usually run autopano-sift standalone first and then open the generated .pto file in hugin afterwards. Should I stick with 0.5? By the way, 0.6 took up a ton of memory when it was building! Watch out. My machine locked up and I had to close all of my other programs until I could move the mouse without it stuttering.
Emmanuel, I see your post on the ptx mailing list now. I'm still unclear how you use autopano-sift with hugin. I have always used them independantly...
Just used hugin-0.6 tonight and it worked great.
Awesome so far. I just did about 6 panoramas last night and no problems. Can some please bump this in portage with ~x86 keyword and marked fixed. Thanks.
I can't get this to build properly at all, I'm uncertain if it has to do with the modular Xorg 7.0 which was marked stable, and I upgraded recently. But anyway check this thread on the forum for details on the errors. http://forums.gentoo.org/viewtopic-p-3494796.html#3494796
Created attachment 94178 [details, diff] Fix the bug that breaks the usage of autopano-sift in hugin-0.6 This is the patch that solve the autopano import bug. Update the ebuild to apply the patch if you want. Anyway, 0.6.1 is coming soon.
I just made an ebuild myself for 0.6 and noticed a few differences to the ebuild contained here: 1) I had an old libpano12 installed and hugin's configure complained it needed at leas version 2.8.1 -- so I changed that. the ebuild here uses 2.8.4... is there a specific reason for that? 2) configure also complained about being unable to find libpano at all so my econf line looks like this: econf --with-wx-config="${WX_CONFIG}" --with-pano="/usr/include/pano12" ${myconf} || die "configure failed" ... still compiling
The mailing list announcement upstream said >=2.8.4 was necessary. Looks like their configure script has not been updated to reflect that. Do you always make ebuilds for yourself even though they are already available on bugzilla?
No I don't, just forgot about bugs.gentoo.org :-)
Created attachment 94432 [details, diff] Fix the bug that breaks the usage of autopano-sift in hugin-0.6 Removed header-hunk as suggested here: http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/epatch/index.html
Created attachment 94433 [details] hugin-0,6.ebuild file includes the patch
Autpano provides a wrapper script which invokes mono. Autopano in hugin would fail because there's no executable "autopanog.exe". So to make it work, I created a file /usr/bin/autopanog.exe with this content: --- #!/bin/bash /usr/bin/autopano --- just symlinking autopanog.exe -> autopano would result in the following message: --- cannot open assembly /usr/lib/autopano-sift/autopanog.exe.exe --- Ok, now I can invoke autopano from within hugin but get the help message on the console I started hugin... The parameters shown in the error message and those from the help message don't match at all... (this is like the fifth attempt to post this message - the message would not show up and the server takes forever to do... well, nothing)
ok, just ignore my last message... I probably had a messed-up ~/.hugin file, after deleting, hugin uses "autopanog" by default which is fine and works perfectly... so, how do we get this new version into the main portage tree? setting to test-request or upstream and hope someone's gonna do something?
Created attachment 94785 [details] hgin-0.6.1.ebuild Hugin 0.6.1 was released over the week end. Here is an ebuild for it. Here is some info from the anouncement: Newsworthy changes in 0.6.1 --------------------------- * fixed Autopano-SIFT integration on Unix and OSX (it was broken in 0.6). * Support for displaying HDR images within hugin, using log or gamma mapping * .hdr file support (tif HDR image files have been always useable) * reduced memory usage, better image caching strategy. * fixed crashes and hangs when using the preview auto update and avoid unnessecary remapping of images. * vignetting correction estimation speed up. * nona and nona_gui can be used to do template stitching, by specifying images on the command line (or dnd shortcut under windows) * distribute fulla.exe with windows package (it was accidentally not included in the 0.6 package) * universal build for Intel Macs, fixed hang after enblend or autopano-sift call * projection can be changed in preview. * removed all references to malicious panotools.info website * various smaller bugfixes
*** Bug 145392 has been marked as a duplicate of this bug. ***
Rather than file a new bug, I'll just mention it here. Hugin should not depend on autopano-sift, it is not strictly necessary.
I just tested the 0.6.1 ebuild on my x86 laptop. I didn't encounter real problems and made a few successful stitches. The compilation of some files takes rather long and uses a lot of memory. e.g. this one: i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../src/include -I../../src/include -I../../src/foreign -pthread -I/usr/include -DHasPANO -march=pentium4 -O3 -pipe -fomit-frame-pointer -MT Stitcher2.lo -MD -MP -MF .deps/Stitcher2.Tpo -c Stitcher2.cpp -o Stitcher2.o
(In reply to comment #19) > Hugin 0.6.1 was released over the week end. Here is an ebuild for it. Here is Maybe you can add a check for boots to be compiled with thread support? Otherwise hugin will fail to build. Thanks.
(In reply to comment #23) > (In reply to comment #19) > > Hugin 0.6.1 was released over the week end. Here is an ebuild for it. Here is > > Maybe you can add a check for boots to be compiled with thread support? > Otherwise hugin will fail to build. Thanks. > Even though I do have boost compiled with the threads use-flag, I still get a compile error complaining about boost not having a thread_group() function: # emerge boost -pv These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] dev-libs/boost-1.33.1 USE="threads -bcp -bjam -debug -doc -pyste -static -threadsonly" 11,237 kB Stitcher4.cpp:(.text._ZN9vigra_ext27transformImageAlphaInternMTIN5vigra23ConstBasicImageIteratorINS1_8RGBValueIjLj0ELj1ELj2EEEPPS4_EENS1_11RGBAccessorIS4_EENS2_IhPPhEENS1_26StandardConstValueAccessorIhEENS1_18BasicImageIteratorIS4_S6_EES9_N6PTools9TransformENSF_IhSB_EENS1_21StandardValueAccessorIhEENS_15interp_spline36EEEvNS1_6tripleIT_SO_T0_EESt4pairIT1_T2_ENSN_IT3_SV_T4_EESR_IT6_T7_ERT5_NS1_6Diff2DET8_bRN5utils20MultiProgressDisplayE[void vigra_ext::transformImageAlphaInternMT<vigra::ConstBasicImageIterator<vigra::RGBValue<unsigned int, 0u, 1u, 2u>, vigra::RGBValue<unsigned int, 0u, 1u, 2u>**>, vigra::RGBAccessor<vigra::RGBValue<unsigned int, 0u, 1u, 2u> >, vigra::ConstBasicImageIterator<unsigned char, unsigned char**>, vigra::StandardConstValueAccessor<unsigned char>, vigra::BasicImageIterator<vigra::RGBValue<unsigned int, 0u, 1u, 2u>, vigra::RGBValue<unsigned int, 0u, 1u, 2u>**>, vigra::RGBAccessor<vigra::RGBValue<unsigned int, 0u, 1u, 2u> >, PTools::Transform, vigra::BasicImageIterator<unsigned char, unsigned char**>, vigra::StandardValueAccessor<unsigned char>, vigra_ext::interp_spline36>(vigra::triple<vigra::ConstBasicImageIterator<vigra::RGBValue<unsigned int, 0u, 1u, 2u>, vigra::RGBValue<unsigned int, 0u, 1u, 2u>**>, vigra::ConstBasicImageIterator<vigra::RGBValue<unsigned int, 0u, 1u, 2u>, vigra::RGBValue<unsigned int, 0u, 1u, 2u>**>, vigra::RGBAccessor<vigra::RGBValue<unsigned int, 0u, 1u, 2u> > >, std::pair<vigra::ConstBasicImageIterator<unsigned char, unsigned char**>, vigra::StandardConstValueAccessor<unsigned char> >, vigra::triple<vigra::BasicImageIterator<vigra::RGBValue<unsigned int, 0u, 1u, 2u>, vigra::RGBValue<unsigned int, 0u, 1u, 2u>**>, vigra::BasicImageIterator<vigra::RGBValue<unsigned int, 0u, 1u, 2u>, vigra::RGBValue<unsigned int, 0u, 1u, 2u>**>, vigra::RGBAccessor<vigra::RGBValue<unsigned int, 0u, 1u, 2u> > >, std::pair<vigra::BasicImageIterator<unsigned char, unsigned char**>, vigra::StandardValueAccessor<unsigned char> >, PTools::Transform&, vigra::Diff2D, vigra_ext::interp_spline36, bool, utils::MultiProgressDisplay&)]+0xd4b): undefined reference to `boost::thread_group::~thread_group()' collect2: ld returned 1 exit status make[3]: *** [nona_gui] Fehler 1 make[3]: Leaving directory `/var/tmp/portage/hugin-0.6.1/work/hugin-0.6.1/src/nona_gui' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/var/tmp/portage/hugin-0.6.1/work/hugin-0.6.1/src/nona_gui' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/var/tmp/portage/hugin-0.6.1/work/hugin-0.6.1/src' make: *** [all-recursive] Fehler 1 !!! ERROR: media-gfx/hugin-0.6.1 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile hugin-0.6.1.ebuild, line 44: Called die !!! compiling failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! This ebuild is from an overlay: '/usr/local/portage'
hugin-0.6.1.ebuild compiles and works fine on amd64 I did an emerge boost with USE="threads" before
For me it says that 'execute_stack_new' was not declared in this scope. This comes from libpano, I have version media-libs/libpano12-2.8.4 Making all in Panorama make[2]: se ingresa al directorio `/var/tmp/portage/hugin-0.6.1/work/hugin-0.6.1/src/Panorama' if /bin/sh ../../libtool --mode=compile i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H "-I." -I../../src/include -I../../src/include -I../../src/foreign -pthread -I/usr/include -DHasPANO -march=athlon-xp -O2 -pipe -MT Panorama.lo -MD -MP -MF ".deps/Panorama.Tpo" \ -c -o Panorama.lo `test -f 'Panorama.cpp' || echo './'`Panorama.cpp; \ then mv -f ".deps/Panorama.Tpo" ".deps/Panorama.Plo"; \ else rm -f ".deps/Panorama.Tpo"; exit 1; \ fi i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../src/include -I../../src/include -I../../src/foreign -pthread -I/usr/include -DHasPANO -march=athlon-xp -O2 -pipe -MT Panorama.lo -MD -MP -MF .deps/Panorama.Tpo -c Panorama.cpp -o Panorama.o ../../src/include/PT/PanoToolsInterface.h: In member function 'bool PTools::Transform::transform(double&, double&, double, double) const': ../../src/include/PT/PanoToolsInterface.h:174: error: 'execute_stack_new' was not declared in this scope ../../src/include/PT/PanoToolsInterface.h: In member function 'bool PTools::Transform::transformImgCoord(double&, double&, double, double) const': ../../src/include/PT/PanoToolsInterface.h:187: error: 'execute_stack_new' was not declared in this scope ../../src/include/PT/PanoToolsInterface.h: In member function 'bool PTools::Tran sform::transform(FDiff2D&, const FDiff2D&) const': ../../src/include/PT/PanoToolsInterface.h:202: error: 'execute_stack_new' was not declared in this scope make[2]: *** [Panorama.lo] Error 1 make[2]: se sale del directorio `/var/tmp/portage/hugin-0.6.1/work/hugin-0.6.1/src/Panorama' make[1]: *** [all-recursive] Error 1 make[1]: se sale del directorio `/var/tmp/portage/hugin-0.6.1/work/hugin-0.6.1/src' make: *** [all-recursive] Error 1 !!! ERROR: media-gfx/hugin-0.6.1 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile hugin-0.6.1.ebuild, line 44: Called die !!! compiling failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! This ebuild is from an overlay: '/usr/local/portage' I will try to provide more info if it's needed.
(In reply to comment #21) > Rather than file a new bug, I'll just mention it here. Hugin should not depend > on autopano-sift, it is not strictly necessary. > In addition, Hugin should not depend on enblend for the same reason. Perhaps sift and enblend useflags would be a better solution.
(In reply to comment #24) > ... > Even though I do have boost compiled with the threads use-flag, I still get a > compile error complaining about boost not having a thread_group() function: > I am also running into this problem. However, I have compiled Hugin from CVS and the process still generates a working binary even though the compilation stops with that error. I am going to post this error to the mailing list for Hugin and see what upstream makes of it.
Created attachment 104483 [details] new version with a lot of enhancement hugin-0.7_beta1 ebuild for 0.7_beta1
Thank you for update hugin-0.7_beta1 ebuild compiles and works fine under amd64 new assistant seems to be comfortable, did not tested other new features so far
Created attachment 106905 [details] new beta version this ebuild is broken, only for debuggers!
I forgo to say you can try the libpano13 taht may work with hugin in a short future. You can have a look at http://bugs.gentoo.org/show_bug.cgi?id=24922
(In reply to comment #24) I finally fixed this issue on my computer by first unmerging libpano12, wxGTK, and hugin. Then I emerged the new hugin-0.7_beta3 and everything built properly.
0.6.1 emerges fine and it is quite stable (0.5 crashes very often). Please add it into the portage tree.
*** Bug 164676 has been marked as a duplicate of this bug. ***
Created attachment 109064 [details] ebuild for hugin 0.7_beta4 Here is an ebuild for the latest version of Hugin.
hugin-0.7_beta4 works well for me with libpano13 and enblend-3.0 which really speeds up the blending process. As noted above, you can find the libpano13 ebuild at bug #24922 and the enblend-3.0 ebuild at bug #164677.
hugin 0.7_beta4 compiles a little bit hard on my system, however hugin works fine on amd64. compilation eats up my ram (2GB) and uses 1-2 GB of swap - a normal behavior? I am using libpano12 and enblend-3.0 (great performance improvement from 2.x to 3.0) --------------------------- Portage 2.1.1-r2 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.4-r4, 2.6.19-gentoo-r5 x86_64) ================================================================= System uname: 2.6.19-gentoo-r5 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ ---------------------------
(In reply to comment #38) > hugin 0.7_beta4 compiles a little bit hard on my system, however hugin works > fine on amd64. > compilation eats up my ram (2GB) and uses 1-2 GB of swap - a normal behavior? Yea, compiling the Stitcher*.cpp files always causes g++ to use large amounts of memory. If you read through the source code at all, a comment in the src/include/PT/Stitcher.h file shows that the developer(s) split up the stitching functions to reduce memory consumption. However, g++ still grabs pretty much everything, which can leave older machines with small amounts of memory seemingly locked up for hours compiling the Stitcher*.cpp files.
Hi folks, I was looking at the hugin docs, and apparently autopano-sift is not a build dependency, it is an *optional* runtime dependency for automatic control point generation. Could we please have this made toggled by a USE flag? I don't use autopano-sift, and hate having to pull down all of Mono just to use hugin. Thanks!
(In reply to comment #40) > Hi folks, I was looking at the hugin docs, and apparently autopano-sift is not > a build dependency, it is an *optional* runtime dependency for automatic > control point generation. Could we please have this made toggled by a USE flag? > I don't use autopano-sift, and hate having to pull down all of Mono just to use > hugin. Check out comment #21 and comment #27. Both autopano-sift and enblend aren't strictly needed. I also do not like all the Mono deps that autopano-sift drags down. Should useflags be used for both with einfo statements telling the user of missing functionality? Along these lines, if anyone is experienced in programming with C and is interested in porting autopano-sift, check out autopano-sift-C from hugin's sf.net CVS tree (or you can browse online at http://hugin.cvs.sourceforge.net/hugin/). Apparently, most of the work is already done; however, there are a few bugs left to work out.
I can certainly echo the resource usage of #38 on emerge. I found adding: MAKEOPTS="-j1" kept it bearable.
Hi guys, I just bumped 0.6.1 in cvs. I added sift and hugin USE flags to make their usage optional. It is currently in package.mask for testing. Please comment :-). Cheers, Marcelo
The new hugin-0.6.1.ebuild in portage looks pretty good to me. However, I haven't tried building it as I am working with the latest beta release. One improvement I would make for users that are new to hugin would be to explain a bit more about what enblend and autopano-sift will do for them. Users who are always griping about bloat might not be convinced of the usefulness of the two packages without a more thorough explanation. I know that users can look up each package definition; however, the definitions are somewhat technical and some users might be too lazy to do that ;). Thus, the einfo for enblend could be expanded to something like this: It is recommended to emerge this package with the enblend use flag to install media-gfx/enblend that blends the seams between images in a panorama. And the einfo for the sift useflag could be expanded to something like this: It is recommended to emerge this package with the sift use flag to install media-gfx/autopano-sift that produces control points between images in a panorama. Thanks for finally getting this in portage, Tim
0.6.1 portage version emerged fine here (~amd64 with both enblend and autopano), I assembled some panoramas with it without a problem (no crash so far!)
Added Tim's suggestion to einfo, unmasked hugin-0.6.1. Thanks guys! We don't normally support beta releases, so I'd rather wait for 0.7.x to be released before adding it to the tree. Cheers!
The meaning of beta varies from project to project. A Debian "beta" would be considered "hardened" elsewhere. ;-) The authors consider hugin to be "stable and recommended for general use". I'd be in favour of adding it to the Portage tree, if only because we can gather experience with it, though I can understand it if you'd rather give it a few more days...
Created attachment 112726 [details] hugin-0.7_beta4 build failure I am still getting build failures with both 0.6 and 0.7 series :( Boost is compiled with threads.
(In reply to comment #48) > Created an attachment (id=112726) [edit] > hugin-0.7_beta4 build failure > > I am still getting build failures with both 0.6 and 0.7 series :( > > Boost is compiled with threads. > It appears you are running into the same problem that a couple of us mentioned earlier. The solution I found was to unmerge libpano12, wxGTK, and hugin. Then emerging hugin again should work fine (see comment 33). I think the problem arises from old wxGTK builds interacting with the hugin compile. I found it strange that simply remerging wxGTK didn't work for me. I had to totally unmerge it and the recompile all packages for hugin to work. If someone has a good explanation of what causes this problem, I would be interested in hearing it.
Created attachment 113059 [details, diff] hugin-missing-boost-lib.patch Patch to fix the build failures.. (probably should be sent upstream)
I would like to confirm that the ebuild for 0.7.4beta from Hal (post #36) works fine for me. The application also seems to run fine, I have tested it on two panoramas. Prior to emerging, I unmerged all dependencies and built them again. I did not experience any stalling in the compilation process as reported, with standard settings (MAKEOPTS="-j2") and less RAM than others (1.3G). I created a private overlay for the time being, until hugin gets out of the beta. Thanks for the ebuild, Hal.
Okies, I added 0.7_beta4 to the tree, in package.mask for now. Thanks everyone! Cheers, Marcelo
(In reply to comment #52) > Okies, I added 0.7_beta4 to the tree, in package.mask for now. > Thanks everyone! > > Cheers, > Marcelo > Just a heads up on this (masked) package. Seems boost nolonger has a 'threads' useflag ( ~ 1.34.0 ) I commented out the 'build_with_use' code from the ebuild and tried with that. <snip> boost found </snip> <snip> checking whether the Boost::Thread library is available... yes </snip> <snip> checking for main in -lboost_thread-mt... yes </snip> <snip> boost_version = 103400 BOOST_CPPFLAGS = -pthread -I/usr/include BOOST_LIBS = BOOST_THREAD_LIB = -lboost_thread-mt </snip> Compiles Fine tho. You /may/ want to put a notice in the ebuild about the wxGTK/libpano12 thing just for users :), cos the 'remove em both' trick worksforme
