• 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

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

Hugin 0.8.0 released!

hugin-logoBruno Postle released Hugin 0.8.0. This is the best Hugin ever and despite the 0 as major version number a very mature and usable piece of software. The highlights:

  • Fast Preview – James Legg’s 2008 Google Summer of Code project that makes the user interface much more responsive
  • Celeste – Tim Nugent’s 2008 Google Summer of Code project that prunes control points from clouds with more than 80% success rate and make stitching more precise
  • PTBatcher – Marko Kuder’s 2008 Google Summer of Code project that enable the batch processing of panorama project
  • Many new projections
  • A lot of small improvements and bugfixes.

A big thank you to everybody who contributed!

Alarm Clock

hugin-logoHere we go again. I prompted a discussion about the Hugin release cycle. And lucky me the wheels started turning. The effort took a dynamic of its own while I was going through a very busy period at work (I’ll post about it tomorrow).

It’s now half a year since Google Summer of Code 2008 finished. Three out of five projects have ripened to trunk. The new Libpano projections are usable in trunk. Bug reports are clogging the bug tracker again, and it seems that the pipeline is frozen. Deep winter?

Under the surface there is boiling excitement. We have a new and very active team member, Lukáš Jirkovský, who has upgraded the codebase to the latest vigra version and is now going through the bug tracker at a fast pace; and Andrew Mihal has developed GPU-powered stitching (powerful videocards are no longer for gamers only). And maybe in a few months Google Summer of Code 2009 is coming.

How do we unclog the pipeline? And most important, how can we prevent future clogging and keep it going indefinitely?

Triggering an ad hoc discussion to wake up the bear from winter sleep is not a good way to keep the release cycle ticking – not even in the world of Open Source. Ubuntu and others have recognized it and have moved to fixed release dates. It’s not ideal, but it’s better than a protracted never-ending and thus frustrating development cycle.

As it could be expected, the discussion, particularly on branching and tagging and the process from the repository to a release attracted many opinions. As Gerry Patterson wisely said, doesn’t everybody have ideas on how to release software?

I am OK with most of the ideas expressed… as long as ideas are followed by action, and action is followed by results. We need to keep the release process ticking, and make it independent.

The generic process which all of the expressed ideas share is the release cycle:

  • develop
  • test locally (development branches, local copies, etc.)
  • test broadly (trunk)
  • release to the general public
  • repeat

And somehow we keep getting stuck in the first three steps.

What we lack are mechanism to move things between the different stages, particularly from the broad test to the release. When is a new development ready for broad testing? when is the project ready for a release to the general public? We need some policies, a way to make such decision that makes them independent of people.

I believe that a moving target like the Hugin project should try to move code piecemeal (as opposed to one big bang), and do it as frequently as possible. We need a lean process that can be repeated frequently.

Moving the code along the first three stages is not so much the issue. Most developers agree to a simple policy: Commit to trunk as early as possible. If local, limited testing shows that no major functionality breaks, move the code to trunk. This is the only way to expose it to broader testing and peer review.

There is a more varied opinion about the release itself. It can’t be replaced by a snapshot (just tarball the latest trunk) because maintaining trunk into a releaseable status all the time requires a considerable effort and slows down the testing of new features in trunk. Moreover, snapshots are not always as polished as users expects production software to be.

One possibility would be to decouple the development cycle from the release cycle, and let the clock control the release cycle (without putting pressure on the development cycle): when the time has come, features that are in trunk and are ready for release are released, while features that are not yet ready are kept for the next release cycle.

It does not really have to be the clock. It could be the readiness of the feature. Then we’d release at every feature. Problem is: how/when to declare a feature ready? The clock would force us to have a look and see if it is ready enough for release or not.

After Google Summer of Code 2008 we had three features move into trunk in a rapid succession: James Legg’s fast preview; Marko Kuder’s PTbatcher, Tim Nugent’s Celeste. Each one of them would have warranted a release in my opinion. So we could have released 0.8.0 (0.7.0 + fast preview); 0.8.1 (0.8.0 + PTbatcher); 0.8.2 (0.8.1 + Celeste). The result would have been a release every two months.

Instead, all of these beautiful features have cumulated in trunk, accessible only to those that venture into building Hugin for themselves. And now, over Christmas, we would have had 0.8.3 (0.8.2 + the new libpano projections). Instead, once again, the commercial stitching application are catching up and will release similar features to the general public before us.

A clock driven release cycle isn’t that bad after all – or are you one of the few people that wakes up in the morning to go to work without an alarm clock?

Sneak Preview III

PTBatcher is the result of three months work of Google Summer of Code 2008 student Marko Kuder and his mentor Zoran Mesec, himself a student last year. Behind the simple interface there are a lot of details and Marko got them pretty well right.

With PTBatcher I can set up all of my stitching projects and go home while the computer works on them overnight. Or run it on a second machine dedicated to stitching on a network, possibly accessed remotely to keep the noise and heat of high-power machines away from my desk.

What I liked particularly about this project is the progression of Zoran from student to mentor. Also the fact that the two of them are at the same university and have real life contact. In these days of ever growing bandwidth and groupware there is still an element that no technology will replace in the near future: real human contact. Once a relationship is established, technology is a great enabler, but there is still nothing as good as a handshake and sharing a meal or a drink. Maybe this is the beginning of a tradition, and in 2009 we will see another student in this lineage?

