World Wide Panorama mailing list archive

Mailinglist:wwp@yahoogroups.com
Sender:Yahoo Account
Date/Time:2009-Jun-22 22:11:00
Subject:Re: this N that

Thread:


wwp@yahoogroups.com: Re: this N that Yahoo Account 2009-Jun-22 22:11:00
Hello all,

sorry for the lack of updates. I'm still working behind the scenes to iron out the kinks, so your thoughts on the flash option are very welcome. 

a) about the Yahoo page. 
The Yahoo server takes care of the mail and member statistics, so these are up to date at all times. The text on the frontpage is just that - a text, and that's one place that tends to get overlooked. I've changed it now to link to the "Next event" on worldwidepanorama.org, which tends to get updated sooner (usually when Pat complains about it ;)

b) about the jpeg/flash "revolution" :)
What we thought:
- QTVR works very well. However, over the last years, Apple has started to disable or limit their support for some features (e.g. flash overlays) or image compression options, and this has caused some panoramas in the archive to no longer work as intended.
- With Quicktime X, due this fall, there's no way to tell if there's support for QTVR in it. The beta version doesn't seem to like it, but then, it's still a developer preview. (see Apple's QTVR mailing list for a few annotations). Maybe we'll get a nice surprise for a change.
- Flash is just about "everywhere". It still has its share of issues (e.g. performance on Mac), but it's making progress rather quickly.

The reasoning then was (roughly) along these lines:
1) How can we reach a wider audience, beyond Quicktime?
2) How can we make contributing as easy as possible?
3) How can we make sure that your contributions remain accessible in the future?

What we decided on:

1) Flash is just about everywhere, even in places where Quicktime is not allowed (e.g. companies)

2) Instead of asking for a Flash file (which is actually just a JPEG "married" to a Flash ActionScript module and saved into a single file), we'd ask people to contribute one of the most ubiquitous and accessible file formats, JPEG.

3) Retaining a "master" JPEG file makes sure that we won't end up with a bad surprise when Flash v11, or v12, or v20, comes out and the "legacy" SWF's with locked-in images suddenly don't play any more. That was the reasoning for keeping the player and the content separated. 
We're using PanoSalado, an open source panorama engine, and keeping the image and the technology separated means we can upgrade or even change the playback engine to e.g. take advantage of smooth openGL playback (sometime in the future - wasn't that announced for Shockwave?) by adapting one single template without risking to lose all the uploaded panoramas.

c) some specific replies:

"I'm encountering the JPEG and Flash revolution here. I liked being able to pick the dimensions of my small panorama. Since I haven't uploaded a test Flash, I don't know if we have the option to pick a display size or not. I've never used a JPEG source for anything except Java applet display. Thought it was a bad idea. 100% quality JPEG? "
First, the display size: Setting the pixels width/height is still where it used to be, and the settings in there set the "frame" for both the flash and the quicktime plugin.

Second, using JPEG as a source. As I mentioned above, it's not that different from using a "monolithic" SWF file, except for the greatly reduced risk of the SWF becoming obsolete and inaccessible with the next generation of the Flash player.

Right after uploading the spherical JPEG, the player will use this "master" file for the preview. That's not quite optimized for the internet, of course. This is why we have a script running which takes the master file and (given a spherical source) uses PanoTools' remap function to turn the sphere into six cube faces, in two sizes: 800x800 for the small flash player, and 2000x2000 for the fullscreen flash player. The small and large QTVR are produced in the same way.
This happens semi-automatically on another computer, not on the webserver - both memory and CPU demand are just a bit too much to do this in real time.

The resulting files are then transfered back to the web server.

"The worst part is specifying tilt for my cylinder. The only way to find it that I know is to open in ptviewer and use trial and error. Is there a simpler way using software that I might have? Let's see. I will have to take my PICT into Photoshop and paste it into a black box with height of 1/2 the long dimension. Perhaps I can calculate the tilt with the ratio of my pano height in pixels to the required sphere height in pixels?"

Cylinders are ... "difficult". The PanoSalado Flash Player automatically adjusts and limits the tilt settings when it is told that the incoming image is a cylinder. However, the current version doesn't like the very large horizontal size that cylinders can reach. The limit is currently 8190 pixels width, though this may improve in the future.

"The "Important Information" text says that if I do upload a QT file I should not upload a JPEG. Why can't I do the QT and the server do the Flash version from a JPEG? "

This was more or less to keep things easy, i.e. by keeping the number of files that one has to prepare for an entry as low as possible. I'll see how to organize this in a way that allows to upload separate files for the advanced users. Should be feasible with minimal trouble. The workaround for now would be to upload the QTVRs first, and then the JPEG "on top".

"Oh, another question. I've made Flash versions of two of my WWP entries that are broken because they don't show the Flash tracks. Can I upload the Flash versions of previous entries? I suppose if you are not taking SWFs, that rules that out. Has there been info about the rationale behind taking only JPEG sources? If so, I missed it."
People can do a lot of funny (and very, very unfunny) stuff with flash files, and there's no way to inspect all incoming SWFs to see if they work or not - some might break with Flash 7, some might cause problems with some configuration, some might keep on triggering ad views in the background etc. The more features inside a SWF, the less manageable it becomes, which is why we chose not to go down the "all-in-one" SWF path.

-Markus
   


      

[Non-text portions of this message have been removed]


Next thread:

Previous thread:

back to search page