• 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

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

Hugin Participates in Google Summer of Code 2010

Congratulations to Bruno, James, and Tim, for doing all the legwork and getting accepted for a fourth participation to this Google initiative that helps attract new talent to Open Source projects.

Hugin will be accepting candidates, and it is never too early to join. You can read some advice on how to apply in past posts to this blog tagged Google Summer of Code.

I won’t be part of the mentoring organization this year. Our family is currently in transition and I don’t have any spare time. I look forward to post a panorama of our new home, roughly 1000 Km further West, but our schedule is slippery as well.

Here We Go Again

hugin-logoHugin 2009.2.0 is still warm and fresh out of the oven and I have started the next release cycle. Hugin 2009.4.0 is coming soon to a download server in your neighborhood. The beauty of parallel development without trunk freeze and the discipline of managing the integration queue are starting to pay off: while I was managing the 2009.2.0 release, Tim added lens calibration to trunk and Thomas added a tool to clean outlaying control points by statistical method.

Three simple criteria and three increasing levels of maturity reduced the bottleneck that has plagued Hugin in the past three years as it had to learn to absorb more change than ever.

The three levels of maturity are:

  • “works for me”
  • integration in trunk
  • release to the general public

And the three tests are

  • functionality
  • multi-platform build
  • regression

Works for me

Developers are no longer hindered by trunk freezes. They can work on their ideas any time, simply by branching out a development codeline either locally or in the central subversion repository (I know distributed revision control systems. Andrew implemented Mercurial for Enblend and I love it. Right now Hugin is undergoing enough change. In a quiet moment we’ll open a discussion about the revision control system).

When the implementation is ready to move to the next level, it is checked against the three criteria. A development codeline – whether under revision control or presented as a patch against trunk – is considered mature when:

  • the functionality it is intended to implement works on the developer’s machine (“works for me” condition)
  • it has been tested to build on the major supported platforms (“does not leave them behind” condition) by at least one contributor for each: Windows, OSX, Linux
  • it does not unintentionally break existing functionality (“no regression” condition)

When a development codeline reaches maturity, it enters the integration queue.

Integration Queue

The integration queue is the ordered list of new features / development codelines waiting to be integrated in trunk. The prioritization is a collective decision by consensus of the developers. Silence = consent. The discussion, and the latest version of the list, are on the mailing list.

The integration queue is not set in stone: a change in the maturity status of a feature in waiting is good reason to review/change the ordered list. In any case it is reviewed after every release branching.

The integration queue is all about coordination. The code matures further. Ideally developers talk and there should not be conflicts. In the real world changes in trunk may affect the new functionalities or the other way around. This is the the time to solve this kind of conflicts, and to test the code on a (slightly) broader basis.

A feature from the integration queue is ready to be merged into trunk when

  • the functionality it is intended to implement works on the machines of the testers who bothered to play with the codeline (“works for them” condition)
  • it has been tested that a merge with trunk builds on the major supported platforms (“does not break trunk” condition) by at least one contributor for each: Windows, OSX, Linux
  • it does not unintentionally break existing functionality (“no regression” condition)

This limits the time during which trunk is unavailable. Integration of the features that have gone into 2009.2.0 and will go into 2009.4.0 was almost seamless. And the clean up from the 2009.2 release cycle has benefited trunk so mcuh that the 2009.4 release cycle is expected to be even faster.

If trunk has absorbed a feature from the integration queue and we’re not yet ready for a new release (e.g. because the current release cycle is still on), integration of the next mature feature from the integration queue starts.


Developers are polled once a month whether trunk warrants a release. If there are enough new features and/or bug fixes compared to the last release somebody starts a release cycle. Instead of releasing from trunk, forcing a freeze, we now branch out a release codeline. That release codeline absorbs all the change control that was slowing down development in trunk to a halt. And the polishing changes that it get benefits trunk at the same time.

Again, a release branch is declared matured and released to the public when

  • the functionality it is intended to implement works for a larger number of testers (“works for the public” condition)
  • it has been tested to build on the major supported platforms (lives up to Hugin’s ideal of being “truly cross-platform”)
  • it does not unintentionally break existing functionality (“no regression” condition)


All of this would not be possible without human resources: developers, translators, builders, documenters. A big thank you goes to all of them for making this new, more dynamic pace of development possible. The recipe is relatively simple: every resource is self-directed. The least control is exercised on it, the more likely it is to contribute to the project. So the only controls are the maturity tests – and they can be self-administered. Self-responsibility and empowerment reign.

