I am a bit surprised at how low the accuracy seems to be. Does anyone know if this is typical just of OCR done in JS, or OCR in general? I am aware that at least one or two implementations are extremely good (eg. Google ones) but are those complete outliers?
That is specific for this implementation. Note that cursive/handwritten text will continue to be an issue, but machine printed is pretty solid and especially easy if you can narrow down the scope of the expected result (somewhere in this thread someone wonders of it would be possible to prefer 0 to o etc - sure). Note that
a) it's not possible to consistently reach 100% (and depending on the source material and circumstances far less) recognition (have to educate customers about that..)
b) errors are a tradeoff between 'dunno' and 'might be a zero' aka miss vs. false positive. Benchmarks/evaluations usually consider the latter far worse, prefering jf?oster to jf0ster by a long shot. So that's what you'll try to archive.
Source: Approaching ten years (yeah..) in a company that sells OCR solutions and more, integrating Abby, Oce and another half a dozen commercial engines.
I work at a publisher with millions of digitized historical books that we OCR and Abbyy is what we use. Nothing else came close to Abbyy. It is incredibly good, but incredibly expensive.
in my humble experience using OCR programs, there is always a considerable amount inaccuracy. no matter what font I use or font size, I always either end up proof reading the scanned document or just typing it by hand. the letter "O" is almost always translated by the OCR as a "0" or a zero is translated as an "O". it can be pretty frustrating.
I used the ABBYY orc engine to digitize printed documents (idk why they couldn't just keep around the file used to print) and it was quite accurate. At worst one out of a couple hundred would have enough issues where readability was an issue.
Similar experience here, when building a mobile app that did OCR + translations.. As long as the source image was in decent shape, ABBYY did very well. It's also incredibly expensive.
I wish there was a library that allowed you to input expected data (ex: we expect to see zeros 20% more often then the letter O), then the interpreter could compare against that fact and determine the likelihood of it being each letter. As it stands for most libraries that I'm aware of, you just have to get the data and run your own tests to see whether it should be an O or a zero.
Ocrad is not very powerful, it uses hand-written recognisers (one per character) to identify the shapes of the characters. Compare this with more modern libraries such as Tesseract which use neural networks and OCRopus which adds language modelling.
I kept giggling at its poor recognition. It's comically bad, but I think it's a step in the right direction. It was very fast at incorrectly identifying letters. If only it were very fast and mostly correct.
Hand writing my name Chris was difficult for it to pick up. It kept thinking my "C" was an "L" and putting spaces in between letters. Also determined my "S" was an underscore. Still pretty cool. Thanks!
Interesting - I've had the Project Naptha (http://projectnaptha.com/) Chrome extension installed without really looking under the hood.
Turns out it has Ocrad.js and Tesseract as two engine options - it uses them to automaticaly convert images on the page to selectable text.
It demos well, but then I tried a simple test - a photograph of some text (http://imgur.com/TCnGlZG), Ocrad.js utterly failed at it, almost all letters were incorrect.
I looked at this recently to try to pick some values off a high res png of a pdf. That was a little too ambitious for this library. It's probably good for smaller images with a few words.
It might be easy, but until iOS 8 is released, non-Safari JS still takes a performance hit. [1] You may want to take a look at the Tesseract library and Objective-C wrapper. [2]
