ImageGear .NET
OCR Performance Considerations
| User Guide > How to Work with... > Recognition > Recognition > OCR Performance Considerations |
There are different considerations to be taken into account when you want to improve recognition accuracy. Typically, they also have consequences for the processing speed.
This is one of the most important factors that influences accuracy.
If auto-zoning is needed, use ImGearRecDecompositionMethod Enumeration.STANDARD, the most accurate page parser available in the recognition engine. Applying the STANDARD algorithm results in better throughput in overall accuracy, though in some complex cases it might require significantly more time to complete.
If processing speed is also important, consider using the LEGACY algorithm.
Finally, use FAST when the processing speed has a higher priority than accuracy, and the image content of the originals is simple enough (e.g., good quality letters without graphics or tables). In this case, it is recommended that the Non-gridded table detection algorithm be disabled (see DecompDetectNongriddedTablesEnabled Property).
The most suitable filling method and recognition module should be specified, as described in Recognition Modules.
If more than one recognition module supports a given filling method, consider whether for your application it is better to specify the recognition module in your program rather than accept the setting selected by the recognition engine through the ImGearRecRecognitionModule Enumeration.AUTO option.
By choosing different combinations of the auto-zoning algorithm and specific recognition modules, 2-3 times faster recognition speed at the cost of increased error rate (1.5-2 times more errors) can be achieved.
For example, when speed is an issue, consider using OMNIFONT_MTX, OMNIFONT_FRX, OMNIFONT_MOR, or OMNIFONT_PLUS2W, instead of the default omnifont module OMNIFONT_PLUS3W.
These are set at engine level, and determine how thorough the recognition should be, i.e., whether more time should be taken to try for higher accuracy. There are three possible values: ACCURATE, BALANCED, FAST, set using the ImGearRecRecognitionSettings.Tradeoff Property. For more details, see Specifications for the recognition modules.
The behavior, and hence accuracy, of some recognition modules can be influenced by separate module-specific settings. These settings are accessed via the Modules Property of ImGearRecognition Class. The Modules Property provides access to ImGearRecModuleCollection Class, which provides the following properties to access module-specific settings:
In the Recognition module specifications each module has its own section, Accuracy Issues.
This determines, at zone level, which set of characters should be considered as valid. By eliminating characters that are known not to appear in the zone, accuracy can be improved. If non-validated character shapes are encountered in a zone, they are either replaced by the rejection symbol or forced to a similar-shaped validated character. A major component of the Character Set is the language choice. Setting the wrong language(s) and/or language dictionary (or leaving unneeded ones enabled) is likely to slow down recognition and reduce accuracy considerably. The steps for defining the Character Set are given (with examples) in a following section, Define the Character Set.
This consists of any combination of the following checking tools:
The Checking subsystem will find characters, words, or zone contents that do not match program-specified rules for that zone. It can be instructed either to only mark these occurrences, or be given permission to change them when it finds a sufficiently similar acceptable solution. See the section (Improving Accuracy with the Checking Subsystem) for examples.
Character Set limitation and the Checking subsystem (CSS) both influence accuracy, but in different ways. Both, either or none of them can be used; the integrator should decide which balance is best. Their effects, when used separately, can be summarized as follows:
Limiting the Character Set gives the program the greatest decision power, using the checking subsystem to only flag errors is safest, but requires more post-processing outside the recognition engine to check all non-conforming cases.
A typical balance would be to impose broad restrictions by limiting the Character Set, e.g., specifying the permissible languages, but using the checking subsystem for detailed control over parts of the recognized text where it's important that the original data be recognized and passed for checking precisely as it was written (e.g., for an ID Code incorporating a check-digit method). This later checking should make it possible to determine whether any error is due to optical recognition errors or was originally invalid.