To me resources are like water. They will flow to an attractive codeline like a stream flows into a riverbed. Barrages (such as a trunk freeze) only impede the flow. Water finds alternative ways, and so do potential contributors. My only task left is to remove bottlenecks. Let them flow!

Google Summer of Code 2009 Wrap Up

Another summer is over. The maples in my neighborhood are changing color and we just finished our third Google Summer of Code (GSoC) participation, the best ever. Like the previous two editions, GSoC has been a catalyst beyond the five project slots generously allocated to us by Google. GSoC has been more than money. More than an opportunity to attract fresh contributors and get things done. It has been first and foremost a transformational opportunity, making an inherently insider organization an open and outward looking one.


Google generously allocated five slots to us and this year we decided to allocate one of them to a smaller Open Source project. It seems to me that there is an ideal mentoring organization size (or at least minimum size) for GSoC participation. Smaller mentoring organizations require a similar amount of administrative effort as larger ones. Sharing is a way of enabling smaller projects to participate while limiting the burden on Google’s Open Source Programm Office.

There are many small Open Source projects in our related field, and in talks I had with them most expressed interest. I decided to work with Professor Sébastien Roy’s Vision 3D Lab at Université de Montréal and his LightTwist project for a few reasons:

  • I needed to make a case to our community that sharing is in our interest. Indeed there was a very short discussion about LightTwist’s relevance to the Hugin community.
  • Meetings and contacts between members of the Hugin community and of the Vision 3D Lab go back to Libre Graphics Meeting (LGM) 2007. We share a similar culture / attitude.
  • Last but not least, I was looking for more academic contacts to promote GSoC recruiting efforts.

The experience worked better than expected. We even organized a joint display of Hugin artwork projected with Lighttwist at LGM 2009. I warmly recommend other organizations to do the same: Next year give a lift to a smaller project!


This was my biggest deception this year. I did put a lot of effort upfront – contacting professors at relevant faculties in my region and beyond. The turnout – at least for us – was zero. Recruiting is indeed our bottleneck. This year again we had more mentors than allocated students, so we rotated mentoring responsibilities. Our recruiting needs improvement.


One of the biggest question was to hire new students or returning ones? I am thankful to my fellow mentors for changing my mind on this one, and I hope our faithful returning students will forgive me. Initially I even convinced one of last year’s students to participate as a mentor. Then I asked him to submit a project proposal. Thank you, Tim, for your flexibility! Student’s life is IMO the most beautiful period in one’s lifetime, enjoy it while it lasts!


Three months are a short period. To make the most out of it candidates must be up to speed from day one. Following the lead of other mentoring organizations, we introduced qualification tasks. Despite some controversy amongst a few vocal students, it has worked well for us. Our goal was to determine basic proficiency with the tools. Other organizations, notably x264, have put more effort in the qualifying tasks so that they also determine if the candidate has the skill to complete the task. It may be more work, but it is definitely best practice IMO, and we should consider putting in this upfront effort.


Remote collaboration works better after a physical handshake. I interviewed all serious candidates by phone and try to organize as many face to face meeting with community members as possible. More by lucky circumstances than by design we managed to meet all students this year: two at LGM in Canada and three at a dedicated meeting in the UK. These meetings have been very productive. Even face to face meeting did not prevent us from failing one student, but they are useful and we should try to bridge physical distance in the future as well.


Our two returning students did not have to get up to speed with the code base and could take on more ambitious projects. And indeed they did, beyond my dreams and expectations.

James Legg, mentored by Bruno Postle, refactored code deep into the core to implement his new layout model. The model works. Minor quirks in specific situations will be fixed. This project corrects a design weakness, unintended heritage of the pre-HDR time.

Tim Hugent, mentored by Tom Sharpless, produced an automatic lens calibration tool. The calibrated lens model still need a lot of validation work through practical use in the field. The potential benefits are improved precision and, beyond panorama making (and Hugin) better images from less than perfect lenses. This project was the first step in an exciting new direction.

Lukáš Jirkovský, mentored by Andrew Mihal, brought deghosting (the removal of moving artifacts from multiple exposures) to the next level and made it available to enfuse, the preferred choice for photo realistic exposure bracketing. Also this project will continue after the end of GSoC.

