• 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

    March 2019
    M T W T F S S
    « Dec    
  • Archives

Enblend Tracker on Launchpad

On the night from Sunday to Monday, with the help of Gavin at Canonical, we moved Enblend’s tracker from SourceForge to Launchpad.  Another step in the modernization of Hugin’s infrastructure.

Hugin is getting a lot of bug reports that actually concern Enblend, simply because Hugin is a GUI that uses Enblend in the back end.  Now, instead of marking them as invalid and asking the reporter to go and file the same report in the same SourceForge application but for a different project, we can simply mark with a single click that it affects Enblend, and the report is automatically moved to where it belongs.

Another great feature of Launchpad, but it works only if the concerned projects are all tracking issues on Launchpad.

I described the moving process for Hugin.  Here is the synposis for the command line.  But first start your web browser, log on to SourceForge and get the ${PROJECT}_export.xml file at https://sourceforge.net/export/xml_export2.php?group_id=${YOUR_PROJECT_ID}&show_projectsummary=0&show_projectresources=0&show_projectnews=0&show_filereleases=0&show_forums=0&show_trackers=1&show_tasks=0&show_projectadmin=0 (you will need to determine your project’s ID.

Get also get http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head%3A/doc/bug-export.rnc

Then type:

sudo apt-get install rnv bzr
bzr branch lp:sfbugs2launchpad
sfbugs2launchpad/convert_sf_bugs.py ${PROJECT}_bugs.xml
rnv bug-export.rnc output.xml

Rename output.xml to something meaningful, post it on the web and ask nicely Canonical to import it for you.


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.

The Most Welcoming Bed and Breakfast in London, Ontario

Londinium was established as a town by the Romans almost 2000 years ago. It was common practice for Romans to adopt and romanize native names for new settlements. Not so the Brits: when they settled North America, they brought their names with them. So there are a dozen Londons in North America, one of them in Canada.

We’ve been to the original London many time, and we visted London, Ontario for the first time last summer. We were lucky to find the most welcoming bed and breakfast in London, Just For You. Owned and operated by Ron and Gerard two Dutch expatriates, this bed and breakfast combines the coziness and warmth of a B&B with a level of service that competes with the best five stars hotels of the world. It was an inspiring place to recharge our energy before and after our busy days in the city. Gerard served us healthy and creative breakfasts. One day he treated us to Poffertjes, a sweet complement to the varied and well presented fruit salad and accompanied with original Dutch Hagelslag and real cumin Gouda.

The room was so welcoming, I felt inspired to shoot an HDR panorama and to test if recent developments have made it easier on artists to create HDR panoramas. The bottom line is: things will soon become easier. For this panorama I had to work through some issues of the tool chain.


A New Approach to High Dynamic Range (HDR) Panoramas

Disclaimer: the author has been contracting with Photomatix.

Stacking and stitching or stitching and stacking exposure stacks has been discussed in the past, as a manually controlled workflow. It has been automated in Hugin 2009.2.0. As a reminder: stacking and stitching is generally more efficient but had a draw back for full spherical panoramas. Last time I tried it suffered from vortex-like artifacts at nadir and zenith. The upcoming enblend-enfuse 4.0 introduced new algorithms that may linder the problem. Time to try again.

The process in a nutshell:

  1. Shoot the brackets for a full spherical panorama using a tripod (i.e. perfectly aligned stacks).
  2. Merge the stacks to individual HDR pictures.
  3. Stitch the pictures as if they were LDR pictures (the current Stitcher tab in Hugin really need some explanation – details below).

This is how I did it, in detail.

1. Shot bracketed RAWs. Fed them to Photomatix Pro and batch processed into HDR. Optional: In the same batch Photomatix Pro can also generate an initial tonemapped version (needed to set up the stitching project).

There are many software to merge RAWs into HDR, some of them Open Source. The reason why I use Photomatix is the automated batch processing that includes fixing chromatic aberration and noise. This automates those deterministic aspects of the process and let me focus on those aspects where human creativity makes a difference.

Photomatix’ Manual recommends using a third-party RAW converter and gives detailed instructions for white balance, basic settings, and curves. I did not find any drawback in using Photomatix’ integrated RAW converter.

