• Subscribe

    Subscribe to This Week In Panospace by eMail.
    Subscribe in a reader
  • License

    Creative Commons License
    This work is © 2008-2012
    by Yuval Levy
    and licensed under a
    Creative Commons License.
  • Entries

    September 2018
    M T W T F S S
    « Dec    
  • Archives

Hugin 2010.4.0 Officially Released

Today I declared the Hugin build released a few days ago final. It is dedicated to Milko K. Amorth, a pioneer of the full spherical panoramic photography that we have lost last year under tragic circumstances.  He will be missed.

This release of Hugins brings a load of new features.  The two most notable are the result of two Google Summer of Code (GSoC) 2010 projects:

The built in control point generator cpfind was the is the GSoC project of Antoine Deleforge, built on top of more than three years of contributions made by too many people to list here.  For the first time Hugin is “feature complete”.  This does not mean that there are no new features coming.  It only means that it is now possible to run the typical stitching workflow end-to-end without relying on third party non-Free packages.

The new underlying controller, Makefilelib, the GSoC project of Florian Achleitner.  Users of the GUI won’t notice, but it enables a more robust stitching process, distribution on multiple stitching nodes, finer grained control and extension of the process through other third party tools controlled by the same Makefile.

More information in the release notes.

Another first: the user-community around Hugin is growing and the user-contributed binaries are already available or will be available shortly after the source code release.  Many Thanks to everybody who has contributed to this great release cycle, particularly to Matthew Petroff for the Windows builds and to Harry van der Wolf for the OSX builds.

Hugin 2010.4.0beta2

Right on the heel of the first beta, here is the second beta in this release cycle.  It’s only one week since the first beta, but a lot of effort has gone into translations and bug fixes.  The changes since beta1 are summarized in the release announcement.

Once again the leading users have responded to the call and built binaries for their respective platforms.  Not that it is a competition, but this sounds almost like the results of a race with Harry van der Wolf coming in first with builds for Mac OSX, followed closely by Andreas Metzler’s Debian/experimental and Matthew Petroff with builds for Windows.  Extra bonus for Matthew who published his builds on our SourceForge page.  Uploading to SourceForge is easy and if your SSH-Key is correctly set in their system you don’t even need to enter a password.  Just start a command line and type something like

rsync --partial --progress -e ssh hugin-2010.4.0beta2.tar.bz2 yuv,hugin@frs.sourceforge.net:/home/frs/project/h/hu/hugin/hugin/hugin-2010.4_beta/

No such problems for users of platforms with proper package management system.

Bruno published Fedora builds at the usual location and I used Andreas’ Debian packages to publish Ubuntu builds for Lucid and Karmic in the Hugin PPA on Launchpad.  Moreover I tried a Soyuz feature and copied the Lucid source from the Hugin PPA to my personal PPA where it built successfully for Natty.  I  don’t have a Natty install yet so I can’t really test if it worked.

Next scheduled release is a release candidate for December 17.  Maybe an additional beta before that if further testing is required.  I don’t want to push too much on the builders.  The build mechanisms are oiled and ready.  If the performance of the last two beta releases is an indication for the future, this may be the first Hugin release to shrink the lag between source code release and binary release to less than 48 hours.

For now, happy bug fixing!

Hugin 2010.4.0beta1 released.

Hugin 2010 Logo

Yesterday I released the first tarball in the new Hugin release cycle.  The goal is to release 2010.4.0 before the end of the year.

It’s only a couple of months since the last release, but a lot has changed, in the code, in the process, and in the infrastructure.

I wrote about the infrastructure change three days ago.  The activity in the new bug tracker is massive.

In the code, the most important news is that with its own brand new control points detector, Hugin can be considered feature-complete.

To underscore this achievement, the project has given itself a new look, contributed by Cristian Marchi, that has given an evolutive face lift to the original design by Dr. Luca Vascon whose source files have been lost in time.

In terms of process, this time around we have more contributors than ever, on multiple disparate platforms.  The project will still stick to its policy of releasing source code as soon as it is good to go and leaving it up to the user communities on the different platforms to produce and distribute binaries because it does not make sense to delay the release of source code only because there are no binaries; and it does not make sense to delay the release of binaries for a platform with faster builders only because there are no binaries yet on other platforms.  However the natural and inevitable time lag between a released source package and a working binary package (which is what most users are looking forward to) is likely to be reduced for most platforms.

