|
RecAPI
|
Both RecAPI and IPRO were modified between version 12.x and 15.0. RecAPI retained its basic approach. Some functions were renamed so that they are separated more clearly into the two-level structure.
Although the step from version 12 to 20 brought some profound changes, our experience was that the mechanical porting of a medium complexity application (without utilizing new functionality) can be done in a couple of days. Porting of OmniPage 14 (an application of high complexity), done by two developers (familiar with both the application and the new RecAPI) took only a couple of weeks.
Almost all CSDK RecAPI functions received the parameter: Settings Collection ID, to provide profile-like functionality. All Settings Collections have their own set of settings and values. See Settings Manager Module on how to handle and use settings.
HPAGE replaced HIMG in RecAPI. As the name suggests, HPAGE stores more data than HIMG. HPAGE can store several different versions and processing states of the given image, ranging from the original image, the primary image (with pre-processing modifications), its black-and-white variant (prepared for OCR), and thumbnails. If the integrating application needs to display or report on these image versions, the given variant needs to be specified in the image functions where it is possible (IMAGEINDEX). If the application does not need these variants, the II_CURRENT image index should be used. As the internal representation of the loaded image, CSDK 12.7 used the data structure identified by the HIMG handle. Any given HIMG used to be identical with the loaded image, also for storing the results of decomposition and OCR operations - i.e. zones and recognized text.
The data structure behind the HPAGE handle is the internal representation on the page to be processed. It has taken over the storing functions of HIMG: it stores zones as well as text after the relevant processing phases. The functionality and the outputs of these phases have been further expanded in CSDK: information about lines and frames within the image (also stored by HPAGE) is also accessible. Furthermore, from HPAGE, you can also access the distinct processing phases of the loaded image. That is, besides the current image, the binary converted image is also stored. If need be, the original and the OCR images are also available and a thumbnail image is also created.
Naturally, the application can decide which image types are to be kept in memory. In such a case, image types to be deleted are dropped, since they play no further role in processing.
Within HPAGE, the distinct image types are identified by IMAGEINDEX. So, you do more than just access each type - it is also possible to specify or retrieve coordinates in the coordinate system of the selected image. If you specify II_CURRENT IMAGEINDEX as the input parameter, this would reproduce the functionality of the corresponding CSDK 12.7 function, since it is this image phase that corresponds to what used to be stored in HIMG. Accordingly, some functions have received a new IMAGEINDEX input parameter.
CSDK supports irregular zones. A zone can be composed of sub-zones, defining its shape. When there are no sub-zones present, it is the zone dimensions that define the zone area. If sub-zones are specified by the kRecAddZoneRect function, or they are created during a call to the kRecLocateZones page parse function, the zone will be composed of sub-zones, and zone dimensions only define the incorporating area. In this case, recognition will only be carried out in the subzones.
CSDK has two zone lists: one for user zones, the other for OCR zones. Being separate, the list of the user zones does not need to be deleted during decomposition. Decomposition (kRecLocateZones) takes user zones as input and it creates OCR zones out of them in the following ways:
Depending on user settings, decomposition can also search for further zones in the page, outside the existing ones. OCR zones get finalized via several steps, since they can change during the recognition process (among others, non-gridded tables are created now, and text zone borders are mapped on actual text) thus user zones may be needed during recognition. If you modify user zones, the current OCR zone list is deleted (since the OCR zones contained in them were created according to the user zones prior to the modification) and new OCR zones will be created (according to the new user zones) in the next decomposition or recognition process.
To emulate CSDK 12 functionality do not run decomposition while defining user zones, or delete user zones before decomposition and copy the OCR zones into the user zone list with the kRecCopyOCRZones function after the recognition process. This will delete previous user zones, just as in CSDK 12.