Low Hanging Fruits vs. Seeding a Tree

Low hanging fruits are a tenet of Open Source:  work smarter rather than harder; reuse as much code as possible;  release early and often.  This way spare-time contributions bear fruits quickly.  And yet there are situations when the fruits are not low hanging.  Actually, the fruits do not exist yet.  Somebody has to plant the initial seed and help a tree grow for it to bear fruits.

Seeding and growing takes time.  A Google Summer of Code project is an opportunity for such a seed.  Technically it is a 480 hours project all in one chunk, compared with the average spare-time contributor that puts in 2-4 hours per week and would take 2-4 years to clock that same quantity of hours (not considering the losses due to the pauses between the chunks of work).

So while in most cases the tenet of focusing the effort on the low hanging fruit still holds, it is important not to miss unique opportunities to add new seeds to a project.

Hugin Participates in Google Summer of Code 2011

Congratulations to Habi for spearheading the effort.  A list of all 175 accepted mentoring organizations is here.  If you know of a university student who would like to get paid to write code this summer, let them know about the Google Summer of Code: the student is free to work on a project idea of is liking, including his own original ideas, within the context of a mentoring organization like ours, and gets T-shirt and a neat stipend from Google.

Next step for would-be student participants that wants to do work on the Hugin/Enblend/Panotools codebase is to join the mailing list, introduce themselves and make their intention of participating in the Summer of Code as students known, and work on their applications.  The earlier you start, the better.  The application deadline is April 8 19:00 UTC.

For advice to would-be student participants, look at the Google Summer of Code category in this blog.  Good luck everybody!

Hugin-2011.0_beta 1 released

I just kicked off a new release cycle with the release of Hugin-2011.0_beta1.

It’s only two months since our last release, and yet the project has made another leap forward.  Pablo improved CPFind (Hugin’s own patent-free control point detector) to the next level.  Darko integrated his Google Summer of Code 2010 project, making the fast preview even more interactive.  Thomas added a gray point picking tool for white balance control.  Vladimir Nadvornik added functionality to register stereo images.  And as usual there are lot of small improvement and bugfixes.

From a process perspective, this is the first time that we run a release with a formal schedule.  During the previous cycle I announced my intentions and mostly stuck to them; and when setting up Hugin on Launchpad I did reflect the previous cycles and releases in the project’s history.  But now dates are being put foward.  No panic, oh Open Source purists!  The dates are purely indicative and the principle still stands:  a release happens when it is ready, not when it is due.

From an infrastructure perspective, this is our first release since SourceForge was attacked.  For the first time I am actively seeking redundancy,  using both project hosting infrastructures available to us:  SourceForge and Launchpad.  The tarball can be downloaded here and here.  Nobody likes SPOFs.

To continue what I hope will become a tradition started with the 2010.4.0 release, this release will be dedicated to Claudius Ptolemaeus and Marinus of Tyre.  Details in the ‘about’ menu of the app.

And to start a new tradition, this release will feature artwork from a Hugin user in the splash screen.  There are a few candidates for it and you, the user, get a chance to choose which one will be adopted.  The cutoff date for the voting will be a few days before the first release candidate.

Enjoy the best Hugin ever!

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.

Moved 2: From Subversion to Mercurial. Part 1, Setting the Stage

It’s less than four weeks since I drove that 26′ U-Haul truck full of stuff and I’ve had enough of moving for a while.  So why move again?  This is a different kind of move: a move to more efficient infrastructure.  To a decentralized source code repository.  Thank you Subversion, you’ve served us well over the past years.  Welcome Mercurial, a distributed revision control system (RCS) of the next generation.  In this series of three articles I describe how I moved Hugin from Subversion (SVN) to Mercurial (Hg).  In the first part I’ll describe how to kick off the process in the community and set the technical stage on your machine.  The second part deals with the technical code conversion.  The third part with the conversion aftermath and the actual switch.  Once the road is mapped out, the process is a relatively straight forward one.  I made some mistakes while mapping the road and I hope that if you find yourself in the same situation, these articles will help you prevent such mistakes.

Why Mercurial and why Now?

It could have been git, or Bazaar.  They are all equally good.  But I found Mercurial to be the one with the more mature client support, particularly GUI clients on disparate operating systems; and it is well supported at SourceForge where Hugin is currently hosted.  Our project needs to accommodate contributors using Linux, Windows, OSX, BSD and we do not want to leave anybody behind.  To get all stakeholders buy into the process I started a public discussion.

