Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Open Office, Reconnaissance de caractères, Xsane, Kooka et Cie...

freebunter

Salut,

alors voilà j'ai installé la new version et ça marche par contre je n'ai pas encore installé le français. Le reconnaissance de caractère est impecc sauf quelques coquilles et qu'il ne reconnait pas les caractères gras soulignés (il les zappe tout simplement).

En résumé, je ne sais pas exacctement ce qu'il a fait ce Jeffrey Ratcliffe mais ça marche 😃

@+

edit: Français installé

Dom

@ sorbus
Merci de ta réponse. Ta proposition n'a pas changé la donne. J'ai refait alors une installation et depuis ça fonctionne. ???

Pour contribuer à l'évolution de l'outil, voilà ce que j'ai remarqué :
- Lorsque je lance tesseract en ligne de commande (avec tesseract chemin/de/votre/image.tif nom_du_fichier_de_sortie_sans_extension -l fra) je n'obtiens rien, alors qu'en mode graphique, avec gscan2pdf/tesseract, ça marche.
- Mon scanner (HP Photosmart 2575 Tout-en-un) ne dialogue pas avec gscan2pdf ; il y a à chaque fois un message d'erreur. Je scanne, j'enregistre et importe sous gscan2pdf.
- Le format .tiff, généré automatiquement par mon scanner, n'est pas accepté par l'outil ; je dois renommer les fichiers au format . tif avant de les importer dans gscan2pdf et de lancer la roc.

Sorbus

@Dom

J'ai refait alors une installation et depuis ça fonctionne

Quelle version as-tu réinstallé ?
(question juste pour savoir quelle version on a pour comparer nos tests).

- Lorsque je lance tesseract en ligne de commande (avec tesseract chemin/de/votre/image.tif nom_du_fichier_de_sortie_sans_extension -l fra) je n'obtiens rien, alors qu'en mode graphique, avec gscan2pdf/tesseract, ça marche.

Si ça marche avec gscan2pdf, ça doit marcher aussi en ligne de commande. Mais par défaut, le fichier de sortie n'est pas sur le bureau mais dans /home/ton_identité. As-tu vérifié que tu ne le trouves pas là ? (en plus, au départ, il n'est pas placé par ordre alphabétique, mais en fin de liste).
Si tu veux le récupérer sur ton bureau, il faut faire :

tesseract chemin/de/votre/image.tif /home/ton_identité/Desktop/nom_du_fichier_de_sortie_sans_extension -l fra

- Mon scanner (HP Photosmart 2575 Tout-en-un) ne dialogue pas avec gscan2pdf ; il y a à chaque fois un message d'erreur. Je scanne, j'enregistre et importe sous gscan2pdf.

Pour le scanneur, je ne sais pas... (gscan2pdf 0.9.19 ou 0.9.20 ?)
Sinon, tu utilises quel logiciel pour scanner : Xsane ? Kooka ?

- Le format .tiff, généré automatiquement par mon scanner, n'est pas accepté par l'outil ; je dois renommer les fichiers au format . tif avant de les importer dans gscan2pdf et de lancer la roc.

Il faudrait donc préciser le logiciel utilisé pour scanner. Je viens de refaire l'essai avec Xsane, qui sort des fichiers au format .tiff. gscan2pdf importe bien ces fichiers et effectue sans problème la ROC dessus, sans qu'il soit nécessaire de les renommer en .tif au préalable.

De mon cà´té, j'ai fait un premier test de unpaper sur un texte de 7 lignes scanné penché avec Xsane au format .tiff, importé avec gscan2pdf :
--> première ROC réalisée sur le texte penché : le résultat est correct.
--> traitement du texte par unpaper (en cochant seulement "rotation : bas" et "bord : bas")... le texte est bien redressé à l'écran. La ROC donne ensuite un résultat légèrement différent de celle réalisée sur le texte penché... mais ni plus ni moins bon.

Sorbus

A propos de Xsane et de Kooka...

J'ai fait un tour sur les sites de ces deux logiciels.
Il semblerait que Kooka soit en panne de développement... Il y a donc peu d'espoir pour qu'il intègre tesseract à court ou moyen terme.

Pour Xsane, le développement semble se poursuivre activement (la dernière version sous Gutsy est la 0.991... la plus récente est la 0.995). Mais il n'est pas fait mention de tesseract dans les projets... Donc, l'éventuelle intégration de tesseract dans Xsane, ce n'est pas non plus pour demain.

