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-----
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.
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
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 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>
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