Coming soon to Hugin.

When the dust settles

It’s a few week before the official coding starts. The students are bonding nicely with the community. Ideas are flowing, and some patches too. I can’t wait to see what they will do when they are officially on Google’s payroll and assigned to work full time on hugin.

While Pablo and Alexandre P. are at LGM, time to introduce properly this year’s team that will participate in the Google Summer of Code. There is a lot to be written, and more may come over the next few months as the summer unfolds. For now, here is an overview of the six projects we’re working on, of the people, and of exciting things to come.

The Projects

There are six projects this year in our portfolio, even though only five are listed on the Hugin/panotools entry at Google. The sixth project is a joint effort with VideoLAN on their leading cross-platform media player. It is listed on their page at Google.

OpenGL hugin preview

The preview windows is central to the panorama making process. It is here where the author looks at his composition before rendering it. It is here that framing decisions are being made, interactively. Right now the interaction is slow.  James Alastair Legg, mentored by Pablo d’Angelo, will improve the panorama preview windows by giving it the speed of OpenGL. We expect near real-time interaction for the author when composing his panorama.

Automatic Feature Matching for Panoramic Images

Critically important to stitching panoramas is to identify overlapping images in two features and align them in space. In the past, this was tedious, manual work. Then control point detectors came along. Those available to hugin users are still tainted by patents. It’s a two step process: detecting features and matching them. In Google Summer of Code 2007 Zoran Mesec wrote the detector, MatchPoint. This year Onur Küçüktunç will write the matcher, mentored by Alexandre Jenny, author of the original autopano and of Autopano Pro. A beautiful example of cooperation and co-existence between the proprietary and open source world. We expect to have a fully patent free control point detection process.

Masking in GUI

Overlap regions between two images are the nature of stitched panoramas. Since the world is in movement, such overlaps often present challenges that won’t match. The current solution is to render each image on a separate layer, and then mask out manually one of the two images so to display only one frozen instance of the moving object. This can often be a painful work at the single pixel level. Fahim Mannan, mentored by Daniel M. German, will introduce a simpler workflow: just mark the moving object with a couple of approximate brush strokes and his code will work out the exact object boundaries automatically. We expect an improvement for those using hugin to stitch action panoramas.

Batch Processing

Photographers often come back from the field with tons of photographs to stitch. A lot of this could be automated. Even more so with the up and coming pano-videography. Marko Kuder, mentored by Zoran Mesec, will improve hugin’s batching abilities. We expect to be able to process repetitive tasks without human intervention.

Machine-based Sky Identification

Some areas of photographs are better suited for control points than others. The sky, with its moving clouds, definitely not, as good control point don’t move between images. Timothy Nugent, mentored by Yuval Levy, will train a support vector machine (SVM) to identify clouds in the sky as a bad area for control points, so that it can be masked out before triggering the control point detection. Once working the method can be extended to other features as well, such as foliage and water.

Panorama Viewing in VideoLAN

19 years after Tim Berners-Lee invented the web there is still no universal format to view panoramas on the web. Apple’s QuickTimeVR, the original technology to display full spherical panoramas, is not available on platforms other than Windows and the Macintosh, and it is no longer developed by Apple. A lot of good things have happened with Flash panoramas in the last year. Nevertheless, a lot of legacy content out there is captive of the QuickTime format, like the World Wide Panorama. In Google Summer of Code 2007 Leon Moctezuma added functionality to FreePV. This year Michael Ploujnikov mentored by Yuval Levy will integrate panorama viewing in VLC, a leading cross-platform media player. We expect Linux users and users of other alternative platforms to have access to the majority of QTVR content soon.

The team

I’m happy to pass the admin role to Alexandre Prokoudine this year. We had more available mentors, student applications and project ideas that we would have loved to follow through, but resources are limited also for large corporations and Google is already very generous with us. We would have loved to see students working on leading edge image processing under the supervision of Andrew Mihal of enblend/enfuse fame, or John Cupitt of VIPS. Maybe next year. Other mentors that registered with our organization on the Google Code page and are left without student are Bruno Postle, Jim Watters and Ken Turkowski. We are a team, and like last year I expect a lot of help and community support to the six lucky students.


Cooperation is a topic I particularly care about for this edition of the Google Summer of Code. We are leveraging the Summer of Code to reach beyond our small world. I am proud that we found an ally in the VideoLAN team, a larger mentoring organization. Granted, we are natural allies: hugin/panotools is used to create media; and VLC is used to play it. Nevertheless, this cross-collaboration, whose idea is the result of a meeting with Jean-Baptiste Kempf at the 2007 Google Summer of Code Mentor Summit, is IMO a demonstration that the whole is worth more than the sum of the parts and that an initiative like the Google Summer of Code adds much more value to the world of FOSS than what can be stated in (highly appreciated) numbers. 175 mentoring organization, 1125 students, 90 countries.

And in our small world we’re working a partnership deal to further motivate and propel the hugin/panotools team, similar to what we did last year. Stay tuned for an announcement.