• 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 2008
    M T W T F S S
    « Mar   May »
  • Archives

Do the right thing

Where there is human activity, mistakes are inevitable. want to avoid them? stay put, but you’ll miss plenty of opportunities. it is how mistakes are dealt with that makes the difference between mediocrity and excellence.

I made a mistake during the processing of student applications for the Google Summer of Code. Because of my mistake an application had an inexplicable status when the slotting of the accepted applications came. It was ranked correctly but slotted wrongly. The slot was instead assigned to the application just under the watermark.

You can imagine how the students felt when they saw the published results. The communication channels were all a buzz – with 1125 accepted applications out of more than 7000, there’s a lot of talk going on!

And you can imagine how I felt when I saw the outcome of my mistake. Left to my own devices, my options were all bad:

  • if I stay put and ask my organization to keep silent, it would be unfair. unfair to the deserving student. unfair to my co-mentors. unfair to the ranking process. unfair to Google.
  • if I have the error corrected, fairness is re-established. but at a cost. I could see the disappointment of the deserving student who got slotted and whose slot is then taken away.

I felt bad, but I had to take responsibility. Something had to be done quickly. If fairness was to be re-established, it had to be done as quickly as possible to limit the damage. And if somebody had a better alternative, I needed their help now.

I contacted Google. This was really not the right time. With 1125 accepted applications out of 7000+ there must have been a lot of dust flying around. So while leaving the door open for alternatives, I kindly asked for the slot to be reassigned to the higher ranking application.

Asking for more would have been in my opinion an unacceptable demand and a lack of respect for Google’s donation; for the other 170+ mentoring organization and for the allocation process we were all part of.

A few hours later, an email from Leslie filled my hearth with warmth and joy. She found an extra slot for us in the flying dust! I don’t know if it came from a not yet resolved duplicate; from students who had already disappeared; or even from a student who decided to spend the summer colonizing Mars instead of coding FOSS: Leslie saved the day and turned the situation into a win-win.

Thank you, Leslie. Thank you, Google!

Where there is human activity, mistakes are inevitable. Empowering people and organization take the chance of dealing with them in a way that makes everybody proud of being part of this excellent initiative.

Another exciting Summer of Code ahead!

Student and the Google Summer of Code: What is Next?

The list of accepted students to the Google Summer of Code will be published very soon. If you are on that list, important information below. But first a word for those who are not on the list.

Not on the list

Thank you for your effort. There were a lot of excellent applications. Unfortunately resources are limited, hard choices had to be made and many good applications had to be rejected. It’s the application, not you! The rejection is based on a number of criteria, many of which you could not influence. These include the availability of mentoring resources specific to your proposal; the importance of the proposed work for the community; the number of sponsorships allocated to the community.

What’s next? You are probably disappointed now. Take the time you need to come to terms with the outcome and clear your mind. Then look forward.

  • What have you learned from this experience?
  • What can you do better next time you write an application (for a grant, for a job, or for an hypothetical future edition fo the Summer of Code)?
  • What can you do to improve your chances in the community next time if another opportunity arises?

You are still welcome and we’ll happily help you integrate our community like we help any person new to our community. I’d reccomend you read the advice for accepted students, you may find opportunities there. Last year, one of our students that was not on the list initially got on it 24 hours before coding began.

On the list

Feeling lucky? you deserved it. Take a day to enjoy the feeling. Then roll up your sleeves. You passed the first milestone and there are a few more ahead.

What’s next? You are taking up a new committment. The dates that were tentatively penciled in become fixed committments. You’re hired. Your work time is booked. Moreover, you may want to reschedule some of your free time to bond with the community until May 26. Hang around, participate, communicate, contribute.

In contrast to your work time, there is no obligation on your free time. You do what you can and want, like any other volunteer, which in our case means like every community contributor. While there is no obligation, I strongly advice you to at least do the following:

  • Establish a relationship with your assigned mentor. How will you want to work together?
  • Communicate what can be expected of you. What are your current committment? How much time can you volunteer to the community in the coming four weeks? What do you intend to do in that time?
  • Communicate with the community at large. Blend in.

If you want to really impress, one additional patch to the code against a bug in the bug tracker would be awesome.

We believe we made a good choice, and we hope you believe the same. We are still getting to know each other and while unlikely it is still possible for you to desist or for your mentors to change their minds before May 26. Last year we replaced one student 48 hours before coding began. To avoid this, the recipe is simple: join the community. Hang around, participate, communicate, contribute. And don’t put too much pressure on yourself. Manage expectations.

April Installer

After a hiatus from Windows in March, here is the latest hugin installer. Before heading to the download page, be aware that it still has bugs, some of them recently discovered. There are workarounds too:

For this bug, go into the images tab, select the images for which you need control points and click on the button to generate.

