Ascent
Capture 6.x Application NoteAC
Kofax Capture 8.0 Service Pack 2 is the latest release of the Kofax Capture (previously named Ascent Capture) product. The Kofax Capture Network Server (previously called the Ascent Capture Internet Server) is included in the Kofax Capture product. Please refer to the Kofax Capture 8 Web pages for any Kofax Capture Network Server information.
is the latest release of the Ascent Server product.The purpose of this document is to define the rules used for zone resolution in the Recognition Server queue.
Each zone is clipped from the source page image. Any image processing is applied after the clipping. It is important to keep this in mind when setting certain parameters (like line removal). For example, a "minimum height" for vertical line removal might default to 200. The page might show the line as being larger than that. However, when the zone is snipped out, the total zone height might only be 150, so the line is only 150.
In Ascent Capture version 5.0 and above, the zone can be tested in the Administration module using the Test functionality. In the properties of each zone, there is a button called "Test" which will show the results with the Image Processing settings applied to the zone.
The internal OCR engine utilized by Capture 5 is from a company called Caere. It is based on their 6.1.2 development kit.
Any values specified for a field type are passed as "suggestions" to the engine. Frankly, we have not noticed any significant accuracy improvement by doing this.
All OCR text is filtered in the following way: All leading and trailing blanks are removed, as are new-line characters.
A series of complex rules is employed to eliminate unwanted character fragments from the zone results. Capture actually passes the zone plus a small margin around it to the OCR engine and then filters the results. This allows the OCR engine to completely recognize characters on the border of the zone rather than assuming that such character fragments are quotes, periods, or other unwanted "noise."
In general, a character must reside completely within the original zone boundaries to be accepted. Characters that do not reside completely in the zone are not reflected in the final output.
A more liberal policy is allowed for the descending, English-alphabet, lower-case letters "g", "j", "p", "q", and "y." If these characters reside completely within the zone, then they are accepted as with other characters. However, an additional option exists. If these characters overflow the zone only on the bottom, and they are at least 50% within the zone, and there is at least one other character on the same line that was accepted in the normal way, then the descending character is accepted. This feature allows users to draw zones around "normal" text areas without worrying that descending characters will get "dropped." The complex rules prevent stray, unwanted characters from appearing the output.
An exception to these filtering rules exists for "fixed pitch" zones. In such a case, the OCR engine synchronizes its recognition to the first character it finds. The internal zone expansion can bring in more text than originally zoned. In most cases, this is fine since the additional text is later filtered. However, with "fixed pitch," extra text can improperly cause the engine to recognize only text of a size found outside the zone. Because of this, no expansion or fragment elimination logic is applied in this case.
Because the actual zone is expanded when sent to the engine, a separate zone image is generated if a recognition script requires it.
The final confidence of the zone is computed as follows:
( total number of characters –number of "unsure" characters) / total number of characters * 100
Note that "error mark" characters are not considered as part of the "total number of characters" number.
Reading a "typical" OCR zone (i.e. one that is a word or two) takes a total of about 400ms on a 300Mhz machine. Of this, about 120ms is overhead within Capture. The other amount takes place within the Caere engine.
The use of an image zone within the script adds another 70ms per zone.
Larger zones seem to degrade performance linearly with respect to total zone area (although text density is probably a factor as well).
Performance seems to degrade linearly as zones are added. It is unknown if performance will decrease on a slower machine, or fail to get faster on a quicker machine. Older Caere engines have shown to "max out" and fail to get faster on faster machines.
The ICR (or hand-writing) engine we use is from a company called Recognition Technologies. It appears to use a neural net type of algorithm where the engine is trained by example.
No pre-processing is performed if values are specified.
All ICR text is filtered in the following way: All leading and trailing blanks are removed.
No further filtering is performed on ICR zones. This is partially due to scheduling constraints, and the fact that the ICR engine does not determine zonal boundaries as well as the OCR engine.
The final confidence of the zone is the average of character confidences produced by the engine.
Each ICR zone takes about 250ms on a 300Mhz machine. Of this, 120ms is overhead within Capture. The rest takes place within the ICR engine.
Performance seems to degrade linearly with additional zones.
Performance degradation with larger zones is not known exactly. It is at least linear with area, and some results have shown it to be exponentially slower.
Performance change is unknown across different speed machines.
There is currently no additional performance hit involved with any recognition script usage (beyond the actual code within the recognition script).
The OMR (or mark sense) engine we use is developed in house. It is a simple pixel counter that computes the ratio of black pixels to total pixels. If the percentage of black pixels in the zone exceeds the threshold set in Admin, then a "1" (one) is returned as the result. Otherwise a result of "0" (zero) is returned.
No pre-processing is performed if values are specified.
If force-match is specified, then the result value (0 or 1) is matched to the forced match values (see below). Without a recognition script, this has little benefit and might actually cause strange results if values other than 0 or 1 are used. However, if paired with a recognition script, this could be useful. Provided the recognition script translates the 0 or 1 into one of the force-match values, this provides an effective translation technique. When the user goes to manually index that field, the translated values will display in a drop-down combo.
The confidence goes up linearly with the absolute distance of the final pixel percentage from the threshold percentage. If it's a "match" then a darker image produces a higher confidence. If it's a non-match, then a lighter image produces a higher confidence value.
OMR performance per zone is about 130ms on a 300mhz machine. Of this about 120ms is overhead not associated with pixel counting.
Performance is expected to degrade linearly with additional zones and/or slower machine speeds.
Performance is expected to degrade minimally with larger zones. Such degradation may not even be measurable unless the zones are very large. This is because the overhead cost of processing a zone is so much higher than the cost of performing the actual recognition.
An SBL "Recognition Script" may be applied to any zone type executed during forms processing.
After the zone is snipped from the image, and image processing is applied, the "PreRecognition" function is called within the script. If desired, the script can tell the application to skip the default recognition of that zone.
After default recognition is applied, the "PostRecognition" function is called.
See the user documentation for more information on the syntax and capabilities of these scripts.
If the field type has been set up with force match, or force-match is turned on internally (see below), then the results of the engine are matched to the value list. The value that has the most character pairs that match wins.
Note that force-match processing is done AFTER the "PostRecognition" function in the recognition script (if a script exists).
A separation zone may be used to separate pages into documents. If a separation zone exists for a batch, and separation by separator zones has been selected, the system executes that zone on every page. If the zone succeeds, then a new document is started.
If no match text is provided, then the zone wins if the result value is non-null and the confidence exceeds the threshold set.
If a match text is provided, force-match is turned on internally, and the zone wins provided the recognized text is "close" to the match text. If an exact match is required, then the confidence should be set to 100. Otherwise, the confidence threshold actually indicates how close the match must be.
A form ID zone may be used to identify a document as a part of a specific form. Page-level form id is always performed first. Any "winners" of page-level form id are checked for form id zone. A form cannot "win" if it has a Form ID zone, unless that zone wins.
If no match text is provided, then the zone wins if the result value is non-null and the confidence exceeds the threshold set.
If a match text is provided, force-match is turned on internally, and the zone wins provided the recognized text is "close" to the match text. If an exact match is required, then the confidence should be set to 100. Otherwise, the confidence threshold actually indicates how close the match must be.
An OCR registration zone can be used to augment or replace page-level registration. Page-level registration tries to offset all zones based on how far large features on the page are offset from the same features on the sample page. This works extremely well in some cases, but can produce invalid results if the sample page is not predictable, the zone location can vary on the page, or the scanned pages are stretched or distorted.
In such cases, it is often better to utilize an OCR registration zone. An OCR registration zone is a special OCR zone that contains a registration point. This point must be set where the user expects the lower-left of the first character of the text in that zone to reside. The lower-left of the first character in the zone on the sample image is the normal location.
Normally, the bounds of the OCR registration zone should allow enough white space around the search text to allow for the expected offset of the scanned images. It is extremely important that the bounds of the zone have sufficient clearance from other text or features on the page.
In order to be utilized, the OCR zone must "win."
If no match text is provided, then the zone wins if the result value is non-null and the confidence exceeds the threshold set.
If a match text is provided, force-match is turned on internally, and the zone wins provided the recognized text is "close" to the match text. If an exact match is required, then the confidence should be set to 100. Otherwise, the confidence threshold actually indicates how close the match must be.
Assuming the zone wins, the registration point on the sample image is compared with the lower-left point of the first character completely within the zone. If match text is provided, the registration point is taken from the first character in the zone that actually matches the first character of the search text.
Note that the recognition script has no way of modifying the procedure for extracting the registration point. Modifying the recognition results will only determine if those results are utilized.
Currently, only one OCR registration zone can be used on a page. To lessen the effects of distortion or stretching, this zone should be placed as close as possible to index zones.
The following rules apply to the resolution of a single index field assuming the existence of zero or more associated zones.
Mapping multiple zones to the same index field has some interesting applications:
The Kofax Capture / Ascent Capture Technical Support group is comprised of three subgroups (discussed on the Support Options Web page), whose members are knowledgeable in all aspects of the Kofax Capture / Ascent Capture product and Kofax / Ascent modules, including installation, configuration, operation and development. Each group receives ongoing product training from our Engineering department relating to the general Kofax Capture / Ascent Capture product and their specific area of expertise. These groups have in depth knowledge of networking, databases, hardware, and programming which they use when assisting all supported Kofax Capture / Ascent Capture customers.
The Kofax Capture / Ascent Capture Installation, Configuration, Operation, and Web product's Technical Support group can assist with installation and configuration of the base Kofax Capture / Ascent Capture products as well as troubleshooting problems that occur in production. They have lots of experience with installation problems, batch class setup, patch code and bar code problems, hardware key issues, OCR engines, MSDE etc. They provide support for the Ascent Xtrata and Kofax Capture Import Connector - Fax / Ascent Fax products. They also can assist with the Kofax Capture / Ascent Capture Web products such as the Kofax Capture Network Server / Ascent Capture Internet Server and the Kofax Capture Import Connector - Web Services / Ascent Collection Server. They can assist with installation or connectivity problems across LANs, WANs or the Internet.
For details regarding technical support available for all Kofax products, please review the current Support Overview & Options and Product Support Eligibility Matrix Web pages.
Contact Us