'good' barcode readers work on partly obscured, partly dirty, printed on
non-optimal color package, slightly skewed, and strongly reflecting
(specular) packages, like your average packaged food from the grocery for
example, in despite of the barcode designer's CLEAR instructions as to
what barcodes are to be printed on (see www.barcodes.com for a good set of
infos - they manufacture wands and other barcode related products). The
idea is that the marketing department of the food manufacturer is always
right <g>. I don't know about there, but here the grocer(ess) must punch
in numbers for every 5th package type passed in front of the laser reader
(mirror scanned type) (bad average). This is 80% recognition and it seems
to be acceptable although I am quite sure that high volume supermarkets
would be happy with a better figure.

Your example from the library probably does OCR besides reading barcodes
and applies some sort of fuzzy logic to find out if that's a card, a book,
both, or neither you are trying to fool it with. This is more than reading
barcodes. I am also quite sure, without having seen it, that it fails
sometimes.

Each task shown in pgr. 1 is very easy to solve by itself. The problems
begin when you need to solve them all together, like in real life, because
the requirements are conflicting. You also have a time-frame and need to
be able to sell it for something that allows you to make money from it.
This is why the theoretical path must be abandoned at some point and then
you must go to war, by trial and error, until it seems to work right. Then
you go to the target area and it stops working and you start over ;-).
Just think of the effect of high efficiency lighting on a detector without
an own light source, like a small ccd camera, for a starter.

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body