For this bug, just click inside the panorama preview to move the panorama slightly and then go back to the optimizer and click optimize.

Hugin is becoming better, now with a wide variety of control point generators!

Control Points Generators, the more the merrier.

There is a big choice of control point generators in the latest hugin installer. Many of them are experimental. Some work better for some situations than others. Variety is positive as there is likely to be a solution to most situations. But it is also daunting. Which one to choose, and how? here a few pointers. Moreover, the default preferences settings as set by the installer are written down, so you don’t have to be afraid of changing them and not know how to change them back.


Match-n-Shift is Bruno Postle’s idea. Images are remapped to a conformal projection before the identification process. Despite the added step, match-n-shift is not significantly slower. For fisheye lenses, the quality of control points is better than non-remapped generators. Currently it only works with the good old autopano and it is subject to the same patents constraints, but efforts are underway to make it work with Matchpoint.

Default preference settings: -f %f -v %v -c -p %p -o %o %i

Autopano-SIFT Perl

Autopano-SIFT Perl is the latest incarnation of the classic SIFT-based control point generator that has been used by hugin users for years, and its use is limited by the SIFT patent in some countries, notably the United States. The shell wrapper script has been rewritten in Perl by Bruno Postle so that it can be compiled for and run on Windows (where Perl is optional). Linux and OSX users have had access to this tool for a long time.

Default preferences settings: –noransac –points %p –output %o %i


Autopano-SIFT-C is Tom K. Sharpless reengineering of Autopano-SIFT Perl. Tom is passionate about precision and efficiency. He initially used the full scale image to achieve best possible precision, but there is a cost to that: double the maximum dimension and it quadruples the time needed to process that single picture. This gets compounded as the pictures are matched against each other. Autopano-SIFT-C current default is 1600 pixels, but in my installer I have set it to 800 pixels, the value used by match-n-shift and by autopano-SIFT Perl, which yields excellent results.

Autopano-SIFT-C is more efficient and thus slightly faster, though I could not notice the difference with my average project. It also does some remapping, but I found match-n-shift much more elegant. The main difference is that Autopano-SIFT-C has a monolithic approach. Everything happens within a single file: scaling, reprojection, detection, matching, so it is less flexible to combine and cooperate with other tools.

Last but not least, the algorithm is still SIFT, so patents may apply.

Default preferences settings: –maxdim 800 –maxmatches %p %o %i
–maxdim (default 1600) => set to 800 to compare with a-c-c

Edit: I’ve been made aware of a recently introduced expandos in hugin that I had forgotten. –maxmatches %p %o %s will use a conformal projection. A practical show of how right Agos’ comment below is!


Matchpoint was Zoran Mesec’s 2007 Google Summer of Code project. He wrote it as a drop-in replacement for the generatekeys program that came with autopano, so it was easy for Bruno Postle to adapt the Autopano-SIFT-C wrapper to it. Unfortunately Matchpoint still has a problem dealing with transparency masks, so it can’t be used with match-n-shift.

Matchpoint is the only feature detector in this article to be free of patent. It is still experimental but yields useful results. In the upcoming Google Summer of Code participation Onur Küçüktunç will develop a feature matcher to go with, mentored by Alexandre Jenny, the author of Autopano Pro.

Default preferences settings: –noransac –points %p –output %o %i


Panomatic is the newest kid on the block. It is an implementation of the SURF algorythm (which is also patent protected in some jurisdictions) by Anael Orlinski. It is built to extract maximum power from modern multi-core processors and comes in two flavors. The standard Pan-o-matic runs on modern CPUs, that means Pentium 4 and newer or AMD Athlon XP and newer. The NOSSE version runs also on older CPUs.

Default preferences settings: -o %o %i

A few interesting options for those who may want to try:

  • -n<number> sets the of cores to use (default: autodetect)
  • –fullscale use full scale images to detect keypoints
  • –ptgui activate compatibility with PTGui

So which one should I choose?

The default is Autopano-SIFT-C. It is robust and yields good results. But if you are using fisheye lenses, Match-n-Shift is probably a better option. If you have a modern powerful multi-core CPU, you may want to give pan-o-matic a try.

All of them, though are subject to patents – either SIFT or SURF. It is your responsibility to make sure that you are not violating a patent in your jurisdiction of residence.

Matchpoint solves the patent issue for feature detection, and hopefully by the end of the Google Summer of Code we’ll have a patent-free solution also for the feature matching.

The Human Reflex

Next time you go to a restaurant, let your friends choose where they want to sit. Chances are that they will prefer the chair with the back to a wall – an ancient reflex from the time our ancestors lived in caves and gathered around the fire.

Such habits can sometimes get in our way. Most people today are aware of the environment. But do you turn the shower off when soaping your body? And do you wash cutlery and crockery in a still water basin or under running water? Oh, sure the dishwasher…