Yulia Kotseruba, mentored by Sébastien Roy, added new blending algorithms to LightTwist, making it possible to extend the projection surface vertically and opening up new fields of uses such as dome projection or, given enough wall space, a low-cost high-resolution IMAX replacement. Work continues and will be published in a scientific review.

Last but not least a word about Dev Ghosh, mentored by Daniel German. Unfortunately we had to fail Dev because he had not achieved the agreed (and revised) milestone. To his credit he got the mathematics right – his MatLab implementation works. Chances are that the code will be implemented in our code base, sooner or later.

A big THANK YOU to all the students for their effort and dedication!

Update: The only reason to fail Dev was quantity. The quality of his work was excellent. Daniel has implemented it in Libpano and it may become the first chunk of 2009 code to be officially released, with the upcoming libpano 2.9.15.


We found the right recipe for this last year and we recidivate. During GSoC students focus on implementation. They will integrate their code after GSoC. As an encouragement, they will be sponsored a panoramic head from Nodal Ninja, an industry leader that sees the benefits of supporting Open Source software that drives sales of its hardware. At the time of writing, the first project has been already integrated in trunk. Thank you, Bill Bailey, marketing director for Fanotec.

Community Development

On this year’s mentoring organization application form there was one interesting question about “criteria used to select community members“. This lead to some introspection, following which I drafted this community charter. Thank you, Google Open Source Program Office, for giving us food for thoughts.


GSoC projects have accelerated the pace of development. Our sequential development process with trunk freezes and long release cycles was no longer adequate. I’ve taken it upon myself to re-engineer it and at the time of writing we’re getting ready to release for the first time under the new, parallel process. I hope we can integrate and release all the code developed for GSoC 2009 before Christmas, and that our project team will increase it’s capacity to absorb and release code changes.


After graduating university I was offered a job at a company that I still admire (I accepted another job because it gave me the opportunity to expatriate). That company had a three year cycle: the first year you’re hired as a junior and trained on the job. if you did it well the second year your boss moves on and you put your imprint on the job, adding to it what you have learned. On the third year, you train a junior to replace you and if everything went well you’re promoted to the next job. This helped the company stay nimble and up to date. We need a similar attitude in our project. People come and go, and we need to groom the next generation of committers before the current generation fades out; and to document our processes and know how for the perusal of the next generation. GSoC has been a great recruiting ground and our next project leader may be amongst this year’s GSoC students.


Before our GSoC participations, joining Hugin was a steep learning curve. Still today we get consistent feedback from GSoC candidates and students that getting up to speed with the code base is the biggest hurdle they face. Things have improved. In 2007 with an SDK for Windows developers. In 2008 with the equivalent for OSX developers and with build documentation for different platforms. This year it was the release process, and there is more on the plate for the years to come – much of this thanks to GSoC. Thank you, Google!

Hugin-2009.2.0_beta 4 Released

hugin-logoI just released Hugin-2009.2.0_beta4. This is likely to be the last beta in the current cycle. A release candidate is likely to follow soon.

In case you’re wondering about the version number: we’ve decided that a 0.x version number does not reflect well the status of Hugin. A 0.x version number is associated with new/untested/unfinished prototypes. Hugin has long passed that stage. It is very stable and finished enough to be recommended for the general public. It is evolving rapidly, though. So instead of dealing with the major/minor version uptick, we decided that the major version is the release year and the minor version is a sequence number, with odd numbers representing development versions and even numbers representing releases. Since this is the second release in 2009 (after 0.8.0), it is called 2009.2.0.

The highlights:

  • GPU accelerated stitching. Highly experimental. Activate from Files -> Preferences -> Stitching. Depends on a combination of hardware, driver, input images and other factors. Details will be posted in the Hugin FAQ.
  • Improved Preferences panel (Control Point Detectors), with user friendly presets for the most popular choices.
  • Improved control of stitching process (Stitcher tab). Hugin now features an additional Exposure fusion -> Blended and fused panorama output option, useful when it is not possible to keep exposure and white balance constant between shots.
  • Fast Preview shows control points connected with lines – the longest the line the worse the quality (except for vertical and horizontal control lines).
  • Streamlined support for libpano. Libpano13 is now required. Discontinued support for legacy libpano12.
  • Improved build system / support for different platforms.
  • Lots of bugfixes.

I hope we can get the final 2009.2.0 out before the end of the month so that we can continue focus on the next release, which will include the new feature that has been merged into trunk: a lens calibration tool, Google Summer of Code project by Tim Nugent, mentored by Tom Sharpless.

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!

