• 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

    June 2008
    M T W T F S S
    « May   Jul »
  • Archives

PTViewerME2 Tutorial – Part 2

In the first part we looked at the requirements and prepared the media. If you have not downloaded and played the VR from that first part, do it now. Next you will make a VR for the cellphone with your own media. Discussion of advanced features is left for the last installment.

Prepare the Java Archive

  • Copy the QTVR you prepared during part 1 and the PTViewerME2 Java archive into a new folder
  • Start a command line prompt and change to that folder
  • Extract the PTViewer Java archive with the following command
    jar xf PTViewerME.jar
  • Delete the PTViewerME.jar file itself
  • Move MANIFEST.MF from inside the META-INF folder one level up
  • Delete the META-INF folder
  • Delete the .mov files that were in the archive
  • Edit the file default.html
    name="Chiostro" file="chiostro.mov"

    The embed tag can take many parameters. Of importance to us at this moment are file and order. Set the name of your QTVR in file, and make sure order is like above: the order of the left and right cubefaces is swapped in PTviewerME2 with respect to the QTVR format.

    Manifest-Version: 1.0
    MicroEdition-Configuration: CLDC-1.1
    MIDlet-Name: Chiostro
    Created-By: 1.4.2_05 (Sun Microsystems Inc.)
    MIDlet-Permissions: javax.microedition.io.Connector.file.read
    MIDlet-Vendor: You
    MIDlet-1: Chiostro, PTViewer.png, PTViewerME
    MIDlet-Version: 1.0
    MicroEdition-Profile: MIDP-2.0

    Write down the MIDlet-Name as you will use it later for the deployment. Don’t worry about the rest, we’ll look at it in more detail later.

  • Prepare a new Java archive
    jar cfm Chiostro.jar MANIFEST.MF *

Deploy The Java Archive

Our Java midlet is now ready, let’s prepare it for deployment.

  • Look up the size of the JAR file. In the example below it is exactly 82,978 bytes. This value is very important, write it down.
  • Create a new file. The filename is the same as the JAR, but the extension is JAD, so in this case it is Chiostro.JAD. Start with the content of MANIFEST.MF and complete it to look like below. Details in this file are critical to midlet deployment. If a value is not right, the phone will indicate the MIDlet is corrupt and refuse to play it.
    MIDlet-1: Chiostro, PTViewer.png, PTViewerME
    MIDlet-Jar-Size: 82978
    MIDlet-Jar-URL: Chiostro.jar
    MIDlet-Name: Chiostro
    MIDlet-Permissions: javax.microedition.io.Connector.file.read
    MIDlet-Vendor: You
    MIDlet-Version: 1.0
    MicroEdition-Configuration: CLDC-1.1
    MicroEdition-Profile: MIDP-2.0
  • In the MIDlet-Jar-Size line enter the exact size of the JAR that you looked up earlier
  • The MIDlet-Jar-URL is the file name
  • It is paramount that the lines that are present in both the MANIFEST.MF and the JAD file are exactly the same

Play it!

Copy the pair of JAR/JAD files to your Java-enabled cellphone and enjoy.

If it does not work…

  • Make sureboth the JAR and the JAD file are copied to the cellphone.
  • Check again the JAD file, particularly the Jar-Size. If you re-worked your JAR, chances are that its size has changed.
  • If the cellphone indicates an invalid application, check MANIFEST.MF and the JAD file for consistency.
  • Make sure the MIDlet name matches the filenames for both JAR and JAD files.
  • And if you need support hugin-ptx is where free panoramic software is discussed.

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.

Apple’s QuickTime Update Breaks Detection

Recently Apple updated QuickTime. I received the update on my Windows box via Apple Software Update and I agree with John Lilly, Mozilla CEO, when he blasts Apple. It undermines the trust relationship great companies have with their customers, and that’s bad – not just for Apple, but for the security of the whole Web”. Indeed, it tried to sneak once again iTunes on my machine, despite me repeatedly checking the “ignore this upgrade” box.

The latest QuickTime update also undermines some of the plug-in detection code used to find out if a visitor has QuickTime in the browser, including in Apple’s own Safari. I found out about it the hard way last weekend at the first Toronto Panoheads Meeting. Lucky me I could divert my talk and talk about the World Wide Panorama instead.

Plug-in detection is critical to the proper display of plug-in dependent content such as VR. Trying to display a VR using a plug-in that is not available on the client results in awful degradation.

