OCR common interface

20 years ago I helped develop one of the early OCR technologies into a commercially viable product. The company eventually merged with the main competitor at the time and they produced OmniPage.

I can tell you two things:

(1) There was no standardized interface at the time and there has never been any economic incentive to create one.

(2) Almost every OCR program has to be able to take an image as input and provide text as output. So the basic interface is exactly the same for all OCR at a high level of description.

Early OCR expected black and white images at 300 dpi (pretty standard for scanners of the time) or 200 dpi ("high quality fax") and gave you ascii (or unicode) text out. As memory and processing speeds increased, the accepted higher resolution and grey-scale and eventually color images.

I think you can get away with defining your interface as accepting an image (preferrably not jpeg as the compression is not good for text) and yeilding text.

Write all your higher level logic to that interface, and then beneath that interface you may need to add code to convert image formats and text representations to and from a specific OCR engine.

As a general rule, I'd recommend you at least include OmniPage as one of your OCR engines -- they have an incredibly vast proprietary training set that they train their OCR with. Very few of the newcomers (less than 10 years old) will have had the resources or the time to compile a training set anywhere near as close to what they have. In the world of pattern recognition, the size and quality of the training set pretty much trumps the algorithm in determining the accuracy of the result. If speed and space are more important than accuracy, then the algorithm is key.