One of the long term issues with having a technology, which should be much more powerful than existing hardware is finding an appropriate use scenario for it. Today one occurred to me on my commute.
I've been doing a lot of experimenting with synthetic focus imagery. Having recently written a tool to help me do image matching, I've begun to appreciate why Hugin gets so bogged down generating and matching control points. The cross correlation of 2d image sets is a huge resource hog. Fortunately, the bitgrid should be quite capable of handling it, because the computations are data local, with the only global data being the source material which loads once per frame, and the output maximum coordinates, again once per frame.
I imagine a remote control glider with a pair (latter an array) of cameras feeding into a system which correlates the images to generate altitude data. It should be possible once this 2d triangulation is done, with hints from the navigation system, to then generate a 3d image of the area below, with altitude information at least as accurate as the pixel resolution allows.
If the plane is slow and stable enough to allow multiple overlapping images of the same area, it should be possible to derive super-resolution images using Richardson-Lucy deconvolution.
It all hinges on the question of power consumption of a single bitgrid cell. Something I don't know, but an experienced IC designer should be able to figure out on his lunch break.
Wherein Mike Warot describes a novel approach to computing which follows George Gilders call to waste transistors.
Thursday, October 28, 2010
Subscribe to:
Post Comments (Atom)
Blog Archive
About Me
- Mike Warot
- I fix things, I take pictures, I write, and marvel at the joy of life. I'm trying to leave the world in better condition than when I found it.
2 comments:
What you call "BitGrid" exists, and is known as a Field Programmable Gate Array (FPGA). See my reply on Slashdot & relevant Wikipedia articles for starters...
That's an intringuing idea. I have a couple of questions for you...
Have you tought about a programming interface? To keep things simple, it could be interesting to use the data lines for programming, but you could also create something that is as hard to use as a single tape turing machine by doing that. Have you tought about it?
Also, have you tought about using simpler or more complex elements? Why did you settle with a lookup table? There are plenty of functions you can put on the elements and still get get a computer, by using simpler elements you can reduce the transistor count, and consequently, increase the grid size. On the other way around, you can use communication channels wider than one bit (you know, most people like doing calculations with 80bit floats), what can lead to a more usefull overall product, even with the reduced grid size.
Why did you choose EPROM? My first guess at something for it would be static RAM.
And, finally, have you tought about the testing circuitry? You may not even need some circuitry specialized on testing, but that will depend on how programming and I/O work.
Post a Comment