OSNews

Excellent review, very thorough and clear.

99% accuracy is still pretty bad, imagine 10 errors when you scan a 1000 word document. And 99% accuracy was only obtained by programs that are highly experimental and unavailable to the average GNU user.

Too bad, the state of open source OCR is really immature compared to what is available for Windows. I wish HP would supply good OCR software for Linux with their scanners. I used to use OCR on Windows about 10 years ago, and it was awful. Then I recently tried OCR again with the Windows software (forgot the name) that came with my HP PSC 1300 printer/scanner combo, and it was eerily accurate- truly impressive. However, it required installing a disgustingly slow, bloated, poorly designed package of unrelated software, typical HP junk. And it's Windows only.

Edited 2007-05-24 00:27

That while we're smashing through processor speed barriers, and now you can get a fairly powerful machine for under 500 bucks, and we have refrigerators that will order groceries for us when we're running low on staples the 2 "holy grails" of mainstream computing haven't made nearly the same amount of progress: Speech recognition and OCR have seen very small gains in progress over the past decade compared to the rest of the computing realm.

It's a pretty good indication of just how complex these types of technologies really are...having computers understand human types of communication is extremely difficult. This isn't a Linux vs Windows vs whatever deal, it's a man vs machine plight.

I look forward to the day where I can talk to my machine, and it'll produce compilable code. Ok maybe not really, but it's a nice thought nonetheless ;-).

I have worked in *nix-based image processing for almost 4 years, and have repeatedly beat my head against the OCR barrier. In the end, we had to go with OCRXTR, by Vividata.

I have tried GOCR, ClaraOCR, OCRad, and Tesseract. All my results were just not even close to realistic for production work.

For some reason, although I could compile Tesseract on FreeBSD just fine after a little coaxing, the output was absolute garbage; mostly it looked like line noise, or Perl poetry. Not anywhere close to accurate. Maybe there are some Linux-specific assumptions in Tesseract?

GOCR produces half-decent results if all you are looking for is English ASCII output from fairly simple documents. But, even then, it's performance is really bad in comparison to OCRXTR. On the order of 1/10 the speed at best.

ClaraOCR is interesting, and we even considered contracting the author to extend it to allow for server-side work, but it was just not a reasonable time-investment.

Consider, Vividata OCRXTR can process 300-dpi black&white pages on at least the order of two pages per second, and has a fairly linear performance curve, even with large multipage Tiff files. Also, it works for color images, automatically handles inverted pages, preserves images in pages, and produces nicely-formatted PDF output. All in all what I would consider minimum requirements for production. There just is no comparison at this point. Unfortunately, since it is Linux only, I have to run Linux compatibility mode in FreeBSD in order to use it.

But like someone said earlier, it's more of a Man Vs Machine fight than Winvs*Nix fight.

I've been looking for proper software for converting images to text (bulk) and there simply isn't anything free which is relevant.

Now here how this should be done for those interested.

First of all, Neural networks and similar techniques can "teach" your box to handle handwritten stuff etc. So anyone building an OCR software has to be really good in this expertise. Secondly, a "training" part is obviously a need for these kind of softwares in order to get better.

There used to be a proprietary software called Eyes on Hands which has some really good features (Cost: 10 000$+).

For instance, when scanning plenty of docs with numbers, you set up scan fields and say "here we'll have a number as input". Then it matches numbers or characters against what it thinks it is and lists all of them in a logic order in columns. Saying something like "We believe these are 9's in descending order based on likelyhood". Then you just look at it's interpretation and can easily correct what it has done wrong. By using AI/NEural NEts in the software, it can actually then get better at interpreting.

HOwever, as with any software.. I seem to have the experience that any "Niche software" which isn't of great value to sysadmins have very few OSS counterparts I'm afraid. Which is simply just sad =(.

People here or elsewhere that have a problem with FOSS OCR apps actually think FOSS is free labor, free slaves working for them. That's not the case at all.
If people really want the field to improve, they can make FOSS programs so that everyone can improve them. The fact that few people improved gocr or ocrad shows that it's of no great interest.
As for admins and regular users, gocr and ocrad are more than sufficient. gocr + ocrad are sufficient, with FuzzyOCR, to help my SpamAssassin recognize image spams, and it's sufficient for the very rare use of OCR at home.
Besides, IIRC the kde app knows about ocrad too.
So I think they're good enough for regular users, and admins.
For more specific work, of course, as always with FOSS, these apps won't improve by magic alone.

To be correct OCR is and was developed using a few special OCR type faces. The engine used a bitmap overlay on each character since spacing was not kerned it was almost easy but very time intensive.

Today billions of packages and addresses are read by delivery and postal machines.

They basically find the address region. Try to break it up to lines of print. Then try to split the lines to single characters. They then use a confidence level from 3 to 6 character engine. Each engine uses it's own algorithm. One is a software copy of an original single purpose hardwired computer designed almost 30 years ago. Oddly the modern engines have not been able to fully beat the old system. Most of the newer designs use either a mathematical based on pixel or shapes/curves to determine the character.

99% accuracy isn't all that bad for a typical document. Is it good enough for the U.S. Postal Service? Probably not. But it would do the trick for the vast majority of applications.