2024- 2023
- 2022
- 2021
- 2020
- 2019
- 2018
- 2017
- 2016
- 2015
- 2014
- 2013
- 2012
- 2011
- 2010
- 2009
2008
Polyglot 12: R- Air Compressor
- Stanford CS145
- Retina
- Electoral College
- Obama vs McCain
- Perpetual Motion
- Book Safe
- Cráneo de Cristal
- Back to School
- Artificial Neuron
- Search Appliance
- Orthogonal Viewer
- Porcupine
- Bitmaps in JavaScript
- My Brain
- Domino Logic
- Faster is Better
- Transfer
- Car Fire
- Helsinki
- Jessa Gamble
- Maker Faire 2008
- Downhill Walker
- Youngme / Nowme
- Python Parallel Port
- MobWrite 2
- Class Clown
- Mask
- Progress
- Angel Island
- Scapegoat
- Localhost
- Disneyland
- Technical Difficulties
- Wooden Brain
- 2007
- 2006
- 2005
- 2004
- 2003
- 2002
Orthogonal Viewer
7 September 2008
On the flight out east I threw two previously published projects together to form something new. You've probably seen the animations of my brain and the JavaScript BMP library. So the next step is to reformat the MRI data into a compact JavaScript data structure, then render it on the fly inside a web browser. I'm rather shocked at how well it runs under Firefox 3 and Chrome (Yay, I can finally start mentioning Chrome!), while Opera and Safari do an acceptable job of it. Once again, IE is the boat anchor that keeps dragging web applications back.
If you have a fast connection, load the Orthogonal MRI Viewer. Be patient, it's got 12MB of data to download. If someone can come up with a decent yaw/pitch/traverse control that translates to a plane formula (such as: ax + by + cz = d), this viewer could render arbitrarily angled slices, not just orthogonal ones.
The biggest stumbling block I encountered was the data compression. It turns out that the JavaScript literal string notation for the null character (\0) must be avoided when encoding arbitrary data. If this notation is followed by a number, the result is parsed as one octal character. E.g. '\012' means the linefeed character (%0A), not the null character (%00) followed by '1' and '2'. A somewhat nasty ambiguity to identify when buried within a 12MB data stream.
Flying back west proved interesting. The US border agent (stationed within the Ottawa airport) tried cross-referencing my H1-B visa with his database. A sensible check, since otherwise you could just Photoshop your visas. Sadly, my visa wasn't listed in his five databases. At this point I was detained and brought into a back office for further processing. The stamps in my passport certainly looked genuine, and my employer looked vaguely reputable. So as a last resort, the agent pulled up a list of all H1-B visas granted, in chronological order, and started scanning through the list for "FRASER". Page after page, each screen-full containing ten names. Next. Next. Next. After an hour of this stunningly boring chore, he finally found my entry. With a quick stamp, he approved my re-entry to the US -- ten minutes after my plane had departed.
In fairness, I can understand the problem. I mean, their database has literally THOUSANDS of entries. That quantity of data would overwhelm any imaginable computer system. Clearly the only scalable approach is a visual search. However, they really ought to look into using pigeons.
