Hi,
I currently have a kiosk application that I would like to port to a wireless, *portable* implementation. So, small tablets or (ack!) smart-phones (with the phone functionality permanently and irreparably disabled) seem a good choice. Phones being better suited in terms of size (want to tuck this into a shirt-pocket while not in use).
But, I rely extensively on barcodes to provide data to the application (item identification, location identification, etc.).
Since (some) cell phones currently have QR code capabilities, I figure adding that to a camera-equipped tablet (or phone) is a potential solution.
Before I get myself "pregnant" on a solution path, I need to get a handle on what's "realistic" in terms of expectations.
[I don't *use* cell phones so my ignorance here requires patience :> ]I know (some) cameras have motion video capabilities. From that, I can (?) deduce that the optics and electronics in the camera are "fast enough" that images can be captured at "several" frames per second.
- does this effectively render the "phone" useless for other tasks (i.e., how CPU intensive is this task, how clumsy is the interface to the camera output, etc.)?
- is this occurring at the same resolution as still pictures? or, is the camera degraded to a lower "movie mode"?
The phones that I have played with require the camera to be explicitly "activated" (no doubt because the typical user doesn't want the camera on all the time -- privacy? performance? battery life??).
- does the use of the camera (in movie mode) eat batteries?
- is there some *other* significant start-up/run cost that is associated with the camera functionality?
- does the *camera* drive the interface or does the application? By that, I mean, do you say, "go into movie mode" and then sit back and wait for the camera to deliver frames at whatever rate
*it* wants? Or, do you say, "give me a frame, *now* (note that in this latter case, you could effectively run the video at 2 FPS, 3 FPS, 12 FPS, etc. -- as appropriate to your application)What I would *like* to do is leave the camera on continuously and have my barcode recognizer/decoder processing images as fast as feasible. So, instead of the user having to explicitly enable the camera, point it at the targeted barcode label and *then* take a "capture barcode" snapshot, the application can hunt for suitable labels itself and use them as appropriate.
Since the recognizer can be a resource pig, you would want to be able to control the rate at which it processes images. I.e., "take a picture, process it, twiddle thumbs so other parts of the application can run, lather, rinse, repeat".
Are there any other issues that could eat my lunch that I haven't considered?
Finally, any pointers for *hackable* camera tablets/phones? (of course, they need to have some form of WiFi capability)
Thx,
--don