The preference for running water is another ancient reflex. In nature still water is more likely to be contaminated. In a modern household this reflex is an obstacle to environmental-conscious behavior and requires an extra effort to be overridden.

Nature does not like voids. When new areas open to human endeavor, new reflexes are not far away. To my parents’ generation, a mouse is first of all a furry rodent. My kids will most likely think of a computer input device first.

Reflexes are an efficiency mechanism of the mind. They reduce the effort required to deal with a recurring task. They work well in most situations, but on a few occasions they yield false positives. Once instilled, they are difficult to override.

Each person develops her own reflexes. Reflexes come in clusters as people subject to similar experiences tend to develop related reflexes. Once formed, it takes a lot of energy to override a reflex. Think of a Briton driving on continental Europe, or an American driving in the United Kingdom. There is no right or wrong side of the road to drive: there are only local standards. And there are reflexes developed by people growing up with them.

Replacing a reflex is an even more complex process. Left to nature, reflexes change over generations and the change is hardly predictable. To intentionally influence such a process requires a concerted effort with plenty of resources, persistence, and leadership. Canada has tried to adopt the metric system since 1970, but to these days when I talk with my Canadian father-in-law or when I go to the local Home Depot, I’m confronted to a confusing mix up of imperial and metric units.

The three ways to deal with reflexes

  • Advocate a change and hope for the best
  • Impose a change
  • Adapt and design for the existing reflexes

Advocation is utopia and not always successful. Awareness campaigns advocate careful usage of water, but at the end of the line the user will choose the path of least resistance.

Imposition is harsh and not always possible. Governments can curb waste of water with imposed regulations, higher prices and penalties; and monopolists can sometimes impose a change too. But given an alternative, most users will take it.

Adaptation is the most elegant and efficient solution. Nobody had to advocate or impose dishwasher adoption to me. The beauty of the dishwasher is that it fits in well with existing reflexes. Sure, it has plenty of other positives features too, but the killer feature is that I don’t have to change my lazy habits.


Every product cycle introduces changes. The successful designers are careful to understand the interaction of their changed products with existing reflexes. They spend millions on usability labs to learn from the user’s interaction with their products. They consciously focus on incremental changes adapted to existing reflexes. And they carefully gauge how many radical changes they can introduce before the reflex becomes an obstacle to their product’s popularity. This is even more true for software, with its faster product cycles and ease of change.

New car models come out every year with incremental improvements. But fundamentally cars have not changed in the past 30 years: sit at the steering wheel of any rental car at any airport of the world and most reflexes learned at home still apply. There has been occasional eccentrics, like the Citröen 2CV with its stick shift out of the dashboard; but most car manufacturers adapt to what has established itself as a standard.

Before trying to change my reflexes I will look hard for a device compatible with them. Ah, the dishwasher… if only there was a mainstream shower device capable of such water efficiency.

And software?

The majority of current users have developed reflexes with market leading software from the recent past. Reflexes are a legacy that must be taken into account if the software is to become widely adopted. Like any legacy, it often means constrains and painful compromises.

Current web user reflexes were developed on Netscape Navigator; office workers developed their reflexes over the past twenty years mostly on Microsoft Office; graphic designers on Adobe Photoshop.

To compete in those areas, a software package needs first mimic the behavior of the (old) market leader. Even if it means making painful compromises. The first goal is to achieve acceptance and market share, not to lead the pack into a new, revolutionary direction. No user will ditch the comfort of his habits without a very compelling reason. It’s too easy (and efficient) to lazily stick with the existing reflexes and legacy software. Press the big button on the dishwasher.

Only after critical mass is established can a software project start to exercise some careful leadership. The radical change envisioned by the project’s founder becomes the vision toward which the software evolves over time. However the pace of software evolution needs to be carefully synchronized to the much slower pace of habits evolution. Do it too fast and the users will refuse to follow. Witness Windows Vista.

In the browser wars of the nineties, Microsoft first adapted to the existing reflexes and copied leader Netscape Navigator. It has taken a number of interactions (and the compelling power of a monopolist) to first “encourage” users to adopt Internet Explorer, and then lead them to change habits. Not necessarly toward good new habits. HTML email anyone?

It works the other way too: OpenOffice adapted to existing reflexes of office workers. Sure, it is a Microsoft Office look-alike, but it has achieved the critical mass and can slowly but surely start to change the paradigm.

Only a package with critical mass has the clout to influence the direction of change, and even the nine hundred pound gorillas have limits: move forward at a too reckless pace and the magic breaks, leaving users behind with their old habits.

My desktop

As a user turned off by Microsoft, I am looking for a change. Not everything that is done on the other side of the divide is bad, and I am not willing nor able to ditch all of my reflexes. I have reported to the Gnome usability list two habits that are too much change for me: the way Gnome deals with timestamps when copying files, and the way it deals with thumbnails.