Spring was the right time for repository cleaning.  With a tight integration schedule the team merged most outstanding development branches into the main code line.  Migrating before branching out again for a new set of Google Summer of Code projects will avoid extra complexity.

For more than two years Hugin has been humming along on an asynchronous development and release process that has helped increase the capacity of the project to absorb changes.  Despite a diligent, disciplined and careful team we seem to have hit a scalability ceiling.  It may be lack of resources (except for the Google Summer of Code students during their three months on Google’s payroll, we’re all here in our spare-time) but I suspect that it is also the infrastructure and I expect Mercurial will further increase the capacity of the project to absorb changes.

SourceForge

One of the first questions to arise from the community was the scope of the change.  If already changing RCS, how about reviewing all infrastructure?  Hugin has been at SourceForge since inception.  A lot has happened in the project hosting arena since.  Sites like GoogleCode, Launchpad, BerliOS, GIThub offer a panoply of services – RCS; bug tracking; mailing lists; web and download hosting.  Often different implementations of the same Open Source tools.  Mostly “free” (as in beer, but beware of the alcohol)  for Open Source projects like Hugin.

The RCS, while central to the project, is just part of a project’s infrastructure.  Migrating the whole infrastructure is beyond the scope of this project.  And beyond the available resources too.   Just moving the nearly 200 open bug reports (many of which are stale or duplicate – the bug tracker needs a good spring cleaning too) to a new bug tracking system can keep a spare-timer busy for months.  SourceForge may not be the most fashionable choice, but it works for us.

Server and Client

On the one side is an existing SVN repository on the SourceForge server.  On the other side is a new Hg repository on the SourceForge server.  How do I move the code from one side to the other?  The first mistake I made was to work on the SourceForge server itself.  This slowed me down and ate their precious bandwidth.  I should have known better: SVN runs on the server sitting in my office closet.  Even that was too much overhead.  The most efficient way to go about the task is to mirror the SVN repository to a local client and work from there.

These are the steps for a K/X/Ubuntu distribution:

sudo apt-get install mercurial subversion python-subversion
svnadmin create hugin-mirror
cd hugin-mirror
echo '#!/bin/sh' > hooks/pre-revprop-change
echo 'exit 0' >> hooks/pre-revprop-change
chmod +x hooks/pre-revprop-change
export FROMREPO=https://hugin.svn.sourceforge.net/svnroot/hugin/
export TOREPO=file://`pwd`
svnsync init ${TOREPO} ${FROMREPO}
svnsync --non-interactive sync ${TOREPO}


The initial sync can take hours or more.  This is a good time to take a break.  If the sync is aborted, you may need to reset the lock state and restart the conversion:

svn propdelete svn:sync-lock --revprop -r 0  ${TOREPO}
svnsync --non-interactive sync ${TOREPO}

It’s a good idea to repeat the above two commands in a cron job or a startup job to keep in sync with the repository over time.

Your local machine is set for the job.  Keep the discussion in your community going, to get all relevant stakeholders to buy into the process. On the next installment we’ll look at how to map the road.

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.

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.

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.

Nodal Ninja Calibration Tutorial

Ever since Bill Bailey sponsored our Google Summer of Code team with Nodal Ninja panoramic heads, I’ve been using it for higher resolution partial panoramas.

The guy in red with the white beard brought me a Sigma 15mm Fisheye lens. And the guy in blue with the black beard had to calibrate it right away. And at the same time describe this ingenious method he first saw from John Houghton. This works only for dSLRs. All you’ll need is a second camera and a source of bright light.

Assemble the Nodal Ninja with the lens to be calibrated and position it with the source of light in the back.

Position your second camera so that it can see the center of the lens.

Calibrate the horizontal position (left/right relative to the rotator in the horizontal plane) by moving the camera between two symmetric positions and checking that the entrance pupil disc is in the same place at the two positions. The symmetric positions are simply 180° apart by turning on both the horizontal and vertical rotators.

Once the horizontal position is calibrated, calibrate the depth of the camera on the upper arm. Again, the principle is the same: take two pictures of the panoramic head in two different positions and compare the positions of the entrance pupil disc.

For fisheye lenses the yaw difference between the two pictures must be the stepping used during shooting because the entrance pupil moves with changes of the light’s angle of entry. So if you shoot six around at 60°, turn the panoramic head to -30° and to +30° relative to the second camera. Shoot and compare the two pictures.

Music courtesy of Quantum Jazz, licensed CC-BY-SA.

Happy calibrating!

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.

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!