First to respond to my call was Matthew Petroff.  He made Windows binaries in four variations (32bit/64bit, installer and standalone zipped) available within a few hours and before anybody else.  Matthew has joined the team recently and he has done some excellent polishing work on the Windows side of thing.

Then the indefatigable Harry van der Wolf followed up.  Building for OSX is always a little bit different/special and require more effort than most other platforms.  He reported this morning that everything works and will produce the coveted bundle installer tomorrow.  What would Hugin Mac users do without Harry?

Andreas Metzler reported a “work for me” update to the Debian experimental source package.  Based on his work I will try to produce my first Ubuntu packages of Hugin for Ubuntu Lucid (my main system) and Jaunty (chrooted), and Gerry Patterson will tag-team for Maverick.

On the Fedora front things are quiet but not less up to date.  Between Bruno Postle and Terry Duell recent versions of Fedora should be covered soon.

Lukáš Jirkovský will try to use OpenSuSE Build Service, but he’s very busy and there is no guarantee.

No promises.  There is always an inevitable lag between the release of a source tarball and that of a usable binary – at minimum the time it takes for the builder to download the tarball, build it, run a minimal test, and publish it.  But we are doing our best to make this the Hugin release with the shortest delay from source to binary.

This weekend is a test run.  The really interesting run will be when we approach the final release.  Keep your champagne cold for now.

And when will somebody report success building Hugin on Android or iOS?

From Subversion to Mercurial. Part 3, Implementation Day and Beyond

If you followed the steps described in the first and second parts of this series, you should have a Mercurial (Hg) repository ready to replace your project’s Subversion (SVN) repository.  In this third and last part we’ll go over Implementation Day, with particular detail on how to implement this migration on the SourceForge infrastructure.


Can’t test enough.  Your script produces an Hg repository that looks OK on superficial investigation with tools like hg log and hg view.  But does the code build?  Hugin’s build system had a couple of dependencies on SVN and they needed to be updated.  Thomas Modes and Kornel Benko stepped up to the task.  Can developers and builders use this repository?


On Implementation Day the project will transition from SVN to Hg.  While all relevant contributors are proficient in SVN, Hg was new territory for many.  While progressing on the conversion I kept the community informed and took every opportunity to encourage learning of the new tools, including public tutoring that continues after the transition.  You want to encourage people to share their experiences and learn from each other.  Conceptually the biggest difference between SVN and Hg is that with Hg the repository sits on your local client.  A check in to SVN is the equivalent of a check in and a push to Hg.  Offline operation is not possible with SVN but it is with Hg.  However both are revision control system (RCS) and very similar to use.

Implementation Day Overview

Warn everybody one last time.  Create a new repository on SourceForge for each migrating code line.  Lock down SVN by revoking write access to everybody but a few maintainers who will clean up after the transition.  Run once again the whole migration on a green field, from scratch, to be sure that everything to the very last SVN commit is included.  Test one last time this new local repository (compare it to previous results); create the new repository on SourceForge and push your local repository to it. Last but not least, configure the repository on SourceForge and announce the transition to the world.  Sounds easy.  The devil is in the detail.

Mercurial on SourceForge

SourceForge has been very generous with the projects it is hosting: we can have unlimited Hg repositories.  Unfortunately there are rough edges.

To activate Mercurial for your project:

  • Login via the web as a project administrator and go to the “Develop” page for your project.
  • Select the Project Admin menu, and click on “Feature Settings”.
  • Select “Available Features”.
  • Select the checkbox to the left of the “Mercurial” heading. Your repository will be instantly enabled.

This first repository will be fine but if you want to activate more than one repository you will have to manually set them to be group writable.  To activate additional repositories:

  • Log on to SourceForge’s shell service (assuming you have set up your SSH key) with `ssh -t USER,PROJECTUNIXNAME@shell.sourceforge.net create`
  • Navigate to your project’s Mercurial space with `cd /home/scm_hg/P/PR/PROJECTUNIXNAME`, e.g. for Hugin this would be `cd /home/scm_hg/h/hu/hugin`
  • Create a new directory with the name you want for the repository.  E.g. for Hugin’s website this was `mkdir hugin-web`
  • Execute `hg init DIRNAME` (where DIRNAME is the directory you just created, e.g. `hg init hugin-web`). This will initialize the new repository.
  • Inside the new repository, edit the configuration file .hg/hgrc (see configuration section below)
  • SourceForge rough edge: group write access must be given manually `chmod -R g+w /home/scm_hg/P/PR/PROJECTUNIXNAME/DIRNAME`

