Debian Debian-France Debian-Facile Debian-fr.org Debian-fr.xyz Debian ? Communautés

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 11-01-2020 19:49:49

phlinux
Membre
Distrib. : Buster
Noyau : 4.19
(G)UI : Openbox (+Rox+Feh)
Inscription : 10-05-2009

Retour d'expérience sur ocrfeeder version du gitlab

Bsr,

Un des problèmes de la version "officielle" debian est l'impossibilité de générer un document multipages. L'export en odt est également mal exploitable car le texte se retrouve dans une sorte de sur-couche, un objet en fait .
La page du projet https://gitlab.gnome.org/GNOME/ocrfeeder/

Version actuelle : 0.8.1 compilée sous sid

Pour commencer on peut récupérer les éléments sources sur gitlab. Allons-y.

# pour récupérer les sources
apt install git


Se placer dans le rep de compil (par exemple ~/ocr), puis:

git clone https://gitlab.gnome.org/GNOME/ocrfeeder
cd ocrfeeder
./autogen.sh
make

C'est tout, si aucun message d'erreur n'apparaît. Il peut manquer quelques paquets; en voici une liste, sans doute non-exhaustive

gnome-common
libgtk2.0-dev    # fournit glib-gettext
yelp-tools        # fournit yelp.m4
python3-enchant
python3-sane
python3-reportlab
python3-odf
python3-gtkspellcheck
gir1.2-goocanvas-2.0    # GObject introspection data for GooCanvas

Une fois la compil réussie on peut lancer ocrfeeder

~/ocr/ocrfeeder/bin/ocrfeeder

Normalement ça fonctionne, et cette version ne comporte pas les bug indiqués plus haut.

Mais pour être plus propre, toujours à partir du répertoire des sources on peut en profiter pour construire un deb.
Pour ça voir le tuto du wiki DF sur cette page https://debian-facile.org/atelier:chant … uet-simple

Pour résumer ce tuto:

# paquets de construction
apt install build-essential automake autoconf libtool pkg-config libcurl4-openssl-dev intltool libxml2-dev libgtk2.0-dev libnotify-dev libglib2.0-dev libevent-dev checkinstall
# make déjà fait donc
checkinstall

J'ai rencontré quelques petits soucis notamment celui de devoir créer des répertoires à la main. C'est peut être dû au fait que je sois dans un chroot.

L'étape de configuration (./configure --les-options-qui-vont-bien) serait à tester avant de passer le make; dans un prochain post peut être.

Donc on se retrouve avec un paquet installé et bien sûr désinstallable.

Le seul petit souci est que les dépendances ne sont pas "liées" au paquet; si c'est possible ce serait une des modif à apporter à la construction

A plus

Dernière modification par phlinux (27-07-2021 16:37:01)


Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent

Hors ligne

#2 16-01-2020 16:01:43

phlinux
Membre
Distrib. : Buster
Noyau : 4.19
(G)UI : Openbox (+Rox+Feh)
Inscription : 10-05-2009

Re : Retour d'expérience sur ocrfeeder version du gitlab

Finalement la version du paquet que j'ai construit ne fonctionne pas, ou a fonctionné et ne marche plus.
Retour vers le script python généré avec ./autogen.sh; mais bien qu'il fonctionne, le traitement est très long surtout si on a bon nombre de pages à traiter.

Donc le plus rapide, et le moins agaçant, est d'utiliser la version cli. Voici un exemple de script, à améliorer, mais qui permet de lancer le traitement et d'aller faire les courses pendant ce temps.

#!/bin/bash

# commande de base
COM=~/ocr/ocrfeeder/bin/ocrfeeder-cli

REP1=/dossier_des_images_à_traiter

REP2=/dossier_des_textes_produits

# listage des images
LISTEIMG=`ls -1 $REP1/ | sort -n`

# lcd du traitement
for IMG in $LISTEIMG; do
    $COM -i $REP1/$IMG -f TXT -o $REP2/`echo ${IMG%.*}`.txt
done


Malgré tout une erreur concernant Gtk s'affiche au démarrage du script

/home/phlinux/ocr/ocrfeeder/bin/../src/ocrfeeder/util/lib.py:24: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
  from gi.repository import Gtk

Passer les arguments demandés dans l'interpréteur Python3 n'a rien changé

