Script OCR en masse

Version imprimable

23/04/2016, 08h02
lejimi

1 pièce(s) jointe(s)

Script OCR en masse

Bonjour,

j'ai un client qui voudrait que je lui fasse la saisie de tout un livre ancien. Pour gagner du temps, j'ai tout de suite pensé à l'OCR avec Tesseract.

En m'inspirant de cette page : https://www.linux.com/learn/how-scan...n-source-tools j'ai créé ce petit script (mon tout premier) qui a l'air de fonctionner : Pièce jointe 207736 Il est sans doute perfectible et je suis ouvert à toute suggestion.

Ce que je peine à comprendre, c'est la fin de l'article de linux.com qui propose un petit script de nettoyage des espaces : le script nettoie un texte sélectionné. Mais l'auteur ne précise pas dans quel contexte doit être faite cette sélection. On peut la faire dans n'importe-quel soft ? De plus je ne vois rien dans le script qui mentionne la sélection comme étant le texte sur lequel travailler (mais je débute en shell…)

Au final, je me dis que pour nettoyer le résultat de l'OCR, un script Python serait plus adapté en raison des outils de manipulation de chaînes que propose ce langage. D'où une dernière question : si je place ce script Python dans /usr/local/bin est-ce que mon, script mass-ocr pourra l'appeler comme s'il s'agissait de n'importe quelle commande ordinaire ? Inversement, si à l'avenir, je crée un script Python pour inclure l'ensemble de mes outils dans une interface graphique, est-ce que celui-ci pourra appeler le script-shell ?

Ah ! Je suis sous Debian 8, XFCE.

Merci de votre aide !

Edit : je tiens mon interface graphique ! gedit peut aussi bien lancer des scripts shell que des scripts Python comme si c'était des greffons.
24/04/2016, 23h55
Jipété

1 pièce(s) jointe(s)

Salut,

Citation:

Envoyé par lejimi

Bonjour,

j'ai un client qui voudrait que je lui fasse la saisie de tout un livre ancien. Pour gagner du temps, j'ai tout de suite pensé à l'OCR avec Tesseract.

:aie:
Gain de temps et OCR c'est incompatible !
Si tu veux passer tes scans à l'OCR c'est pour transformer des fichiers images en fichiers textes, ce qui va t'obliger, une fois la conversion terminée, à tout relire car tu n'as alors pas droit à la moindre erreur (j'ai en exemple un bouquin de Bukoswki mal OCRisé [si je peux me permettre ce néologisme] qui est à certains endroits une vraie catastrophe : point d'exclamation transformé en "L", ou l'inverse [là j'ai mis le L en majuscule pour qu'on comprenne bien de quoi il s'agit : dans le livre il est en minuscule], les accents qui sautent, etc. [Women, n° 5900 au Livre de poche]).

Et quand je vois le temps qu'a mis tesseract pour me scanner très mal limite illisible/inutilisable une demi-page A4 (environ, une minute), je me dis que tu n'es pas rendu...
À gauche le fichier original .tiff à 300 dpi, à droite le résultat de tesseract...
Pièce jointe 207824

S'il n'y a pas nécessité de traitement de texte après le scan, oublie l'OCR.

Citation:

Envoyé par lejimi

Ce que je peine à comprendre, c'est la fin de l'article de linux.com qui propose un petit script de nettoyage des espaces : le script nettoie un texte sélectionné. Mais l'auteur ne précise pas dans quel contexte doit être faite cette sélection. On peut la faire dans n'importe-quel soft ? De plus je ne vois rien dans le script qui mentionne la sélection comme étant le texte sur lequel travailler (mais je débute en shell…)

Pas des espaces ! De la numérotation des pages, nuance, tout simplement en faisant sauter la première ou la dernière ligne de chaque page. Ce qui veut dire, au passage, que s'il y a des pages avec texte et sans numérotation, ben c'est la dernière ou la première ligne du texte qui va sauter... :aie: :aie: :aie:
Quant à la sélection, il n'y en a pas : l'outil prend les fichiers (qui correspondent aux pages) un par un et voilà.

Citation:

Envoyé par lejimi

D'où une dernière question : si je place ce script Python dans /usr/local/bin est-ce que mon, script mass-ocr pourra l'appeler comme s'il s'agissait de n'importe quelle commande ordinaire ? Inversement, si à l'avenir, je crée un script Python pour inclure l'ensemble de mes outils dans une interface graphique, est-ce que celui-ci pourra appeler le script-shell ?

