Pour les francophones, en voici une synthèse, l'article étant plus complet (avec à la clé, graphiques de comparaison et copies d'écran de chaque produit testé).
Les tests ont porté sur la phrase "The quick brown Métis jumped over the fluffy Finance Manager" permettant de tester quelques pièges classiques pour la reconnaissance, ainsi que les accents, le tout décliné :
- en différentes polices, de différentes tailles
- avec des scans en noir et blanc ainsi que nuances de gris
- le tout à différentes résolutions (ce qui entre en ligne de compte plus qu'on ne pourrait le croire)
Clara OCR et OCRE lui ont semblé encore inutilisables.
OCRAD obtient 97%, mais semble incapable de reconnaître les accents.
Tesseract (logiciel libéré par HP en 2006) obtient 99%, en n'ayant échoué que sur les accents.
Ocropus utilise Tesseract et obtient le même résultat. Ses fonctionnalités à venir et le support de Google font qu'il est le plus prometteur.
"Pour le fun", il a aussi essayé la version de démonstration d'un OCR commercial pour Linux : Aspire OCR. Il obtient 91% .
Aller plus loin
- Analyse par Austin Aucton (168 clics)
- Ocropus (190 clics)
- GOCR (350 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mise-en-page
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Peut-être que les outils ne sont pas encore prêt pour faire gagner suffisament de temps. Je me souviens d'une démonstration d'un logiciel de reconnaissance vocale pour Windows Vista. Le testeur a passé son 20x plus de temps à corriger qu'à taper (en même temps, quelle idée de coder en Perl, faut être maso).
[^] # Re: mise-en-page
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
A c'était le bon temps ....
[^] # Re: mise-en-page
Posté par BAud (site web personnel) . Évalué à 3.
http://cookerspot.tuxfamily.org/wikka.php?wakka=Reconnaissan(...)
J'ai particulièrement galéré au début avec la config du micro que j'en ai fait une page spécifique et un petit outil de diagnostic (qui pourra servir pour ekiga et openwengo d'ailleurs). http://cookerspot.tuxfamily.org/wikka.php?wakka=Reconnaissan(...)
Maintenant que Java va être bientôt libre, cmusphinx sera sans doute mieux intégré dans les distros et on verra peut-être apparaître ce qu'on a pu voir pour la synthèse vocale avec espeak qui prend bien en compte le français (pour un truc encore en test...) : http://cookerspot.tuxfamily.org/wikka.php?wakka=SyntheseVoca(...)
Si certains s'y mettent, qu'ils n'hésitent pas à faire des retours directement sur ce wiki (faut juste s'inscrire et savoir que tout le contenu est sous quadruple licence libre : http://cookerspot.tuxfamily.org/wikka.php?wakka=WikiLicense ).
Je ferai sans doute un article quand j'aurai un peu plus creusé le sujet (parce que bon là, les tests avec de la reconnaissance de la parole en anglais, mon accent ne doit pas être probant :/).
[^] # Re: mise-en-page
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Je n'ai jamais entendu parlé non plus d'une suite à cette libération. C'est bien dommage !
Des tas de travaux universitaires sont archivés dans des locaux poussiéreux. Imaginons la même synergie que celle de wikipedia pour l'OCR et pour la reconnaissance de la parole... On peut rêver !
[^] # Re: mise-en-page
Posté par BAud (site web personnel) . Évalué à 7.
- reconnaissance de caractère :
° google a un projet en cours pour le scan de textes, ne stocker que le texte et non les scan permettra des économies de place et des réutilisations bien pratiques (recherches dans le contenu, rééditions éventuellement, possibilité d'accessibilité aux anciens textes pour les aveugles avec la synthèse vocale...)
° pour tout ce qui est gestion d'archivage, le fait de scanner permet d'économiser la place de stockage du papier, le fait d'utiliser l'OCR permet d'ajouter de l'aide au tri par exemple (j'ai en tête ce que fait free mais d'autres doivent utiliser les mêmes "idées")
- reconnaissance vocale : disons plutôt reconnaissance de la parole (vocale c'est pour reconnaître/identifier le locuteur, bref),
° cela sert pour les dictées de texte, par exemple lors d'expertises médico-légales ou lors d'opérations (un peu comme dans les experts / NCIS / Scully dans X-files...) sachant qu'une secrétaire repasse derrière pour archiver le relevé de ce qui a été fait. A priori, il y a apprentissage du logiciel de reconnaissance (vu qu'il dispose de beaucoup d'échantillons de la même voix et du texte correspondant corrigé...).
° cela sert pour faire le kéké à ouvrir son navigateur automatiquement quand on dit "Ouvre navigateur web" (mais là c'est du mono-locuteur, c'est plus facile)
° cela sert pour la reconnaissance des tonalités envoyées à ta messagerie vocale sur ton mobile (BouygTel avait sorti ce service au siècle dernier...) et reconnaître un vocabulaire limité (des chiffres) ou des choix de menu (sans trop d'équivoque). Demain, cela permettra de ne plus quitter le volant en voiture pour passer au CD suivant et chercher une chanson...
[^] # Re: mise-en-page
Posté par Frédéric COIFFIER . Évalué à 1.
[^] # Re: mise-en-page
Posté par kemar . Évalué à 2.
[^] # Re: mise-en-page
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Imaginez la maîtresse d'école qui raconte Ali Baba aux enfants et essaie de leur faire imaginer le merveilleux derrière le mythique "Sésame, ouvre-toi".
Alors, l'un des bambins va lui dire : " Mais madame, le voleur est idiot, il aurait dû prendre un système mono-locuteur au lieu d'un système multi-locuteur !".
Bref, le merveilleux disparaît et les instituteurs n'ont plus qu'à se recycler. Au fait, j'ai surpris mon épouse, institutrice, en train de faire faire le train à vapeur aux enfants. La dernière locomotive à vapeur avait été retirée de la région des années plus tôt.
O Tempora, O Mores!
[^] # Re: mise-en-page
Posté par M . Évalué à 2.
Je reve, on ne parle pas des projet libre d'ocr de texte dans le domaine publique. J'aurais cru pourtant qu'on était sur linuxfr.
reconnaissance vocale : disons plutôt reconnaissance de la parole (vocale c'est pour reconnaître/identifier le locuteur, bref),
Aussi les carkit
[^] # Re: mise-en-page
Posté par BAud (site web personnel) . Évalué à 2.
donc il y a le projet Gutenberg http://www.gutenberg.org dont j'ai retrouvé un petit historique http://translatio.ens.fr/miroir-nef/dossiers/gutenberg_fr.ht(...) et La bibliothèque Classiques Sciences Sociales https://linuxfr.org/2005/10/05/19677.html
tu en voyais d'autres ? ça me permettra de les ajouter en bas de http://wiki.eagle-usb.org/wakka.php?wiki=SemantiqueEtLangue
# Très peu significatif
Posté par nimnim . Évalué à 3.
Dans la vraie vie on fait de la ROC sur des documents que l'on n'a pas en version électronique, qui sont passés par X fax/copieurs, ont des taches/marques/plis, ont été posés de travers à l'une des étapes, etc
De même déduire le support du Français à partir de la reconnaissance d'une lettre accentuée... MDR
Quand à faire de l'analyse de mise en page... si déjà on était capable de récupérer le texte de base proprement. Une analyse de mise en page partielle fait plus de travail que reformatter du simple texte manuellement.
[^] # Re: Très peu significatif
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Austin Acton est aussi un passionné de musique. J'espère qu'il nous fera un ONR (Optical Notes Recognization) pour transformer une partition en code lilypond ;-)
Son site est http://groundstate.ca/austin . J'ai aussi quelques photos de lui devant son ordinateur comme http://pjarillon.free.fr/docs/RMLL2004/Austin-Acton.jpg
[^] # Re: Très peu significatif
Posté par nimnim . Évalué à 5.
Cela n'empêche pas le test de ne pas être significatif. Comme beaucoup de débutants (ce qu'Austin écrit clairement) l'auteur se laisse séduire par un test synthétique simple et extrapole des résultats qu'il n'aura pas dans une utilisation réelle.
La simple vérité c'est que la ROC a été un échec commercial parce qu'elle n'était pas fiable (ce qui a conduit par exemple HP à abandonner puis libérer le moteur qui est devenu OCRopus). Les gros projets de numérisation mettent en ½uvre des moyens humains (correcteurs) et matériels (numériseurs performants) bien supérieurs à ce qu'un particulier peut trouver acceptable en temps ou en argent. Les petits projets de numérisation... je cherche mais je n'en vois pas.
La ROC reste un gadget que les PME achètent avant de constater qu'elle n'est pas assez fiable pour leur être de la moindre utilité en pratique. (et ce n'est pas un problème de capteur, si on peur mettre des capteurs couleur dans les téléphones ça fait longtemps qu'on pourrait diffuser les capteurs N&B nécessaires à la ROC si les logiciels voulaient bien suivre)
En outre, l'essentiel des développements a été concentré sur l'anglais, donc dès qu'on s'éloigne du latin non accentué les résultats déjà pas terribles se dégradent fortement (témoin ce test simpliste où un seul moteur reconnaissait le é. Et ce en l'absence de traces ou même d'autres lettres accentuées qui auraient pu le perturber).
C'est triste mais les disciplines de traitement du langage naturel ont bénéficié depuis des années d'un traitement privilégié dans les universités et autres instituts informatiques, sans jamais donner de résultats à la hauteur de l'investissement.
ROC, reconnaissance vocale, traduction automatique, la liste des casseroles est longue. Les ordinateurs n'ont pas les mêmes points forts que les êtres humains.
Tout au plus arrive-t-on aujourd'hui à déchiffrer codes postaux et plaques d'immatriculation de manière à peu près fiable (à peu près, témoins les tracteurs qui ont reçu des contraventions autoroutières quand les radars automatiques ont été déployés)
Un ONR marchera sans doute beaucoup mieux - les notations musicales présentent beaucoup moins de variabilité qu'un texte libre.
[^] # Re: Très peu significatif
Posté par BAud (site web personnel) . Évalué à 2.
Les correcteurs orthographiques ou de grammaire ? Un humain repasse derrière, ce qui permet de lui mettre en évidence certaines fautes (pas toutes effectivement).
Il ne faudrait pas confondre l'objectif de la recherche, qui trouve les moyens de réaliser une solution ou fait des propositions, charge à d'autres d'implémenter, charge à d'autres d'industrialiser, charge à d'autre d'exploiter...
Clairement, l'ordinateur en tant qu'outil montre son utilité, en tant qu'intelligence indépendante il est encore un bébé (avec une très grande mémoire exacte quand même...).
De ce que j'en ai vu, la reconnaissance de caractère (ou de la parole) peuvent utiliser beaucoup d'heuristiques basées sur les probabilité d'avoir des lettres proches les unes des autres (ou des sons), donc bon ça demande un travail non négligeable (pour les di-plet, triplets, quadri-plets...) langue par langue.
[^] # Re: Très peu significatif
Posté par Jak . Évalué à 2.
Ce n'était pas une erreur de lecture, le système lisait correctement les plaques, mais les forces de l'ordre ont repéré, grâce à ce type d'erreurs, un trafic de plaques d'immatriculation. Cela dit, comme la plaque d'immatriculation d'un véhicule agricole n'a pas le même format que les autres véhicules, il est aussi possible que ce soit à la lecture d'une plaque étrangère que ça ait foiré.
[^] # Re: Très peu significatif
Posté par Laurent Morel . Évalué à 2.
Le problème de la ROC est complexe, certes, et a mis des années à progresser. Mais aujourd'hui on peut dire que la reconnaissance des caractères imprimées est fiable -- pour un document de qualité bien évidemment, ce qui n'est pas toujours le cas, et jamais à 100%. Essaie un jour un logiciel comme abbyy fineReader, tu constateras des performances très bonnes, bien supérieures à celles de l'ancien logiciel hp aujourd'hui libéré.
Maintenant il est clair que je ne vois pas trop l'usage qu'on peut faire de la ROC dans un bureau de PME : scanner des pages manuellement n'est pas pensable ; les gains n'apparaissent qu'en automatisant toute la numérisation/reconnaissance, ce qui nécessite des investissements importants.
Je pense que la complexité du domaine et l'étroitesse des applications a limité les ambitions des programmeurs du libre. Rien que la construction d'une base d'apprentissage est un projet en soi. L'analyse du layout est un vaste domaine également, et si on se penche sur la segmentation (décomposer une ligne en mots, un mot en lettres), on sent vite des problèmes complexes apparaître... Finalement, la reconnaissance des lettres prises une par une paraît bien simple quand on prend la mesure du projet complet.
Quant à la reconnaissance des partitions musicales, le problème est là encore plus complexe qu'il n'y paraît, sans doute davantage même que la reconnaissance de texte (mais tout dépend de la complexité et de la qualité de la partition). La thèse de Bertrand Couäsnon était en ligne autrefois, j'en conseille sa lecture aux intéressés : http://www.irisa.fr/imadoc/HTML/B..Couasnon.fr.html mais impossible de remettre un lien dessus ?!
Tous ces problèmes sont résolus facilement par l'homme car ils nécessitent l'agrégation d'informations redondantes et disparates : toutes choses difficiles à formaliser pour l'ordinateur. La plupart des erreurs commises par les logiciels paraissent évidentes à l'humain ; pourtant si celui-ci doit expliquer les raisons de l'erreur, il va voir que ses explications vont chercher, au final, bien plus loin que ne peuvent "voir" les programmes.
[^] # Re: Très peu significatif
Posté par Frédéric Lopez . Évalué à 2.
Moi je vois plusieurs usages dans les PME pour de l'OCR un peu amélioré :
- numérisation en masse de factures ou bons de commande pour les inclure automatiquement dans une gestion financière ;
- reconnaissance et classement automatique de courrier ;
- distribution automatique aux destinataires par messagerie ;
- circuits de distribution et de validation informatisés via workflows ;
- évolution vers le zéro papier ;
- archivage légal automatique.
On reçoit généralement des documents structurés de façon similaire (destinataire en haut à droite dans un courrier, format fixe pour les bons de commande, etc.), le reste pouvant être trié manuellement.
Ça ne me semble pas nécessiter un investissement si important et ça peut être très utile dans une PME. D'ailleurs il existe pas mal de solution de ce type sur le marché. Pourquoi pas une solution libre ?
[^] # Re: Très peu significatif
Posté par let antibarbie = xp <- xp - 1 . Évalué à 2.
Julien.
[^] # Re: Très peu significatif
Posté par BAud (site web personnel) . Évalué à 2.
beaucoup de choses semblent publiées
http://www.irisa.fr/imadoc/HTML/Welcome.html
si tu trouves des choses intéressantes dans ftp://ftp.irisa.fr/local/imadoc/ tu nous le diras ?
# Austin Acton lit cette nouvelle
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
"« Ah! Des commentaires interessants! » après avoir lu cet article.
[^] # Re: Austin Acton lit cette nouvelle
Posté par be_root . Évalué à 2.
Là il va sûrement changer d'avis :-)
Il se prend pour Napoléon, son état empire.
# Groklaw utilise Tesseract pour scanner les pdf
Posté par oliv . Évalué à 3.
http://www.groklaw.net/article.php?story=20061210115516438
# Reconnaissance de caractères pour écriture manuelle
Posté par François B. . Évalué à 3.
Contexte : je suis archer, et je trouve que le logiciel existant fourni par la fédération est une catastrophe : saisie des résultats difficile (quasi obligation d'utiliser la souris lors de la saisie de masse par exemple), limitation de l'OS utilisable (le format d'échange est un « format standard Excel », j'espère que c'est du csv mais je n'ai pas pu voir le détail), nombreux bugs...
Mon idée : je voudrais lancer un projet pour le suivi de compétition qui remplacerait le logiciel actuel. Mais comme la fédération ne voudra certainement pas valider un logiciel qui a été réalisé par trois gars dans un garage, il faut qu'il ait des fonctionnalités supérieures à celui existant. Je pensais alors à la lecture automatique des feuilles de marque.
Les feuilles de marque se composent principalement d'un tableau, avec la marque de chaque flèche par case, puis le total de la volée (une volée est un groupe de 3 ou 6 flèches pour les compétitions les plus classiques), puis le cumul. Une marque est soit « M » (manqué) lorsque la flèche est hors du blason, ou un nombre entre un et dix.
Je me posais donc la question de la faisabilité d'une reconnaissance d'écriture manuelle pour les feuilles de marque, sachant que je remarque souvent des erreurs de calcul lors des cumuls... Les feuilles seraient numérisées et analysées et dès qu'une incohérence marque/cumul est détectée, l'opérateur reprendrait la main et utiliserait son propre système de reconnaissance pour trancher (ses yeux et son cerveau). Il faudrait également détecter la présence de rouge dans une case (modification par un arbitre).
Aujourd'hui, les archers et marqueurs signent leur feuille de marque en fin de tir et cela vaut pour acceptation du résultat... Cela ne me satisfait pas.
Est-ce que quelqu'un connaitrait un outil permettant de faire une reconnaissance ciblée ? Les zones à reconnaitre pouvant être facilement délimitées par une détection de la grille.
Question bonus : est-ce que d'autres archers souhaiteraient mettre en place ce projet avec moi ?
[^] # Re: Reconnaissance de caractères pour écriture manuelle
Posté par Guillaume Rossignol . Évalué à 2.
Pour ce qui est de la reconnaissance des feuilles de marques, vu la qualité de celles ci j'imagine mal un logiciel de reconnaissance le faire lui même (on verifiait lors des tournois à Meyzieu toutes les feuilles à la fin... même les humains en bavaient pour les relire). En plus du rouge, du M qui ressemble rarement à quelque chose.
Il me semble que la premiere priorité serait quand même une modernification de l'interface (fonctionnellement parlant) et le passage à un logiciel portable.
Oui, mais là, c'est le reglement qu'il faudrait changer ^^
[^] # Re: Reconnaissance de caractères pour écriture manuelle
Posté par François B. . Évalué à 1.
C'est vrai que certains écrivent vraiment avec leurs pieds (ils sont d'ailleurs doués de leurs pieds), mais j'osais espérer que s'ils étaient prévenus du traitement automatique, ils feraient peut-être un effort pour écrire mieux. De plus, quand j'étais étudiant (à la fin du siècle dernier), j'ai appris que la Poste reconnaissait les codes postaux sur les enveloppes avec une précision strictement supérieure à 95% (je ne me rappelle plus exactement du nombre, mais je suis sûr que c'était plus de 95). Donc techniquement c'est faisable... mais est-ce que le libre en est capable ?
Tu veux dire que les feuilles étaient recalculées ? Vous êtes courageux dans votre compagnie ! Ici, si la feuille est signée, on reporte directement le total inscrit sur l'ordinateur.
Bien sûr, ça serait super. Mais après avoir discuté un peu avec quelques arbitres, il semblerait que la fédération ait payé assez cher le logiciel actuel, et qu'elle risque d'être très conservatrice et ne pas vouloir changer. C'est pour ça que je me disais que s'il y avait une fonctionnalité tueuse en plus, ça aiderait grandement à la décider.
Si la technique permet de faciliter l'application d'un réglement plus satisfaisant à moindre effort, ce logiciel pourrait être le catalyseur de cette évolution...
/me rêve
# OCR & video
Posté par Sebastien - aem (site web personnel) . Évalué à 1.
a de nombreuses reprises j'ai cherché sur le net une solution pour faire de la capture video (avec camera + carte d'acquisition ou webcam seul) et de la reconnaissance de caractères...
je suis certain que ce genre de solution existe, notamment pour la lecture de code barre par video (et pas lecteur code barre)
mais en libre ??
j'ai tenté a partir de plusieurs appli, utiliser des pipes mais entre les pb de carte d'acquisition (ou de webcam), les passages de parametres, les formats, la compilation des sources etc ... je ne m'en sort pas
si vous avez une idée, ou tenté cette experience
merci par avance
[services informatique](http://www.aexm.fr/ "AEM") sur Grenoble
[^] # Re: OCR & video
Posté par herodiade . Évalué à 2.
Il y a un bout de code pour ça dans les sources de mplayer (ça converti la vidéo en une suite d'images statiques, et passe gocr dessus).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.