Detecting the availability of the plug-in is the first step in graceful degradation: if the plug-in is detected, chances are that the content will display properly. If it is not detected, the website can degrade gracefully and show the visitor a static image or a link to download the relevant plug-in.

There are two ways to detect the plug-ins: ActiveX probing (for Internet Explorer) and parsing the navigator.plugins array (for all other browsers). In Firefox, it is possible to display the content of the navigator.plugins array in a user readable format by typing about:plugins in the address bar:

Until recently, QuickTime’s version was listed in the form of Major.Minor.Revision. Now they seem to have moved to Major.Minor (Revision) – and some parsers will choke on that. Mine did.

I not only detect QuickTime, I also try to discern the real QuickTime from the many third party plugins that set their name so to fool the detectors and return positive to detection, like Totem or VLC. Hence, I check with a strict syntax, and when Apple breaks the syntax, my detection returns a false negative.

False negatives are IMHO better than false positives. The reason why third-party plug-ins want to fool the detector is because they think they can play QuickTime content. It may be true for audio/video and other linear content. Unfortunately it is not (yet) true for VR, objects or panoramas. Discerning whether the original QuickTime is installed or a copycat, makes the difference between a gracefully degraded website or one showing a broken movie.

Fixing my detection code was quick and all websites using it have been updated automatically. Of course it would be nicer if Apple would stick to its own conventions in the first place.

Hugin on Gentoo Linux

Thomas Pani just published a Gentoo ebuild for hugin and related tools.

Perl in Windows

Perl is a free and mature scripting language, created by Larry Wall. It is used as glue language for some of the hugin and libpano functionalities. Phil Harvey’s Exiftool, required by hugin, is also written in Perl.

Perl lends itself well for cross-platform scripting because it comes installed by default with most operating systems. Not with Windows. To work around Window’s limitation Steffen Müller maintains pp, a tool originally developed by Audrey Tang that creates standalone executables from Perl programs.

If you are just a Windows user, you can simply be thankful to Steffen and the PAR::Packer community for enabling developers and builders to supply you with a simple solution to run the software on your Windows box.

And if you are interested to know how to build those executables, read on this tutorial which I’ve put together with help from the PAR::Packer community, particularly Mark Dootson.

Infrastructure to build Windows executable from Perl scripts

This is highly experimental. it has been tested on PAR::Packer 0.980 released May 14, 2008.

Install MinGW – MSVC 2008 EE is not supported

  • Download MinGW-5.1.4.exe from the MinGW homepage.
  • Follow the default install (click all the “Yes” and “Next” buttons), but add g++ to the mix, i.e. on the screen where you can tick boxes to choose what to install, check the box with g++ (and leave anything else as is). It will be installed in C:\MinGW
  • Run the now installed C:\MinGW\MinGW-5.1.4.exe from the command line to ensure you get the latest updates.

Install ActiveState Perl 5.10.0 build 1002 (The free version is enough. Other/newer versions may also work, this is the one that worked for me).

Then start the Perl Package Manager (PPM) from the new entry in the Windows Start menu and search and install the following packages:

  • Get-opt-ArgvFile (>=1.07)
  • module-scandeps (>=0.78)
  • par-dist (>=0.22)
  • parse-binary (>=0.10)

Download dmake-4.11
Extract dmake to C:\MinGW so that you have a folder called C:\MinGW\dmake

Make yourself an environment batch file, call it perl.bat, with the following content. Use it to start the command line interface (CLI) with a double click.

set PERL_PATH=C:\Perl
set PATH=%MINGW_PATH%\bin;%MINGW_PATH%\mingw32\bin;%MINGW_PATH%\dmake;
set LIB=%MINGW_PATH%\lib;
set INCLUDE=%MINGW_PATH%\include;
set PATH=%PERL_PATH%\site\bin;%PERL_PATH%\bin;%PATH%
cmd /K

Install manually Win32-exe-0.11, Par-0.977 and Par-Packer-0.980.

  • Download the archives and extract them to temporary folders
  • doubleclick on perl.bat to start a CLI
  • in the CLI, run the following commandsinside each of the temporary folders
    > perl Makefile.PL
    > dmake
    > dmake test
    > dmake install

test your installation

create a file test.pl with the following content:

print "hello world!\n";

in the CLI, check that it works

> perl test.pl

compile it

> pp -o test.exe test.pl

test it

