Optimize FlexiLayout structure and search with Group elements

Using Group elements to search for objects is most efficient, because grouping elements together reduces the number of hypotheses for an element and speeds up the search for the resulting hypothesis for the whole FlexiLayout. Moreover, if the grouping of the elements reflects the logic of the document, it helps to optimize the structure of the FlexiLayout and makes it more explicit. Grouping several elements together into one Group element enables FlexiLayout Studio to treat this set of elements as a whole with its own hypothesis (composed of individual hypotheses for elements in the group). Analysis of hypotheses and their elements takes place within the Group element, and only the user-specified number of the best hypotheses (1 by default) is used in the subsequent search for other elements. The entire tree of elements can be regarded as one Group element, the best hypothesis for which is the result of matching the FlexiLayout.

​

The GroupSample.fsp sample project

The GroupSample.fsp project (folder %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Group\Project1) shows how Group elements can be used. The goal is to detect the fields with the invoice number, the invoice date, and the invoice sum on the image.

​

Group the invoice fields into InvoiceRequisiteGroup

As the image shows (and as is usually true for all financial documents), the number and the date of the document are neighboring fields. Even if the arrangement of the fields on another document is different, they will still be close to each other. Furthermore, they are connected by the logic of the document, as they describe certain bank details and form a logical block. To make the structure of the FlexiLayout more explicit, the project groups them into a Group element named InvoiceRequisiteGroup. The first element in the Group is an element of type Static Text, named InvoiceNumHeader, which describes the search constraints for the name of the field “Invoice number”. The string “Invoice” is specified as the value of this element. Based on an analysis of the available images, the invoice number is searched for to the right of the name, with the help of an element named InvoiceNum. Similarly, under the line with the invoice number, the project contains an element for the date field, named InvoiceDateHeader. To search for the date itself, the project uses the group DateGroup with the following subelements: InvoiceDate and InvoiceDateAsString. For more information, see Date search after high or low-quality recognition. To detect the field with the invoice sum, the project uses two elements: a Static Text element named TotalSumHeader (its value “Totalsum(EUR):” is written without spaces), and a Character String element named TotalSum, which looks directly for the sum. The string “Invoice”, specified as the value of the element InvoiceNumHeader, can be encountered on the test images three times: as the name of the field “Invoice number”, as a substring of the name of the field “Invoice date”, and at the bottom of the invoice, as a substring in the invoice conditions: “Current invoice is…”. Note also that the name “INVOICE” (which the InvoiceNumHeader element is meant to detect) is very noisy, which caused an error in the name. In the other lines, the string “Invoice” is clear, and the quality of the corresponding hypotheses must be higher than that of the hypothesis for the name.

​

How the group selects the best chain of hypotheses

Now try matching the FlexiLayout with the test images in the batch. Once you have started the FlexiLayout matching procedure by selecting the Match command, you will see that the tree of hypotheses consists of a single chain. Double-click InvoiceRequisiteGroup to open its Properties dialog box, where you can see which hypotheses were generated for its subelements, which chain in the Group turned out to be the best, and why. There are three hypotheses for the InvoiceNumHeader element, matching the number of “invoice” strings detected. The quality of the hypothesis of interest is lower (approximately 0.99), because its area on the image is noisy and FlexiLayout Studio could only recognize “INVOIC” instead of “INVOICE”. The quality of the other two hypotheses, however, is the maximum (Chain quality = 1). The properties of the InvoiceNum element specify that the invoice number can have any number of digits and should be sought to the right of the name. On this image, these conditions are met in all three cases, which enabled FlexiLayout Studio to continue creating a chain of hypotheses for each of the hypotheses for the name of the “Invoice number” field. Although the Pre-search quality of each of the hypotheses of the InvoiceNum element is 1, the correct chain is still the worst. This happens because chain quality is assessed by multiplying the qualities of all the hypotheses forming the chain. For the required name this quality is about 0.99. If the Group did not have any other elements, the final choice at this stage would be incorrect.

​

Why the correct chain wins despite lower initial quality

As noted earlier, the properties of the InvoiceDateHeader element specify that it should be sought under the line with the invoice number. However, none of the chains with the best quality (Chain quality = 1) resulted in a hypothesis for the name of the date field. Consequently, null hypotheses were formed in these chains for the InvoiceDateHeader element. Since the default quality of a null hypothesis was not changed, the resulting Chain quality of the corresponding chains dropped to 0.97. At the same time, the element corresponding to the name of the date field was found for the chain that had the lowest quality. The quality of its hypothesis is approximately 0.993. It is less than 1 because the image in the area of the name is noisy, which resulted in a recognition error and an incomplete match between the recognized text and the value specified in the properties of the InvoiceDateHeader element. As a result, the found hypothesis was penalized and its final quality is about 0.98 (the result of multiplying 0.99 by 0.993). Nevertheless, the final quality of this hypothesis is higher than that of the others (0.97), so at this stage this chain is the best. To detect the date field, the project uses the Group element DateGroup, which specifies that at least one of the elements cannot be found if the other has been found (the Dontfind function was used). Because of the document layout features and the properties specified for the InvoiceDateAsString element (its alphabet allows digits), FlexiLayout Studio managed to find the date field for all the chains, though only one of the three hypotheses is actually correct. Since in each Group one of the elements has been found while the other has not, the final quality of the chain in each of the DateGroup groups is 0.97 (1 multiplied by 0.97, the default quality of the null hypothesis). In this example, the final quality of the DateGroup chains will not affect the “balance” among the hypotheses at the moment of detecting the InvoiceDateHeader element, that is, the quality of each of the chains is multiplied further by 0.97. In the end, FlexiLayout Studio generated a single hypothesis for the Group element InvoiceRequisiteGroup, which corresponds to the best chain in the Group. Its quality is approximately 0.953, that is, the “group approach” helped the right hypothesis win, even though its initial quality was lower.

​

The tree of hypotheses without Group elements

To see how the tree of hypotheses would look without Group elements in the FlexiLayout, open the GroupSample.fsp project in the Group\Project2 folder. The tree is shown in the following figure. As is clear from the figure, after detecting the FormID element, the tree of hypotheses branched out because several hypotheses are generated for the InvoiceNumHeader element. As a result, FlexiLayout Studio has to compare the qualities of each of the chains, starting every time from its very first element and moving down to the last. Moreover, for any document with a layout more complex than the one in this example, a FlexiLayout without Group elements will produce a tree of hypotheses with too many branches, which will make FlexiLayout matching more difficult. In real-life tasks there is usually no need to explore all the possible combinations of every hypothesis for one element with every hypothesis for every other element, as most of the elements might be detected independently of one another. That is why you should group elements into the smallest possible Group elements, to reduce the number of combinations to analyze and speed up the search. Moreover, since the quality of the final chain is calculated by multiplying the qualities of all the hypotheses in that chain, the volume of calculations may be much higher in a tree with too many branches, which will result in slower FlexiLayout matching.