(sidchroot)ph@phlinux:~$ python3
Python 3.7.6 (default, Dec 19 2019, 09:25:23)
[GCC 9.2.1 20191130] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> gi.require_version('Gtk', '3.0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'gi' is not defined
>>> from gi.repository import Gtk
__main__:1: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.

La solution est d'indiquer ces mêmes arguments dans le script python qui regimbe. C'est lui : ~/ocr/ocrfeeder/src/ocrfeeder/util/lib.py auquel on va ajouter ce qu'il faut 

# original
import os
import mimetypes
from PIL import Image
import tempfile
from gi.repository import Gtk
import math
from .constants import *
import sane
import tempfile
import locale
import xml.etree.ElementTree as etree
from .log import debug
[.........]
# modifié
import os
import mimetypes
from PIL import Image
import tempfile
import gi     # ajout
gi.require_version('Gtk', '3.0')     # ajout
from gi.repository import Gtk
import math
from .constants import *
import sane
import tempfile
import locale
import xml.etree.ElementTree as etree
from .log import debug



Voilà, voilà....

Dernière modification par phlinux (27-07-2021 16:18:55)


Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent

Hors ligne

#3 27-07-2021 16:50:31

phlinux
Membre
Distrib. : Buster
Noyau : 4.19
(G)UI : Openbox (+Rox+Feh)
Inscription : 10-05-2009

Re : Retour d'expérience sur ocrfeeder version du gitlab

Yop,

Apparemment ça n'a pas intéressé beaucoup de membres...

Néanmoins une compilation d'une nouvelle version (0.8.3) sous Buster ne fonctionne malheureusement pas.
Le script décrit au-dessus est lancé et on attends.......et toujours rien. Arrêt du bouzin à la main (^c) et voici le retour

Traceback (most recent call last):
  File "./ocrfeeder-cli", line 141, in <module>
    resolution)
  File "/usr/local/bin/ocr/ocrfeeder/bin/../src/ocrfeeder/feeder/layoutAnalysis.py", line 493, in recognize
    for bounds in block_bounds]
  File "/usr/local/bin/ocr/ocrfeeder/bin/../src/ocrfeeder/feeder/layoutAnalysis.py", line 493, in <listcomp>
    for bounds in block_bounds]
  File "/usr/local/bin/ocr/ocrfeeder/bin/../src/ocrfeeder/feeder/layoutAnalysis.py", line 502, in __recognizeImageFromBounds
    text = self.readImage(clip)
  File "/usr/local/bin/ocr/ocrfeeder/bin/../src/ocrfeeder/feeder/layoutAnalysis.py", line 545, in readImage
    text = self.ocr_engine.read()
  File "/usr/local/bin/ocr/ocrfeeder/bin/../src/ocrfeeder/feeder/ocrEngines.py", line 90, in read
    return os.popen(self.engine_path + ' ' + parsed_arguments).read()


Il est à noter que même la version compilée sous Sid (voir au dessus) et testée sous Buster à le même comportement; bon ça peut paraître "normal", mais tout de même...
Si parmi ceux qui pratiquent le pypy le python, quelqu'un voulait bien se pencher, merci d'avance...

Dernière modification par phlinux (27-07-2021 16:54:22)


Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent

Hors ligne

#4 27-07-2021 17:34:35

phlinux
Membre
Distrib. : Buster
Noyau : 4.19
(G)UI : Openbox (+Rox+Feh)
Inscription : 10-05-2009

Re : Retour d'expérience sur ocrfeeder version du gitlab

Solution.
Il s'avère que ocrfeeder-cli demande quelques paramètres supplémentaires pour cette version (0.8.3).

Donc le minimum à préciser serait l'engine (moteur ocr). En reprenant le script du post#2 (ou directement sur la ligne de commande) ça peut donner :

#!/bin/bash

# compile du 20210727

COM=~/bin/ocr/ocrfeeder/bin/ocrfeeder-cli
REP1=/dossier_des_images_à_traiter
REP2=/dossier_des_textes_produits
LISTEIMG=`ls -1 $REP1/ | sort -n`
# respecter la mise en majuscule pour le type de sortie
EXT=ODT
# moteur ocr (impératif)
ENGINE=tesseract
LANGUAGE=en

for IMG in $LISTEIMG; do
    $COM -e $ENGINE -l $LANGUAGE -f $EXT -i $REP1/$IMG -o $REP2/`echo ${IMG%.*}`
done

Le type ODT ajoute directement l'extension au fichier de sortie mais ce n'est pas le cas pour TXT ou PDF (pas testé les autres)
A la prochaine...

Dernière modification par phlinux (27-07-2021 17:53:04)


Pages perso : feh, omegat, udisks, passerelle, schroot vraiment transparent

Hors ligne

#5 27-07-2021 18:29:16

David5647
Membre
Distrib. : Debian Bullseye/Sid
Noyau : 5.7.0-2-amd64
(G)UI : KDE/i3wm
Inscription : 27-08-2017

Re : Retour d'expérience sur ocrfeeder version du gitlab

Dans ton message en #2, c'est simplement un avertissement (warning) et pas une erreur (error). Le script se plaint seulement que la version de gtk n'a pas été précisée, en mettre une au "hasard" ne me semble pas pertinent.

Pour ton message en #3
. Quel code compiles tu? Tu pourrais te procurer le .deb issu de sid/testing, ou compiler depuis les sources de sid/testing puisque le paquet y est en version 0.8.3

#!/bin/bash
# telechargement des sources
wget http://deb.debian.org/debian/pool/main/o/ocrfeeder/ocrfeeder_0.8.3.orig.tar.xz
wget http://deb.debian.org/debian/pool/main/o/ocrfeeder/ocrfeeder_0.8.3-3.debian.tar.xz

# extraction
tar -xvf ocrfeeder_0.8.3.orig.tar.xz
tar -xvf ocrfeeder_0.8.3-3.debian.tar.xz -C ocrfeeder-0.8.3/

# compilation
cd ocrfeeder-0.8.3/
debuild -b -uc -us -rfakeroot

Plus généralement, si une nouvelle version sort et que la dernière version debian est en retard, tu peux récupérer simplement le ocrfeeder_x.x.x.debian.tar.xz, le ocrfeeder_x.x.x.orig.tar.xz étant directement le contenu du dépôt côté éditeur. Si il n'y a pas de différences majeurs (c-à-d modification des dépendances la plus part du temps), ça devrait passer.

3e point, pourquoi ocrfeeder, plutôt que directement tesseract? (Question naïve, je n'ai aucune idée des possibles différences en cli, j'utilise tesseract habituellement)

4e point, dans ton code,

$REP2/`echo ${IMG%.*}`

, j'aurai écrit directement

$REP2/${IMG%.*}

, le "echo" n'est pas utile.

Voilà pour les maigres p'tits trucs que je peux raconter la dessus.

Dernière modification par David5647 (27-07-2021 18:31:25)

Hors ligne

Pied de page des forums