I got hugin 0.7beta4 running on the latest ubuntu release 7.10.
I would like to use the new automatic exposure optimizer but cannot
find the "exposure tab".
Do I have to wait for a beta 5 release or is there a build problem in
ubuntu ?
On Tue 27-Nov-2007 at 13:44 -0800, Stefan F. wrote:
>I got hugin 0.7beta4 running on the latest ubuntu release 7.10. >I would like to use the new automatic exposure optimizer but cannot >find the "exposure tab".
Beta 4 was released in February and I think the 'Exposure tab' was added since then.
Maybe someone has packaged a newer version for Ubuntu? ..or you could compile from SVN:
Refering to step2:
"In a i386 system the equivalent is probably (COULD SOMEBODY
CHECK THIS ONE?)" ...
I checked it, result = "0 upgraded, 0 newly installed, 0 to remove and
14 not upgraded."
The libraries of step 2 are already installed in step 1. But step 2
does no harm.
I got problems, when building enblend:
enblend-gpu.o: In function `wrapupGPU()': enblend/src/gpu.cc:289:
undefined reference to `glutDestroyWindow'
enblend-gpu.o: In function `initGPU(int*, char**)':
enblend/src/gpu.cc:120: undefined reference to `glutInit'
enblend/src/gpu.cc:121: undefined reference to
`glutInitDisplayMode'
enblend/src/gpu.cc:122: undefined reference to `glutCreateWindow'
enblend/src/gpu.cc:148: undefined reference to `glutDestroyWindow'
collect2: ld returned 1 exit status
To build hugin I needed 2 more packages:
I installed "libwxgtk2.8-dev" and 2 related packages with synaptic
package manager
I installed "gettext" with synaptic package manager to get the
"msgfmt" program
I guessed this warning does not affect me...
#warning Linearly constrained optimization requires LAPACK and
was not comp
The hugin build was aborted:
hugin/src/hugin1/hugin/po/it.po:1033: `msgid' and `msgstr'
entries do not both end with '\n'
/usr/bin/msgfmt: found 1 fatal error
I still tried sudo make install - but now hugin will not start
anymore.
The /usr/bin/hugin executable has still an old date (Nov. 20., but I
compiled on Nov. 28).
I will have to try once more to get some more exeperience with the
build process...
On my second try I could build hugin thanks to the latest revision
(correction of the italian translation).
But I still can't start hugin:
hugin: error while loading shared libraries: libhuginbase.so.0.0:
cannot open shared object file: No such file or directory
The library has been installed to /usr/local/lib
Probably I should set a search path to give priority to my own built
applications (/usr/local/) as there are still several hugin files
installed in usr/bin from the first install of hugin through the
ubuntu package manager.
As I'm not an experienced linux user I don't know how to set up these
path.
- or do I have to uninstall the original hugin with the ubuntu
package manager?
By the way I even had troubles to find "terminal" (it is under
Applications.Accessories.Terminal)
This would be helpful to mention on the <http://wiki.panotools.org/ Hugin_Compiling_Ubuntu> page.
On Sat 01-Dec-2007 at 02:24 -0800, Stefan F. wrote:
>On my second try I could build hugin thanks to the latest revision >(correction of the italian translation). >But I still can't start hugin: > hugin: error while loading shared libraries: libhuginbase.so.0.0: >cannot open shared object file: No such file or directory >The library has been installed to /usr/local/lib >As I'm not an experienced linux user I don't know how to set up these >path.
The ultimate solution is to get some .deb snapshot packages released, as there is no need for everybody to have to jump through these hoops.
The problem as you discovered is that your system doesn't look for libraries in /usr/local/lib.
You can get this to work on your system by setting the LD_LIBRARY_PATH environment variable or by adding the path to /etc/ld.so.conf
(please somebody correct me if this isn't the right advice for ubuntu)
Well.. It's not really finished.. I still got a problem when building
enblend:
enblend-gpu.o: In function `initGPU(int*, char**)':
undefined reference to `glutInit' , `glutDestroyWindow' ... and
some more
After "./configure" I found the following warning:
checking for GLUT library... no
configure: WARNING: WARNING: GL/GLU/GLUT not found, disabling GPU
mode
I'm finding header files under /usr/include/GL (glut.h,
freeglut.h ...)
I'm finding libraries under /usr/lib (libGL.so.1.0.9639, libGLU.so.
1.3.070001, libglut.so.3.8.0 and some links to it)
I fiddeled around with installing and uninstalling the packages:
freeglut3-dev, libglut3-dev and glutg3-dev but was not successful.
When getting the libraries as described below, both packages freeglut3-
dev and libglut3-dev are installed.
sudo apt-get install pkg-config libtiff4-dev libboost-graph-
dev libboost-thread-dev \
liblcms1-dev libglew-dev libplot-dev
libglut3-dev libopenexr-dev libopenexr2c2a
Maybe it shouldn't build "enblend-gpu.o" at all ..?
So I'm quite lost here and can't build enblend under ubuntu.
> Well.. It's not really finished.. I still got a problem when building > enblend: > enblend-gpu.o: In function `initGPU(int*, char**)': > undefined reference to `glutInit' , `glutDestroyWindow' ... and > some more
Since I have no problems here with kubuntu, I searched for this reference. Here it is in "/usr/lib/libglut.so.3", which is a part of "freeglut3"-package. (This is _not_ freeglut3-dev)
> After "./configure" I found the following warning:
> checking for GLUT library... no > configure: WARNING: WARNING: GL/GLU/GLUT not found, disabling GPU > mode
> I'm finding header files under /usr/include/GL (glut.h, > freeglut.h ...) > I'm finding libraries under /usr/lib (libGL.so.1.0.9639, libGLU.so. > 1.3.070001, libglut.so.3.8.0 and some links to it)
> I fiddeled around with installing and uninstalling the packages: > freeglut3-dev, libglut3-dev and glutg3-dev but was not successful. > When getting the libraries as described below, both packages freeglut3- > dev and libglut3-dev are installed. > sudo apt-get install pkg-config libtiff4-dev libboost-graph- > dev libboost-thread-dev \ > liblcms1-dev libglew-dev libplot-dev > libglut3-dev libopenexr-dev libopenexr2c2a
> Maybe it shouldn't build "enblend-gpu.o" at all ..?
> So I'm quite lost here and can't build enblend under ubuntu.
Bruno Postle wrote: > On Sat 01-Dec-2007 at 17:12 -0800, Stefan F. wrote: >> enblend-gpu.o: In function `initGPU(int*, char**)': >> undefined reference to `glutInit' , `glutDestroyWindow' ... and
>> After "./configure" I found the following warning:
>> checking for GLUT library... no >> configure: WARNING: WARNING: GL/GLU/GLUT not found, disabling GPU >> mode
> I had the same problem on fc8 x86_64 and got it to compile by > starting with a fresh enblend CVS checkout.
> Though now I get the same error building in a mock chroot with all > the right headers/libraries installed, so there is something else > going on here.
Make sure that you have x86_64 libraries installed.
>>> checking for GLUT library... no >>> configure: WARNING: WARNING: GL/GLU/GLUT not found, disabling GPU >>> mode > Make sure that you have x86_64 libraries installed.
> [root@kursk lib]# yum list mesa-libGL mesa-libGLU
Thanks, I had them. I eventually figured out the full list of packages required to compile enblend, these packages and their dependencies are required to build 3.0 on fedora:
For enblend 3.0 the following packages with similar name and
description are already installed on ubuntu:
(libtif4-dev, libboost-dev, liblcms1-dev, libplot-dev, freeglut3-dev,
libglew1.4-dev)
Also for 3.1: (libjpeg62-dev, libpng12-dev)
The only missing library was "libxi-dev" - after installin this one I
could compile - uff!
thanks again Bruno !!!
Now my odyssey has nearly ended.
Nearly - because when I want to stich a panorama from hugin I
immediately get the message
"Error while executing process"
From a terminal I can start nona and enblend - they print there
command line help message.
On Wed 05-Dec-2007 at 12:10 -0800, Stefan F. wrote:
>Now my odyssey has nearly ended. >Nearly - because when I want to stich a panorama from hugin I >immediately get the message >"Error while executing process" >From a terminal I can start nona and enblend - they print there >command line help message.
Don't know what this might be, though you can test to see if any of the tools are failing by stitching the project directly with 'make':
Save (without stitching), you should get a 'project.pto.mk' Makefile as well as the 'project.pto' file. In a terminal, run 'make' like so:
cd /path/to/folder make -f project.pto.mk
This should give you some idea where the problem is.
On Thu 06-Dec-2007 at 13:23 -0800, Stefan F. wrote:
>PTmender -o IMG_8490-IMG_8496 /home2/stefan/Pictures/2007/2007_08_12\ Chillagoe/2.\ Wahl/IMG_8490-IMG_8496.pto >PTmender Version 2.9.12 , originally written by Helmut Dersch, rewritten by Daniel German >Illegal token in 'p'-line [69] [E] [E-0.607398 R0 n"TIFF_m c:DEFLATE r:CROP"] >Illegal token in 'p'-line [82] [R] [R0 n"TIFF_m c:DEFLATE r:CROP"]
It looks like PTmender doesn't know about the new E & R parameters, so it refused to do the stitch.
Is there any reason why you are using 'PTmender' instead of 'nona' as your stitcher? 'nona' should be the default.
I switched from 'nona' to 'PTmender' and back to 'nona' again.
I probably have saved the project with 'PTmender' once before.
I'm not shure if there was another (now solved) problem:
My initial problem "Error while executing process" may also happen
when
wrong executables from 'hugin/src/hugin1/tools/' are installed.
(as described in another post)
The correct come from 'hugin/src/tools/'.
Currently there is a missing file in SVN:
error while making hugin:
hugin/src/hugin1/base_wx/platform.cpp:29:37: error: CoreFoundation/
CFBundle.h: No such file or directory
Not to forget the success - my first panorama with automatic exposure
blending has been created !
> The ultimate solution is to get some .debsnapshot packages
> released, as there is no need for everybody to have to jump through
> these hoops.
That would be great!
> The problem as you discovered is that your system doesn't look for
> libraries in /usr/local/lib.
I think the debian rules prevents the use of /usr/local for anything
but system admin stuff (ie. root only I guess), and the .deb
maintainers are told to move files where they belong. I do see the
logic in using /usr/local for local builds though (http://
en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard). The fact that
debian (and derivates) does not look there at all is a major pain in
the butt. Must remember to --prefix=/usr on everyting one bulids.
On Sat 15-Dec-2007 at 10:54 -0800, Morgan.Torv...@gmail.com wrote:
> I do see the logic in using /usr/local for local builds though > (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard). The > fact that debian (and derivates) does not look there at all is a > major pain in the butt. Must remember to --prefix=/usr on > everyting one bulids.
Using `make install` to put something like hugin into /usr isn't such a good idea as there is no easy way to remove all the files at a later date. On debian/ubuntu you can use `checkinstall` which will do the right thing and give you something you can remove with dselect (or whatever you use these days on debian for package management).
> Using `make install` to put something like hugin into /usr isn't
> such a good idea as there is no easy way to remove all the files at
> a later date. On debian/ubuntu you can use `checkinstall` which
> will do the right thing and give you something you can remove with
> dselect (or whatever you use these days on debian for package
> management).
Does this mean that hugin does not have a "make uninstall" option?
Surely, the number and names of executables and libraries does not
change so often that this should be difficult to maintain?
> > The ultimate solution is to get some .debsnapshot packages > > released, as there is no need for everybody to have to jump through > > these hoops.
> That would be great!
> > The problem as you discovered is that your system doesn't look for > > libraries in /usr/local/lib.
> I think the debian rules prevents the use of /usr/local for anything > but system admin stuff (ie. root only I guess), and the .deb > maintainers are told to move files where they belong. I do see the > logic in using /usr/local for local builds though (http:// > en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard). The fact that > debian (and derivates) does not look there at all is a major pain in > the butt. Must remember to --prefix=/usr on everyting one bulids.
Hi Morgan, this is not needed. Look at your configuration file "/etc/ld.so.conf". There should be a line like include /etc/ld.so.conf.d/*.conf Now you could create a file (e.g. /etc/ld.so.conf.d/local.conf) with a simple line /usr/local/lib Then call sudo ldconfig and you are done.
On Sun 16-Dec-2007 at 01:38 -0800, Morgan.Torv...@gmail.com wrote:
> Does this mean that hugin does not have a "make uninstall" option? > Surely, the number and names of executables and libraries does not > change so often that this should be difficult to maintain?
It doesn't and maybe it should, but even if it did this would be very fragile - On most linux distributions /usr is maintained entirely by the package management system.
This is why we don't have to worry about linux systems getting 'clogged up', all I have to do is `rm -rf /usr/local && yum update` and I have a system that is effectively as clean as a fresh install.
