ImageGear for C and C++ on Windows v19.1 - Updated
Optimize Performance
There are different issues to consider when you want to improve accuracy. Typically, they also have consequences for the processing speed. This topic provides some information about optimizing performance and accuracy in the following areas:
Image quality is one of the most important factors that influences accuracy. A resolution of 300 dpi or 400 dpi is best for recognition.
Use image preprocessing to enhance the quality of a given image to get more accurate auto-zoning and recognition.
Load grayscale or color images into the recognition engine without any conversion (IG_REC_IMG_CONVERSION_NO) and combine this with image preprocessing in order to get more accurate output.
If auto-zoning is needed, use IG_REC_DCM_STANDARD, the most accurate page parser available in the recognition engine. Applying the IG_REC_DCM_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 algorithm IG_REC_ DCM_LEGACY.
Finally, use IG_REC_ DCM_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: IG_REC_decomp_nongridded_table_detect_set() ).
The most suitable filling method and recognition module should be specified, as described in the previous topic.
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 IG_REC_RM_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 IG_REC_ RM_OMNIFONT_MTX, IG_REC_ RM_OMNIFONT_FRX, IG_REC_ RM_OMNIFONT_MOR, or IG_REC_ RM_OMNIFONT_PLUS2W (default) instead of the omnifont module IG_REC_ RM_OMNIFONT_PLUS3W.
These are set at page level, and determine how thorough the recognition should be, i.e., should more time be taken to try for higher accuracy. There are three possible values: IG_REC_ TO_ACCURATE, IG_REC_ TO_BALANCED, and IG_REC_ TO_FAST, and these are passed to the IG_REC_tradeoff_set() function. For more details see the Technical Specifications for the Recognition Modules.
The behavior, and hence accuracy, of some recognition modules can be influenced by separate module-specific settings.
MOR, PLUS2W and PLUS3W: For poor-quality fax output, the fax compensation switch IG_REC_MOR_is_faxed_set() can be used.
This determines the zone level at which a set of characters should be considered 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.
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 recognition with the checking subsystem for precise 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 function). This later checking should make it possible to determine whether any error is due to optical recognition errors or was originally invalid.