Skip to main content
Si toutes les hypothèses de la chaîne d’éléments dans l’élément Group ont une qualité égale à 1, les autres hypothèses de ces éléments ne seront pas analysées.
Cela permet d’optimiser le FlexiLayout, d’accélérer la procédure de mise en correspondance et d’éviter la « ramification » indésirable de l’arbre des hypothèses. Cependant, une hypothèse optimale pour FlexiLayout Studio ne correspond pas forcément à l’objet recherché dans l’image.Cela peut se produire si les contraintes de recherche de l’élément ne sont pas suffisamment strictes. Lorsqu’une telle situation se présente, analysez d’abord les paramètres définis pour la recherche de l’élément.

​
Le projet d’exemple GO.fsp

Prenons le projet GO.fsp (dossier %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\GO\1), dont l’objectif est de trouver le champ « Numéro de facture ». Le projet comporte deux pages :
  • Page 1 – La qualité de l’image est bonne.
  • Page 2 – Le nom du champ recherché est parasité.
Le projet contient le groupe InvoiceGroup, qui contient l’élément utilisé pour rechercher le nom du champ : un élément Static Text nommé InvoiceHeader avec la valeur « INVOICE ». Pour rechercher le champ « Numéro de facture » lui-même, le projet utilise un élément Character String nommé InvoiceNumber. Les contraintes de recherche du champ par rapport à son nom sont spécifiées dans la section Relations de l’élément InvoiceNumber.
La casse du nom dans la section Texte de recherche n’a pas d’importance.

​
Pourquoi la génération d’hypothèses s’arrête sur une chaîne de qualité 1

Notez que la chaîne « Invoice », spécifiée comme valeur de l’élément InvoiceHeader, apparaît trois fois sur les images : comme nom du champ Numéro de facture, comme sous-chaîne dans le nom Date de la facture, et en bas de la facture, comme sous-chaîne dans les conditions de paiement « Current invoice is… ». Vous pouvez donc prévoir qu’il y aura trois hypothèses après la procédure de mise en correspondance. Après avoir exécuté la procédure de mise en correspondance du FlexiLayout en sélectionnant la commande Associer, vous pouvez constater que l’arbre d’hypothèses dans l’élément Group InvoiceGroup ne comporte qu’une seule chaîne complète au lieu des trois attendues, et que cette unique chaîne ne correspond pas au nom détecté.
Capture d’écran de l’arbre d’hypothèses dans ABBYY FlexiLayout Studio pour le projet GO.fsp, montrant le groupe InvoiceGroup avec une seule chaîne complète de qualité 1 qui ne correspond pas au nom détecté.
Si vous examinez les propriétés de chacun des éléments de la chaîne générée, vous verrez que la Chain quality de chaque hypothèse est de 1, ce qui a déclenché l’optimisation : lorsque FlexiLayout Studio détecte une chaîne idéale du point de vue de la qualité (c’est-à-dire une chaîne de qualité 1), il cesse de générer des hypothèses.
Pour afficher l’arbre d’hypothèses du groupe, double-cliquez sur le nom de l’élément Group dans l’arbre d’hypothèses, appuyez sur Entrée ou sélectionnez Afficher les détails dans le menu contextuel.
L’algorithme de FlexiLayout Studio détermine quel objet de l’image est préféré aux autres lors de la génération d’hypothèses. Comme les résultats de la mise en correspondance du FlexiLayout ne sont pas satisfaisants, il faut analyser les causes du problème afin de déterminer comment le résoudre. Premièrement, la zone de recherche de l’élément InvoiceHeader n’est pas limitée. Deuxièmement, la description de l’élément InvoiceNumber indique que la chaîne de chiffres peut avoir une longueur quelconque (car la longueur possible du numéro de facture n’est pas connue). Elle précise également que la chaîne doit être recherchée à droite du nom, à peu près au même niveau horizontal. Comme vous pouvez le constater, les trois occurrences du mot « Invoice » répondent à ces conditions. C’est pourquoi la détection incorrecte du nom a automatiquement entraîné la détection incorrecte du champ Numéro de facture. Vous devez ajouter des contraintes supplémentaires afin que l’hypothèse correcte soit finalement la meilleure et que le FlexiLayout soit optimal, pas seulement en termes de vitesse de mise en correspondance.