Accepted Students for Google Summer of Code 2009

MascotteThe dice have rolled. For the third year in a row the Hugin community will mentor five Google Summer of Code students as they go about writing free software:

  • James Legg of Fast Preview fame will tackle the Layout Panorama Model mentored by Bruno Postle, improving the handling of stacks.
  • Tim Nugent of Celeste fame will tackle Straight Line Detection for Lens Calibration mentored by Tom Sharpless, improving the handling of fisheye lenses.
  • Lukáš Jirkovský, too young in 2008, has become a significant contributor to our community over the past year and will tackle Ghost Removal for Enfuse, mentored by Andrew Mihal.
  • Dev Ghosh will add Mosaic Mode to Hugin/Panotools, mentored by Daniel German.
  • Last but not least Yulia Kotseruba will add functionality like multiple blending to Lighttwist, mentored by Sébastien Roy.

I am particularly proud of the collaboration with Sébastien Roy on Lighttwist. First, because I believe there is a cultural fit between his Vision3D laboratory and the Hugin community. Second, because it is good to see academics releasing the result of their research (which, let’s not forget, is often funded with public taxpayer’s money) to the general public under an Open Source license.  And last but not least, because I think that Lighttwist is the natural extension to Hugin. I would dare to advance that Lighttwist is to panoramic photography in 2009 what QuickTimeVR was to it in 1999. In a private email exchange Ken Turkowski, inventor of QuickTimeVR and one of our team, acknowledge the analogy.

Then there is a sixth project that I care about. We have teamed up once again (and we hope to be luckier this time) with VideoLAN to bring QTVR playback to this popular media player. This time with an extra bonus: Wiimote control. León Moctezuma, who in 2007 added SPi-V playback to FreePV, will build on his expertise of FreePV and add the Wiimote on top of it, mentored by Antoine Cellerier of VideoLAN.

What’s next for the students? this article I wrote exactly one year ago applies.

Good Luck, students, I hope to congratulate you all in a few months.

A Patch, The First Milestone

hugin-logoBefore considering students for the Google Summer of Code, we ask that they provide a patch against the current codebase. Admission to the program is competitive, and some candidates may perceive the patch as part of the competition. It is not. The competition is at the proposal level, but you need a patch for your proposal to be considered. Why do we ask for a patch?

Think of it this way: when you take a taxi ride from the hotel to the airport, you trust somebody you don’t know. However it’s not blind trust: some simple and implicit observations give you good reasons to trust the driver: if he can knock at your door, he must have the vehicle to get there and the skills to drive it. Furthermore, while he’s loading your luggage into the trunk, you get a chance to observe his vehicle and his behavior. By the time you start the journey with him there are still no guarantees that he won’t get lost or have an accident, but at least you know that he has the basic tools (the car) and the basic skills (he drove it up to your door). You have done your due diligence.

Similarly, you need to quickly build the same level of trust with our community. Do you have the tools it takes to hack into the code? and do you know how to use them? When a contributor uploads a patch to our mailing list or to our tracker (preferred, but to make sure you get noticed please post a link on the mailing list too) he builds instantaneously the same level of trust that the unknown cab driver builds with every new customer: he implicitly shows that he has the tools (hardware, operating system, internet connection, coding environment, repository access) and that he can use them for basic operations.

This is just the beginning of the journey, not the destination. It is a task designed to show basic proficiency. We will not choose our student based on this task. We will choose her based on her proposal. But we won’t consider her proposal if this task is not done, because what use is a driver who promises to get us to the airport if he can’t pull up around the corner and park in front of our door?

My recommendations for the patch, at this point:

  • Get yourself the right tools. Ubuntu, Windows, OS X, almost any platform will get you there. Some are easier than others. When in doubt, ask on the mailing list.
  • No inspiration? Check Bruno’s suggestions.
  • Get it done and out of your way quickly, so that you can focus on your proposal in the little time left before the deadline.

What you should not try to do is something like this patch by 2008 student Tim (likely 2009 mentor). It is very nice, but it was done after a Summer of Code, not before. Those who started early like Lukáš have had plenty of time to establish a deeper relationship with the community, and produce some big patches. If you are starting just now, you need to focus. The deadline is April 3. You can impress us between the moment you get the patch done and the application deadline, April 3. And if you need help, ask. We’re here to help you. Good Luck.