It has better dynamic range than anything your digital harddrives can offer

Actually it already exists: http://www.justin.tv/ (its called Lifecasting: http://en.wikipedia.org/wiki/Lifecasting_(video_stream))

Actually nearly every time someone uses neural networks for image processing, they use the same approach, of making a long vector from the image pixels and feeding it into an ANN. And you are right that it has a lot of associated problems, but the ones you gave aren't really a problem with their software.

Like you said, you might want to use images of different sizes, or images that are in different pixel locations, and like you said, you need to pre-process the images so that they are of the exact same size and generally the desired features are in the exact same position in all images. Any image recognition system needs to do this, because it definitely is the most important part of image recognition, but after you have done that, then I don't see why you can't use the ANN library mentioned in this article to do the actual image recognition part.

In other words, any software that can handle images of different sizes or features in different locations is likely to include the same sort of preprocessing steps as you would need to do when using this ANN software.

OpenCV does provide very basic image recognition abilities but I definitely welcome any new open-sourced libraries that tackle image recognition too.

and by then, your WPA Encryption would be the last of your worries!

so whats the square root of 5? i don't think the pedophile manual has that one!

Finally, some useful advice!

In 2006 & 2007 I was working at the American company that was working on this. I was working on a different project so I don't know the exact details, but I know they were using the BrainPort to let blind people see things (sending electrical spikes onto the tongue with a resolution of 64 points on the tongue). But it was actually funded by the military to allow hi-tech soldiers to get extra information through their tongue.

The demo they were working on at the time was to allow the soldier to get an idea of where their fellow soldiers where, through the BrainPort. After some practise, they can tell through their tongue that they have a soldier behind them on their left and 2 more coming on their right, for example. Here is a little description of the project: http://www.ihmc.us/research/projects/SensorySubstitution/

simple.

Yeah actually I read quickly through that already :-) But I was still confused because I know that in Australia we had a vote across the whole country, trying to decide whether Australia should become a Republic (having a President) or stay as a Monarch. It turns out that there's 2 meanings of the word "Republic", and so by some definitions, Australia is a Republic, and by other definitions, Australia is NOT a Republic! "http://www.ozpolitics.info/guide/topics/republic/"

No wonder I was confused!

Just make it a Google site for free and spend the rest on trips to Hawaii for "background research".

I'm no expert, but doesn't "Republic" just mean there is a President in the federal government? For example, Australia has a Prime Minister and no President, so its not called a Republic, whereas somewhere like Iran or America has a President, hence why they're called a Republic?

I completely agree, for so many reasons, robotics is usually not something you can just create a standard API or OS and expect it to be immediately useful. The whole point of robotics is generally to invent new methods of controlling a robot, or to invent new hardware for a robot. There are already various robotics libraries around, such as:
Player/Stage
ActivMedia ARIA
YARP
MRVL
Yobotics Construction Set
URBI
Microsoft Robotics Studio plus other libraries that are used for AI (such as OpenCV) and also various hardware libraries. The problem is that when you are working with a complete robot (not just researching 1 element of a hypothetical robot), the different parts of the robot (such as the motors, the low-level sensors, the high-level sensors, the hardware controllers, the computer OS & drivers, the robot software architecture and the AI of the robot, and even the physical environment that the robot is placed in, are usually very dependent on each other. If just one of those items/modules is behaving strangely, the problem can show up in any of the other items.

For example, imagine you have a robot using a Neural-Network based AI brain running Microsoft Robotics Studio on Windows XP to drive a 6-legged robot around a room without crashing into the wall. If you build the whole thing and then test it and find out that it usually avoids the walls but occasionally it runs into a wall, the problem might be that the wall is partially invisible to your type of sensors (eg: a black wall is barely visible to InfraRed sensors), it might be that one of your sensors is misaligned, or a wire is loose or has inadequate electrical shielding, or one of your 6 robot legs can't turn the robot fast enough to avoid the wall, or one of your motor controllers isn't powerful enough for the manoeuvre, or your batteries or power wires are overloaded, or your microcontroller board can't communicate with your main computer fast enough, or Windows XP is causing an occasional delay in processing, or Microsoft Robotics Studio has a bug, or your Neural-Network AI library has an occasional bug in it, or the way you've configured the AI library isn't quite correct, or the way your code is controlling the whole AI and robot has a bug in it.
With all of these potential problems, NOT ONE of these can always be debugged in isolation by thinking of it as a robot made of completely separate modules, because if you move something in the robot you might make a loose wire become temporarily connected, or by testing it on the bench it might not cause the same power problems, or your Neural Network system might act strange only to something in your environment, etc.

Whether you used a robotics library to make things easier or you invented everything from scratch, wont necessarily make much difference overall, because you have so many problems to solve, and a typical robotics library will only solve a small part of it. If the robotics libraries or OSes were perfectly bug-free and were open-source and provided a solution to the majority or things you would need to do in robotics, then they would be extremely useful, to stop people from reinventing the wheel everytime. But recently I've worked on 3 different research robots that were did use large robotics libraries / operating systems, and in all 3 cases, the libraries were useful for a large part of what was needed, but there was always something that needed to be slightly different, or some rare bug in the library, and so in all 3 cases we spent so much trouble getting the libraries to do the task the exact way we needed it, that it would have been just as easy to create the whole thing from scratch ourselves.

Those are just some of the reasons why robotics libraries or operating systems are a LOT harder to standardise than something like a PC library or operating system! I would consider robotics to be closer to where the computer industry was about 70 years ago, when very little of the problems had been solved, and everything was very expensive and required a lot of difficulty to design, and everything was still being trialled and invented from scratch by hand.