​
Ancrer le nom au bord droit de la page avec Nearest

Si l’on suppose que la disposition des champs est identique sur toutes les pages du projet, le plus simple est de « dire » à FlexiLayout Studio que la chaîne requise « Invoice » est l’élément le plus proche du bord droit de la page. Pour cela, écrivez le code suivant dans la section relations avancées de pré-recherche de l’élément InvoiceHeader : Nearest: PageRight;. Cela fonctionne parce que l’intitulé du champ recherché « Numéro de facture » est le seul élément le plus proche du bord droit de la page. Si ce n’était pas le cas, ou si le document n’avait pas une structure fixe, la fonction Nearest ne pourrait pas résoudre le problème.

​
Pénaliser les hypothèses de nombres éloignés avec FuzzyQuality

D’autres façons d’effectuer cette tâche, y compris dans le cas d’un document semi-structuré, sont présentées dans le projet GO.fsp (dossier GO\2). Comme vous pouvez le voir sur les images, la distance entre la chaîne de chiffres et le mot “invoice” est la plus faible dans le champ recherché “Numéro de facture”. C’est le cas sur toutes les pages, ce qui permet d’influer sur les valeurs de qualité des hypothèses générées en saisissant le code suivant dans la section Advanced post-search relations de l’élément InvoiceNumber :
Cela signifie que si les deux éléments sont détectés, la distance entre eux est calculée pour l’hypothèse de l’élément InvoiceNumber, et FlexiLayout Studio vérifie si elle appartient à l’intervalle {0, 0, 0, 10000}*dt. Cette description de l’intervalle montre la dépendance linéaire entre la qualité de l’hypothèse et la distance entre les éléments : plus la distance est grande, plus la pénalité est élevée (la fonction FuzzyQuality renvoie la Post-search quality de l’hypothèse ; celle-ci est visible dans la fenêtre Properties de l’hypothèse). La valeur de la limite droite de l’intervalle (10000dt) a été déterminée expérimentalement. Lors du choix de cette valeur, vous devez tenir compte de la distance entre les objets correspondants sur les images de test. Comme le montre la figure suivante, avec les propriétés d’intervalle spécifiées, la pénalité maximale (1) correspondra à une distance de 10000dt. En conséquence, une distance de 1000dt entraînera une pénalité de 0.1, une distance de 100dt, une pénalité de 0.01, et ainsi de suite. Ainsi, pour des distances réelles d’environ 100 à 300 dots, visibles sur les images, le coefficient de pénalité sera de 0.99 à 0.97.
Diagramme de la courbe de pénalité FuzzyQuality, montrant la pénalité maximale de 1 à une distance de 10000dt, une pénalité de 0.1 à 1000dt et de 0.01 à 100dt.
Pour plus d’informations sur l’utilisation de ces fonctions, voir Rechercher des éléments avec Nearest et FuzzyQuality.
Pour les images de ce batch, l’hypothèse correspondant au champ indésirable “Numéro de facture” avec la valeur “2005” a reçu la pénalité maximale, tandis que l’hypothèse correspondant au champ recherché a reçu la pénalité minimale. Comme la pénalisation a rendu la Post-search quality de toutes les hypothèses différente de 1, toutes les hypothèses des deux éléments de l’élément Group InvoiceGroup seront désormais analysées. Notez que le champ “Numéro de facture” a été correctement détecté même sur la page 2, où le mot “Invoice” est très bruité, ce qui a provoqué une erreur de reconnaissance et, par conséquent, des pénalités supplémentaires pour l’hypothèse.
Capture d’écran des résultats de mise en correspondance FlexiLayout dans ABBYY FlexiLayout Studio après l’ajout de la pénalité FuzzyQuality, montrant que le champ Numéro de facture est correctement détecté même sur la page 2 bruitée.