Oui et oui, mais les scripts peuvent également être n'importe où et tu peux quand même les appeler : suffit de préciser le chemin complet dans le nom du script, genre /chemin/complet/vers/script.
25/04/2016, 02h13
lejimi

M'est avis que ça ira quand même plus vite que de taper "à la flic" juste avec les deux index. J'ai déjà OCRisé au boulot (sous Ouinedaube) et avec le rechercher-remplacer de LibreOffice, ça se décoquillait pas mal.

Sinon, je persiste (mais je signe pas : demain je dois signer ma déclaration de revenus, nul ne m'en voudra d'économiser mes forces) : il y a bien à la fin de la page que j'indique un bout de code qui supprime les sauts de lignes d'une sélection (mais ça Gedit le fait de série) et se débrouille pour ne laisser qu'un espace à la fois.

Du coup mon script mass-ocr, je dois pouvoir le transformer en plugin Gedit en remplaçant le complete.txt de la fin par $CURRENT_DOCUMENT_OU_JE_SAIS_PLUS_QUOI_DU_MÊME_GENRE ?
25/04/2016, 09h10
Jipété

Citation:

Envoyé par lejimi

M'est avis que ça ira quand même plus vite que de taper "à la flic" juste avec les deux index. J'ai déjà OCRisé au boulot (sous Ouinedaube) et avec le rechercher-remplacer de LibreOffice, ça se décoquillait pas mal.

Je n'en suis pas convaincu : dans l'exemple que je donne, rien n'est exploitable, il faut donc perdre du temps à s'en rendre compte puis tout retaper.
Donc, mathématiquement parlant, tout retaper directement prendrait moins de temps.
Mais tu ne réponds pas à la question principale : OCR'iser ce livre une fois celui-si scanné, est-ce vraiment nécessaire ?
Enfin, c'est toi qui voit, hein...

EDIT : je réalise après coup que tu as peut-être saisi ta réponse après que ce fil ait été déplacé par un modo, en faisant sauter l'image que j'avais insérée, auquel cas tu ne l'as pas vue... Je l'ai retrouvée et réinsérée, je t'invite à y jeter un œil.

Citation:

Envoyé par lejimi

il y a bien à la fin de la page que j'indique un bout de code qui supprime les sauts de lignes d'une sélection (mais ça Gedit le fait de série) et se débrouille pour ne laisser qu'un espace à la fois.

Oui, désolé, je ne l'ai pas vu, hier... :oops:
25/04/2016, 16h19
lejimi

Je suis obligé d'OCRifier car au départ c'était la demande d'un client qui projette une ré-édition.

Quel logiciel d'OCR utilises-tu ? Car avec Free OCR sous Windows et Tesseract sous Debian, j'obtiens des résultats bien meilleurs que les tiens et parfaitement exploitables.
25/04/2016, 16h25
Christophe

Avec des bons logiciels sous Windows, on arrive à un résultat acceptable, après correction.

Sous Linux, je sais pas l'efficacité des produits dispo.
25/04/2016, 17h24
Jipété

Citation:

Envoyé par lejimi

Je suis obligé d'OCRifier car au départ c'était la demande d'un client qui projette une ré-édition.

Ouais, ben tu pourrais parfaitement mettre en page des fichiers .TIFF ; s'il n'est pas question de toucher au texte, personne n'y verrait que du feu. 'fin bon, j'dis ça j'dis rien, hein :P

Citation:

Envoyé par lejimi

Quel logiciel d'OCR utilises-tu ? Car avec Free OCR sous Windows et Tesseract sous Debian, j'obtiens des résultats bien meilleurs que les tiens et parfaitement exploitables.

Le tesseract comme toi.
La seule différence c'est que je pars d'un fichier .jpg que j'ai converti avec The Gimp en .Tiff à 300 dpi. Effectivement, je suis extrêmement surpris d'un si mauvais résultat, et je n'ai pas d'explications.

Et comme ça m'énerve :mouarf:, je viens de refaire un essai à partir d'un fichier natif en 300 dpi et là, c'est nettement mieux ! 95 % de réussite, c'est bien, surtout que le document ne s'y prêtait pas trop : un imprimé administratif (c'est tout ce que j'ai sous la main en 300 dpi) ! Mais ça ne t'empêchera pas d'être obligé de tout relire.
Sale corvée, si le sujet n'est pas intéressant...
25/04/2016, 17h51
lejimi

Tout relire, ça fait partie de la prestation, même si tu saisis à la main : les fautes de frappes sont inévitables.

