Revisting Old Places

I’m currently at my parents in southern Switzerland. Usually this is a wonderful place with plenty of sunshine (there is an institute for solar research just around the corner). For the past three days it was under torrential rain (more than 150 liters per square meter in 12 hours). The rain has not stopped Fulvio Senore and Alessandro Ugazio from giving us a warm welcome on a train stop in Domodossola, Italy (restaurant panorama is in the making; the RAW files have been converted with RAWstudio; Hugin has stitched them; I’m struggling with the masks and layers in GIMP). My parents are enjoying their grandchild.

I had plans to meet old school friends and to take some pictures in old and familiar places. No pictures under the rain. Instead, I revisited a different kind of old and familiar places. It has been about a year since the last time I’ve looked back at the effort I initiated to document the Hugin build process. My hope for that page (and for the build and release process) was that it would take care of itself over time. While there is now a thriving community of builders and testers, some part of that effort had not materialized as I hoped. During the last LGM I discussed some of the learnings with Pablo and we’ll start implementing them after the 0.8.0 release. In the meantime, I started updating the page.

That page, with the pages linked from it, represent an important step to me: the stepping stone from user to contributor. When I joined Hugin, I was just a user. Actually, I was a pain in the neck user, asking for stuff all the time. I wish I could have contributed stuff, but I lacked the necessary knowledge and the learning curve looked daunting steep. So I contributed my chutzpah and organized our first participation to the Google Summer of Code in 2007. One feedback we got from the first crop of GSoC students was that the learning curve is daunting steep. So I’ve pushed and pulled around the community to ask those with the knowledge to document it into that bare structure I’ve started. With the help of many community members, and support from the core developers, we put together a documentation self-explaining enough to get more users over that stepping stone. It did not take long until it was picked up and we now have a thriving community of builders and testers. Moreover the instructions helped new developers (such as the 2008 and 2009 Google Summer of Code students) to get faster over the learning curve and become productive faster.

The build process is now self-sufficient. When dependencies change or features are added, the feedback loop between developers and builders is fast and efficient. The documentation still needs updating now and then. I look forward for the 0.8.0 release so that we can move on to improve the release cycle (and the closely related debugging cycle) along similar lines. But first, I look forward for the weather to clear, and to spend some quality time in the place of my youth.

PTViewerME2 Tutorial – Part 1

So you want to display virtual reality (VR) panoramas on a cell phone. If your cellphone is  Java-enabled, this tutorial may be for you.

I wanted to understand the buzz about VR on cellphone. To be honest, on such a tiny display it is not nearly as spectacular as on an average PC display. But it has its merits, if only to illustrate the concept of VR when discussing with a potential customer.

I used Helmut Dersch’s PTViewerME2. Don’t expect the quality of the legendary older brother PTViewer, another creation of professor Dersch, improved and currently maintained by Fulvio Senore.

PTviewerME2 can work in two way: stand alone or with separate media files.

In stand alone mode, the media and the applet are packaged in a single midlet. While it is possible to pack multiple VR with the midlet, it is not recommended because of memory issues. In this tutorial, we will make a single stand alone VR.

With separate media files, the VR is fetched from another archive or from the Internet. In both cases, the cellphone will keep asking if the midlet should be granted access to the filesystem or to the network, unless it is signed. Signing is beyond this tutorial.

Java on cellphones is a lottery – there are dozens of variations of the Java Virtual Machine (JVM) and little control over them. Compatibility is an issue. This can be frustrating. There are four entries for Java in the list of 101 great programming quotes. Read them and get over it – this is Java.

Still with me? OK, let’s go. In this first part we will look at the requirements and prepare the media. Later we will produce and deploy your VR to your cellphone and discuss advanced features.

Cellphone Requirements

Besides a color display and as much heap memory as possible, the cell phone will need the following Java technologies / profiles:

• MIDP 2.0
• CLDC 1.1
• JSR 75 FileConnection and PIM API
• JSR 184 Mobile 3D Graphics API

Don’t worry about the weird acronyms, just look at this table. Is your phone listed? If it has MIDP 2.0 or higher, CLDC 1.1 or higher and a Yes in the JSR 184 column, it is likely to work. The size of heap column gives you an idea of what resolution you can afford before Java crashes with an out of memory error. If your phone is not listed in the above table, check its tech specs at the manufacturer’s website.

Even if the phone’s specs are OK, the ultimate test is playing an actual VR. Do it now before embarking in a journey that may end in frustration if it does not work.

• Download this zipped VR
• Verify its MD5 sum
• Unzip it
• Connect the phone to the computer
• Transfer the pair of JAR/JAD files
• Play them. Use the phone’s cursors to pan left and right and tilt up and down. You can also zoom in and out.

Please comment back here with your phone model and what worked and what did not. Sometimes the boundaries of the cubefaces are visible. This may be due to the Java Virtual Machine’s (JVM) JPEG decoder or other factors that can’t be controlled by PTViewerME2.

Computer Requirements

Now that it is determined that the VRs will work on your phone, prepare your computer to author your own.

• If it is not yet on your computer, get and install Java.
• You will need software to produce QTVR out of your equirectangular images. Thomas Rauscher’s Pano2VR is a comfortable choice. Buy a license. Alternatively use Bruno Postle’s jpeg2qtvr, a free perl command line script.
• Get the PTViewerME2 archive and the Java Application Descriptor (JAD) from Professor Dersch‘s website and save them in a folder on your desktop.
• Last but not least, you will need an equirectangular image like the one below.

Prepare the media

Make a QTVR from your equirectangular image. Use a cubeface of 256px, and enough JPG compression to keep the QTVR smaller than 200Kb. A discussion of these parameters will follow in a future installment.

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!