Configuration of the Mercurial Repository on SourceForge

SVN support on SourceForge is mature and projects are used to amenities such as email commit notifications.  Hg support is better than what the scant documentation suggests.  Most standard functionality, including email notification, works, even if it is officially unsupported.  One only has to find out how to configure it.  I played around with some trial and error already when optimizing the Enblend repository last year.  This is the hgrc file template that works for us:

changegroup.notify = python:hgext.notify.hook

from = NOTIFICATION_ADDRESS@lists.sourceforge.net

host = localhost

baseurl = http://PROJECT.hg.sourceforge.net/hgweb/PROJECT/DIRNAME

sources = serve push pull bundle
test = False
config =
template = \ndetails:   {baseurl}{webroot}/rev/{node|short}\nchangeset: {rev}:{node|short}\nuser:      {author}\ndate:       {date|date}\ndescription:\n{desc}\n
maxdiff = -1

NOTIFICATION_ADDRESS@lists.sourceforge.net = **[trusted]

users = *

You’ll have to replace your own project unix name PROJECT; your own Hg repository top directory DIRNAME; and your own NOTIFICATION_ADDRESS mailing list.  The configuration options are documented.

Committer Write Access

With a dRCS like Mercurial write access has a completely different meaning.  Everybody can `hg clone` an existing repository and once cloned has full write access and can publish their own repository.  The d in dRCS stands for distributed.  Technically there are no more hierarchies and no more central control.  All clones are equal.  Whoever owns a clone can decide to publish it on the web, e.g. with `hg serve`, and give write access to whomever they want.  Granting SourceForge write access only means that the committer can push to the repository hosted on SourceForge.  What makes a repository authoritative is user’s trust, and this is given implicitly by pulling from it.

SourceForge Rough Edges, Again

I wish there was a way to group-manage access rights on SourceForge.  I have not found it.  I needed to revoke SVN access to most developers, and grant them Hg access.  I had to click through each and every contributor registered with the project and single handedly managed their access rights.  To make things worse the pseudo-ajax web interface of SourceForge is everything but asynchronous: it reload the page after each change.  Ajax-cosmetics with underlying old technology from the last century.

One point projects on SourceForge will need to pay attention to are default access rights.  I did not find a place to change those, so every new project member gets by default SVN access right, unless you explicitly remove them.  It seems to me that the defaults on SourceForge are based on the principle of random uncoordinated historical growth.  Have they ever heard of the generally accepted principle of least privilege?  And the default file access for newly created extra Hg repositories is less than reasonable least privilege (see above).

<rant>And don’t tell me about SourceForge’s IdeaTorrent and ways to request and enhancement.  In my experience it does not work and some things on that site have been broken for years when the fix is simple, easy, and does not take much time.  Have you tried to use a SourceForge mailing list archive?</rant>


Now that everything is set, you can simply `hg push` from your local repository to the SourceForge one.  Or if you’re really confident, you can rsync the .hg directory (but don’t forget to edit the .hg/hgrc configuration file on the SourceForge end).

CMake Build System

Our CMake build system depended on SVN and after the push it was broken.  Kornel Benko and Thomas Modes fixed it.  Bruno Postle added a break in the CMake build system in the SVN repository, to warn users of that repository that newer versions are in Hg.  Harry van der Wolf updated the OSX build system.