> test.exe

here you go, ready to build your perl scripts into Windows executables!

Out of order

I try to automate as much of my process as I can – time is too short to do manually what a computer can do automagically. One of my favorite tools for such automated processing is ImageMagick. It runs on a FreeBSD server in the closet. I drop my stitched panoramas via the network at one end and at the other end I get a whole bunch of output formats. When I need a new type of output, I just update my scripts and run them all over my archive of images.

I regularly update the server. The FreeBSD ports collection is one of the best things I’ve ever seen for system upgrade and maintenance, I have been a happy user for years. The nature of the system is such that sometimes a package will break despite the robustness of the ports system as a whole. When it does, careful analysis is required. Is this a problem of my specific system configuration or a bug with a software package or library? And if it is a problem of a software package or of a library, which one is it?

After the last upgrade to ImageMagick my engine broke down. Before filing a bug report with ImageMagick I looked for confirmation from other ImageMagick users on the Magick users mailing list. Is it a problem with my specific system, or with ImageMagick? I don’t know yet.

I was surprised to say the least by this reply asking me to file a bug report on a web based forum. Web based forums don’t even work as proper mailing list replacement (can’t read/reply offline). Now they are supposed to replace a bug tracker?

Compare it with dedicated bug trackers like the SourceForge bug tracker (not the best one) that we use for hugin; Bugzilla used amongst other by the Mozilla foundation and Gnome; trac used amongst others by WordPress and wxWidgets.

Can a web based forum keep track of the status of a bug? assign it? prioritize it? find duplicates? close a bug?

17 pages, 814 topics (bugs?)! that looks like a lot of noise to me. Purge! A bug tracker should only list relevant information, and if there are 17 pages of open bugs against a package the size of ImageMagick, something is badly broken. Web based forums smell stale.

I wish I had the time and resources to confirm if the problem with manipulating TIFFs in ImageMagick is specific to my box or a bug in the code, and to file a bug report if necessary. Unfortunately I currently lack the time and resources. I found a workaround for my specific situation: GraphicsMagick. In my glue script, it worked as a drop in replacement for ImageMagick. And it has a bugtracker where I can file bug reports without the nuisances of a web based forum. I will get back to ImageMagick when I have the time to make my system work again with it.

VR panorama on a Nokia cell phone

panorama on a Nokia 5200A few weeks ago I was forced to buy a new cell phone. I belong to the (minority?) kind of people who use a phone only to make and receive calls. Moreover, I don’t need to fry my brain with extended usage of cellular service. Last but not least, I travel internationally. My requirements boil down to:

  • GSM tri- or quadriband phone, unlocked
  • a local prepaid SIM card
  • lowest possible rates
  • reasonable credit expiration policy
  • simple backup / management from the desktop

I already have my good old Nokia 6310i, that has followed me from Europe to North America. All I need is a simple prepaid SIM card. As others have found out before me, the Canadian wireless industry is useless. The only way to get a decent prepaid SIM card was to buy a phone. Since I must buy a phone, I may as well buy one that fits my requirements. Only one offering met my requirements: 7-Eleven’s Speakout. with the Nokia 5200. There are no 7-Eleven in Québec, so I waited for the next occasion I was in Ottawa ( BSDCan 2008 ) and bought one there. 7-Eleven Speakout is in my opinion the best service currently available to Canadian customers with similar, simple need as me.

This is pretty much a mainstream consumer phone. And since it fulfilled the minimum requirements for Helmut Dersch’s PTviewerME, I decided to give it a try. It works! I will explain in a future post how to make it. I might show the how-to live this weekend in Toronto at the Panoheads meeting hosted by Mark Banas at Autodesk if there is interest.

In the meantime, I can’t do otherwise but rant about Nokia. This will most likely be my last Nokia handset ever. This company is displaying an arrogant attitude on my desktop and in the community of free software.

On my desktop, the Nokia software is an all-or-nothing thing. It hijacks media from my preferred media player (VideoLAN), and it hijacked all of my Java code too! It has that bloated Vista feeling, and is as far as I am concerned a downgrade from the barely acceptable eight year old software that came with my previous Nokia model.

And then Nokia wants to teach us business? The market will teach them a lesson: respect! The desktop belongs to the user. Before messing it up, ask for permission. And if the user only needs a part of your software functionality, respect that as well and don’t install bloatware.

Hasta la vista, Nokia, soon comes OpenMoko.