Salut,Je suis un novice de la plate-forme Alfresco...

[zomurn]

Bonjour,

Je viens de tester le petit utilitaire que tu cites : tesseract-ocr et le résultat est très correcte.
En fait, j'ai effectué la chaîne de transformation suivante :

1) Je scan ma facture EDF en format .tiff (seul format reconnu par l'utilitaire ; malheureusement il est très volumineux)
2) Via l'API Java Jai, je crop l'image tiff d'entrée pour générer une image tiff de sortie qui ne contient que la zone que je cherche à OCRiser
3) Via le programme Java, je lance le programme  tesseract-ocr avec en input l'image tiff croppée.
4) J'obtiens en output un fichier texte contenant par ex. le montant total TTC.

Maintenant je m'intéresse à la robustesse de l'algorithme : c'est à dire, une valeur seuil que je calcule et m'indiquera si oui ou non le scan est correct pour OCRisation de la facture.
Cela veut dire que je m'attends toujours au même modèle de facture d'entrée (coordonnée de la zone d'extraction en dur dans le code) et que le scan soit fait correctement (la feuille mise bien à plat dans le scanner), que les plis éventuels de la feuille nuisent pas à la qualité de l'OCR, que l'orientation de la feuille ne soit pas trop inclinée (normalement non si on la cale bien dans l'angle dans le scanner), etc…

A la suite de quoi, je pense qu'il est possible de générer le modèle de métadonnée à la volée après intégration de la facture dans Alfresco.

Merci.

[dranakan]

Hello,

Chapeau, tu n'as pas chômé…

>>Je scan ma facture EDF en format .tiff (seul format reconnu par l'utilitaire ; malheureusement il est très volumineux)
Bon, tu peux scanner en PDF, puis changer le format avec ImageMagick. Tu peux aussi découper la forme avant la conversion pour économiser place/temps…

L'idéal serait de pouvoir gérer les positions avec un utilitaire en ligne (à créer) dans Alfresco.
Par exemple, si la forme de la facture change, il serait judicieux d'entrer dans un programme, positionner un rectangle (sur le champ que l'on désire extraire) puis sauver ce modèle (qui communiquera les bonnes positions des champs lors de l'extraction).

Cela devrait être utilisable par un employé de bureau. Comme ça, s'il y a une nouvelle facture à extraire (d'un nouveau fournisseur) ou une facture change de forme, la personne responsable créée le modèle d'extraction et les champs sont traités…
Il faudrait reconnaître les modèles (d'après le nom, num. téléphone…)

Enfin… ce ne sont que des idées… et beaucoup de temps à développer…

[zomurn]

Bonjour,

Bon, tant qu'on est sur le sujet, voici le fruit de mon travail des dernières études (les dév sont en cours).
En fait pour gérer les nouvelles factures ou bien la modification de celles existantes, cela passera par une demande au développeur.
Je pense qu'il vaut mieux, il en va de la qualité de l'OCR….du moins surtout s'il y a peu de factures différentes à intégrer.
De plus, il sera toujours temps de "migrer" vers une belle applet où on défini des zones rectangulaires sur une image (en début de projet, cela est coûteux en temps et n'est pas ce qu'attend le client, mais plutôt une "démo" d'un truc qui montre que l'OCR marche.)
en ce qui concerne la robustesse, j'ai ajouté quelques paramètres.
Plus globalement, j'ai carrément défini un fichier de template XML qui correspond à la config de l'OCR pour une seule facture.
Donc un fichier de conf ocr XML par factures différentes.
Voici un exemple de définition de mon Shema XML :

<?xml version="1.0" encoding="UTF-8"?>
<ns:ocr xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:ns="http://www.intuitiv.fr/OCRSchema" xsi:schemaLocation="http://www.intuitiv.fr/OCRSchema ocr.xsd"
   ns:name="OCR EDF 300DPI BW">
   
   <!–   Montant total TTC–>
   <ns:area ns:name="Montant total TTC" ns:type="numeric">
      <ns:rect ns:xmin="1" ns:ymin="1" ns:width="1" ns:height="1" />
      <ns:threshold ns:bin="0" ns:band="0">
         <ns:fixed ns:value="11000" ns:tolerance="10" />
      </ns:threshold>
   </ns:area>
</ns:ocr>‍‍‍‍‍‍‍‍‍‍‍‍‍

- Le tag "ocr" est le tag racine avec un seul attribut "name" qui revèle l'intitulé du template ocr (spécifique à une facture, ici une facture d'EDF scannée en 300DPI noir et blanc : c'est ce à quoi est adapté ce fichier de conf !)
Ensuite, la balise "ocr" contient une ou plusieurs balises "area" qui sont ni plus ni moins des zones rectangulaires à définir et qui peuvent contenir une valeur seuil ("threshold"). Ici la valeur seuil est de 11000 avec une tolérance de + ou - 10%. Cela veut dire que le nombre de pixel noir est d'environ 11000 dans cette zone et si à 10% près cela n'est pas respecté, cela signifie que le scan est mauvais ou bien qu'il ne s'agit pas d'une facture EDF 300DPI NB TIFF Compréssé.
Un tag "area" peut être de 3 types pour aider l'OCR : numeric (une zone qui contient que des chiffres, il s'agit d'un argument de valeur pour tesseract), alphanumeric (peut contenir tout et n'importe quoi), identity (une telle area veut dire que si cette zone n'a pas été validé suite à la valeur seuil spécifiée alors l'OCR est refusé de manière certaine : il ne s'agit pas d'une facture EDF). En général, je pense définir la zone du logo "EDF" comme zone de type "identity".
Par extension, grâce à la zone de type identity , je serai capable de déterminer la facture que l'on scan (EDF, GDF, FT, etc.)

….voilà pour les ébauches "théoriques" .