The disruption was short.  A few hours after going live, developers started committing again, using Hg.  Builders started building and distributing again, using Hg.  The Google Summer of Code students cloned away their own copies of the source code and started working on the next major developments for Hugin.  After taking on the most complex of the code lines in the SVN first,  I migrated the remaining ones over a few hours Sunday night.  Hugin and most of its related projects live now happily in Hg and can easily be converted to other formats, including Bazaar, git, and even SVN.  Initially I thought to mirror the default code branch from Hg to SVN, but our project does not really need that.  Subversion has been made completely redundant by a newer, better, superior tool. Mercurial and its likes would not exist without Subversion, and should be seen as a continuum in the lineage rather than a break from the past.  With Mercurial, Hugin is freer than ever, and you are free to take it further on a journey to the future.  For now Hugin still lives on SourceForge, where the next critical bit of infrastructure is the bug tracker.  But with Mercurial the dependency on SourceForge; and the dependency on any single central service or person; has been further reduced.  Long and Free live Hugin.

Hugin 2010.0 Released

Last week Bruno released Hugin 2010.0. It was almost immediately followed by binaries for MacOSX (Harry), Debian/Ubuntu (Andreas), Fedora (Terry). The step from release candidate to release had been longer than usual because of the lack of feedback from Windows builders/users whose interest seems to have shifted to the development version, which has already a few new cool features such as a masking tool.

Trunk still has a few rough edges, but overall is ready for the next cycle. Consensus is forming on moving the codebase to Mercurial and potential new Google Summer of Code projects are being discussed on the mailing list.

Releases, Releases.

Somehow the end of the Gregorian calendar year seems to be a popular time for software releases. There have been a number of interesting releases in the past two weeks in the area of Free photography in general and panorama making in particular. Too many to mention them all.

The one that caught my attention is PTStitcherNG 3.0b by Prof. Dr. Helmut Dersch. Helmut has been at the forefront of panorama making software for more than a decade now, and his new tool optimizes for speed and memory footprint. A 1.5 gigapixel panorama will stitch within less than 100MB RAM. To me this comes very convenient: since I upgraded my photo gear the resulting images are too big to stitch on my ailing notebook maxed out on RAM.

Unfortunately for the time being it is free and not Free. Binaries are freely available for Windows, OSX, and OpenSuse 11.1 (x86_64). Users of Linux distributions other than OpenSuse will need to run the Windows binary through Wine and take a 30% performance hit. The currently distributed binaries only work on SSE3 processors. Helmut says that a source code release is pending the scientific publication of his results. For the Pentium M / Ubuntu 9.04 notebook whose life I’m trying to extend beyond shelf-date  I’ll have to wait for SSE2 binaries or for the source code. I worked around it by rsyncing the source images to my Kubuntu 9.10 office workstation and running PTStitcherNG there, remotely.

Another notable release is Enblend-Enfuse 4.0 that has been overhauled by Christoph Spiel and has spurned a release of newer versions of related GUIs,   ImageFuser0.7.4 by Harry van der Wolf and EnfuseGUI 2.1 by Ingemar Bergmark.

Last but not least, Bruno released Hugin 2009.4.0. completing the work I left unfinished, and started the release cycle for 2010.0.0. James topped the Holiday present by merging into trunk the much awaited new layout branch, with his Google Summer of Code project and Pablo’s XYZ  parameters for image position.

Too Much Love Will Kill You

With the increased pace of development, added features, and improved stability, Hugin has become more visible and has got more attention and love from potential users, and of course they have needs and wishes.

One recurring user request is: “why don’t you make binaries available?” John Riley argues for a “concerted effort to create binaries”, saying that Hugin “deserves a much wider audience than those who are willing and/or able to build it from source” and that “making it more accessible would increase its visibility, which could get more people interested in contributing”.

No doubts that binary distributions would be nice. How do they fit in the plan? What is the status of the project? Of the binaries? What are the priorities?

The Plan

Most contributors to Hugin are volunteers. The rule number one is that there is no master plan. Well, I do have my plan, but I can not impose it on others; and others can’t impose their plan on me. Each contributor decides what is right for him, set his own priorities and contributes what he wants. If the contribution makes sense other contributors will adopt, follow, join, contribute.

I like to think of contributors as a free-flowing fluid on the project, like water on Earth. The fluid is naturally attracted to valleys where it forms rivers and lakes. Its passage shapes the landscape.

Controlling the fluids would need expensive barrages. Most often not a practical proposition. Project administrators only decide what is on Sourceforge and even this is not control: The software is Free. No barrier can prevent the fluids from flowing in an alternate direction and if that direction is more attractive, others will follow. It’s purely meritocratic.


