Zum Hauptinhalt springen
Wenn alle Hypothesen der Elementkette im Gruppenelement (Group) den Quality-Wert 1 haben, werden die übrigen Hypothesen dieser Elemente nicht analysiert.
Dies geschieht, um das FlexiLayout zu optimieren, das Matching-Verfahren zu beschleunigen und eine unerwünschte „Verzweigung“ des Hypothesenbaums zu vermeiden. Eine Hypothese, die für das Programm optimal ist, entspricht jedoch nicht unbedingt dem im Bild gesuchten Objekt. Das kann passieren, wenn die Suchbedingungen für das Element nicht streng genug sind. Wenn eine solche Situation eintritt, sollten Sie daher zuerst die für die Elementsuche festgelegten Parameter analysieren.
Betrachten wir das Projekt GO.fsp (Ordner %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\GO\1), in dem wir nach dem Feld „Rechnungsnummer“ suchen. Das Projekt hat 2 Seiten:
  • Seite 1 – die Bildqualität ist gut;
  • Seite 2 – der Name des gesuchten Feldes ist verrauscht.
Wir haben die Gruppe InvoiceGroup erstellt, die das Element enthält, mit dem nach dem Feldnamen gesucht wird. Es handelt sich um ein Element vom Typ Static Text mit dem Namen InvoiceHeader und dem Wert „INVOICE“. Um nach dem Feld „Rechnungsnummer“ selbst zu suchen, haben wir ein Element vom Typ Zeichenkette mit dem Namen InvoiceNumber erstellt. Die Suchbedingungen für die Suche nach dem Datumsfeld relativ zum Namen haben wir im Abschnitt Relations des Elements InvoiceNumber angegeben.
Die Groß-/Kleinschreibung des Namens im Abschnitt Search text spielt keine Rolle.
Beachten Sie, dass die Zeichenfolge „Invoice“, die als Wert für das Element InvoiceHeader angegeben ist, in den Bildern dreimal vorkommt: als Name des Feldes „Rechnungsnummer“, als Teilzeichenfolge im Namen „Rechnungsdatum“ und unten auf der Rechnung als Teilzeichenfolge in den Zahlungsbedingungen „Current invoice is…“. Daher können wir vorhersagen, dass es nach dem Matching-Verfahren drei Hypothesen geben wird. Nach dem Ausführen des FlexiLayout-Matching-Verfahrens durch Auswahl des Befehls Match sehen wir, dass der Hypothesenbaum in der Gruppe InvoiceGroup statt der erwarteten drei nur eine vollständige Kette hat, und diese verbleibende vollständige Hypothesenkette entspricht nicht dem Namen, den wir zu erkennen versuchen. Wenn Sie sich die Eigenschaften jedes Elements in der erzeugten Kette ansehen, werden Sie feststellen, dass die Chain quality jeder Hypothese 1 ist. Dadurch wurde die Optimierung ausgelöst: Wenn das Programm eine ideale Kette in Bezug auf die Quality erkennt (d. h. mit der Quality 1), stellt es die Erzeugung von Hypothesen ein.
Um den Hypothesenbaum der Gruppe anzuzeigen, doppelklicken Sie im Hypothesenbaum auf den Namen des Gruppenelements, drücken Sie Enter oder wählen Sie im Kontextmenü Show Details aus.
Welches Bildobjekt in der Phase der Hypothesengenerierung gegenüber den anderen bevorzugt wird, bestimmt der Algorithmus des Programms. Da die Ergebnisse des Matchings des FlexiLayout unbefriedigend sind, sollten wir die Ursachen des Problems analysieren und entscheiden, wie es gelöst werden kann. Erstens haben wir den Suchbereich für das Element InvoiceHeader nicht eingeschränkt. Zweitens haben wir bei der Beschreibung des Elements InvoiceNumber angegeben, dass die Ziffernfolge beliebig lang sein kann (weil wir die mögliche Länge der Rechnungsnummer nicht kennen). Außerdem haben wir angegeben, dass sie rechts vom Namen und ungefähr auf derselben horizontalen Ebene gesucht werden soll. Wie Sie sehen, erfüllen alle drei Vorkommen des Wortes „Invoice“ diese Bedingungen. Deshalb führte die falsche Erkennung des Namens automatisch zur falschen Erkennung des Feldes „Rechnungsnummer“. Sie müssen daher einige einschränkende Bedingungen hinzufügen, damit am Ende die richtige Hypothese die beste ist und das FlexiLayout nicht nur hinsichtlich der Matching-Geschwindigkeit optimal ist.” Wenn wir annehmen, dass die Anordnung der Felder auf allen Seiten des Projekts identisch ist, ist es am einfachsten, dem Programm „mitzuteilen“, dass wir die Zeichenfolge „Invoice“ benötigen, die dem rechten Seitenrand am nächsten liegt. Daher schreiben wir den folgenden Code in den Abschnitt Advanced pre-search relations des Elements InvoiceHeader: Nearest: PageRight;. Das können wir tun, weil die Bezeichnung des gesuchten Felds „Rechnungsnummer“ das einzige Element ist, das dem rechten Seitenrand am nächsten liegt. Wäre das nicht so oder wäre das Dokument nicht formalisiert, könnte uns die Funktion Nearest bei der Lösung des Problems nicht helfen. Um alternative Möglichkeiten zur Lösung dieser Aufgabe zu zeigen, einschließlich des Falls mit einem semi-strukturierten Dokument, haben wir das Projekt GO.fsp (Ordner GO\2) erstellt. Wie Sie auf den Bildern sehen können, ist der Abstand zwischen der Ziffernfolge und dem Wort „invoice“ im gesuchten Feld „Rechnungsnummer“ am geringsten. Das gilt auf allen Seiten, wodurch wir die Quality-Werte der erzeugten Hypothesen beeinflussen können, indem wir den folgenden Code im Abschnitt Erweiterte Nach-Suchbeziehungen des Elements InvoiceNumber eingeben: if (not InvoiceHeader.IsNull) and (not IsNull) then { FuzzyQuality: Rect.Left - InvoiceHeader.Rect.Right, {0, 0, 0, 10000}*dt; } Das bedeutet, dass, wenn beide Elemente erkannt werden, für die Hypothese des Elements InvoiceNumber der Abstand zwischen den Elementen berechnet wird und das Programm prüft, ob er in das Intervall {0, 0, 0, 10000}*dt fällt. Diese Beschreibung des Intervalls zeigt die lineare Abhängigkeit zwischen der Quality der Hypothese und dem Abstand zwischen den Elementen – je größer der Abstand, desto höher die Abwertung (die Funktion FuzzyQuality stellt die Post-search quality der Hypothese wieder her – sie ist im Eigenschaftenfenster der Hypothese zu sehen). Der Wert für die rechte Grenze des Intervalls (10000dt) wurde experimentell ermittelt. Bei der Wahl dieses Werts sollten Sie den Abstand zwischen den entsprechenden Objekten auf Testbildern berücksichtigen. Wie aus der Abbildung unten hervorgeht, entspricht bei den angegebenen Intervalleigenschaften die maximale Abwertung (1) einem Abstand von 10000dt. Entsprechend führt ein Abstand von 1000dt zu einer Abwertung von 0.1, ein Abstand von 100dt zu einer Abwertung von 0.01 usw. Bei realen Abständen von etwa 100–300 Dot, wie wir sie auf unseren Bildern sehen können, beträgt der Abwertungskoeffizient also 0.99–0.97.
Siehe Verwendung von Nearest und FuzzyQuality zum Suchen nach Elementen für weitere Details zur Verwendung dieser Funktionen.
Für die Bilder in diesem Batch erhielt die Hypothese, die dem unerwünschten Feld „Rechnungsnummer“ mit dem Wert „2005“ entspricht, die maximale Abwertung, während die Hypothese für das gesuchte Feld die minimale Abwertung erhielt. Da die Abwertung dazu führte, dass die Post-search quality aller Hypothesen nicht mehr 1 ist, werden nun alle Hypothesen beider Elemente des Gruppenelements InvoiceGroup analysiert. Beachten Sie, dass das Feld „Rechnungsnummer“ sogar auf Seite 2 korrekt erkannt wurde, wo die Bezeichnung „Invoice“ stark verrauscht ist, was einen Erkennungsfehler und folglich zusätzliche Abwertungen für die Hypothese verursachte.