2. Identified control points between the images.

None of the control points detectors known to me support HDR files (out of Photomatix) as input at this time. Hence the need for the initially tonemapped images. For this specific panorama, taken with an 8mm fisheye, there were not that many images to link, so I opened the HDR images in Hugin’s Control Points tab and clicked myself through them. A passage through that tab is anyway mandatory to establish vertical control lines.

3. Stitch in “Normal” output mode.

This is the confusing part. Currently Hugin’s Stitcher tab has three main output modes, each with their variations: Normal; Exposure Fusion; and HDR merging. Intuitively, this is HDR, right? but it’s not merging. We (the Hugin team) need to do our homework and improve the interface.

Another confusing point is the output format selection for the “Normal Output”. The only options available are TIFF, JPEG, PNG. Don’t worry, choose TIFF and the result can be loaded and tonemapped in most HDR software, including Qtpfsgui (soon to be renamed Luminance) and Photomatix (correction: with Photomatix Pro 3.2.6 I had to open it with Photoshop first and save as EXR). It would be nice if we had also EXR there, like for the merging process. And Radiance HDR too. Or at least an indication that the TIFF output will be 32bit.

Hickups And Fixes

The resulting HDR equirectangular had an artefact at the Zenith. Enblend 4.0 pre-release, with default settings, produced a dark speckle instead of a vortex. Smaller, but still disturbing.pitchedcp



pitched_4noopTo study this, I pitched the panorama down 90°, bringing the Zenith to the middle of the equirectangular, on the equator (and consequently the Nadir on the 360° at the equator). And to make it visible, I used plain color images. The four images on the right are: a simple, unblended output of the six layers on top of each other; the blend with Enblend 3.2; the blend with Enblend 4.0; and last the working workaround: the blend with the –no-optimize option suggested by Christoph Spiel, release manager for Enblend 4.0. The not optimized version enabled me to produce a usable HDR equirectangular and continue the process. On Christoph’s request, I dug deeper in the code to isolate when the artefact is introduced. With his patient guidance and a few experiments it seems narrowed down to the seam-line vectorization or de-vectorization code.


The resulting HDR equirectangular is technically correct. Enblend 4.0 (pre-release) is an improvement, though not yet perfect. As an added bonus, on multi-core CPUs it is also significantly faster than previous versions.

The other obstacle left is tonemapping: many tonemappers, notably Qtpfsgui (soon to be renamed Luminance) don’t deal properly with zenith and nadir, limiting the user’s choices. The latest Photomatix is tested to deal with the 360° seam and the zenith. In the meantime this is just a post-processing inconvenience that can be solved with a brush in Photoshop or GIMP.

That was a much longer than expected processing for a panorama, but it was worth it. I hope it helps advance Enblend 4.0 toward release.


The general recommendation (which still stands) is to keep exposure and white balance fixed across shots when shooting for a panorama. This is not always possible, e.g. with cell phone cameras. Hugin had photometric adjustments and other functionality to deal with exposure and white balance variations for a while. Now in the upcoming 2009.2.0 release this is all accessible through a single tick on the Stitcher tab: Blended and fused panorama.


Bruno Postle has published a tutorial about stitching auto-exposed panoramas.

Hugin-0.8.0 for Gentoo Linux

hugin-logoGentoo Linux is a “special flavor of Linux that can be automatically optimized and customized for just about any application or need. Extreme performance, configurability and a top-notch user and developer community are all hallmarks of the Gentoo experience”. At the core of Gentoo is Portage, a software distribution system. Unlike most Linux distributions, Portage does not distribute binaries. Instead, like the FreeBSD ports collection, it distributes scripts that automatically get the appropriate source code and build it, customized for the user’s specific needs.

Thomas Pani has updated both the release and snapshots available to Gentoo users via Portage. Gentoo is the first Linux distribution known to me that gives all of its users access to Hugin-0.8.0. That’s the equivalent to a binary distribution on other platforms. If you want to stay on top with Hugin and related tools, Gentoo is an excellent choice.

Give a Man a Fish

Groundhog protecting his holeSo the Hugin project team released 0.8.0 three weeks ago. What are the expectations, and what does release actually mean?

