hugin-0.8.0 released
Bruno Postle
Hash: SHA1
Thanks to everyone responsible for this release!
Hugin is a panorama stitcher and more.
Changes since 0.7.0
The last release in October 2008 introduced major changes to the way
hugin worked. Although this new release looks and feels much the
same as 0.7.0, it adds some great new features and makes a lot of
small improvements:
Fast Preview window
A new Fast Preview window has been added, this uses OpenGL graphics
acceleration to show changes as they happen. You can drag photos
around the window and they will warp to their new positions in
real-time. Everything else you need to turn, pan and crop your
panorama can now be done interactively in the Fast Preview.
This Fast Preview also now acts as a hub for working with a panorama
project: the Identify mode lets you click on the overlap between two
photos to bring up the Control Point editor for that pair of photos.
Celeste sky identification
Stitching makes use of static scenery such as buildings to match
photos together, however objects that move cause misalignments, and
clouds move enough to be a particular problem. To make better
panoramas, Hugin has now been trained as a Support Vector Machine to
ignore clouds when matching photos.
New panorama projections
Panoramas tend to have a very large field of view, and Hugin does a
good job simulating virtual wide-angle lenses for output. But
painters and artists can do better than photographers, often
spanning scenes that look absurdly distorted when squeezed into
photographic perspective. Influenced by these vedutismo artists,
Hugin introduces some new projections for more elegant wide-angle
perspectives: Pannini, Biplane and Triplane.
In addition, Orthographic and Equisolid output have been added to
Hugin's already extensive set of azimuthal projections.
Batch Processor
Creating Hugin projects is now easier than ever, but actually
stitching large panoramas slows your computer - Usually at the same
time that you want to do something else. Now with the Hugin Batch
Processor, stitching can be postponed until it is convenient for
you.
Projects can be added to the queue from Hugin itself, or directly by
drag-and-drop from a file manager. In the Batch Processor you get an
overview of progress where the projects can be easily rearranged,
paused or canceled.
Online help
The manual has been updated to cover the new features and adds more
glossary pages explaining panorama and photography related words.
Languages
Most translations have been updated, plus Hugin is now available in
Slovenian and Chinese Traditional. The manual has been completely
translated into Italian.
Other improvements
There are many more changes in this release, here are just some of
them: a Reset... button in the Camera and Lens tab, better support
for 'special' characters in folder and file names, Align... now
works properly when loading saved lens .ini files, hints added to
Control Point tab pull-down lists, stitching now starts with a
series of tests, gcc-4.4.0 support, better Makefile plugin support,
man pages for command-line tools, new button icons throughout and a
command-line version of Celeste
Control point generators
Hugin doesn't yet ship with a 'Patent Free' control point generator.
So you either need to pick control points manually - Not as
difficult as it sounds - or install and configure one of the
following control-point generators as 'plug-ins':
* autopano-sift-C
* panomatic
* match-n-shift
* Autopano-SIFT
* Autopano freeware version
Upgrading
Upgrading from previous versions of hugin should be seamless. If you
do have problems with old settings, these can be reset in the
Preferences by clicking 'Load defaults'.
For users compiling from source: note that the minimum version of
wxWidgets supported is now 2.7.0, libpano13 needs to be at least
2.9.14, and that hugin now requires GLEW, the OpenGL Extension
Wrangler Library.
See the the README and INSTALL_cmake files for more information.
Thanks to all the contributors to this release and members of the
hugin-ptx mailing list, too many to mention here.
Hugin can be found at http://hugin.sourceforge.net/
Hugin sourcecode can be downloaded from sourceforge:
https://sourceforge.net/projects/hugin/files/
SHA1SUM: 698f0a7c4bb25efdf06313d05e3980f20d088ce5 hugin-0.8.0.tar.gz
This release is identical to 0.8.0_rc5 and equivalent to svn 4008.
Binary releases are expected to follow in the next few days.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFKYPbLFqOhwCjyCLoRAp9gAJ0Rzd6x/XZ31dbsfRMQr9J9wcWt4gCgh7E7
h6zYsOkTeTyYrYSorbQJXZY=
=zoLO
-----END PGP SIGNATURE-----
Tduell
I have just built Linux Fedora 11 X86_64 rpms (binary packages) and
sent them off to Bruno.
I expect they will be available from his server soon.
Cheers,
Terry
allard
Great work, good to see it released to the rest of the world! Thanks
to all the developers. Is anybody working on an 'official' windows
installer yet? I could give that a go, but I just tried to build 0.8,
and I get the following error (a few times, in 5 different projects,
this is just an example):
18>wxjpeg.lib(wxjpeg_jdmarker.obj) : error LNK2005: _jpeg_save_markers
already defined in jpeg.lib(jpeg62.dll)
18>wxzlib.lib(wxzlib_compress.obj) : error LNK2005: _compress already
defined in z.lib(zlib1.dll)
18> Creating library C:\HuginSDK\hugin_build\src\hugin1\hugin\Release
\hugin.lib and object C:\HuginSDK\hugin_build\src\hugin1\hugin\Release
\hugin.exp
18>C:\HuginSDK\hugin_build\src\hugin1\hugin\Release\hugin.exe : fatal
error LNK1169: one or more multiply defined symbols found
Any idea what is causing that? I can't exclude user error here, I just
don't have a clue.
Allard
Ryan Sleevi
fact that you have at least two instances of the JPEG/zlib libraries loaded
(wxjpeg.lib and jpeg.lib via jpeg64.dll, wxzlib.lib z.lib via zlib1.dll).
The latter for each of those is probably coming from one of the other
libraries you built/linked (other than wxWidgets, since it contains its
own). http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29_Patches details
some of the changes necessary to the various libraries, which include
updating them to point to wxWdigets for TIFF/JPEG/ZLIB where appropriate. If
I were to wager though, you may want to check exiv2 to make sure it's
linking right, but that's just a guess. Other than that, it's simply a
matter of tracking down which library isn't linking against wxWidgets'
implentation. You can always start with building a fresh SDK
(http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29 ) if you're still not
able to trace it down.
As to building the installer, I would suspect that Ad might be planning on
doing it, given as how he's been building installers for XP/Vista x32 during
development
(http://adhuikeshoven.pbworks.com/hugin%C2%A0installer%C2%A0for%C2%A0Windows
%C2%A0Vista ). He's got 4007 built, and IIRC, the only difference between
4007 and 4008 was a translation change.
I don't know if anyone has stepped up for the Win x64 'release' build. Being
in the US, I'm only really able to push a patent-free installer out, and if
people drop in a CP gen that is 32-bit, it's possible there will be WoW64
issues with filenaming / reg keys / the like between Hugin (native x64) and
the CP gen (32-bit). That's why I hope someone else can step up, so they can
build/ship all the bins (including the CP generators) x64 and potentially
dodge that problem.
allard
developer environment, which had screwed up my hugin build by
insisting on pointing to some of its own libraries. Don't ask me why.
As the only component of Glade I really needed was the runtime, I
uninstalled Glade and that worked.
I built a complete installer including panomatic, autopano-sift-c and
enblend/enfuse. Right now it's on my website at
http://allardkatan.net/misc/hugin/Hugin08_release_Win32_setup.exe ,
but I'll move it if it generates too much traffic. The warnings at the
first screen of the installer don't make much sense yet because I have
not adapted that particular piece of text. Also, because it is based
on the officially dubbed 0.8 release 4008, while Ad has already
released 4012, the page it refers you to after installation says this
is an old version....
This being said, I live in the US now too, so maybe someone else
should handle that official release because of patent issues.
allard
On Jul 17, 11:25 pm, "Ryan Sleevi" <ryan+hu...@sleevi.com> wrote:
> Hard to tell exactly what it might be, but the error is stemming from the
> fact that you have at least two instances of the JPEG/zlib libraries loaded
> (wxjpeg.lib and jpeg.lib via jpeg64.dll, wxzlib.lib z.lib via zlib1.dll).
> The latter for each of those is probably coming from one of the other
> libraries you built/linked (other than wxWidgets, since it contains its
> own).http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29_Patchesdetails
> some of the changes necessary to the various libraries, which include
> updating them to point to wxWdigets for TIFF/JPEG/ZLIB where appropriate. If
> I were to wager though, you may want to check exiv2 to make sure it's
> linking right, but that's just a guess. Other than that, it's simply a
> matter of tracking down which library isn't linking against wxWidgets'
> implentation. You can always start with building a fresh SDK
>
> As to building the installer, I would suspect that Ad might be planning on
> doing it, given as how he's been building installers for XP/Vista x32 during
> development
Yuval Levy
> The warnings at the
> first screen of the installer don't make much sense yet because I have
> not adapted that particular piece of text. Also, because it is based
> on the officially dubbed 0.8 release 4008, while Ad has already
> released 4012, the page it refers you to after installation says this
> is an old version....
welcome to the differences between "snapshots" and final releases.
remember your first installer, when you removed the call to the URL that
shows the welcome page? you want to do that for a release.
the idea of the web page redirect is that snapshots are short lived -
hence upon installation the users are directed to a webpage that tells
them whether they have the bleeding edge / latest snapshot or not.
it could be extended to releases, but I would do it differently. there
is no need for dynamics, so rather than the url with ?SVN=... I would
put a fix URL inside url.txt, pointing it to a web page that is specific
for that release, e.g.
http://hugin.sourceforge.net/installed/0.8.0.shtml (which does not exist
yet) and put on that page the information relevant to the release.
and: for an official release package you want to polish the warnings and
other text. they are all snapshot specific. one wants to hope that we
did some polishing before releasing final 0.8.0.
Ad (and anybody else) can continue to build and publish snapshots, the
system will be trimmed so that it points you to the very latest based on
SVN number. If 64bit snapshots become current and asynchronized with
32bit snapshots, we may need a more fine grained solution in the short
term. in the long term i'd like to see both 32 and 64 bit snapshots
produced with a single script like the one used by Ad.
Yuv
allard
allard
On Jul 20, 10:22 am, Yuval Levy <goo...@levy.ch> wrote:
> allard wrote:
> > The warnings at the
> > first screen of the installer don't make much sense yet because I have
> > not adapted that particular piece of text. Also, because it is based
> > on the officially dubbed 0.8 release 4008, while Ad has already
> > released 4012, the page it refers you to after installation says this
> > is an old version....
>
> welcome to the differences between "snapshots" and final releases.
>
> remember your first installer, when you removed the call to the URL that
> shows the welcome page? you want to do that for a release.
>
> the idea of the web page redirect is that snapshots are short lived -
> hence upon installation the users are directed to a webpage that tells
> them whether they have the bleeding edge / latest snapshot or not.
>
> it could be extended to releases, but I would do it differently. there
> is no need for dynamics, so rather than the url with ?SVN=... I would
> put a fix URL inside url.txt, pointing it to a web page that is specific
Yuval Levy
do I understand correctly that you are building the release so that we
can upload it to the official Sourceforge repository?
Yuv
allard
post it on the panotools site, and let this list know. If there's no
objections to the modifications I made someone can then upload it to
Sourceforge, or I can make some more modifications. That OK with you?
allard
Yuval Levy
> I'll build an installer with some modifications to the text files and
> post it on the panotools site, and let this list know. If there's no
> objections to the modifications I made someone can then upload it to
> Sourceforge, or I can make some more modifications. That OK with you?
sounds like a plan. Given the recent bug reports, you want to call this
one a release candidate and have it tested by those who experienced
difficulties with Ad's builds.
also there are reports of errors with enblend-enfuse. Christoph Spiel
has fixed them in a branch on launchpad. Harry has been using it for the
OSX bundles for a while. I have switched to that branch on my Linux box
for a while and it is robust. I think it would be good to use that
branch for Windows too until the official repository catches up.
I've got my Windows build chain up and running again and I tried to
build Christoph's branch. I still get an error:
2>.\enfuse.cc(552) : error C2065: 'optional_argument' : undeclared
identifier
2>.\enfuse.cc(553) : error C2065: 'optional_argument' : undeclared
identifier
2>Build log was saved at
"file://z:\store\s1tb\hugin_gsoc2009\Hugin-SDK-20090509-win32\enblend-cspiel\src\Release\BuildLog.htm"
2>enfuse - 2 error(s), 3 warning(s)
1>.\enblend.cc(481) : error C2065: 'optional_argument' : undeclared
identifier
1>.\enblend.cc(482) : error C2065: 'optional_argument' : undeclared
identifier
1>.\enblend.cc(483) : error C2065: 'optional_argument' : undeclared
identifier
1>.\enblend.cc(493) : error C2065: 'optional_argument' : undeclared
identifier
I'd appreciate if somebody with more knowledge of VC2008 could help me
understand. In Linux it builds and performs well.
Yuv
allard
I haven't really tried building enblend myself, I got too caught up in
the missing file errors when I did. I just have the binaries, I think
they are even in the SDK (or I added them myself to that folder on my
hard drive, don't remember). In any case, I have not had any enblend
errors, so I haven' t found the need.
In response to Henk: I've updated the installers on my own page and
the panotools website to include autopanoAJ.exe, which is Alexandre
Jenny's version of Autopano.
Who else except Henk have tried my builds and Ad's as well? I've had
around 50 downloads from my site, and there's probable some more from
panotools.org. Please respond, because IMHO we need to get this
release out there. The lag between the release of the linux and
windows versions has been long enough I think.
allard
On Jul 26, 9:30 pm, Yuval Levy <goo...@levy.ch> wrote:
> allardwrote:
Gabriele_Bb
ich habe ein großes Problem mit der Installation von hugin 8.0 und
hoffe, dass mir hier jemand helfen kann.
Leider verstehe ich kein Englisch und kann somit auch mit der
INSTALL_cmake nichts anfangen. Vielleicht kann mir ja jemand erklären,
was ich genau machen muss? Am besten wäre eine ausführliche Schritt
für Schritt Anleitung für Dummies... Ich wäre euch wirklich sehr
dankbar!!!!!!!!
Gabriele
Thomas Steiner
was ist denn Dein Problem? Klappt die Installation nicht (was genau
nicht)? Welches Betriebssystem benutzt Du? Windows Vista?
Thomas
Gabriele_Bb
Ich nutzte Windows xp und habe Hugin 7 installiert. Leider verstehe
ich nicht, wie ich an die neue Version rankomme. Die Datei
hugin_8.0_tarball habe ich heruntergeladen und entpackt. In der Datei
Install_cmake steht irgendetwas von cmake install (ich hab den genauen
Text jetzt gerade nicht vor mir). Ich verstehe nicht, wo ich diesen
Text reinschreiben soll, damit Version 8 installiert wird. Unter Start
- Ausführen hat es nicht geklappt. Leider habe ich überhaupt keine
Ahnung von dieser Art der installation. Bis jetzt hab ich immer
einfach auf das Setup geklickt und alles lief von alleine... Und da
mein Englisch sehr schlecht ist, verstehe ich die Anleitung nicht.
Eine gute Übersetzung konnte ich auch nicht finden. Daher habe ich
gehofft, hier Hilfe zu bekommen.
Vielen Dank noch mal
Gabriele
allard
Mein Deutsch is nicht so gut, aber ich glaub das du versuchst, die
Linux version auf Windows zu installieren. Das geht nicht.
Die Windows-installation findest du hier:
http://hugin.panotools.org/testing/hugin/Hugin08_W32_complete_setup.exe
oder hier:
http://allardkatan.net/misc/hugin/Hugin08_W32_complete_setup.exe
gruesse,
Allard
Yuval Levy
allard wrote:
> Who else except Henk have tried my builds and Ad's as well? I've had
> around 50 downloads from my site, and there's probable some more from
> panotools.org. Please respond, because IMHO we need to get this
> release out there. The lag between the release of the linux and
> windows versions has been long enough I think.
I see five issues and we're good to go:
1) TEXT
I've only tested the installer, yesterday, and my feedback [0] to the
text and the URL called on install
(http://hugin.sourceforge.net/installed/0.8.0.shtml) still stands.
The files license.txt and url.txt, which you can change just before
running InnoSetup, in the INSTALL folder IIRC.
easy.
2) ENBLEND-ENFUSE
I'll try to run one of the large projects that would kill enblend /
enfuse today and will get back to you here. I wish others who reported
enblend-enfuse problems would do too.
This is one can be solved before running InnoSetup to compile the
installer. And it should.
IMO there are three possible solutions:
1. replace the enblend and enfuse binaries with older ones known to work.
2. use the ones currently in the SDK.
3. get the build of the staging branch working and use that one.
On Ubuntu: the staging branch performs very well; the official v3.2
fails repeatedly; the last known status from CVS fails repeatedly; the
mercurial repo has at least two branches, and the status of the staging
branch there is incomplete.
On Windows: the current staging branch does not build yet. I contributed
one fix that improves (but does not solve) the problem. Christoph Spiel
has no access to Windows and does not know MSVC. I need help from
somebody who is more experienced with that compiler. I'll post about
this later.
3) TIMING OF RELEASE
I understand the pressure to release for Windows, but you have to
understand that it is not the same as releasing a tarball or even
releasing a binary for Linux.
To be on par with the Linux release
a) remove from your installer:
* all the control point generators
* enblend-enfuse
* libpano
in Linux these comes as separate tools / installers. In Windows, we
depend on cleaning those up too because shipping them separately would
be a disservice to the users.
b) distribute the source code only - this is what the 0.8.0 tarball
that's on Sourceforge. Common Ubuntu users are still served with 0.7.0.
You can't expect binaries - whether for Linux, Windows, or OSX, to be
released simultaneously as the tarballs. Not with our current
organization (or lack thereof).
c) add the superior way of distributing binaries / packages in Linux
distros (which BTW are also not yet at 0.8.0).
Because in Windows the installer is stand-alone. Once in the world, you
can't take it back. In Linux, you just issue a tarball with a higher
version number and the update trickles down the automatic channels for
the majority of the users.
I prefer to release later and to have a clean release, than to release
now and get the whiners going.
4) QUALITY OF RELEASE
There are serious issues introduced very recently: a recent change in
libpano causes Hugin to switch locale. All of a sudden your Dutch texts
become English. That's not release quality IMO. Has somebody tested
this? I have English-only Windows and can't.
In Linux this does not seriously affect the release of Hugin-0.8.0
because of the above described mechanism. In Windows this will flood us
with complaints.
Hence: we need more testing. For OS X, Ippei and a few others have been
doing this kind of testing and tweaking off-list. This is why there is
an OS X installer up on SourceForge, and the OSX Hugin users community
deserves applause for this. If Windows users want an installer up on
SourceForge, they have to do a similar effort. There is only so much the
developers can help.
5) ACCESS
Allard, can you please provide me with your SourceForge handle? I want
to give you access to the repository so you can save your changes there
/ save them for the future. And maybe even upload the installer, once
it's ready?
Yuv
[0] <http://groups.google.com/group/hugin-ptx/msg/3297f6e345105d30>
Gabriele_Bb
On 4 Aug., 16:59, allard <ka...@physics.leidenuniv.nl> wrote:
> Hallo Gabriele,
>
> Mein Deutsch is nicht so gut, aber ich glaub das du versuchst, die
> Linux version auf Windows zu installieren. Das geht nicht.
> Die Windows-installation findest du hier:
>
> http://hugin.panotools.org/testing/hugin/Hugin08_W32_complete_setup.exe
>
> oder hier:
>
> http://allardkatan.net/misc/hugin/Hugin08_W32_complete_setup.exe
>
> gruesse,
>
> Allard
>
vielen vielen Dank, damit hast du mir sehr geholfen!!!
Linux-Version.... da hätte ich ja noch lange rumprobieren können :-))
Ein herzliches Dankeschön auch an Thomas.
Eine schöne restliche Woche noch
Gabriele
allard
thanks for the feedback. just a few things:
1 which version did you test? I changed the licence.txt from what it
was before, and I removed the URL (the page you refer to does not
exist and I don't plan on making it because I never like it if
installers start opening web pages, but if you want to make that page
I have no problems putting it in the installer).
2 I used the one currently in the SDK. Solving this is way out of my
current capabilities and I dont see myself making the time for
learning that in the near future. We'll need help here. I guess it's
quite common in the open source world that the majority of (potential)
users is on a different platform than most of the developments.
3&4 Point taken. But it doesn't have to be perfect. Whining is
feedback too. We can always release a 0.8.1 (or whatever you'd call
that). I think that even if I did use Dutch Windows I would prefer a
fast preview in English to a slow one in Dutch.
cheers, allard
Yuval Levy
allard wrote:
> 1 which version did you test?
"Hugin08_W32_complete_setup.exe" downloaded July 27, 12:32 EST
> if you want to make that page
> I have no problems putting it in the installer).
I thought I had made a place holder. never mind. now it's there
> 2 I used the one currently in the SDK.
there is no enblend-enfuse in the SDK, at least not in the one I
downloaded two days ago following the Wiki instructions
("Hugin-SDK-20090509-win32.exe")
> Solving this is way out of my
> current capabilities and I dont see myself making the time for
> learning that in the near future. We'll need help here.
I don't expect you to do this. I don't expect anybody to do anything. At
some point somebody will feel the itch and scratch it.
> 3&4 Point taken. But it doesn't have to be perfect. Whining is
> feedback too. We can always release a 0.8.1 (or whatever you'd call
> that). I think that even if I did use Dutch Windows I would prefer a
> fast preview in English to a slow one in Dutch.
Sorry, I completely disagree with you. You can do whatever you want and
publish unofficial snapshots. The official release has to fulfill higher
quality standard. The binaries on Sourceforge get more than 200
downloads per day. We can not afford it to be known as the project who
releases half-backed installers with regressions.
Whining is no feedback. Try working through the reports in the bug
tracker and you'll see the difference between whining and feedback.
Your installer is far from being a release grade package. The SDK is far
from being a release grade SDK.
while the preference between the native language and the fast preview is
debatable, a proper CP finder and proper blending are not.
The SDK (and your installer) ships with the autopano-sift-C version that
leaks memory all over. Tom has fixed most of that. On the good side, it
ships with the old generatekeys.exe too.
The SDK ships with no enblend-enfuse nor with the packages required to
build it. The 3.2 version of enfuse-enblend that you used for your
installer has regressions over previous installers. I am not saying that
it is up to you to fix this. But I am saying that this is a show stopper
for a Windows installer to be officially endorsed as release-grade.
Next I'll look into producing a binary of the staging branch of
enblend-enfuse.
Yuv