Et le client étant éditeur il veut bien un "vrai" fichier texte pour le confier à son propre service de mise en page.
25/04/2016, 20h09
Jipété

Citation:

Envoyé par lejimi

Tout relire, ça fait partie de la prestation, même si tu saisis à la main : les fautes de frappes sont inévitables.

Hé bien, je peux te dire que pourtant on trouve de plus en plus d'horreurs dans les éditions récentes, à croire que le métier de correcteur a disparu :koi:

Citation:

Envoyé par lejimi

Et le client étant éditeur il veut bien un "vrai" fichier texte pour le confier à son propre service de mise en page.

Pas d'bol ! :P
Allez, bon courage...
25/04/2016, 21h39
lejimi

Oui, je suppose que les éditeurs font des économies de bouts de chandelles là-dessus. Même chez Folio (Gallimard !) on trouve des horreurs. Je crois aussi que certains éditeurs font faire leur saisie en Inde, là encore parce que c'est moins cher. Je viens de terminer la lecture de l'autobiographie de Monfreid (au Seuil…) : c'est une catastrophe : au moins une énorme co(q)uille par page…

Et sinon ? Pour ce qui est de mes questions ?
25/04/2016, 23h22
Jipété

Citation:

Envoyé par lejimi

Oui, je suppose que les éditeurs font des économies de bouts de chandelles là-dessus. Même chez Folio (Gallimard !) on trouve des horreurs. Je crois aussi que certains éditeurs font faire leur saisie en Inde, là encore parce que c'est moins cher. Je viens de terminer la lecture de l'autobiographie de Monfreid (au Seuil…) : c'est une catastrophe : au moins une énorme co(q)uille par page…

OMG !
Enfin bon, merci pour ton point de vue, je me sens moins seul :ccool:

Citation:

Envoyé par lejimi

Et sinon ? Pour ce qui est de mes questions ?

Il n'en reste plus qu'une, il me semble :

Citation:

Envoyé par lejimi

Du coup mon script mass-ocr, je dois pouvoir le transformer en plugin Gedit en remplaçant le complete.txt de la fin par $CURRENT_DOCUMENT_OU_JE_SAIS_PLUS_QUOI_DU_MÊME_GENRE ?

Alors pour le plugin je ne sais pas, je n'utilise pas Gedit (et je ne l'ai pas dans ma machine).
Et pour la suite, je ne comprends pas la question, dans la mesure où c'est toi, enfin, l'utilisateur, qui fait générer complete.txt, ou CURRENT_DOCUMENT.txt, ou toto.txt ou abcd.txt, ou MonBouquin.txt, comme tu le sens.
Je ne capte pas bien la question (peut-être à cause de cette histoire de plugin, désolé)...
26/04/2016, 08h01
lejimi

Non, c'est peut-être moi qui ne suis pas clair. En gros, mon script en version "standalone" produit un complete.txt qui regroupe les résultats de l'OCR. Mais j'aimerais regrouper ces résultats sans le document déjà ouvert dans Gedit, celui que les autres extensions désignent par la fameuse variable. Donc je suppose que c'est elle que je dois utiliser.

J'ai d'autres question qui sont restées sans réponse concernant le script de nettoyage des espaces et des sauts de lignes qui est en lien dans mon premier message : où dois-je sélectionné le texte pour que le script s'applique à icelui ? Et qu'est-ce qui fait dans l'implémentation du script, qu'il ne traitera que la sélection ? Je n'y vois nulle part une ligne qui ferait l'acquisition de données…
26/04/2016, 09h54
Jipété

Yop !

Citation:

Envoyé par lejimi

J'ai d'autres question qui sont restées sans réponse concernant le script de nettoyage des espaces et des sauts de lignes qui est en lien dans mon premier message : où dois-je sélectionné le texte pour que le script s'applique à icelui ? Et qu'est-ce qui fait dans l'implémentation du script, qu'il ne traitera que la sélection ? Je n'y vois nulle part une ligne qui ferait l'acquisition de données…

où dois-je sélectionner le texte pour que le script s'applique à icelui ?
Dans Gedit il dit le monsieur :

Citation:

I defined the following tool to work on the current selection:
[snip]
With this, you can select some lines and press your defined shortcut. The whole selection becomes one line.

Pour l'autre question, j'en sais rien...
26/04/2016, 13h26
lejimi

Ah oui ! J'avais pas vu ! Faut reconnaître qu'il le dit pas fort…
28/04/2016, 15h40
cervo