hector

zarer a écritIl travaille actuellement sur l'apprentissage du "vieux latin" avec Tesseract... Il fera un tour dans le secteur quand il aura réglé ses problèmes d'ADSL...

@+

Bonsoir tout le monde:
je suis avec intérêt l'évolution de ce fil.
Juste par curiosité: pourquoi le vieux latin?
Merci!

zarer

Salut Sorbus

Sorbus a écritA propos de Xsane et de Kooka...

J'ai fait un tour sur les sites de ces deux logiciels.
Il semblerait que Kooka soit en panne de développement... Il y a donc peut d'espoir pour qu'il intègre tesseract à court ou moyen terme.

C'est dommage ! kooka était un beau projet... Quelqu'un reprendra bien un jour le flambeau !

Sorbus a écritPour Xsane, le développement semble se poursuivre activement (la dernière version sous Gutsy est là 0.991... la plus récente est la 0.995). Mais il n'est pas fait mention de tesseract dans les projets... Donc, l'éventuelle intégration de tesseract dans Xsane, ce n'est pas non plus pour demain.

Ben ça aussi c'est regrettable... On peut espérer qu'un jour ou l'autre il reconnaîtront la valeur de Tesseract !

zarer

Salut Sorbus !

Je viens d'installer la nouvelle version de gscan2pdf (0.9.20) avec le paquet de b52 pour Tesseract...

Sorbus a écritJ'ai édité mon message précédent : résolu dans le cas de mon installation. A voir pour les installations faites avec le paquet de b52.

Sous Ubuntu 7.10, le problème reste le même avec Tessdata :

Unable to load unicharset file /usr/local/share/tessdata/eng.unicharset

Il faut manifestement refaire les liens symboliques :

sudo ln -s /usr/share/tessdata /usr/local/share

Et tout est rétabli ! un seul lien symbolique donc pour avoir la ROC en français ! On progresse...

Par contre, je viens aussi d'abord confirmation d'une question que nous nous posions : comment se fait-il qu'avec gscan2pdf Tesseract peut faire la ROC sur un fichier .png :

Importing /media/disk-1/home/zamasp/Desktop/nouvelles/nouvelle2.3.1.png
Format Portable Network Graphics
Importing ~/Desktop/nouvelles/nouvelle2.3.1.png, format Portable Network Graphics
Added /tmp/rJ8jpjygzS/9gBO1rabIn.png at page 1 with resolution 28
Process 20799 exited.
convert /tmp/rJ8jpjygzS/9gBO1rabIn.png /tmp/rJ8jpjygzS/1rHV9jBq88.tif; tesseract /tmp/rJ8jpjygzS/1rHV9jBq88.tif /tmp/rJ8jpjygzS/lrsCGux56g -l fra; rm /tmp/rJ8jpjygzS/1rHV9jBq88.tif
Forked PID 20808
Tesseract Open Source OCR Engine
Process 20808 exited.
Waiting to reap process at /usr/bin/gscan2pdf line 5983.
Reaped PID -1

Réponse : il faut compter parmi les dépendances, pour la ROC sur un autre format d'image (.png, .jpg, etc.) que .tif, imagemagick !

gscan2pdf sollicite imagemagick pour créer un fichier temporaire au format .tif avant de lancer la ROC avec Tesseract :

convert /tmp/rJ8jpjygzS/9gBO1rabIn.png /tmp/rJ8jpjygzS/1rHV9jBq88.tif; tesseract /tmp/rJ8jpjygzS/1rHV9jBq88.tif /tmp/rJ8jpjygzS/lrsCGux56g -l fra; rm /tmp/rJ8jpjygzS/1rHV9jBq88.tif

Pas mal ! Astucieux !

Autrement dit, il faut impérativement ajouter imagemagick dans les dépendances de gscan2pdf !

@+

Sorbus

un seul lien symbolique donc pour avoir la ROC en français ! On progresse...
Une petite modification dans le paquet de b52 ne résoudrait-elle pas complètement le problème ?

Merci pour ce test pour les images .png, .jpg... Oui... c'est astucieux. C'est bien noté pour ça :il faut impérativement ajouter imagemagick dans les dépendances de gscan2pdf !

Bushman02

