Anyone integrating OCR into their app, or interested in doing so? This isn't exactly a new technology nor is it necessarily a 6.1 feature (it might just be an auxiliary component only loosely connected to A-Shell), but as I've gotten a recent inquiry about it and am doing some research, I thought I post it as a possible addition to the list.

The immediate interest is in ID card scanning - drivers licenses, insurance cards, etc. There are a variety of companies that make scanners specifically for these kinds of objects, most of which are bound in one way or another to an OCR/data extraction package and possibly an application-integration SDK. There are also the software-only OCR products, like Abbyy Finereader, OmniPage, TextBridge, etc, which presumably could be configured or trained to recognize specific kinds of ID and extract the fields of interest.

For whatever reason, there does not seem to be the variety of choices available in this market segment as in, say, PDF generation. Either we are looking at every expensive developer licenses, and/or substantial per-user license fees. So the main benefit of integration with A-Shell would seem just that, i.e. the integration (simplified deployment, support, tighter control, etc.)

It would be nice to have as part of our document imaging. It could be used for document searches where they are looking for all of the documents that referenced a certain topic. It could also be used for document identification where they would scan a region to get an ID # like the check # or invoice #.

There is one customer who could make use of it now, but they haven't asked about it in awhile.

You might look at the tesseract project; which, is an open source project currently under Google's control. I believe that is what they use for their book scanning to ebook project, and also to power OCR in Google Docs.

The google code page says it works in Linux and Windows (32 & 64 bit)

I have actually looked at it, somewhat. It seems pretty attractive on multiple levels:

1) it scores very high in standardized recognition benchmarks

2) cross platform

3) open source

4) Google sponsored

On the downside:

a) No GUI interface

b) No documentation

I've tried a couple of limited tests with it, and it does a pretty decent job of recognizing text in text-oriented documents. But it wasn't very good at dealing with a driver's license, compared to, say, Abbyy Finereader, which does a remarkable job right out of the box, or to products like the CSS (Card Scanning Solutions) which is specifically targeted at that kind of thing.

Tesseract does have a sophisticated training mechanism for teaching it new fonts, so it could probably be trained (with considerable effort) to deal with the typesetting abominations presented by drivers licenses and other ID cards. Plus, it relies on external image processing libraries to render the scans presentable, so it may be that pre-processing with some cleanup tool like ScanFix would vastly improve the performance with messy documents like ID cards.

Even so, it stands to reason that Google's focus is on unstructured text acquisition, since it plays to their strength. But I suspect that for many A-Shell applications, the focus would be more on structured data. (For example, in scanning an ID card, you don't just want the text but you want to separate it into fields, i.e. name, address, height, id #, group #, company name, etc.) If you're dealing with a limited range of input layouts, you can handle that by isolating the fields within their respective region coordinates. But even drivers licenses come in at least a hundred varieties, making it impractical to either pre-select the format manually (e.g. Oklahoma Class C circa 2002) or to use brute force to try all the formats to see which yields the best results. Hence, it is likely that a general purpose tool would have to offer some kind of additional format-recognition module.

The higher-end retail products combine many of those functions (image processing, cleanup, text recognition, format/layout recognition, output formatting) into one package. Their weakness is the difficulty of integrating them into an app (i.e. ease of deployment, configuration, use, support, cost).

At this point, without more feedback from potential developers/users, it's unclear whether it makes sense for us to get further involved or not.

I can see the issues with specialized implementations like drivers licenses, but it could be very useful in trying to convert to a somewhat paperless office. K&K has years of old paper documents which we've considered other Document Management solutions (DocRecord to be exact)to digitize and index. We haven't really liked the idea of implementing multiple applications for users to have to remember what they need to use to access the tools to do their job. Maybe other developers could use this sort of tool?

Hi,
Twice, in differente ocasions, for two different customers, Kofax solution was considered to implement, at least one of those customers was very near to sign the contract but reconsidered in the last minute, he didn't want to keep paying annualy and, probably, still has enough room to archive documents.
The plan was to integrate the Kofax solution in my software which, basically, would consist on receiving the already processed (categorized) documents and archive.

What we are talking here is the ability to, from inside A-Shell, scan (which we do already) and identify data in a field oriented base, that would be awesome.

The basic case is the, already mentioned above, business card scan; what I propose to customers who go to fairs is to use the portable IrisCard scanner and, after, import the collected data into A-Shell.
It would be great to have this integrated in A-Shell and after scan a card have immediate access to already existing data or start a new record.

So, for what this could matter, I'm for this development.