Some users, particularly in the Windows world, expect the release of a shrink-wrapped product. They expect to click, download, install, use. And of course everything for free.

Easy? Not so quick. What was actually released is nothing more than a tarball, an archive of the source code in a state known to build and work on the major supported platforms. So it could be used to produce executable binaries.

How are those binaries produced? What do they depend upon? What is to be produced? Who does it? How are they distributed? What is missing?


The user community has prepared platform-specific instructions. They may not be perfect but do the job.


There are some dependencies that need to be fulfilled for the recipes to work. Besides the obvious ones of enough disk space; a supported operating system; and installation of the building tools, Hugin 0.8.0 depends on other software packages, both at build time and at run time.

On the Ubuntu package description the dependencies are clearly listed. They are roughly the same for all platforms. They include enblend, enfuse, libpano.


On most Linux based systems a package manager takes care of the dependencies. This means that the packager only has to build Hugin-0.8.0 itself. The package manager will download and install the appropriate dependencies.

On OSX and Windows there is no package manager. The Hugin-0.8.0 binaries alone are useless. The packager has to do extra work.


Anybody with access to a computer can act as a packager, use the instructions and the tarball to produce executable binaries and do whatever they want with it. It’s free.


Anybody can put up the binaries for download anywhere on the internet. In the download section of this blog there are links. On top of that there are two distribution channels with special meaning: the package manager and the official Hugin download page.

The package manager is responsibility of the Linux distributors. They carefully test and approve each package that goes into their distribution. And they don’t backport often. For example, Ubuntu still supports its 8.04LTS distribution until April 2011 for desktops and April 2013 for servers, as well as 8.10, 9.04 and the upcoming 9.10. As of today, the binary of Hugin distributed by the package manager for Ubuntu 8.04LTS is Hugin-0.7.0_beta4. Users of Ubuntu 8.10 are still served with Hugin-0.7.0_beta5. Users of the most recent Ubuntu 9.04 have access to Hugin-0.7.0 binaries. And for the upcoming 9.10, Ubuntu’s plan seems to be to still ship Hugin-0.7.0. We hope that this will change but it is not up to us to change this.

Dependencies Revisited

Specifically, there are three dependencies that currently cause pain. In order of importance:

  1. Enblend and enfuse are mandatory. Without them, Hugin-0.8.0 does not work. The current enblend and enfuse packages have serious problems, causing them to crash. They are a regression compared to previous CVS snapshots, in particular to those versions delivered with the old Windows SDK and with the Hugin-0.7.0 installer for Windows. There are fixes in the staging branch of enblend-enfuse. And Harry has been using that branch to build the OSX Hugin-0.8.0 bundle until his Mac died.
    Unfortunately the staging branch does not build in Windows yet. I researched the problem and fixed part of it (accepted as revision 347 by Christoph Spiel on August 3). Thomas Modes had a look at it before going to holiday and added some more pieces to the solution. But it does not build yet because of Microsoft’s Visual C++ quirks.
  2. Libpano is mandatory. Until recently libpano had a minor but annoying problem: it reverted the language of the user interface to English. Daniel M. German and Thomas Modes solved it in the repository.
  3. A control point generator is a critical. Until recently the autopano-SIFT-C package had serious problems, causing memory leaks and crashes; failing where the previous version bundled with the 0.7.0 OSX bundle and Windows installer succeeded.

On systems with package managers (i.e. Linux) the packager can simply publish Hugin-0.8.0 and rely on the package manager to solve the above listed issues. For systems without package manager the packager must add them to the bundle/installer or to the SDK used to build it.

Distribution Revisited

Distributing a binary that is known to have a regression over previous versions as official release is bad practice. It not only affects the project reputation, it ruins a working system for those users who overwrite the working version with the newer one.

The OSX Hugin users community fixed the problem and an official OSX binary is available from the Hugin site. There is no solution yet in sight for Windows, so currently Windows users are directed to the 0.7.0 installer. Maybe we should direct them to the tarball instead?


Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime. This works with most of our users ond most supported platforms.

Unfortunately for some Windows users it does not seem to work. Give them free fish and they will come for more. Give them the freedom to feed themselves and they will ignore it.

Preparing the Next Release