Je prends le train en marche : je n'utilise Ubuntu (Gutsy, Gnome) que depuis trois semaines. J'ai longtemps pataugé dans les problèmes d'OCR sous une autre distribution et je m'étais fait à l'idée que Linux et l'OCR n'allaient pas ensemble. Or j'ai suivi les conseils de ce forum, installant naà¯vement tout ce que la machine me disait d'installer au fur et à mesure pour ce qui concerne Tesseract et gscan2pdf.
==> Merveille ! à quelques signes près, mes textes sont reconnus !
Grà¢ce à vos suggestions, tout ce qui nécessitait un temps trop long avec kooka+ocrad devient un jeu d'enfant : j'ai testé des documents qui m'avaient jadis posé problème et ça marche.
N.B. :1- j'utilise un petit scanner Canon Lide-30 et je le règle sur 300 à 600 dpi en mode trait.
2 - J'avais déjà installé Imagemagic
Merci à tous !

zarer

Salut Sorbus,

Sorbus a écritun seul lien symbolique donc pour avoir la ROC en français ! On progresse...
Une petite modification dans le paquet de b52 ne résoudrait-elle pas complètement le problème ?

J'ai essayé de faire moi-même le paquet .deb (mon premier paquet !) mais rien y fait : toujours le lien à créer !

Finalement, avec les conseils de b52, j'ai refait un second paquet tesseract contenant lui-même la création du lien symbolique (un fichier postinst) et ça marche sans souci !

Je vais ajouter un fichier complémentaire "postrm" de manière à supprimer le lien symbolique lors de désinstallation du paquet... histoire de ne pas laisser de trace !

:cool:

Sorbus a écritMerci pour ce test pour les images .png, .jpg... Oui... c'est astucieux. C'est bien noté pour ça :il faut impérativement ajouter imagemagick dans les dépendances de gscan2pdf !

Ouais... c'est bon à savoir !

😃

@+

zarer

Salut Sorbus,

Je ne comprenais pourquoi tu n'avais plus besoin de créer le lien symbolique :

Sorbus a écrit...dans le cas d'une installation de tesseract selon le tuto de la doc Ubuntu francophone, il n'y a plus besoin du lien symbolique. Je l'ai supprimé. gscan2pdf v.0.9.20 trouve les fichiers de langues sans problème dans /usr/local/share/tessdata.

Il reste à voir ce que ça donne dans le cas d'une installation avec le paquet de b52.

Si en effet, lors de l'installation de tessseract par les sources tu copies les fichiers du répertoire /tessdata dans /usr/local/share, comme tu l'indiques dans le tuto de la doc :

tar -zxvf tesseract-2.00.fra.tar.gz
cd tessdata
sudo cp * /usr/local/share/tessdata

Dans ce cas, effectivement, ça passe tout seul. Mais par conséquent tu as deux répertoires /tessdata... Il y en a un dans /usr/share, non ?

@+

Sorbus

@Bushmann02
Merci pour le retour. Et si tu peux, par la suite, tiens-nous au courant de tes éventuels tests, difficultés ou découvertes...

@zarer

tar -zxvf tesseract-2.00.fra.tar.gz
cd tessdata
sudo cp * /usr/local/share/tessdata
Dans ce cas, effectivement, ça passe tout seul. Mais par conséquent tu as deux répertoires /tessdata... Il y en a un dans /usr/share, non ?

Non. Il n'y en a qu'un : /usr/local/share/tessdata
Il n'y en a pas dans /usr/share

C'est pour cette raison que je pensais que l'installation de tesseract seul ne crée pas de dossier /usr/share/tessdata... et que la création de ce dossier à cet endroit venait peut-être du paquet de b52.

il faut impérativement ajouter imagemagick dans les dépendances de gscan2pdf !

Je viens d'installer gscan2pdf puis tesseract sur mon portable qui est sous Gutsy en architecture 64 bit.

Constats :

1°) les deux s'installent sans problème en 64 bit en suivant les indications de la doc Ubuntu francophone.

2°) Imagemagick est une dépendance qui est déjà installée par défaut lors de l'installation de gscan2pdf. Il n'y a donc pas besoin de s'en soucier... ça se fait tout seul :

