There is still room for improvements: I’ve discovered lot of interesting stuff that I’ve to try in Lilli Thompson speech at the GDC. In particular I’d like to improve:

• memory usage: track V8 garbage collection
• thumbnails loading: could be speed-up by using a web workers too
• Three.js rendering: I still need to switch to r48 and use BufferGeometry
• bundle.out generation: still very slow for big synth

To accelerate bundle.out file generation I’ve found a solution working pretty well for very large ascii file (80mo+). I’m generating the ascii file by writing directly in binary in a Uint8Array (by chunk of 1mo). The resulting code is more complex but is as fast as regular string concatenation and in comparison as a memory footprint very limited. It’s not integrated in the extension yet as my test case is working well (ascii ply generation) but bundle.out is slow (I need to track V8 bailout/deopt to understand why it’s slow).

I’ve also improved a lot my binary parsing by using only native binary parsing (DataView). One thing about DataView: did they realize that if you forgot the endianness parameter it will use BigEndian? (littleEndian = x86, bigEndian = Motora 68k).

Thanks to both optimization the new version is 4x faster! (loading time: 24s > 6s)

solution 1

• cross-orign was forbidden in contentscript (fixed now since chrome 13)
• lack of TypedArray copy/transfert -> JS array replacement
• Loading time: 13600ms (24400ms with the previous version without optimized binary parsing)

solution 2

• Issue: the UI is frozen during parsing (lack of threading)
• Loading time: 6500ms

solution 3

• I’m using transferable objects to both send the xhr.response (ArrayBuffer) and receive the parsed Float32Array (vertex positions) and Uint8Array (vertex colors).
• Issue: I didn’t manage to spawn a worker from my extension directly (SECURITY_ERR: DOM Exception 18): I’ve been forced to inline the worker as a workaround.
• Loading time: 6000ms

solution 4

• Issue: because of this bug workers can not do cross-orign xhr.
• Loading time: N/A

I’ve also optimized the PLY file generation by generating binary file on the client side instead of ascii.

• Ascii: 74mo in 9000ms
• Binary: 17mo in 530ms (~17x faster!)

Sadly I didn’t manage to find a way to accelerate “bundle.out” ascii file generation yet (involving lot of string concatenation and numbers formatting).

I didn’t have updated the extension on the chrome web store yet as I’m working on using the new BufferGeometry of Three.js that should be more efficient. Building BufferGeometry directly from Float32Array (vertex positions array) and Uint8Array (vertex colors array) seems a really better solution IMO.

Mesh compression

I’ve also discover the webgl-loader mesh compression solution recently. I’ve compiled my own version of objcompress.cc and fixed the JSON export. Then I’ve created my own format allowing to pack in one file all the utf8 files (thus reducing the number of http request needed). I will post about it soon: stay tuned!

Firefox extension?

On a side note I’ve also been playing with the new mozilla add-on builder SDK… well IMO Firefox isn’t the best browser for extension anymore. I’ve been very disappointed by the restriction applied to code running in the contentscript (for example prototype.js is not working: I had to use a clone that I’ve built long time ago). And I’m also very concerned about their security strategy: they don’t have a cross-orign xhr permissions field in the manifest. Thus extensions can do cross-orign request to all domains by default! Nevertheless I’ve managed to port the binary parsing of the point cloud but Three.js is not working either .

I’m sure that some of you have an idea of what to do with a bundle.out file from a PhotoSynth .
BTW, this export wouldn’t have been possible without Peter Sibley help, thanks Peter! He has help me by giving me the missing information needed to do the bundle.out PhotoSynth export.

New features:

• Point cloud downloading is working now!
  • Previous downloadify solution wasn’t working due to a Chrome bug and was removed
  • New version is using Html5 BlobBuilder + FileSaver instead
  • But you need a Chrome version >15
• Picture thumbnails are displayed thanks to my sop bypass trick
• Windows Azure support (corresponding permission was added to the manifest)

Other features are coming:

• basic panorama support (using atlas.jpg only: no progressive download yet)
• download zip file of whole synth?
• bug fixes (the current version is still very buggy, especially the menu)
• other cool stuff are coming!

If you don’t have Chrome you can take a look at my previous video showing most of the new feature (except point cloud downloading). The previous version wasn’t available as it was using my previous trick to bypass sop restriction (too slow to be widely used).

The new version is available on the Google Web Store.

