Bugzilla Bug 141617

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 an attachment (id=92733) [edit]
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 an attachment (id=94178) [edit]
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 an attachment (id=94432) [edit]
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 an attachment (id=94433) [edit]
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 an attachment (id=94785) [edit]
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 an attachment (id=104483) [edit]
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 an attachment (id=106905) [edit]
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 an attachment (id=109064) [edit]
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 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.

(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 an attachment (id=113059) [edit]
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