Blogroll

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.

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.

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.

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.

Allocation

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!

Recruiting

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.

Students

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!

Selection

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.

Meetings

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.

Projects

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.

Integration

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.

Speed

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.

Generations

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.

Conclusion

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!

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.

The first time I needed video broadcasting service it was for a screencast of Hugin’s fast preview functionality, developed as a Google Summer of Code project by James Legg. I went to the GSoC mentors mailing list for intelligent advice and made an informed choice: Vimeo had the better conversion quality. A few month later I needed broadcasting services again and I kept using Vimeo to share with family and friends the exploits of our son. I like the service, its clean look and most of all its outmost respect of privacy and of content ownership.

When I applied for the best job in the world, I knew they were partnering with YouTube. I also knew that in the meantime YouTube upgraded its encoding quality. Is it good enough to motivate me to switch? YouTube is the most popular and has become synonymous with online movies like MP3 has become synonymous of digital music files. There are better formats for digital music files than MP3, like the lossless Monkey’s Audio APE or the Open Source OGG-Vorbis. So how does YouTube compare to Vimeo today?

Find it out for yourself below, where the two services are side by side. In the process of producing my video, I ran it through Vimeo to control rendering after conversion before submitting. Note that for HD playback you’ll need to click and go to the respective YouTube/Vimeo sites. This article is not really in my interest as the contest is still on and my interest is to direct traffic to my 60 seconds clip here, and for you to vote for it and to talk about it with other friends so that they go watch and vote too. If you care about VR and want to see this big PR-event showcase VR as well, you have an interest to vote for me too since you know that I will have all of my pano gear with me and will put it to good use, promoting the techniques that you too are using and promoting.

A few more details of the video. I usually render in FullHD but I ended up rendering this one in “simple” HD because of the weight limitation (my 60 seconds video clip ended up at 45MB). Below are, side by side, the Vimeo-encoded and the YouTube-encoded versions of the clip. Up to you to judge which quality you like most.

Here 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?