Live Demo (require WebGL enabled browser)

My implementation is very strait-forward: my PhotoSynthHDDownloader creates 6 jpg from a panorama url. The 6 faces of the cube are downloaded at full resolution. This solution is suitable for panorama created with an iPhone (low res) but not acceptable for gigapixel panorama (you need progressive download/display). I’m using Three.js as WebGL engine and I’d like to implement a megatexture solution to display very large panorama (I’ve found a very impressive working implementation and played with it: it is working with Google Chrome / Firefox 10).

To be able to handle panorama as well, my Google Chrome extension needs to use megatexture and it would be really more efficient if Microsoft could add the missing cors header to allow WebGL cross-origin (even only for photosynth.net). And as they’ve just moved their data to Windows Azure, I guess that it may be easier to add this header . Otherwise I’ll have to use my special trick to bypass webgl same-origin-policy restriction.

• Navigation system (like the Microsoft Silverlight one)
• Thumbnails display in the WebGL content [beta]

Adding the pictures wasn’t easy: it is not possible to draw a texture coming from another domain on a WebGL context for security reason. I have found a workaround for this issue (AFAIK unknown: see my post about it). I’ve also managed to “clone” the UI of the Silverlight viewer and to find out how to parse some navigation information from the JSON file provided with each Synth. But I wish that the PhotoSynth team gives me some information about the meaning of some other undocumented parameters…

I won’t release this new version as it is CPU hungry (because of the WebGL restriction workaround), but if the PhotoSynth team adds the missing CORS header this could solve the current WebGL restriction in a cleaner way .

A new feature is coming too (related to my new work at Acute3D).

The principle is very simple: the user drag and drop an unknown picture on the webpage. The picture is resized on the client side using canvas and then sent to the webservice using a classic POST Ajax call with the picture sent in jpeg base64. Then the pose estimator web service try to compute the pose and send an xml response. Then the pose is applied to the Three.js camera used in my PhotoSynth viewer.

I have cheated a little as I’ve used shots of a video with known intrinsic parameters. But I’ve two options to handle really unknown pictures:

• If the jpeg as Exif I can use it to find the focal (using a CCD database and a JS Exif parser)
• Otherwise I am planning to implement this in C++

I hope you enjoy this demo as much as I do and that Google and Microsoft are working in that direction too (especially Microsoft with Read/Write World…)

You can download the new Google Chrome extension from the chrome web store: Three.js Google Chrome extension. The old one is still available but this is not a good idea to have both activated at the same time… Do not hesitate to use the donate button (located in the right side-panel) if you find this extension useful… thanks!

Warning: this extension may use a lot of ram (point cloud are store in memory as regular js array not TypedArray).

Possible improvement

• Add picture thumbnails in the 3d environment (may become impossible without Microsoft adding CORS to the jpeg due to WebGL security issue)
• Add a free flight camera (easy to add but harder without roll: I’ve added features to Three.js Quaternion class for this purpose, but still not ready)
• Make the download point cloud link work! This is not my fault (I hope) I think that this is a Chrome bug. The only workaround that I can think of (without being sure that it would work) for this issue would be that Microsoft host downloadify.swf on photosynth.net… please ask them to do that!
• Add a Meshlab like camera system (mouse handling + white sphere): if you know Three.js please give it a try!

Credits

Please take a look at the list of all dependencies used for this demo in my previous post describing this PhotoSynth viewer.

The only trouble with this demo is that it is using a proxy PHP page to bypass ajax cross-domain security issue. Thus I won’t put it online (as it would kill my bandwidth limit). But I’ll try to update my Google Chrome extension so that you can give it a try too (will take time and I’m going in holiday…sorry).

On the tech side, this demo is using:

• Three.js: for the rendering
• Downloadify: to allow downloading PLY generated on the client-side
• jDataView: to parse binary xhr response
• ImageFlow: coverflow system
• Accordion(except css) + Tween + SynthParser created by me

Other news

On another side I’ve been up to:

• compile a bundler version with PBA support (with bad result: fast BA but erroneous point cloud)
• create a new framework for fast matching: already 3x faster than OpenSynther (which is already really fast). This new framework is compatible with multi-gpu and multi-cpu + you can add constraints to memory usage!
• create an hybrid AR solution for my current work based on my panorama tracking demo and using gyroscope information to fix the computing time of the vision part