Image Recognition on Mobile Phones
mysticalgremlin writes "In a recent presentation, Semacode founder Simon Woodside presents his company's bar code scanning technology that is used in mobile phones. Simon also discusses many places where bar code scanning powered phones are being used. Not bad for an 'image recognizer for a 100 MHz mobile phone processor with 1 MB heap, 320x240 image, on a poorly-optimized Java stack'"
Surely you mean "phone-powered bar code scanning", ie using the phone to scan bar codes, not powering the phone by scanning bar codes...
It's official. Most of you are morons.
> Not bad for an 'image recognizer for a 100 MHz mobile phone processor with 1 MB heap, 320x240
> image, on a poorly-optimized Java stack'"
10 or so years ago we had 3d games on 7mhz machines with 512k of ram, pretty much the same screen resolution yadda yadda - this isn't so impressive.
It was called a "cuecat," and it became one of the great punchlines (along with AOL CDs, foosball tables, VRML, and Jon Katz) of the dot-com era. Cuecats presumed that people read magazines alongside their computers, completely missing the point that if anyone was that "wired" he would be reading his magazines online to begin with.
If your mobile phone can read barcodes, we could print them anywhere - in papers, on billboards, TV adverts - and all you'd need to do is take a photo and your phone automatically loads the webpage in its built-in browser.
These are the generic mass "in-your-face" ads that people, generally, try to avoid but cannot. Ads we "want to see," at least in theory, are, again, those that materialize in the marginalia of our web pages as a result of our search metadata being analyzed. The mobile phone bar scanners are, like the cuecats, already obsolete. If you can't remember the product the billboard is hawking, the billboarder has not done his basic job and does not deserve any gadgetery boost. And if you can remember the product, you can google it.
Anyone running around pointing his cellphone at a billboard so he can capture the barcode and WAP-surf to the company's website should be rounded up, made to serve Nicholas Negroponte his frappe latte mocchachino in bed for a week, ride a segway from Grand Central Station to Wall Street, and have "TOOL" tatooed on his forehead in front of a crowd of 600 fat, drooling, naked, middle-aged "digerati" marketing execs at the next Burning Man festival.
Once a barcode is read you just get the product code. What good is that? You need then to lookup that code up in a database for real info.
As mentioned above, it could give you the lowest prices found on Froogle, Amazon, etc . . . or if they want to do something *really* neat, tell you if that product is available for considerably less (or on sale!) at a different store nearby.I totally disagree: First: It might be new to you, but the web isn't build out of static pages, but can be used interactive. Barcodes like these could be used to do things like voting by scanning the corresponding barcode, ordering stuff.
Second: Entering webadresses on a mobile phone UI is allways a lot of work. When this system is adopted widely, you could just scan the barcode at the bus stop, to load the page with bus times, scan the code at a painting (in or outside a museum), to get more info about it, etc. In other words: it acts as an link between the real and the online world. I think they would be highly usefull, if they would be widespead (in both phones, and applications for them).
Well, it is fairly impressive. J2ME is many things, but convenient and fast are not amongst them. Getting a Java phone to do anything useful at all is quite a feat of programming, getting one to recognise barcodes in realtime is damn near a miracle. Bear in mind the "virtual machine" on most phones is in fact simply a slow interpreter - it makes BASIC look souped-up.
Yes, the image resolution is low but you need to take into account that another spec mentioned is 1MB of Java heap memory. The captured images are stored in Java Image obejcts uncompressed. So the memory requirement for a QVGA (320x240) four-bytes-per-pixel RGBA image is 307,200 bytes, which will fit well within the 1MB of heap memory.
The phone camera will probably be able to capture images with a higher resolution (up to megapixels), but because of this Java heap memory limitation they probably need to limit themselves to QVGA resolution. And besides, if the image processing / recognition algorithms work sufficiently well with images of QVGA resolution, there is no need to use higher resolutions.