Gnome users have their reflexes too, and unsurprisingly many of them are different from Windows reflexes. The first, understandable reaction was evangelizing. After all, I am the one coming to Gnome, so it is natural that I should convert to Gnome reflexes. And there are plenty of them that I am interested to adopt.

The people who answered me on the Gnome usability list are fundamentally right. Gnome is a desktop built on top of Linux. And Linux was built from the ground up to share resources between multiple accounts logged in simultaneously. Each user needs an account to log in to the machine and has access only to those resources that an almighty administrator allocates to him. That’s perfect for the data center, and unsurprisingly Linux commands a high market share there, where virtual users happily coexist. Linux works very well there, in an admin-centric system.

The P in PC stands for Personal. It’s a person using the resources, not a virtual user. And that person has natural reflexes. The continued success of Windows on the desktop is that it was born as, and still fundamentally is, a single-user concept. After all, sharing the same keyboard and display simultaneously is not very practical, and sharing them over time is easier on the basis of personal trust, not of system accounts. System accounts can’t replace personal trust, and I’d rather trust the person currently sitting in front of the PC, than some almighty and distant administrator. That is: if the person sitting in front of the PC trust the administrator, I can trust him as well.

From one answer I got, it seems that a person using Gnome is expected to know which account is logged in. And to know and trust the almighty root account. It has gone so far, that the account has replaced the physical user:

If someone inserts removable media into the machine while I’m logged in, it’s their problem that they didn’t check to see who was logged in.

The natural human reflex is that the person sitting in front of the PC is the current user. The natural human reflex is not to care about such an abstract concept as a login. It seems that a Gnome user is not a person, it is a login! And that the highest objective is to simplify administrator’s life. My proposal was trading off user convenience vs. administrator convenience and has been dismissed as administrative nightmare.

In my opinion a desktop should be uncompromisingly user-centric, not admin-centric. Anything else is useless for a desktop. It seems that not many share this view on the Gnome usability list – or at least they are not vocal about it.

Conclusions (for now)

I am back with the dishwasher. Windows (not Vista) works for me. It will keep working for another few years until Microsoft pulls the plug, forcing users to upgrade to Vista (or beyond). That gives me a few more years to look for alternatives. I will keep dual booting into Ubuntu, promoting the water-efficient shower. And I may bite the Apple – I was a happy OS6 and OS7 user back in university – but that’s another story.

World Wide Panorama

The latest World Wide Panorama event is online. I did not have much time to process my entry, an objectVR movie.

Unfortunately the above site requires QuickTime, and that QuickTime is not available for Linux. There are plenty of media players that play linear QuickTime content, but support for QTVR – cylindrical and cubic panoramas as well as object VR movies – often falls short.

Last year the FreePV viewer was a Google Summer of Code project. This year I hope that we can take it further with the help of the team at VideoLAN. The plan is to integrate it in VLC, one of the most popular free media players out there, and my favorite on both Windows and Linux.

Grocery Shop

A bug tracker is like a grocery shop. Plenty of bug reports are neatly sorted on the shelves, waiting for the developers to fix them.

Developers stroll down the alleys, pick a bug or two and go to the checkout counter. If they are lucky, the bugs fix quickly and they can come back for more.

As any grocery shop owner will tell you, it is important to stay well stocked up with fresh produce. Too much stock will rotten. Too little stock will drive customers away.

Similarly, if there are more reports in the tracker than the developers can handle, things can turn sour: the daunting sight of an endless list can turn even the most motivated developer away. Progress in other areas may make some of the reports obsolete, but which ones? And without feedback the reporters feel that their reports are unimportant and they stop filing.

A significant part of the activity of a grocery shop is inventory management. Removing expired items from the shelves, cleaning up the alleys, making it an inviting environment for shoppers and knowing when to call the suppliers.

The bug tracker is not different. More experienced tester try to reproduce the reported bugs and sort them out. Builders will ship out new snapshot releases to invite new bug reports when the inventory diminshes.

A well working grocery shop depends on a balance between supply and demand, and so does a well working bug tracker.

In the past two months the hugin bug tracker has shed 119 reports. That’s excellent. It has also added 97. This means that there is enough supply of bug reports for now. What the project needs are bug fixes.

Until recently it was almost exclusively Pablo who worked on the fixes. Last week Gerry Patterson stepped in and made significant progress. But the trend is still weak, and the  imbalance between the supply of bug reports and the capacity to follow up on them needs to be absorbed. The project needs more bug fixes. There are still 21 bugs in the 0.7.0 category. I hope the students that have recently joined our community for the Google Summer of Code 2008 will contribute some more fixes before coding of new features start.