[..] automatisation TN3270 et OCR

[Autonoob]

Bonjour,

En fait à la base je cherchais à automatiser une interface TN3270 mais vu ce que j'ai trouvé sur le forum UK ce n'est pas vraiment possible avec mon niveau. (http://www.autoitscript.com/forum/topic ... ntry455611)

Par contre je me penche sur les solutions OCR et je cherche à trouver un moyen de faire "lire" le contenu d'une fenetre 3270 (ressemble à une fenetre DOS) pour l'interpreter et la traiter.

http://www.autoitscript.com/forum/topic ... n-ocr-udf/

Est-ce que quelqu'un à réussi à faire de l'OCR avec des soft ouvert type tesseract comme ci-dessus ?? j'ai chargé le soft qui fonctionne avec leur image test mais pas avec autre chose

[Autonoob]

Bon a priori tesseract ne pourrait reconnaitre que des fichier en niveau de gris.........ça sent le problème insolvable

[Zippo]

Je n'ai pas de réponse à ta question malheureusement, en même temps je ne connais pas l'automatisation de TN3270 et OCR.
Mais chaque problème à une solution ou quelque chose qui s'y rapproche, perd pas patience

[jchd]

Insoluble, certainement pas.
J'ai développé un module OCR en AutoIt spécialisé pour mes besoins. Il est spécialisé en ce sens qu'il ne fait pas véritablement de reconnaisssance de glyphes à proprement parler, mais seulement une détermination de caractères déjà répertoriés. Pour chaque combinaison de caractère, fonte, style, il passe donc par une phase d'apprentissage au cours de laquelle un opérateur précise, pour chaque forme inconnue, le caractère présenté dans un petit dialogue.
Je stocke les caractères reconnus dans une base de données SQLite, que je charge en mémoire au début de chaque utilisation.
Le principe convient très bien pour des caractères type terminal 3270, dont la variété de mise en forme est limitée. Il ne fonctionnerait pas pour des jeux italique dont les limites de caractères se recouvrent dans bien des cas, c'est-à-dire lorsque les caractères individuels ne s'inscrivent pas dans une boîte rectangulaire mais un parallélogramme (e.g. fa où la boîte du f empiète sur la boîte du a). Il n'y a pas de problème à traiter des polices en taille fixe (Courrier New) ou proportionnelle (Arial).
Un compteur d'utilisation de chaque forme permet d'optimiser la recherche en fonction de la fréquence d'occurence. Une autre optimisation permet de ne comparer que le début des caractères (lignes verticales de gauche) jusqu'à la fin de l'éventuelle ambiguïté : un A et un  ont des premières lignes verticales communes en partant de la gauche, mais le soft identifie le bon caractère dès que possible. Mon implémentation fonctionne avec du graphique en niveaux de RGB.

L'implémentation actuelle repose sur l'exploitation d'un texte "bitmap" ne comprenant qu'une ligne (une bande graphique horizontale) où tous les caractères sont sur la même ligne de base (de préférence), mais c'est plus un choix du découpage de l'image, d'efficacité et de simplicité de réalisation qu'une limitation de principe.

Ce "machin" est raisonnablement efficace et, si l'apprentissage a été correctement fait (ce qui n'est vraiment pas compliqué) s'avère parfaitement utilisable "au vol". Seule chose à comprendre avant une utilisation tête baissée des résultats : certaines polices sont elle-mêmes ambigües, par exemple le l et le I en Arial, etc.

L'implémentation que j'emploie est difficile à extraire proprement pour en faire une UDF générique du fait d'autres complications spécifiques à mon cas de figure.

Tout ceci dit, je ne sais pas si tu ne pourrais pas plutôt utiliser une version scriptable d'un TN3270.

[overflow]

tu a un screen de ce que tu essaye de lire ?