monuser@Portable-monuser:~$ sudo dpkg --unpack gscan2pdf_0.9.20_all.deb
[sudo] password for monuser:
Sélection du paquet gscan2pdf précédemment désélectionné.
(Lecture de la base de données... 141167 fichiers et répertoires déjà installés.)
Dépaquetage de gscan2pdf (à partir de gscan2pdf_0.9.20_all.deb) ...
monuser@Portable-monuser:~$ sudo apt-get install -f
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Correction des dépendances... Fait
Les paquets supplémentaires suivants seront installés :
imagemagick libcompress-raw-zlib-perl libcompress-zlib-perl
libconfig-general-perl libgtk2-ex-simple-list-perl libio-compress-base-perl
libio-compress-zlib-perl libpdf-api2-perl libtiff-tools perlmagick
sane-utils
Paquets suggérés :
html2ps libtiff-opengl unpaper

Ceci dit, il était très intéressant de comprendre pourquoi gscan2pdf est potentiellement capable de traiter des fichiers png ou jpg avec tesseract... alors que tesseract ne le peut pas !

3°) un démarrage de gscan2pdf avant d'avoir installé tesseract et gocr produit ce message :

On comprends donc qu'il faut installer au moins un moteur ROC (tesseract ou gocr), ainsi que les paquets unpaper, djvulibre-bin... et le frontend scanadf.
Je ne vois pas de paquet nommé scanadf dans les dépà´ts Gutsy... mais je pense que scanadf est inclus dans sane (?).

4°) La capture d'image ci-dessus étant en pdf [Edit : je rectifie, pas en pdf, mais en PNG], j'ai essayé un traitement ocr dessus, d'abord avec gocr, ensuite avec tesseract...
gocr :

_
_ i__:-_rl:I__ rl : ll rrl_- rl_l_-_ _-__ p_- c_!__- _-__ _
Le frontend scanadf n'est pas d_spon_ble
L'enreg_strement au format Dj_ requ_ert djvuI_bre-b_n
I'out_I unpaper est manquant
La reconna_ssance opt_que de caractjres njcess_te gocr ou tesseract

0 ,N, , , , ,e, , , , , ,p, , , ,a, , , ,s, , , , , ,r, ,e, = ,a, , , ,ff, , , , _, ,c, , ,h, , , ,e, , , , r, , , , ,c, , ,e, , , , , ,m, , , , , , ,e, , , ,s, , ,s, , , ,a, , , ,g, , , ,e, , , ,

_aI_der

tesseract :

PEEàƒ?àƒàƒ**à‰àˆà‰à®à‰à®â€˜**â€˜*à®Iil1F11à®F!1à®à®1!**F11il1MIà®à®**àˆà‰à‰à‰à‰à‰"à®111il11!1111I"""à‰à‰à‰à‰!â€˜à®llà¯à¯à«à®à¯à®à®à®à®à®m
'= ?â€
llliillllill !'à‰'tÂ·:', eà«à«à«à«a 7 7 u=Â¥à«Â·, ià«à«à«à«n sà«à«à«i 7 7 Jtà® &à«à«à«à«Â·j!à®'!à® E 121

gocr après traitment unpaper :

_
_ i__:-_rl:I__ rl : ll rrl_- rl_l_-_ _-__ x_- ci__- _-__ _
Le frontend scanadf n'est pas dIsponIble
L'enregIstrement au format Dj_ requIe_ d)vulIbre bIn
I'outII unpaper est manquant
La reconnaIssance optIque de caracteres necessIte gocr ou tesseract

0 .Ne pas reaffIcher ce message,

_v_alIder

tesseract après traitement unpaper :

www Â«Â«Â«uwÂ«Â«Â«Â«mm Â«Â«Â«Â«mÂ«Â«Â«\Â«Â«Â«Â«Â«Â«Â«lÂ«Â«Â«
pa Frcurwtarwcl scarwaclf r1's
|_'ar1ragÂ¤strar*rÂ·1ar1t an.; Fc.:
I'c.Â¤Â¤...Â¤tÂ¤I Â¤...Â¤r1pÂ¤apÂ¤ar est r*rÂ·1ar1
ITà®I!'InI l'*Â·~Â·Ia pas rÅ“aFFÂ¤c|Â·1ar cs

Sur cet exemple, tesseract via gscan2pdf sur une image PNG, c'est pas encore ça...

zarer

Salut Sorbus,

Sorbus a écrit@zarer
tar -zxvf tesseract-2.00.fra.tar.gz
cd tessdata
sudo cp * /usr/local/share/tessdata
Dans ce cas, effectivement, ça passe tout seul. Mais par conséquent tu as deux répertoires /tessdata... Il y en a un dans /usr/share, non ?
Non. Il n'y en a qu'un : /usr/local/share/tessdata
Il n'y en a pas dans /usr/share

