Journal Aperçu d'AbiScan

Posté par (page perso) .
Tags :
0
6
août
2007
Salutations,

Malgré le manque de motivation, Gnome Scan poursuit son petit bonhomme de chemin (mais que veut dire cette expression?). J'ai implémenté AbiScan, un greffon pour AbiWord alliant Gnome Scan et OCRopus pour intégrer la ROC dans Abiword.

J'ai fait une petite vidéo du résultat : http://bersace03.free.fr/pub/Video/Gnome%20Scan/AbiScan+OCRo(...)

C'est super instable, super incomplet, super brouillion, mais l'idée est là. Si vous voulez tester plus avant, j'ai expliqué comment tester tout ça sur le blog de Gnome Scan (en anglais :/) : http://gnome-scan.blogspot.com/2007/08/abiscan-preview.html (liens et photos d'écran à la clef). C'est assez extrême (y'a 6 logiciels à installer depuis SVN et 3 patches à appliquer …). En gros, c'est pas pour la production =)

Les dév d'Abiword m'ont beaucoup aidé. Je n'avais jamais écrit une ligne de C++ et encore moins navigué dans l'API complexe d'AbiWord. Grâce à eux, j'ai pu m'en sortir en moins d'une semaine. Visiblement, ça les a un peu motivé la petite vidéo ^_^.

Cordialement,
Étienne.
(6 commentaires).

  • # autres logiciels d'OCR

    Posté par . Évalué à 3.

    Et est-ce que tu as prévu de faire fonctionner cela avec d'autres logiciels ?

    Je n'ai jamais essayé moi-même et je sais que les critiques sur les projets libres existants n'étaient pas très enthousiastes (voir par exemple http://web.linuxfr.org/2007/05/25/22532.html).

    Cependant, s'il existe toujours des limitations à OCRopus comme la non-reconnaissances des accents, est-ce que c'est envisageable de proposer une alternative comme GOCR ? (question peut-être stupide, je ne pense pas que GOCR ait été développé avec cette utilisation en tête)

    • [^] # Re: autres logiciels d'OCR

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

      Salutation,

      OCRopus n'est pas un moteur de reconnaissance optique. C'est un logiciel de reconnaissance optique de caractère, de mise-en-page du document, de formattage couplé avec un dictionnaire et une correction dynamique basé sur de la statistique.

      Bref, c'est la couche au dessus de gocr, hocr, ocrad, claraocr, tesseract et tant d'autre. OCRopus se base actuellement sur tesseract, mais c'est prévu de pouvoir se basé sur n'importe lequel, dynamiquement. Il y a d'ailleur déjà des lien vers hocr (hébreux).

      Si ma mémoire est bonne, tesseract 2.0 est censé gérer les accent. Gocr le gère déjà, mais il n'est pas aussi fiable que tesseract.

      Actuellement, AbiScan se base sur Gnome Scan pour numériser, et passe le relai à ocropus via la ligne de commande (merci g_spawn_sync). Le but est qu'OCRopus ne fournisse pas seulement un utilitaire pour le shell, mais aussi une API avec interface Gnome pour prévisualiser/corriger/superviser le long travail de la reconnaissance optique de document.

      Donc AbiScan n'est qu'un pont entre Gnome Scan + OCRopus dans Abiword. Ça implique aussi que Gnome Scan ne gèrera pas la ROC directement et c'est pas plus mal : qu'est-ce que gthumb et f-spot en ont à faire de la ROC.

      OCRopus est très très très immature. C'est simple : y'a même pas de alpha1 ou quelques chose du genre. Y'a même pas l'infrastructure pour distribuer une archive (make distcheck ou équivalent), sinon j'aurai fournit un paquet debian. Mais ils ont une approche au dessus de celle des moteur ROC traditionnelle. Par exemple, si tu vois un test comparatif OCRopus/gocr, tu as le droit à une bonne tranche de rigolade.

      Voilà pour la mise au point. Je pense qu'il faudra que je blogue un jour là dessus pour clarifier la situation (c'est très frais ;-) ).

      Cordialement,
      Étienne.

  • # Bravo ...

    Posté par . Évalué à 7.

    On peut espérer voir Gnome-Scan dans Gnome-2.20 ? En tout cas c'est encourageant.

    De plus, ça fait plaisir de voir qu'on peut publier une vidéo sans gxxgle ou youtnbe.

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Bravo ...

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

      Moi aussi j'aimerais manquer de motivation comme ça...

      Pas mieux qu'au dessus, bravo pour le boulot accompli

    • [^] # Re: Bravo ...

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

      Héhé !

      Pour 2.20 … ça va être dur ! Vu la stabilité du bousin. En tout cas, le patch a été intégré dans le SVN, mais le greffon est désactivé par défaut. De toute façon, c'est tellement la croix et la bannière pour installer toute les dépendances que ça prendra du temps pour arriver.

      À la fin du SoC, Gnome Scan devrait atteindre un stable fonctionnel assez intéressant avec une API plutôt matûre. Y'a encore énormément de boulot : greffon Gimp, traitement intermédiaire (rotation, correction des couleurs, etc.), stabilisation (c'est franchement instable et boggué), etc. Y'a notament l'énorme travail pour tirer au mieux partie des divers scanner SANE, heureusement, la nouvelle architecture permet à l'utilisateur de s'en sortir malgré tout. Avec tout ça, documentation et traduction.

      Comme l'année dernièer avec Gnome Scan 0.4, je pense que Gnome Scan 0.6 arrivera vers Noël et sera donc plutôt pour 2.22 (désolé pour le chagrin).

      Faut voir que Gnome Scan est plutôt mâture comparé à Gegl dont il dépend essentiellement. Ensuite, Gnome Scan n'est que la bibliothèque, il faut l'utiliser (ce qui nécessite une version propre et très stable). Les utilisations : c'est flegita, flegita-gimp, AbiScan et d'autres encore. Chacune est largement indépendante des autres quant à sa stabilité. Par exeùple AbiScan dépend d'OCRopus, encore moins matûre que Gegl, ça mettra donc du temps à débarquer. Cependant, flegita et flegita-gimp devrait être rapidement prêt.

      Et oui, Gnome Scan n'est pas tout en un comme XSane, Kooka, quiteinsane, VueScan, etc. AbiScan ne sera même pas dans le dépôt de Gnome (m'enfin ça, c'est parce qu'on ne peut pas compiler un greffons d'Abiword indépendamment …). Mais c'est aussi sa force : pouvoir avancer à plusieurs vitesse : d'abord la bibliothèque (et flegita) puis le greffons pour les diverses applications.

      Cordialement,
      Étienne.

      • [^] # Re: Bravo ...

        Posté par . Évalué à 1.

        [...] Vu la stabilité du bousin [...]
        Et c'est du à quoi ces pb de stabilité ? C'est plutot localisé dans le code (genre GUI, backends, ...) ou c'est général ?

Envoyer un commentaire

Suivre le flux des commentaires

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