• 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

    September 2009
    M T W T F S S
    « Aug   Oct »
     123456
    78910111213
    14151617181920
    21222324252627
    282930  
  • Archives

Pushing the Boundaries.

One of the constraints when shooting panoramas with Hugin (and with most panoramic tools) is the No Parallax Point (NPP). There are physical and logical reasons to turn the camera around it when shooting images for a perfect stitch: Physically, pictures taken from the same NPP have no parallax. Logically, the mathematics of panoramic software is simpler when assuming that all pictures are taken from the NPP.

Photographers build or buy panoramic heads to help them keep their camera’s NPP aligned with the point around which it is rotated. Unfortunately the panoramic head leaves an undesired footprint on the nadir. One technique to deal with the nadir is to move the tripod for an additional shot, often handheld. That shot is most often offset from the center of the panorama.

PTGui was the first panoramic tool to deal with an offset NPP. It requires the control points in the offset picture to be on a single plane – not an unreasonable assumption for the ground on which the tripod stands. Hugin has lacked this feature for a long time. Now it has been introduced by Pablo, inspired by the discussions preparing Dev’s Google Summer of Code 2009 project (that yielded another type of transform for mosaic mode, implemented by Daniel very recently in libpano.

Dev’s original project was about mosaics and not necessarily the nadir shot. I’m interested in mosaics too, I want to break away from the limiting factor of the sphere.

So the other day I went for a stroll in town, and I shot a few pictures. Hand held. With my son sitting comfortably in the back pack.XYZ_previewThe sphere is still somewhat a limiting factor, and so is the rectilinear projection.

No panoramic head was used to shoot this 18.000 pixels linear panorama. What is next?

Hugin 2009.2.0 released

hugin-logoToday I released the latest stable version of Hugin. It features experimental hardware accelerated stitching using the GPU, more user friendly presets for the control point detectors plugin, exposure layers fusion and many user interface improvements and bug fixes. For details, check out the release notes.

Little Planets Conquering Big Business

080302dufferin_planetGreat news for panorama makers all over the world: Expedia.co.uk is using little planet images of tourist destination by New York photographer Sam Rohn and Paris photographer Alexandre Duret-Lutz.

Browse Network Drives

One issue that affects Hugin (and many other software packages using the native GTK+ GtkFileChooser) is that when browsing for files it does not see network mounts. There are a few ugly workaround there such as mounting them with Gvfs. Does anybody know a more elegant workaround? of course my preferred would be to simply type smb://… in the File Chooser; and for the FileChooser to show the exact same places and drives as Nautilus. Maybe it is possible and I just don’t know how to do it on my Ubuntu 9.04 box? Help welcome.

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!

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.

Auto-Exposure

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.

blended_n_fused

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

History

Using Google Books, Jim Watters located some historic sources on how to make panoramic photos.

Thank you, Jim!

Archimedes’ Principle

Groundhog protecting his hole“Any object, wholly or partly immersed in a fluid, is buoyed up by a force equal to the weight of the fluid displaced by the object.”

Any change thrown into a community is rejected by a force proportional to the conservatism of the community and to the size of the change.

Change needs to be managed, particularly in Open Source communities.

  1. Create a climate of less conservatism, e.g. by getting users used to small, non-critical changes (best practice example: Ubuntu’s continuous and small changes of skin between versions).
  2. Float the ideas early and talk about them so that they won’t come unexpected.
  3. Identify the key opinion- and decision-makers in the community and get them to buy into the ideas. Gather support.
  4. Identify timing opportunities to introduce change (e.g. the new start of a development cycle is better than the middle).
  5. Implement small chunks of change when the opportunity arise and when you’re sure that you have the available resources and support to make them fly.

I’m an agent of change. I just released Hugin-2009.2.0_beta2, and there’s more to come. Watch me. You don’t need to love me.