Journal OCRopus 0.1 : première version !

Posté par  (site Web personnel) .
0
23
oct.
2007
Salutations,

OCRopus vient de sortir sa première version ! La première bêta est prévue pour fin du premier trimestre 2008. D'ici il devrait y avoir quelques version alpha intermédiaire.

OCRopus est un logiciel de reconnaissance de document gérant à la fois le texte, les images et les mise-en-page. OCRopus est à {ocrad,gocr,claraoc,hocr,tesseract,…} ce que le HTML est au TXT. D'ailleurs, OCRopus fournit le résultat en hOCR : du HTML avec des informations spécifiques à la mise-en-page.

Cette première version apporte la segmentation image/texte, la reconnaissance optique basé sur MLP, la statistique de langue basé sur OpenFST pour corriger les erreurs de ROC, prétraitement de l'image (nettoyage, détramage), scriptage avec Lua, outils de tests et d'évaluation, etc.

La bêta devrait voir moins de nouvelles fonctionalités, mais surtout des corrections de bogues, une meilleure qualité du résultat, etc.

http://code.google.com/p/ocropus/

L'équipe OCRopus ne préfère pas avoir de dépêches un peu partout et rester « entre développeurs ».

Cordialement,
Étienne.
  • # Question ...

    Posté par  . Évalué à 1.

    Je n'ai pas testé, mais j'ai une petite question. Est-ce qu'il est possible de récupérer l'image nettoyé (avant OCR). J'aimerais bien bénéficier de fonction de détramage / nettoyage / redressement des pages pour des pages scannées mais conservées sous forme d'images.
  • # Nouveau moteur de ROC pour OCRopus

    Posté par  (site Web personnel) . Évalué à 3.

    Salutations,

    J'ajoute à cette dépêche qu'OCRopus contient un nouveau moteur de ROC en plus de Tesseract. Ce moteur (anonyme) est basé sur les "MLP" (Multi-Layer Perceptron) ou "NN" (Neural Network). Si un linuxfrien pouvait nous éclairer dessus !

    Cordialement,
    Étienne.
    • [^] # Re: Nouveau moteur de ROC pour OCRopus

      Posté par  . Évalué à 10.

      Bon ben pour faire simple, un perceptron est un type particulier de réseau de neurones artificiels, c'est-à-dire un ensemble d'unités élémentaires appelées neurones, par analogie avec nos cellules nerveuses. Ce sont des unités à N entrées et 1 sortie.

      Les signaux d'entrée et de sortie sont du type tout ou rien (1 ou 0), et la sortie vaut 1 si la somme des entrées, pondérée par des valeurs que l'on appelle coefficients synaptiques dépasse un certain seuil (dit d'activation).

      Prenons le cas de la reconnaissance des chiffres de 0 à 9. Dans le cas d'un perceptron simple (mono-couche), on a 10 neurones, qui prennent en entrée chacun des pixels de l'image à analyser. En sortie, le premier neurone vaut 1 et les autres 0 si le chiffre présenté est un zéro. Le deuxième neurone ne s'active que si l'image représente un un, et ainsi de suite.

      Tout le problème consiste à fixer correctement les poids synaptiques pour que les sorties s'activent correctement. Pour cela, on présente au réseau un ensemble de patterns <image d'entrée / résultat désiré>, et on observe quelle est la sortie effectivement obtenue. En fonction de l'écart quadratique moyen par rapport au résultat désiré, on ajuste les poids synaptiques selon des formules bien établies. C'est la phase dite d'apprentissage. Une fois cette phase terminée, le réseau doit pouvoir reconnaître des patterns qui ne font pas partie de l'ensemble d'apprentissage : il peut donc généraliser.

      Les perceptrons tels que présentés ci-dessus sont assez limités. On a donc conçu une variante, les perceptrons multi-couches, dans lesquels la sortie des neurones d'entrée attaque l'entrée d'un nouvel ensemble de neurones, dont les sorties elles-mêmes, etc... jusqu'à la couche de sortie. L'apprentissage (c'est-à-dire le calcul des poids synaptiques) se fait alors par un algorithme dit de rétropropagation du gradient. Cette classe de perceptrons peut traiter des cas plus complexes que les perceptrons simples.

      Les réseaux de neurones étaient à la mode dans les années 90, quand je terminais mes études (mon travail de fin d'études portait là-dessus). Il en existe d'autres types que les perceptrons, et il existe aussi d'autres types de neurones que ceux présentés ci-dessus, mais je ne vais pas m'étendre, j'avais dit "pour faire simple"...
      • [^] # Re: Nouveau moteur de ROC pour OCRopus

        Posté par  . Évalué à 1.

        Cette classe de perceptrons peut traiter des cas plus complexes que les perceptrons simples.

        On va dire qu'à la différence des monocouches, les MLP peuvent traiter des cas utiles. Parce que si je me souviens ce qu'on nous apprenait à l'école, le perceptron "tout con", il est incapable de reproduire la fonction XOR (entre autres). Ce qui donne une idée assez intéressante de ses "limites".

        Clairement, pour du perceptron, "hors MLP point de salut". Ou bien?
        • [^] # Re: Nouveau moteur de ROC pour OCRopus

          Posté par  . Évalué à 2.

          Oui, tu as raison, sauf si on change le type de neurones. Par exemple, un perceptron mono-couche peut réaliser la fonction XOR s'il utilise des neurones de type sigma-pi : à la classique somme pondérée des entrées prises séparément, on ajoute une somme pondérée des produites des entrées prises 2 à 2, voire 3 à 3, 4 à 4... (bonjour l'explosion combinatoire). Le tout avant d'appliquer la fonction de seuil, laquelle ne doit d'ailleurs pas nécessairement être une fonction de Heaviside : toute sigmoïde convient, comme la tangente hyperbolique, par exemple.
    • [^] # Re: Nouveau moteur de ROC pour OCRopus

      Posté par  . Évalué à 1.

      En tout cas ce moteur n'a pas encore été optimisé d'après Thomas Breuel sur la mailing list:
      http://groups.google.com/group/ocropus/browse_thread/thread/(...)
      "In fact, Google has released 120Gbytes of training data, and we also have
      large amounts of training data ourselves. For the alpha release, there has
      been very little training; we have focused on getting the code in place, so
      performance of the character recognizer isn't all that good. For the beta
      release, we'll work on training and improving the character recognition. "

      Question: "I would think that if you showed a neural-net learning system enough documents in format, with hundreds of different fonts for each document, that the program could "figure it out" fairly quickly."
      Réponse:
      Unfortunately, it's a lot more complicated than that. First of all, the
      character recognizers need to be fast in addition to accurate, the
      characters are not presented in isolation, there are font and style
      variations, and there are ambiguities in the input.

      Le meilleur est à venir!
  • # Compilation

    Posté par  . Évalué à 3.

    La page d'aide à la compilation est très complète:
    http://code.google.com/p/ocropus/wiki/GettingStartedWithAlph(...)
    Mais j'ai quand même eu des surprises.
    Il me manquait subversion-tools pour que "svn" dans une console fonctionne.
    Il me manquait une librairie pas recommandée par google, dans ma debian:
    libreadline5-dev , mais en fait à cause d'un problème de liens avec la GPL, ils indiquent sur la mailing-list (http://groups.google.com/group/ocropus/topics?start= ) qu'il faut installer: libedit
    Installer aussi, en plus de libaspell-dev et aspell, des langues comme aspell-en, aspell-fr.
    Et enfin ils ont aussi oublié d'indiquer d'installer: libsdl-gfx1.2-dev et libsdl-image1.2-dev

    Pour Tesseract il faut télécharger un ou plusieurs fichiers langues ici:
    http://code.google.com/p/tesseract-ocr/downloads/list
    Exemple pour le français: tesseract-2.00.fra.tar.gz
    Il faut extraire les fichiers et les copier dans le dossier /tesseract-2.01/tessdata
    Bien vérifier que les fichiers vides ont été remplacés.
    Je vais devoir recompiler Tesseract car j'avais oublié cette étape.
    Heureusement que j'ai un Core2Duo.

    Pour la compilation d'ocropus, taper ./configure, mais surtout pas make ensuite!
    Il faut utiliser jam à la place de make, donc tapez: jam
    Puis installer en tapant: jam install
    Ou plus simplement: ./configure; jam; jam install
    Pour tester que tout marche bien, rester dans le même répertoire et taper:
    ocrocmd/ocrocmd data/pages/alice_1.png | tee output.html

    Ça ne marche pas tout à fait puisque j'obtiens ça:

    There was an error while initializing a word list.
    Try to set an environment variable `wordlist' to a UTF-8 encoded list of words.
    (Right now, `wordlist' was set to /usr/share/dict/words)
    Maybe (release directory)/data/words/en-us will help.
    Alternatively, you can install aspell libraries and recompile.
    ocrocmd/ocrocmd: bad utf8 encoding


    À l'aide!
    • [^] # Re: Compilation

      Posté par  (site Web personnel) . Évalué à 1.

      Super, encore un qui utilise jam.

      Pour ton problème:
      There was an error while initializing a word list.
      Try to set an environment variable `wordlist' to a UTF-8 encoded list of words.
      (Right now, `wordlist' was set to /usr/share/dict/words)
      Maybe (release directory)/data/words/en-us will help.
      Alternatively, you can install aspell libraries and recompile.
      ocrocmd/ocrocmd: bad utf8 encoding


      Le message semble très clair pour moi :
      - soit tu installe les bibliothèques de dev d'aspell et tu recompiles le tout
      - soit tu crée un dictionnaire (fichier contenant une liste de mots encodés en utf-8) et tu le met dans /usr/share/dict/words, ou dans le fichier pointé par la variable d'environnement wordlist.

      Apparemment, tu n'as pas aspell ... Donc il utilise le fichier /usr/share/dict/words. Soit ce fichier n'existe pas, soit il est mal encodé en utf-8

      Après, je ne peux pas aller plus loin
      • [^] # Re: Compilation

        Posté par  . Évalué à 1.

        J'ai installé libaspell-dev et recompilé mais ça n'a rien changé.
        Quant à ton deuxième conseil, si tu ne me donnes pas la liste exacte de toutes les commandes à taper, c'est-à-dire si tu n'es pas Dieu, mon cerveau ne peut rien faire de concret.
        Merci quand même!
    • [^] # Re: Compilation

      Posté par  . Évalué à 1.

      Après une bonne nuit de sommeil, tout m'est apparu plus clairement. Grâce à la documentation de debian sur les variables d'environnement surtout!
      Il faut donc dans une console utilisateur taper: export wordlist=/CheminVersCeDossier/ocropus-0.1.0/data/words/en-us
      C'est le dictionnaire de base en anglais téléchargé dans le fichierocropus-0.1.0.tar.gz

      Ensuite dans la même console ouverte dans /ocropus-0.1.0, on tape ceci pour tester ocropus:
      ocrocmd/ocrocmd data/pages/alice_1.png | tee output.html
      Ça mouline pendant une vingtaine de secondes sur mon Core2Duo, avec plein de choses affichées dans la console.
      On ouvre le fichier /ocropus-0.1.0/output.html avec son navigateur favori, et on obtient normalement un texte en anglais, qui correspond en gros au texte contenu dans l'image /ocropus-0.1.0/data/pages/alice_1.png
      Il y a 8 erreurs dans le premier paragraphe, surtout des lettres o remplacées par le chifre 0. Une seule erreur (la même) dans le second paragraphe. Bref, si on pouvait interdire à ocropus d'utiliser autre chose que des lettres, le résultat pourrait être presque parfait en anglais. C'est un peu dommage car ça semble tout con à corriger comme défaut. Je croyais qu'il n'y avait que des génies qui travaillaient pour google!? En tout cas ça semble réellement être l'énorme pas en avant promis, donc on pourra bientôt ouvrir le champagne!
      Il ne me reste qu'à tester ça en français, en redéfinissant la variable d'environnement wordlist.
  • # conversion PDF -> openoffice

    Posté par  . Évalué à 1.

    Bonjour,

    Ce type de logiciel peut être utilisé pour convertir un PDF en doc openoffice (chaîne: pdf -> image -> html -> openoffice).

    Connaissez vous un script automatisé pour cette opération ?

    Cdlt
    • [^] # Re: conversion PDF -> openoffice

      Posté par  . Évalué à 3.

      je pense que cette chaine est un peu foireuse :
      - le pdf contient les infos sur le texte (voir pdf2text)
      - le pdf contient les infos sur la mise en page (?)

      bref passer par une transformation destructive (pdf->image) pour ne pas etre sur de retrouver le bon résultat, c'est capilotracté.

      le plus ardu est la restitution de la mise en page, la on doit pouvoir récuperer les algos qui produisent le HTML ,

      Je n'ai pas du tout regardé le html produit , vue la doc de hOCR, la mise en page risque d'etre seulement des liste de bounding box, ou de polygone (sous forme xhtml) .
      Les bounding box /chemins doivent etre déja dans le pdf.

      Faire/trouver/bricoler un pdf->xhtml tel que produit par hOCR me semble plus efficace/raisonable et moins risqué.

      ensuite le xhtml->odf , je sait pas si la traduction va donner qqch de tres propre.
      • [^] # Re: conversion PDF -> openoffice

        Posté par  . Évalué à 0.

        Il existe un pdf2text qui marche plûtot bien, qui essaie de
        reproduire la mise en page sous forme ascii, mais je ne crois
        pas qu'il produise d' "informations de mise en page".

        La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

    • [^] # Re: conversion PDF -> openoffice

      Posté par  . Évalué à 1.

      T'as pdftohtml pour la conversion pdf vers html.
      Mais le résultat est assez peu propre.
      La mise en page est quasiment là, généralement il y a juste des problèmes de police, il ne définit pas la bonne, et la bonne, ou celle définie, n'est pas forcément présente sur ton système. Pour le reste ça va, mais ce problème fout déjà pas mal la mise en page en l'air.

      Il te pond un résultat simple : chaque page a une grosse image de fond qui est un « screenshot » de ton pdf, mais sans le texte, et le texte est ensuite rajouté ligne par ligne, positionné au pixel, avec la taille du texte, l'espacement, et les styles (gras, italique...), définis.

      Le document produit est énorme parce qu'il te sort des quantités hallucinantes de styles, dont la très grande majorité ne sont pas utilisés, un script simple permet de nettoyer ça et d'avoir une taille de page à laquelle on pourrait s'attendre.


      En ce moment je bosse sur un petit script python qui irait un peu plus loin, et nettoierai vraiment le code HTML pondu par pdftohtml, en particulier en fixant toutes les tailles et les positions en « em », ce qui permet de faire des zooms HTML purs sur la page (avec ctrl-+ et ctrl-- sous firefox et d'autres).
      Je ferai un journal dès que j'aurai une première mouture fonctionnelle, qui sera évidemment en GPL (ou BSD selon le côté sur lequel tombe la pièce... Voire directement dans le domaine public si ça tombe sur la tranche... :) ).

      Le seul gros problème qui reste c'est que la grosse image de fond c'est gentil, mais en fait c'est gros et pas terrible, l'idéal serait de réussir à extraire les images (ça c'est facile, avec pdfimage), et ensuite de savoir où les positionner dans la page.
      On perdrait quelques éléments de mise en page cependant, genre si un bout de texte est surligné en jaune, pour le moment c'est inclus dans l'image de fond, si on extrait les images et qu'on les positionne, ce surlignage sera perdu.
      Mais on obtiendra quand même un résultat assez propre avec un minimum d'efforts, et le plus léger possible aussi.


      J'ai bien essayé de regarder pdftohtml pour bosser directement dessus, mais j'ai choppé une migraine, alors pour le moment j'évite :p


      Yth.
      • [^] # Re: conversion PDF -> openoffice

        Posté par  . Évalué à 2.

        Y'a ça, qui est passé récemment: http://www.fredemmott.co.uk/blog_116

        En substance, le "pire convertisser PDF -> HTML", et il ressemble à ça:

        #!/bin/sh
        BN=$(basename $1 .pdf)
        pdf2ps $1
        pstopnm -xsize 800 $BN.ps
        cat > $BN.html <<EOF
        <html>
        <head>
        <title>$1</title>
        </head>
        <body>
        EOF
        for file in $BN*.ppm; do
        out=$(basename $file .ppm).png
        convert $file $out
        echo "<img src='data:image/png;base64,$(base64 $out)'>" >> $BN.html
        done
        cat >> $BN.html <<EOF
        </body>
        </html>
        EOF
      • [^] # Re: conversion PDF -> openoffice

        Posté par  . Évalué à 2.

        Je suis allé regarder le pdftohtml et c'est assez intéressant.
        C'est basé sur xpdf et en fait ca rajoute un driver d'impression html a xpdf( qui maintenant est poppler)

        et poppler fournis (en tout cas dans le git),
        les drivers suivants :
        - ABWOutputDev.cc : AbiWord (xml)
        - TextOutputDev.cc
        - splash (?)
        - cairo
        - arthur (qt?)

        je pense que repartir sur l'output abiword peut etre intéressant, ca crache du xml direct, et ca doit extraire les images correctement.


        sinon pour en revenir a la conversion pdf->odf :
        pdf->abiword->odf me parait mieux que de faire de l'OCR.
        • [^] # Re: conversion PDF -> openoffice

          Posté par  . Évalué à 1.

          Hmm, yabon ça l'abiword...
          T'as trouvé un outil qui existerait déjà et ferait ça ?


          Yth.
          • [^] # Re: conversion PDF -> openoffice

            Posté par  . Évalué à 1.

            le driver pout sortir du abword c'est dans le git de poppler, ca vient du Googl SoC 2006.
            Ca doit etre un plugin, mais la page des plugins d'abiword est cassé.

            le packet debian sarge donne un /usr/lib/AbiWord-2.4/plugins/libAbiPDF.so

            au pire, il doit etre possible de prendre la version git de poppler,
            reprendre de main() de pdf2html en utilisant le driver pour abiword,
            de bien tout secouer et voila.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.