Zum Hauptinhalt springen
Die Verwendung von Group-Elementen für die Suche nach Objekten ist am effizientesten, da das Gruppieren von Elementen die Anzahl der Hypothesen für ein Element reduziert und die Suche nach der resultierenden Hypothese für das gesamte FlexiLayout beschleunigt. Wenn die Gruppierung der Elemente außerdem die Logik des Dokuments widerspiegelt, trägt dies dazu bei, die Struktur des FlexiLayouts zu optimieren und klarer zu machen. Wenn mehrere Elemente zu einem Gruppenelement zusammengefasst werden, kann das Programm diese Elementmenge als Ganzes mit einer eigenen Hypothese behandeln (die sich aus den einzelnen Hypothesen für die Elemente in der Group zusammensetzt). Die Analyse der Hypothesen und ihrer Elemente erfolgt innerhalb des Gruppenelements, und nur die vom Benutzer angegebene Anzahl (standardmäßig 1) der besten Hypothesen wird bei der anschließenden Suche nach anderen Elementen verwendet. Der gesamte Elementbaum kann als ein Gruppenelement betrachtet werden, dessen beste Hypothese das Ergebnis des Matchings des FlexiLayouts ist. Sehen wir uns das Projekt GroupSample.fsp (Ordner %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Group\Project1) an, um zu sehen, wie Gruppenelemente verwendet werden können. Hier haben wir ein Bild, in dem wir Felder mit der Rechnungsnummer, dem Rechnungsdatum und dem Gesamtbetrag erkennen möchten. Wie auf dem Bild zu sehen ist (und das gilt in der Regel für alle Finanzdokumente), sind Nummer und Datum des Dokuments benachbarte Felder. Selbst wenn die Anordnung der Felder in einem anderen Dokument abweicht, liegen sie dennoch nahe beieinander. Darüber hinaus hängen sie durch die Logik des Dokuments zusammen, da sie bestimmte Bankangaben beschreiben und einen logischen Block bilden. Um die Struktur des FlexiLayouts klarer zu machen, fassen wir sie zu einem Gruppenelement mit dem Namen InvoiceRequisiteGroup zusammen.
Bevor wir die Elemente gruppierten, haben wir ein spezielles Bezeichnerelement erstellt. (Bezeichnerelemente werden ausführlich im Abschnitt „Identifizieren und Verarbeiten von FlexiLayouts in ABBYY FlexiCapture“ beschrieben.) Dieses Element wurde nur erstellt, um die „Verzweigung“ des Hypothesenbaums zu veranschaulichen, die durch das Vorhandensein oder Fehlen von Gruppenelementen verursacht wird. Nehmen wir an, dass alle Elemente im Baum mit Ausnahme des Bezeichnerelements optional sind und ihre Nullhypothesen die Standardqualität 0.97 haben.
Das erste Element in der Group ist ein Element vom Typ Static Text mit dem Namen InvoiceNumHeader, das die Suchbedingungen für den Namen des Felds „Rechnungsnummer“ beschreibt. Die string „Invoice“ ist als Wert dieses Elements angegeben. Auf Grundlage der Analyse der uns vorliegenden Bilder suchen wir rechts neben dem Namen nach der Rechnungsnummer, und zwar mithilfe eines Elements namens InvoiceNum. In ähnlicher Weise haben wir unter der Zeile mit der Rechnungsnummer ein Element für das Datumsfeld erstellt und es InvoiceDateHeader genannt. Um nach dem Datum selbst zu suchen, haben wir die Group DateGroup mit den folgenden Subelementen erstellt: InvoiceDate und InvoiceDateAsString. Weitere Details finden Sie unter Erstellen von FlexiLayouts für Bilder schlechter Qualität. Um das Feld mit dem Gesamtbetrag zu erkennen, haben wir zwei Elemente erstellt: ein Element vom Typ Static Text mit dem Namen TotalSumHeader (sein Wert „Totalsum(EUR):“ wird ohne Leerzeichen geschrieben) und ein Element vom Typ Character String mit dem Namen TotalSum (letzteres wird verwendet, um direkt nach dem Betrag zu suchen).
Die Einstellungen der Elemente werden hier nicht beschrieben. Sie können sie direkt im Projekt nachschlagen.
Bitte beachten Sie, dass die string „Invoice“, die als Wert des Elements InvoiceNumHeader angegeben ist, in den Testbildern dreimal vorkommen kann: als Name des Felds „Rechnungsnummer“, als Teilstring des Namens des Felds „Rechnungsdatum“ und unten auf der Rechnung als Teilstring in den Rechnungsbedingungen: „Current invoice is…“. Wichtig ist auch, dass der Name „INVOICE“ (den wir mithilfe des Elements InvoiceNumHeader erkennen wollen) stark verrauscht ist, was zu einem Fehler im Namen geführt hat. In den anderen Zeilen ist die string „Invoice“ deutlich, und die Qualität der entsprechenden Hypothesen muss höher sein als die der Hypothese für den Namen. Versuchen Sie nun, das FlexiLayout mit den Testbildern im Batch abzugleichen. Sobald Sie das FlexiLayout-Matching durch Auswahl des Befehls Match gestartet haben, sehen Sie, dass der Hypothesenbaum aus einer einzigen Kette besteht. Der Hypothesenbaum besteht nur aus einer einzigen Kette. Die Qualität der Group entspricht der Qualität der besten Kette in der Group. Doppelklicken Sie auf InvoiceRequisiteGroup, um das Dialogfeld „Eigenschaften“ zu öffnen. Dort können wir sehen, welche Hypothesen für die Subelemente erzeugt wurden, welche Kette in der Group die beste war und warum. Wir sehen, dass es für das Element InvoiceNumHeader drei Hypothesen gibt, entsprechend der Anzahl der erkannten „invoice“-strings. Die Qualität der Hypothese, die uns interessiert, ist niedriger (ungefähr 0,99), weil ihr Bereich im Bild verrauscht ist und das Programm nur „INVOIC“ statt „INVOICE“ erkennen konnte. Die Qualität der beiden anderen Hypothesen ist dagegen maximal (Chain quality = 1). Bei der Erstellung des Elements InvoiceNum haben wir angegeben, dass die Rechnungsnummer aus beliebig vielen Ziffern bestehen kann und rechts vom Namen gesucht werden soll. In unserem Bild sind diese Bedingungen in allen drei Fällen erfüllt, sodass das Programm für jede Hypothese für den Namen des Felds „Invoice number“ eine Kette von Hypothesen weiter aufbauen konnte. Es ist zu beachten, dass die Kette, die wir für korrekt halten, trotzdem die schlechteste ist, obwohl die Pre-search quality jeder Hypothese des Elements InvoiceNum 1 beträgt. Das liegt daran, dass die Chain quality durch Multiplikation der Qualität aller Hypothesen bestimmt wird, aus denen die Kette besteht. Für den erforderlichen Namen beträgt diese Qualität etwa 0,99. Hätte die Group keine weiteren Elemente, wäre die endgültige Auswahl in dieser Phase falsch.
Wir haben für keines der Elemente Post-search relations angegeben, daher gilt für jedes Element Post-search quality = 1, und wir können die Qualität einer beliebigen Hypothese anhand ihrer Pre-search quality beurteilen.
Die Suche nach der besten Hypothese erfolgt innerhalb der Group. Die Qualität aller Ketten wird analysiert und verglichen. Die Qualität der Group wird durch die Qualität der besten Kette in der Group bestimmt. Wie wir oben erwähnt haben, haben wir in den Eigenschaften des Elements InvoiceDateHeader angegeben, dass es unter der Zeile mit der Rechnungsnummer gesucht werden soll. Keine der Ketten mit der besten Qualität (Chain quality = 1) ergab jedoch eine Hypothese für den Namen des Datumsfelds. Folglich wurden in diesen Ketten Nullhypothesen für das Element InvoiceDateHeader gebildet. Da wir die Standardqualität einer Nullhypothese nicht geändert haben, sank die resultierende Chain quality der entsprechenden Ketten auf 0,97. Gleichzeitig wurde das Element, das dem Namen des Datumsfelds entspricht, in der Kette gefunden, die die niedrigste Qualität hatte. Die Qualität seiner Hypothese beträgt ungefähr 0,993. Sie ist kleiner als 1, weil das Bild im Bereich des Namens verrauscht ist, was zu einem Erkennungsfehler und zu einer unvollständigen Übereinstimmung zwischen dem erkannten Text und dem in den Eigenschaften des Elements InvoiceDateHeader angegebenen Wert führte. Dadurch wurde die gefundene Hypothese abgewertet, und ihre endgültige Qualität beträgt etwa 0,98 (das Ergebnis der Multiplikation von 0,99 mit 0,993). Dennoch ist die endgültige Qualität dieser Hypothese höher als die der anderen (0,97), sodass diese Kette in dieser Phase die beste ist. Um das Datumsfeld zu erkennen, haben wir das Gruppenelement DateGroup erstellt, das festlegt, dass mindestens eines der Elemente nicht gefunden werden darf, wenn das andere gefunden wurde (dazu wurde die Funktion Dontfind verwendet). Aufgrund der Besonderheiten des Dokumentlayouts und der für das Element InvoiceDateAsString angegebenen Eigenschaften (sein alphabet erlaubt Ziffern) konnte das Programm das Datumsfeld in allen Ketten finden, obwohl tatsächlich nur eine der drei Hypothesen korrekt ist. Da in jeder Group eines der Elemente gefunden wurde, während das andere nicht gefunden wurde, beträgt die endgültige Qualität der Kette in jeder der DateGroup-Groups 0,97 (1 multipliziert mit 0,97, der Standardqualität der Nullhypothese). In diesem Beispiel wirkt sich die endgültige Qualität der DateGroup-Ketten nicht auf das „Gleichgewicht“ zwischen den Hypothesen bei der Erkennung des Elements InvoiceDateHeader aus, d. h., die Qualität jeder Kette wird einfach noch mit 0,97 multipliziert. Am Ende erzeugte das Programm eine einzelne Hypothese für das Gruppenelement InvoiceRequisiteGroup, die der besten Kette in der Group entspricht. Ihre Qualität beträgt ungefähr 0,953, d. h., der „Group-Ansatz“ sorgte dafür, dass sich die richtige Hypothese durchsetzte, obwohl ihre anfängliche Qualität niedriger war. Um zu veranschaulichen, wie der Hypothesenbaum ohne Gruppenelemente im FlexiLayout aussehen würde, haben wir das Projekt GroupSample.fsp (Ordner Group\Project2) erstellt. Der Baum ist in der folgenden Abbildung dargestellt. Wie aus der Abbildung ersichtlich ist, verzweigt sich der Hypothesenbaum nach der Erkennung des Elements FormID, weil für das Element InvoiceNumHeader mehrere Hypothesen erzeugt werden. Daher muss das Programm die Qualität jeder einzelnen Kette vergleichen, wobei es jedes Mal beim allerersten Element beginnt und bis zum letzten nach unten geht. Außerdem erzeugt ein FlexiLayout ohne Gruppenelemente bei jedem Dokument mit einem komplexeren Layout als in diesem Beispiel einen Hypothesenbaum mit zu vielen Verzweigungen, was das FlexiLayout-Matching erschwert.
Es ist nicht empfehlenswert, alle gesuchten Elemente in einer einzigen Wurzelgruppe zu platzieren. Das eignet sich nur für sehr einfache FlexiLayouts mit weniger als 10 Elementen, was bei realen Aufgaben nur sehr selten vorkommt. Wenn die Anzahl der Elemente in der Wurzelgruppe steigt, wächst auch die Anzahl der Hypothesen stark an, bis entweder das Limit von 10.000 erreicht ist oder der für den Hypothesenbaum zugewiesene Speicher vollständig aufgebraucht ist. In beiden Fällen kann das Matching des FlexiLayouts fehlschlagen.
Bei realen Aufgaben ist es in der Regel nicht nötig, alle möglichen Kombinationen jeder Hypothese eines Elements mit jeder Hypothese jedes anderen Elements zu untersuchen, da die meisten Elemente unabhängig voneinander erkannt werden können. Deshalb empfiehlt es sich, Elemente in möglichst kleine Gruppenelemente zu gruppieren, um die Anzahl der zu analysierenden Kombinationen zu verringern und die Suche zu beschleunigen. Ein nicht gruppierter Hypothesenbaum hat zu viele Verzweigungen, und seine visuelle Analyse ist schwierig. Da die Qualität der endgültigen Kette außerdem durch Multiplikation der Qualitäten aller Hypothesen in dieser Kette berechnet wird, kann der Rechenaufwand in einem Baum mit zu vielen Verzweigungen deutlich höher sein, was das FlexiLayout-Matching verlangsamt.