When the dust settles

It’s a few week before the official coding starts. The students are bonding nicely with the community. Ideas are flowing, and some patches too. I can’t wait to see what they will do when they are officially on Google’s payroll and assigned to work full time on hugin.

While Pablo and Alexandre P. are at LGM, time to introduce properly this year’s team that will participate in the Google Summer of Code. There is a lot to be written, and more may come over the next few months as the summer unfolds. For now, here is an overview of the six projects we’re working on, of the people, and of exciting things to come.

The Projects

There are six projects this year in our portfolio, even though only five are listed on the Hugin/panotools entry at Google. The sixth project is a joint effort with VideoLAN on their leading cross-platform media player. It is listed on their page at Google.

OpenGL hugin preview

The preview windows is central to the panorama making process. It is here where the author looks at his composition before rendering it. It is here that framing decisions are being made, interactively. Right now the interaction is slow.  James Alastair Legg, mentored by Pablo d’Angelo, will improve the panorama preview windows by giving it the speed of OpenGL. We expect near real-time interaction for the author when composing his panorama.

Automatic Feature Matching for Panoramic Images

Critically important to stitching panoramas is to identify overlapping images in two features and align them in space. In the past, this was tedious, manual work. Then control point detectors came along. Those available to hugin users are still tainted by patents. It’s a two step process: detecting features and matching them. In Google Summer of Code 2007 Zoran Mesec wrote the detector, MatchPoint. This year Onur Küçüktunç will write the matcher, mentored by Alexandre Jenny, author of the original autopano and of Autopano Pro. A beautiful example of cooperation and co-existence between the proprietary and open source world. We expect to have a fully patent free control point detection process.

Masking in GUI

Overlap regions between two images are the nature of stitched panoramas. Since the world is in movement, such overlaps often present challenges that won’t match. The current solution is to render each image on a separate layer, and then mask out manually one of the two images so to display only one frozen instance of the moving object. This can often be a painful work at the single pixel level. Fahim Mannan, mentored by Daniel M. German, will introduce a simpler workflow: just mark the moving object with a couple of approximate brush strokes and his code will work out the exact object boundaries automatically. We expect an improvement for those using hugin to stitch action panoramas.

Batch Processing

Photographers often come back from the field with tons of photographs to stitch. A lot of this could be automated. Even more so with the up and coming pano-videography. Marko Kuder, mentored by Zoran Mesec, will improve hugin’s batching abilities. We expect to be able to process repetitive tasks without human intervention.

Machine-based Sky Identification

Some areas of photographs are better suited for control points than others. The sky, with its moving clouds, definitely not, as good control point don’t move between images. Timothy Nugent, mentored by Yuval Levy, will train a support vector machine (SVM) to identify clouds in the sky as a bad area for control points, so that it can be masked out before triggering the control point detection. Once working the method can be extended to other features as well, such as foliage and water.

Panorama Viewing in VideoLAN

19 years after Tim Berners-Lee invented the web there is still no universal format to view panoramas on the web. Apple’s QuickTimeVR, the original technology to display full spherical panoramas, is not available on platforms other than Windows and the Macintosh, and it is no longer developed by Apple. A lot of good things have happened with Flash panoramas in the last year. Nevertheless, a lot of legacy content out there is captive of the QuickTime format, like the World Wide Panorama. In Google Summer of Code 2007 Leon Moctezuma added functionality to FreePV. This year Michael Ploujnikov mentored by Yuval Levy will integrate panorama viewing in VLC, a leading cross-platform media player. We expect Linux users and users of other alternative platforms to have access to the majority of QTVR content soon.

The team

I’m happy to pass the admin role to Alexandre Prokoudine this year. We had more available mentors, student applications and project ideas that we would have loved to follow through, but resources are limited also for large corporations and Google is already very generous with us. We would have loved to see students working on leading edge image processing under the supervision of Andrew Mihal of enblend/enfuse fame, or John Cupitt of VIPS. Maybe next year. Other mentors that registered with our organization on the Google Code page and are left without student are Bruno Postle, Jim Watters and Ken Turkowski. We are a team, and like last year I expect a lot of help and community support to the six lucky students.

Partners

