In March 2010 I co-founded TAB Worldmedia one of the world's first full service Augmented Reality agencies.
Just a quick note: my first Binary Ajax project is ready for release (well, testing I mean).
EXIF Thumbnail Fetcher is a Greasemonkey user script, which lets you retrieve the embedded thumbnail of a digital camera image over the ‘net, without downloading more than strictly needed.
See my previous post for some more details. And, please test it and let me know your experiences!
Now retrieving binary data through XHR is possible, I started working on a proof of concept: a remote Exif data loader.
The idea is simple: if you have your original digicam photos online, just bulk downloaded from the camera, you only have very non-descriptive names for reference. Was that one interesting image called IMG_1234.jpg, or was that the blurry one and are you looking for IMG_2345.jpg? Your only option seems to download the whole blob, easily several MBytes per image for contemporary multi Mega Pixel camera.
Now there is hope for a smarter solution.
Most digicam images have embedded meta data in the Exif format, often including a nice little thumbnail.
Wouldn’t it be nice to retrieve this embedded data over the network to preview a photo by thumbnail?
I haven been working on this problem and have a proof of concept ready, coded as Greasemonkey user script for Firefox (1.5 and 2.0).
From a very high level the working principle is:
A few months ago I concluded that it is simply not possible to download binary files for Ajax purposes, at least not with Firefox (see Retrieving binary data with XMLHttpRequest).
Last Monday, Marcus Granado posted “Downloading Binary Streams with Javascript XMLHttpRequest“, where he demonstrates that it is possible to get a binary clean stream through XMLHtttpRequest.
It boils down to using the right Charset in with the proprietary overrideMimeType() function. Read his post to see how.
In one word: Wow! This opens up a whole lot of new applications, for instance with Greasemonkey scripts.
I’m glad I have been proven wrong!
Update: this does not work for me as is…
What happens is that all bytes above 127 (decimal) are returned as a really big value. The solution, however, appears to be very simple:
var filestream = load_url(url); var c = filestream.charCodeAt(x); if (c > 255) c -= 63232;
Apparently, the extra high value is not caused by extra bytes being gobbled up, but constructed on the fly. Luckily this is done in such a deterministic way.
I’m working with javascript in a UTF-8 page context and, although I have experimented with some other character sets for the page, this made no difference. I’m using Firefox 1.5.0.6, Mac OSX right now.
I’m really interested in other users’ experiences. Please share them via the feedback form!
@Einar – yes, you’re right. I somehow missed this, could have saved me some trouble ;-(
Twitter links powered by Tweet This v1.8.3, a WordPress plugin for Twitter.
einar, and
I think you didn’t read the article to the end. The example he gives for getting the bytes shows you to do this:
var abyte = filestream.charCodeAt(x) & 0xff;
Which is the same as your if (c > 255) c -= 63232; but cleaner and more understandable.