hugin-logoHugin 0.8.0 has been released two weeks ago. Like with 0.7.0 the release cycle has been too loaded. We introduced plenty of new features (many developed during Google Summer of Code 2008), but forgot to fix some trivial things such as the location for temporary files (which can grow to gigabytes of size). Moreover, the prolonged trunk freeze has forced developers like Gerry Patterson and Thomas Modes to withhold those incremental improvements and bug fixes that make the difference between a software package with rough edges and a polished application.

I decided it is time to fix our release cycle and changed some things, breaking the old pattern. Most important, I’d like to make development independent of release so that we move continuously forward. I intentionally broke a few things and triggered a healthy discussion. It seems that we reached consensus and I’ve started to clean up the subversion repository. The next release will be 2009.2.

Besides pent up incremental improvement, there are some bigger changes on the horizon, but for 2009.2 we will retain only one of them: Andrew Mihal has added GPU support to nona. This means that users with a modern video card can leverage it for faster processing. This has been ready for a few months and it is time to release it. It will be the main change of the next release.

Our Google Summer of Code students will excuse me if I don’t talk about what’s beyond. This time we won’t make the mistake of loading too many things into one release. Their projects will follow, hopefully in rapid sequence, after 2009.2.

Below I document how I merged Andrew’s nona-GPU branch into trunk, hoping that it will be helpful for other merges. It shall be quick and painless – as long as the new functionality in the development branch does not work, it does not make sense to merge.

I started with a clean slate.

1) I fetched the branch from the repository

 $ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/branches/nona-gpu h.nona.gpu
 $ cd h.nona.gpu

2) I pointed the browser to the SVN log viewer for the branch

3) I identified the revisions concerned: 3510,3511,3522,3523,3535,3563,3568,3569,3574,3582,3583,3648,4069

4) I created a diff file containing all the changes in the revision

$ svn -r 3510 diff > nonagpu.diff

5) I checked out a fresh trunk

 $ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin

6) I built to make sure the initial status is known and OK

 $ mkdir ../h.build
 $ cd ../h.build
 $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local ../hugin
 $ make
 $ make package

7) I installed it and tested to make sure it works

8) I moved and applied the patch

 $ mv nonagpu.diff ../hugin
 $ cd ../hugin
 $ svn up
 $ patch -p0 < nonagpu.diff

9) applying the patch identified two conflicts in two CMakeLists.txt files:

 patching file src/hugin_base/CMakeLists.txt
 Hunk #1 FAILED at 51.
 1 out of 1 hunk FAILED -- saving rejects to file src/hugin_base/CMakeLists.txt.rej
 patching file src/CMakeLists.txt
 Hunk #1 FAILED at 9.
 1 out of 1 hunk FAILED -- saving rejects to file src/CMakeLists.txt.rej

10) I fixed the conflicts manually

11) I built the merged code to make sure I did not break anything major

 $ mkdir ../h.build
 $ cd ../h.build
 $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local ../hugin
 $ make
 $ make package

12) I installed and tested

13) I looked at each of the revisions concerned in the log viewer, e.g. 3511 to find out if files where addded, deleted or moved, and used the appropriate svn commands to add them. It would have been faster to look at the diff file, but like that I could also read Andrew’s comments and code changes and understand what was going on.

 $ svn add src/hugin_base/panotools/PanoToolsTransformGPU.cpp
 $ svn add src/hugin_base/vigra_ext/ImageTransformsGPU.cpp
 $ svn add src/hugin_base/vigra_ext/ImageTransformsGPU.h

14) In the end I was ready to commit

 $ svn ci

So what is the current status and what is next?

The code added a new dependency on GLEW. Most likely that this breaks the Windows build until the SDK is updated. So we need to update the SDK.

Andrew’s GPU code works and is available with the switch -g to those building trunk SVN4146 or later. I started to investigate support of the feature in the GUI, although in my opinion it is not mandatory to have GUI support to release the new feature.

There are enough new features in trunk so that when at the beginning of September the Hugin developers are polled whether to release or not, chances are that we’ll decide to go into release mode. My wish is to see this release out in September. Even if it will happen before the end of the year, I will be more than happy. Maybe a quantum leap for the project?