C'est pour cette raison que je pensais que l'installation de tesseract seul ne crée pas de dossier /usr/share/tessdata... et que la création de ce dossier à cet endroit venait peut-être du paquet de b52.

Alors je ne comprends pas... J'ai refait le paquet deb plusieurs fois (c'est mon premier paquet !) et systématiquement la "debianisation" (ce doit être ça !) installe /tessdata dans /usr/share...

La compilation depuis les sources doit, quant à elle, créer le répertoire /usr/local/share/tessdata. Je ne vois que cette explication.

L'inconvénient avec cette méthode (compilation des sources) c'est que ce n'est pas très propre : il serait bon d'ajouter la procédure pour faire place nette lors d'une mise à jour, tu ne crois pas ?

Ceci dit, il était très intéressant de comprendre pourquoi gscan2pdf est potentiellement capable de traiter des fichiers png ou jpg avec tesseract... alors que tesseract ne le peut pas !

Oui oui ça l'est... D'autant que partout l'on peut lire que tesseract ne reconnaà®t que le format .tif, ce qui est le cas, mais aidé par imagemagick avec gscan2pdf, tesseract fait des merveilles !

Je ne vois pas de paquet nommé scanadf dans les dépà´ts Gutsy... mais je pense que scanadf est inclus dans sane (?).

Oui oui scanadf est bien inclus dans le projet sane...

4°) La capture d'image ci-dessus étant en pdf, j'ai essayé un traitement ocr dessus, d'abord avec gocr, ensuite avec tesseract...
[...]
Sur cet exemple, tesseract via gscan2pdf sur une image PNG, c'est pas encore ça...

Tu as fait une ROC sur un pdf ou une image .png ?

Chez moi la ROC depuis la .png (avec imagemagick) ne pose aucun souci...

Sorbus

Tu as fait une ROC sur un pdf ou une image .png ?

Excuse... J'ai écrit trop vite "une image pdf"... Mais non, je voulais écrire "une image PNG" : la capture d'écran du message "Attention, il manque des packages" que j'ai placée dans mon précédent message : pas trop mal reconnue avec gocr, mais très mal avec tesseract.

J'avais déjà fait ce test sur mon fixe... sans avoir non plus de résultat correct avec gscan2pdf+tesseract sur des captures d'écran en PNG.

Sur quel type de fichier PNG as-tu fait tes tests (quelque chose de bien net, en noir sur blanc ?)

La compilation depuis les sources doit, quant à elle, créer le répertoire /usr/local/share/tessdata. Je ne vois que cette explication.

Oui... c'est la seule piste.

L'inconvénient avec cette méthode (compilation des sources) c'est que ce n'est pas très propre : il serait bon d'ajouter la procédure pour faire place nette lors d'une mise à jour, tu ne crois pas ?

En effet... il faudrait... Mais je n'ai jamais vraiment étudié la question pour les diverses applications que j'ai compilées jusqu'à présent...

Il faudrait que je puisse indiquer ça pour ceux qui ont installé comme moi.
Ensuite... on peut modifier la doc pour proposer plutà´t l'installation par le deb de b52 révisé par zarer...

zarer

Sorbus a écrit
Tu as fait une ROC sur un pdf ou une image .png ?
Excuse... J'ai écrit trop vite "une image pdf"... Mais non, je voulais écrire "une image PNG" : la capture d'écran du message "Attention, il manque des packages" que j'ai placée dans mon précédent message : pas trop mal reconnue avec gocr, mais très mal avec tesseract.

J'avais déjà fait ce test sur mon fixe... sans avoir non plus de résultat correct avec gscan2pdf+tesseract sur des captures d'écran en PNG.

Pas de probème...

Sorbus a écritSur quel type de fichier PNG as-tu fait tes tests (quelque chose de bien net, en noir sur blanc ?)

Oui oui une image nette en noir & blanc...

Sorbus a écrit
La compilation depuis les sources doit, quant à elle, créer le répertoire /usr/local/share/tessdata. Je ne vois que cette explication.
Oui... c'est la seule piste.

En fait c'est le cas... b52 vient de me le confirmer :

