État des lieux de la reconnaissance de caractères libre (OCR)

Posté par (page perso) . Modéré par Nÿco.
0
25
mai
2007
Technologie
Un contributeur bénévole à Mandriva, Austin Acton, a pris le temps de tester toutes les solutions libres d'OCR (ou ROC pour Reconnaissance Optique de Caractères) disponibles, dans un article en anglais.

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)
GOCR est le seul logiciel à reconnaître les caractères accentués, mais n'obtient que 94% de réussite dans la phrase de test. Il est la seule option actuellement pour un texte en français ; la bonne nouvelle, c'est qu'il est disponible dans toutes les distributions.

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

  • # mise-en-page

    Posté par (page perso) . Évalué à 6.

    Bonjour,

    À noter que ce teste ne traite que la reconnaissance de caractère, mais aucunement l'analyse de la mise en page de document (pour extraire les images du texte, remettre en forme un tableau, etc.). Évidemment, il n'y a pas d'analyse de document sans ROC, mais il faut reconnaître à OCRopus son avancé la dessus. D'autant que la reconnaissance d'OCRopus n'est autre que celle de tesseract (pour le moment).

    Cet été, un étudiant travail sur la reconnaissance vocale pour pilote le bureau Gnome : http://code.google.com/soc/gnome/appinfo.html?csaid=4F64D394(...) . Gageons que le libre va rattraper son retard dans ces deux domaines cruciaux dans l'avenir de l'informatique.

    Étienne
    • [^] # Re: mise-en-page

      Posté par (page perso) . Évalué à 2.

      « cruciaux dans l'avenir de l'informatique »... Hum. La reconnaissance vocale ça fait longtemps que ça existe et vu le succès remporté, je pense pas que ça soit une révolution et que ça soit critique comme besoin. Idem pour l'OCR.

      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 (page perso) . Évalué à 3.

        IBM Via Voice dans Mandrake 7.1

        A c'était le bon temps ....
        • [^] # Re: mise-en-page

          Posté par (page perso) . Évalué à 3.

          Si vous voulez vous amuser avec la reconnaissance vocale, j'avais (re-)regardé ce que ça donne maintenant :
          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 (page perso) . Évalué à 2.

          J'avais eu l'occasion à l'UEC d'Hourtin de demander à une personne d'IBM de libérer de code de ViaVoice. Quelques semaines plus tard IBM annonçait la libération d'une partie du code. Je ne sais pas si il y a eu relation de cause à effet.
          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 (page perso) . Évalué à 7.

        crucial, non mais tu serais étonné des utilisations importantes qui en sont faites :
        - 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 . Évalué à 1.

          Pour moi, la reconnaissance vocale, ça me semble très important pour l'accessibilité. Pour les personnes handicapées, on pourrait inventer des multitudes d'équipements à commande vocale et à moins coût (pas de licences à payer).
          • [^] # Re: mise-en-page

            Posté par . Évalué à 2.

            Pas mal aussi pour les tests de prononciation dans les logiciels d'apprentissage de langue, même si c'est d'une utilité moins "critique"...
        • [^] # Re: mise-en-page

          Posté par (page perso) . Évalué à 2.

          Un très vieil exemple de reconnaissance de la parole : Ali Baba et les 40 voleurs !
          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 . Évalué à 2.

          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...)
          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
  • # Très peu significatif

    Posté par . Évalué à 3.

    C'est un peu rapide de conclure sur le test d'une phrase, sans aucun formattage, qui vient d'être imprimée sur du papier propre.

    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 (page perso) . Évalué à 3.

      Austin a fait un test rigoureux dans un cadre précis. Si tu ne trouves pas que ce soit assez, fais le !
      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 . Évalué à 5.

        Le test est rigoureux je l'accorde. L'auteur est aussi visiblement sérieux et bien intentionné.

        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 (page perso) . Évalué à 2.

          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.

          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 . Évalué à 2.

          > 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)

          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 . Évalué à 2.

          Pour nuancer un peu :
          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 . Évalué à 2.

            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.

            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 . Évalué à 2.

        A propos des reconnaissances de partitions musicales, j'ai déjà vu ça quelque part, et il faut croire que ça marche ! Ils bossent là dessus à l'Inria, dans le projet Imadoc.. je sais pas trop ce qui est publié de leurs travaux, mais en tout cas ils font des trucs vraiment très intéressants.

        Julien.
  • # Austin Acton lit cette nouvelle

    Posté par (page perso) . Évalué à 2.

    Austin est un canadien anglophone mais il comprend et parle français (quand c'est nécessaire). Il vient de m'écrire :
    "« Ah! Des commentaires interessants! » après avoir lu cet article.
  • # Groklaw utilise Tesseract pour scanner les pdf

    Posté par . Évalué à 3.

    Cet article a quelques mois, et décrit l'utilisation de Tesseract par Groklaw pour scanner des documents pdf (dépositions, motions, décisions de tribunaux). Un script est même fourni pour aider. Il semble que Tesseract soit très satisfaisant pour ces documents "du monde réel".
    http://www.groklaw.net/article.php?story=20061210115516438
  • # Reconnaissance de caractères pour écriture manuelle

    Posté par . Évalué à 3.

    Je profite de cet article pour m'informer un peu pour un projet que j'ai en tête depuis quelques temps...

    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 . Évalué à 2.

      Je n'ai pas tiré à l'arc cette année (manque de temps) mais si la ligue n'a pas changé de logiciel depuis l'année derniere, il n'y a pas à dire, c'est merdique. La seule chose qu'il fait correctement, c'est l'impression des resultats... bref

      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.

      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.
      Oui, mais là, c'est le reglement qu'il faudrait changer ^^
      • [^] # Re: Reconnaissance de caractères pour écriture manuelle

        Posté par . Évalué à 1.

        Je n'ai pas tiré à l'arc cette année (manque de temps) mais si la ligue n'a pas changé de logiciel depuis l'année derniere, il n'y a pas à dire, c'est merdique.
        Moi c'est le contraire, je n'ai repris le tir qu'en septembre dernier, après un arrêt de plusieurs années... alors je ne sais pas si le soft a changé.
        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
        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 ?
        on verifiait lors des tournois à Meyzieu toutes les feuilles à la fin
        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.
        Il me semble que la premiere priorité serait quand même une modernification de l'interface (fonctionnellement parlant) et le passage à un logiciel portable.
        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.
        Oui, mais là, c'est le reglement qu'il faudrait changer
        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 (page perso) . Évalué à 1.

    une question...

    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 . Évalué à 2.

      Pour autant que je sache, c'est ce que font les outils qui extraient les sous-titres de DVD (au format vidéo mpeg-2) vers un format texte.
      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.