Cooperation is a topic I particularly care about for this edition of the Google Summer of Code. We are leveraging the Summer of Code to reach beyond our small world. I am proud that we found an ally in the VideoLAN team, a larger mentoring organization. Granted, we are natural allies: hugin/panotools is used to create media; and VLC is used to play it. Nevertheless, this cross-collaboration, whose idea is the result of a meeting with Jean-Baptiste Kempf at the 2007 Google Summer of Code Mentor Summit, is IMO a demonstration that the whole is worth more than the sum of the parts and that an initiative like the Google Summer of Code adds much more value to the world of FOSS than what can be stated in (highly appreciated) numbers. 175 mentoring organization, 1125 students, 90 countries.

And in our small world we’re working a partnership deal to further motivate and propel the hugin/panotools team, similar to what we did last year. Stay tuned for an announcement.

First May Installer

This is the first hugin installer in May, and probably not the last one. Fahim Mannan, one of the students that joins us for this year’s Google Summer of Code, is leading the way into the Community Bonding Period. He has helped fix some bugs that warranted for a new snapshot. The other students are being active as well. This will be a great summer.

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

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

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

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

Pan-o-matic

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.

Change

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.

Flash Panoramas, the more the merrier.

The beginnings

In the beginning there was QuickTimeVR. Or was it ptviewer? Those were the days! At the turn of the millenium fans of both technologies fought endless verbal battles about which one is best to display their full spherical artwork. Then two things happened that left them in the cold:

• now defunct iPix forced Helmut Dersch to pull the plug on panotools and ptviewer. The first Open Source panorama authoring and publishing solution survived thanks to the contributions of Fulvio Senore (ptviewer) Jim Watters, Bruno Postle, Daniel M. German and other contributors (panotools). Helmut’s software was ahead of time. He is now back in the community with new ideas.
• business logic at Apple pulled the plug on QTVR development. It has lingered unsupported inside QuickTime, until recent updates crippled some functionality dear to VR-artists.

Life went on

• Starting with the release of Windows XP Service Pack 1, Microsoft removed Java from its system and initiated Java’s decline in ubiquity. It has continuously lost market share since then and is now down at about 84%. Ten years after the inception of the web there was no widely deployed standard yet to display VR content!
• 3D accelerated video cards became mainstream, and with them the market share of Adobe Shockwave increased too. Probably the first 3D accelerated panorama viewer, SPi-V was released November 22 2004 by Aldo Hoeben.
• A flurry of viewing technologies came and went. None of them achieved more than single-digit market share. Noteworthy is DevalVR that attracted a passionate following of discerning users for its smooth panning and small footprint.

A new Open Source viewer is born September 14, 2005 when Pablo d’Angelo starts the FreePV Open Source Panoramic Viewer Project with Fulvio Senore and Thomas Rauscher. It is the first viewer to play QTVR on Linux and raises a lot o

f hopes in the community. A Google Summer of Code 2007 project by Leon Moctezuma added SPi-V playing capabilities, but the viewer is still experimental and suffers of the same problem the flurry of other viewing technologies: lack of market penetration. Keep fingers crossed, this year it may become a Google Summer of Code again, integration with the VLC media player.

Flash to the rescue!

Flash based panorama players have existed for a while, though most of them did not correct perspective properly and where apt for either flat pictures (like Zoomify), or for cylindrical panoramas.

With the arrival of Flash 8 in August 2005 (although Linux users had to wait until January 2007, when Flash 9 for Linux was released), full spherical panoramas became possible. First generation full spherical players include Thomas Rauscher’s Pano2QTVR and Immervision’s PurePlayer Flash. Flash 8 was not completely up to the challenge yet. The audience reported seeing snakes instead of straight line.

With Flash 9 quality improved dramatically. Denis V. Chumakov’s FPP became the most popular Flash 9 player.

Flash is the most widely distributed plugin, with a market penetration of 98%. Adobe has done almost everything right to get Flash widely accepted. It’s a unique value proposition of ubiquity, features and flexibility.

In March 2007 I predicted a mushrooming of Flash based panorama viewers within 12-18 month, similarly to Flash based mp3 players. Today, Patrick Cheatham and Zephyr Renner made my prediction come true with the release of an Open Source viewer based on the Papervision3D engine. I hope it is the start of a growing community effort.

Meanwhile, Adobe works on Flash 10 that will include hardware accelerated 3D. Exciting times ahead!