:salut:
Bon ma solution n'est pas forcement pratique mais je pense que le but final c'est d'arriver a tes fins. Il y a un outil gratuit ChronoScan qui peut te faire de l'OCR de très bonne qualité. Il est utilisable en ligne de commande. En un rien de temps tu peux gérer impec ! ;)
28/04/2016, 19h46
Jipété

Citation:

Envoyé par cervo

Il y a un outil gratuit ChronoScan qui peut te faire de l'OCR de très bonne qualité. Il est utilisable en ligne de commande. En un rien de temps tu peux gérer impec ! ;)

C'est cela, oui...
On est quand même dans le forum Linux, là, et sur la page Download du logiciel que tu préconises on peut lire

Citation:

Supported Operating Systems

Windows 10 (x86 and x64)
Windows 8.1 (x86 and x64)
Windows 8 (x86 and x64)
Windows 7 (x86 and x64)
Windows Vista (x86 and x64)
Windows XP Professional SP3 (x86 and x64)
Windows XP Media Center Edition SP3
Windows XP Home SP3
Windows Server 2008
Windows Server 2003 SP2

et avec un plus un Nag Screen pour la version personnelle et gratuite... :roll:
04/05/2016, 09h46
cervo

:salut:
:mouarf: j'avais oublié qu'on etait en mode linux !... Souvent faut coupler les 2 pour en tirer profit ... meme si je suis conscient que " Linux is the BEST ":mouarf::mouarf:
04/05/2016, 15h56
lejimi

Je suis content que Cervo ai fait remonté ce sujet : cela me donne l'occasion d'un petit bilan.

Mon client a finalement confirmé sa commande et m'a fait parvenir les pages du livre sans reliure, ce qui permet de les placer bien à plat sous le scanner (avantage). Le papier est bien jauni, inconvénient, mais il m'a suffit d'en tenir compte en poussant fortement les paramètres --contrast et --brightness de la commande scanimage. J'ai également opté pour une résolution de 600ppp

Moralité, j'ai pu OCRiser environ 27 pages en deux heures, en n'ayant que très peu de corrections à faire. Même la préface composée en italique n'a pas posé de problèmes. Traiter les 166 pages du livre ne devrait donc prendre que quelques jours : au temps pour l'OCR qui n'est pas un gain de temps !

Petit mystère, mon scanner est "baladeur" : la commande scanimage -L me renvoie des valeurs différentes alors que l'appareil est toujours branché sur le même port USB. Du coup --device 'genesys:libusb:001:003' doit parfois être transformé en --device 'genesys:libusb:003:007' ou autre. Finalement j'ai supprimé cette option : s'il n'y a qu'un scanner, scanimage le retrouve de toute façon ; cela prend juste un peu de temps.
05/05/2016, 00h41
Jipété

Merci pour ton retour,

et bien joué !
:ccool:

Citation:

Envoyé par lejimi

Mon client a finalement confirmé sa commande et m'a fait parvenir les pages du livre sans reliure, ce qui permet de les placer bien à plat sous le scanner (avantage). Le papier est bien jauni, inconvénient, mais il m'a suffit d'en tenir compte en poussant fortement les paramètres --contrast et --brightness de la commande scanimage. J'ai également opté pour une résolution de 600ppp.

T'as bien de la chance : il se trouve que j'ai fait un test, hier ou avant-hier, directement inspiré de ce que tu as fourni ici, et je dois avoir une version moisie de ScanImage, ce "machin" (pas d'autre mot, et restons poli) ne reconnaît pas l'option --contrast, gère comme il le sent l'option --brigthness +20 (sortie console = scanimage: rounded value of brightness from 20 to 3) et ignore purement et simplement --resolution 300 : le fichier résultant se retrouve à 72 dpi dans The Gimp, autant dire que tout le reste derrière n'amène qu'à une OCRisation à vomir :evilred:.

Bah, au moins je sais que si j'avais un taf lourd là-dessus faudrait que je commence par mettre à jour le bazar.
Et en attendant, je continue avec Sane.
05/05/2016, 08h13
lejimi

Honnêtement, Jipété, je ne connais pas assez le sujet pour savoir ce qui ne va pas chez toi. Peut-être ta version de scanimage est-elle plus vieille ou plus récente que la mienne ?

J'avais déjà fait ce type de travail sous Windows et j'avais eu de bons résultats avec FreeOCR (solution graphique, outils de nettoyage intégrés…) Pourtant, je travaillais sur des formats poches, avec une belle ombre entre les deux pages, malgré un aplatissement « vigoureux ».