Lorsque ./configure est correctement construit, il est possible de lui passer (entre autre chose) comme paramètre :
$ ./configure --prefix=/usr
Ce qui coupe la chique au préfix/défaut qui est: </usr/local> pour </usr/local/bin/PROGRAMME>, etc ...
Donc un : $ ./configure --prefix=/usr donne: </usr/bin/PROGRAMME>, etc ...

Et lors d'une débianisation, ce paramètre est automatiquement défini.

Voilà l'explication... Le paquet source de Tesseract, et c'est normal, n'est pas debianeux !
L'installation par les depà´ts sous Lenny installe /tessdata dans /usr/share/tesseract-ocr...

Autrement dit, pour respecter l'organisation debian sur Ubuntu, il est "souhaitable" (je mets des guillements...) de placer /tessdata dans /usr/share...

Sorbus a écrit
L'inconvénient avec cette méthode (compilation des sources) c'est que ce n'est pas très propre : il serait bon d'ajouter la procédure pour faire place nette lors d'une mise à jour, tu ne crois pas ?
En effet... il faudrait... Mais je n'ai jamais vraiment étudié la question pour les diverses applications que j'ai compilées jusqu'à présent...

Je dis ça parce que c'est une des règles que moi-même j'oublie de m'appliquer : "ne rien installer que l'on ne peut pas désinstaller"...
😃

Sorbus

La piste est par là... et encore par ici. Je vais donc essayer de faire le nécessaire pour moi... et pour la doc.

Et je vais tester tesseract sur du PNG noir et blanc... Mais j'aurai noté au passage que GOCR ne se débrouille pas trop mal avec un PNG en couleurs...

Sorbus

J'ai désinstallé tesseract 2.01 par make uninstall... puis je l'ai réinstallé. J'ai donc indiqué la procédure de désinstallation dans la doc pour ceux qui l'installent en compilant. Pour une architecture en amd64, je pense d'ailleurs qu'il n'y a pas d'autre solution, puisque le paquet de b52 "tesseract_2.02-1_i386.deb" est destiné aux architectures i386.
Tiens... je vois d'ailleurs que c'est "tesseract 2.02" et non "2.01"... Vous avez trouvé ça oà¹ ?

Echo de mes derniers tests sur du PNG.

--> je note que l'on obtient beaucoup d'infos en lançant gscan2pdf dans un terminal avec la commande :

gscan2pdf --debug