Hugin is undergoing major change. Growth has exposed the limits of the previous structures, and we had to adapt to the new dynamic.

When I first got involved with Hugin three years ago, I found the learning curve extremely steep. We needed to make it more attractive to contributors. In response to the difficulties encountered by the Google Summer of Code students the project reacted with SDK and documentation. Hugin has become more accessible for contributors. We see the result with new contributors coming on board almost every month (and without the incentive of a Google internship). Their contributions pose new challenges.

Last year we integrated four major contributed features: celeste; fast preview; batch processor; and new projections.The integration resulted in a development freeze for much of 2009, until the 0.8.0 release last July.

In the meantime, the queue of new contributed features waiting for integration had doubled:

  • GPU-stitching (to use modern hardware for faster stitching, integrated in 2009.2.0);
  • lens calibration (to develop a better mathematical model for the lens geometry, integrated in 2009.4.0 but not ready for practical use);
  • deghosting for enfuse (to reduce ghosts when merging stacks of images with enfuse, integrated in trunk and scheduled for release after 2009.4.0);
  • CPclean (to prune bad control points by statistical method, integrated in 2009.4.0);
  • Auto-crop (to reduce the blank areas around the image);
  • New layout mode (to improve the handling of exposure stacks);
  • XYZ-transform (to improve geometric positioning when the images are not taken from precisly the same no-parallax-point);
  • Masking in GUI (a Google Summer of Code 2008 project that we’re still studying how to integrate).

And there are plenty of small incremental improvements here and there that would not have happened if we were in a freeze.

Extrapolating the past, we’d be frozen until 2011. This would effectively kill the project. I introduced parallel development to solve the bottleneck, and I hope we can work through most of the back log before the end of the winter.

There is a cost to parallel development: desynchronization. And the less glamorous areas of the project suffer particularly. Building binaries for distribution is such an area.


The Hugin project is committed to release source code that builds on a wide variety of platforms. The creation and distribution of binaries is left to the users’ communities. Of course we are users ourselves, and we do build binaries, mostly for testing purposes and only on our respective platforms. Our contribution to the distribution process is mostly documentation, because building for self-use and building for distribution are two completely different things, despite a common set of underlying steps.

We stop at the source code for many reasons. Primarily: limited access to all the platforms; limited resources; limited time. Building for distribution requires extra care (quality assurance) and extra steps that are critically important to make the difference between a good distribution and a dysfunctional one. Starting from a fresh source tree is strongly recommended to build a proper distribution. A developer’s source tree is seldom fresh. It contains the traces of the developers work, and this has the potential to contaminate the build process.

One of my activities over the past three months, as I took charge of our release process, was to liaise with downstream distributors to help them produce better distribution in the hope that new versions of Hugin will trickle faster down the distribution channel to the end users. The result:

  • The Hugin FreeBSD port is now easier to maintain and maintainer Vasil Dimov tracks recent releases closely.
  • The Hugin Gentoo Linux ebuild is kept up to date by Thomas Pani, Gentoo maintainer.
  • Coordination with Andreas Metzler and the maintainers team at Debian resulted in the clean up of some outstanding issues and better support of that plattform and its derivates, including Ubuntu. Unfortunately Hugin 2009.2.0 did not make the cut for Ubuntu 9.10, which has Hugin-0.8.0 available through it’s package manager.

Of course this is of little interest for people who do not use FreeBSD, Gentoo, Debian, Ubuntu. And the reality is that the majority of users are still on Windows. Systems without package managers (Windows and OSX) add additional effort / complexity to the build and distribution of binaries. Nevertheless, Harry van der Wolf, supported by some other Mac users, provides unofficial OSX binaries on a regular basis. And for Windows, I have recently guided a few users through parts of the build process. Unfortunately none of the resulting Windows binaries is stable enough to be declared official.


Given all the back-log of features to integrate, and the consequent knowledge that the current release of Hugin is short lived and a newer, better one is just around the corner, why put the effort to produce a Windows installer that will be obsolete soon? Of course ideally the installer should track closely the development, but it seems to be too much effort at the moment. At some point, the gap between the installer and the code will be deep enough to attract more attention, and somebody may be motivated to provide a Windows installer.