--> je n'ai réussi à rien avec gscan2pdf+tesseract sur des captures d'écran en PNG, même en noir sur blanc (capture d'un texte en police 12 dans OOo)... ni sur une photo d'un texte à bonne résolution (mais pas très droit, et en noir sur fond brun/jaune), même après traitement unpaper.

--> je note que gscan2pdf importe les fichiers à la résolution qu'il "choisit" (j'ignore comment) :
Added /tmp/wEacDaTsL1/IZdUszDKTZ.png at page 1 with resolution 28
(j'ai vu aussi la résolution 72)...

--> j'ai été surpris que dans tous les cas, gocr produise un résultat, moyen et lisible, mais hélas généralement pas assez bon pour que la roc soit vraiment utile.

--> j'ai cependant obtenu aussi un résultat avec gscan2pdf+tesseract dans un seul cas : capture d'écran d'un texte OOo en police 36 (Times).
Sur ce texte, voici le résultat :

GOCR :

Il était un petit navire
qui n'avait jamais navigué

tesseract : rien

GOCR après traitement unpaper (options par défaut) :

Il était un petit navire
qui n'avait jamais navigué

tesseract après traitement unpaper (options par défaut) :

Il était un pctit navirc
qui n'avait jamais navigué

--> le traitement unpaper a ici un effet pour permettre à tesseract de travailler... (étonnant, car le texte de l'image PNG est initialement droit et sans parasite... GOCR s'en tire d'ailleurs très bien avec). Quel est l'effet de unpaper dans ce cas ? (je note que le traitement unpaper à notamment pour effet de convertir le PNG au format PNM... et qu'ensuite, pour la reconnaissance avec tesseract, gscan2pdf convertit le PNM en TIF).

--> On a l'impression que le post-traitement en français n'a pas été utilisé par tesseract puisque nous retrouvons des "e" transformés en "c"... pourtant, dans le terminal, j'ai bien :

convert /tmp/wEacDaTsL1/YYPgdoTgn1.pnm /tmp/wEacDaTsL1/U5z6EY6mC1.tif; tesseract /tmp/wEacDaTsL1/U5z6EY6mC1.tif /tmp/wEacDaTsL1/3J7efAh5c1 -l fra; rm /tmp/wEacDaTsL1/U5z6EY6mC1.tif

--> Dernier élément : pour la ROC avec GOCR, gscan2pdf convertit le PNG en PNM (de la même façon qu'il convertit le PNG en TIF pour tesseract). Tous les tests de ROC évoqués dans ce fil avec GOCR ont été réalisés sur des fichiers PNG... Il faudrait donc refaire ces tests directement sur des fichiers enregistrés en PNM. Cela résoudrait peut-être quelques interrogations du début de ce fil...

Voilà ... je stoppe les essais pour quelques jours, faute de temps... @+

zarer

Salut Sorbus,

Sorbus a écritJ'ai désinstallé tesseract 2.01 par make uninstall... puis je l'ai réinstallé. J'ai donc indiqué la procédure de désinstallation dans la doc pour ceux qui l'installent en compilant.

J'ai ressorti mes premiers bouquins sur UNIX/Linux pour retrouver ce sage conseil:

Il faut agir de manière réversible

Chaque fois que l'on installe un périphérique, un logiciel, que l'on met à jour des données, il faut pouvoir revenir en arrière car l'opération peut être accomplie incorrectement.

Je trouve que c'est même une règle qu'il faudrait appliquer systématiquement. Trop souvent je l'oublie dans mes articles et ne me l'applique pas assez...

Le paquet .deb est beaucoup plus facile à manipuler de ce point de vue-là . De plus, il s'intègre parfaitement au système de fichiers de Debian/Ubuntu.

Normalement, les programmes sâ€™installent dâ€™eux-mêmes dans les sous-répertoires /usr/local. Mais les paquets Debian ne doivent pas utiliser ce répertoire, car il est réservé à lâ€™usage privé de lâ€™administrateur système (ou de lâ€™utilisateur).

Mais pourquoi dans ce répertoire, et pas dans un autre ? Parce que Debian nâ€™installe jamais de fichiers sous /usr/local â€” cet arbre est réservé à lâ€™usage de lâ€™administrateur système. Sur un système Debian, de tels fichiers doivent plutà´t aller sous /usr.

Les positions exactes des exécutables, icà´nes, documentation, etc., sont spécifiées dans le standard de la hiérarchie de fichiers.

Voir le Guide du nouveau responsable Debian.

Les devs de Tesseract ne travaillent pour Debian... C'est à nous de nous adapter...

Sorbus a écritPour une architecture en amd64, je pense d'ailleurs qu'il n'y a pas d'autre solution, puisque le paquet de b52 "tesseract_2.02-1_i386.deb" est destiné aux architectures i386.
Tiens... je vois d'ailleurs que c'est "tesseract 2.02" et non "2.01"... Vous avez trouvé ça oà¹ ?

En fait, ça vient de la génération du paquet... c'est bien la version 2.01 : le prochain paquet respectera le n° de version...

Sorbus a écritEcho de mes derniers tests sur du PNG.
[...]
Voilà ... je stoppe les essais pour quelques jours, faute de temps... @+

Merci pour tous ces tests ! Très instructifs... Il va falloir approfondir cette histoire de traitement unpaper...

@+

Sorbus

ocube... tesseract... xsane
dernières nouvelles :
http://www.mandrivauser.de/viewtopic.php?pid=166894#p166894
http://www.geocities.com/thierryguy/ (voir "ocube - a tesseract wrapper")
http://www.geocities.com/thierryguy/ocube.html
http://ubuntuforums.org/archive/index.php/t-404619.html (voir "PART 2: SETTING UP A SCRIPT FOR BATCH PROCESSING" et la suite)
http://linuxappfinder.com/package/ocube

Il a déjà été question de ocube dans ce fil... Mais nous n'avons pas creusé. Ce qui semble intéressant... ce sont ces annonces : "ocube works well with xsane.", "ocube makes tesseract work with xsane! (scanner GUI)", "TesseractOCR goes XSANE !!!!"

Reste à comprendre comment... en français 😉

Sorbus

Et voilà (merci MadMax).
Testé... ça marche avec mon installation compilée de tesseract (et fichiers de langues placés dans /usr/local/share)... A tester par les utilisateurs du deb de b52.

« Page précédente Page suivante »