ubuntuusers.de

Hallo nochmal, ich hab' die fehlenden Abhängigkeiten aus debian testing eingebunden/installiert, hat geklappt, make funktioniert und es trainiert jetzt fleißig.

Ich beschäftige mich auch gerade mit dem Training von tesseract-ocr (3.03.02), genauer wollte zunächst mal alle Kommandos für das Training installieren. Vorgegangen bin ich nach der Anleitung in der FAQ:

Where are the training tools for Ubuntu 14.04 ?

sudo apt-get build-dep tesseract-ocr
sudo apt-get install devscripts
dget http://http.debian.net/debian/pool/main/t/tesseract/tesseract_3.03.03-1.dsc
tar xvzf tesseract_3.03.03.orig.tar.gz
cd tesseract-3.03
zcat ../tesseract_3.03.03-1.diff.gz | patch -p1
debuild -us -uc
cd ..
sudo dpkg -i *.deb

http://code.google.com/p/tesseract-ocr/wiki/FAQ#Where_are_the_training_tools_for_Ubuntu_14.04_?

Gekommen bin ich bis zu dieser Zeile:

dget http://http.debian.net/debian/pool/main/t/tesseract/tesseract_3.03.03-1.dsc

Da gab es dann diese Fehlermeldung:

1
2
3
4
5

tesseract_3.03.03-1.dsc:
dscverify: tesseract_3.03.03-1.dsc failed signature check:
gpg: Unterschrift vom Sa 29 Mär 2014 01:09:16 CET mittels DSA-Schlüssel ID 34B36856
gpg: Unterschrift kann nicht geprüft werden: Öffentlicher Schlüssel nicht gefunden
Validation FAILED!!

Benötigt man dazu das debian-keyring-Package? Dann habe ich noch gemerkt, dass in ~/.gnupg die Datei pubring.gpg leer ist.

Mit den folgenden beiden Befehlen bekomme ich keine Ausgabe:

gpg --list-secret-keys
gpg --list-keys

Mit Synaptic aber auch mit dpkg und mit apt habe ich seit Oktober schon alle möglichen Programme installiert und noch nie Probleme mit Signaturen oder Schlüsseln gehabt.

Ich probiere mal das hier:

gpg --keyserver keyserver.ubuntu.com --recv-keys 34B36856

Mit folgendem Befehl bin ich jetzt einen ganzen Schritt weitergekommen:

dscverify --keyring ~/.gnupg/pubring.gpg  tesseract_3.03.03-1.dsc 

Der Befehl dscverify erwartet (laut Manpage) Schlüsselbunde nämlich in ganz bestimmten Verzeichnissen mit ganz bestimmten Dateinamen wie z.B. " /usr/share/keyrings/debian-keyring.gpg". Mit dem vorherigen gpg-Befehl hatte ich aber nur die Datei ~/.gnupg/pubring.gpg upgedatet bzw. gefüllt. Deshalb muss man diese Datei extra als Schlüsselbund an den Befehl dscverify übergeben.

Als Erfolgsmeldung kommt dann:

tesseract_3.03.03-1.dsc:
      Good signature found
   validating tesseract_3.03.03.orig.tar.gz
   validating tesseract_3.03.03-1.diff.gz
All files validated successfully.

Den Rest schaffe ich jetzt glaube ich alleine. 😉

Hi!

Na, dann viel Erfolg! Vielleicht kannst du ja den alten Archiv/tesseract-ocr/tesseract-ocr trainieren-Artikel wiederbeleben? Ich hab ihn ins Archiv geschoben, weil er für Version 2 war; aber so viel hat sich imho nicht geändert, hab' mich aber dann nicht mehr am Trainieren von Tesseract versucht...

so long
hank

Hi! Ich versuch's morgen mal. Gerade bin ich absolut fasziniert/schockiert von dem "Linux-Nerd dringend gesucht"-Thread über die EDV-Verhältnisse in Bayern. 😉

Ich denke im Script im Abschnitt tesseract-ocr (Abschnitt „xsane2tess“) befindet sich ein Fehler. Da ich dieses Programm nicht kenne, wäre es nett, wen mal einer von euch einen Blick darauf werfen könnte.

Meine Vermutung ist, dass alles ab Zeile 149 nicht mehr zum Script gehört, sondern ein normaler Text ist.

VlG

Dimanche schrieb:

Meine Vermutung ist, dass alles ab Zeile 149 nicht mehr zum Script gehört, sondern ein normaler Text ist.

Ja, da hast Du recht. Danke fürs Bescheid geben. Ich habe das gefixt. ☺

Liebe Grüße,
Torsten

Hi!

Der Artikel an sich passt auch für Tesseract 4.0 unter Bionic.

Allerdings funktioniert das, was auf der Kommandozeile ohne Probleme geht, im xsane2tess-Skript nicht; ich bekomme im Log seltsame Ausgaben, wie

read_params_file: Can't open /usr/share/tesseract-ocr/4.00/tessdata/configs/
Tesseract Open Source OCR Engine v4.0.0-beta.1 with Leptonica
Warning. Invalid resolution 0 dpi. Using 70 instead.
Estimating resolution as 414

Eine Texterkennung erfolgt dann, wenn es auch recht lange dauert.

Noch wirrer wird's, wenn ich versuche, das hocr-Config-File zu verwenden. Das Skript findet, wie oben beschrieben, die Config-Datei nicht, meldet dann

Error in findFileFormatStream: failed to read first 12 bytes of file

und versucht dann anscheinend, per 'cat' alle versteckten Daten aus meinem Home-Verzeichnis zu verbinden (warum auch immer), was natürlich nicht funktioniert,

cat: .: Is a directory
cat: ..: Is a directory
cat: .abtool: Is a directory
cat: .adobe: Is a directory
...

und schließlich scheitert dann auch der rm-Befehl aus dem Skript 😲 ...

rm: cannot remove '.': Is a directory
rm: cannot remove '..': Is a directory
rm: cannot remove '.abtool': Is a directory
rm: cannot remove '.adobe': Is a directory

mit dem eigentlich nur die bei funktionierendem Skript (also unter Xenial, mit tesseract 3.0.x ) erstellte Temporärdatei wieder gelöscht wird...

EDIT OOps, oder doch nicht - die versteckten Dateien scheinen alle weg zu sein 😳

Kann mir keinen Reim darauf machen - hat sich von Xenial zu Bionic etwas Grundlegendes bei der Verwendung von Skripten verändert? Oder liegt es an tesseract 4.00?

Hm, getetst bionic lass ich also erstmal weg, trusty wüdre ich demnächst rausnehmen, und das ganze entsprechend etwas straffen.

so long
hank

Heinrich_Schwietering schrieb:

Kann mir keinen Reim darauf machen - hat sich von Xenial zu Bionic etwas Grundlegendes bei der Verwendung von Skripten verändert? Oder liegt es an tesseract 4.00?

Hallo, ich kenne das nicht, aber zum rm und Skripte mal so ins Blaue: Wenn statt Dateien in einer neuen Version Verzeichnisse an der gleichen Stelle liegen, kann das natürlich Probleme bei der Verwendung von cat, rm und Konsorten geben.

Gruß BillMaier

Hi!

Danke für dein Interesse - mir scheint das an der neuen tesseract-Version zu liegen. Während im Terminal alle Optionen vernünftig erkannt werden, scheint es mit den Anweisungen im Skript nicht zu funktionieren. Die zusätzliche Option "hocr" wird nicht erkannt; dann scheint die Leerstelle zwischen den Einträgen für die Sprache zu Verwirrung zu sorgen (wobei ich mir auch nicht sicher bin, dass Sprache die richtig verwendet wird - tesseract meckert z.T. wegen "diacritics" die aber im Deutschen zu hauf vorkommen, bei jedem Umlaut), und das Skript irgendwie im Homeverzeichnis landet, und dort etwas aus dem Ruder läuft...

Sowas in der Art hatte ich schon mal; weiß leider nicht mehr genau, was es war, und wie es geändert werden konnte.

Es wirkt auf mich so, als ob tesseract aus dem Skript heraus nicht an weitere Informationen kommt; so z.B. die Auflösung der Xsane-internen temporären Bilddatei - da "hilft" sich das Programm der Logmeldung nach ja such selber, die angebliche Auflösung "0" wird in 70 "korrigiert", um nachher auf 414 zu kommen - tatsächlich war das Bild mit 300 dpi eingescannt worden...

Andere xsane2OCR-Programme - die funktionieren alle nach dem selben Schema - machen da bisher eigentlich keine Probleme.

Vielleicht sollte ich mir tesseract mal ganz neu bauen, aktuell ist Version 4.1.irgendwas.

so long
hank

Hi!

Habe die Rätsel lösen können - zum einen mein Fehler 😳 bei der Eingabe der Optionen für die Konfigurationsdateien, zum anderen kann tesseract 4 die Auflösung der intern von XSane verwendeten Dateiformate nicht direkt auslesen... Daher die Meldung Warning. Invalid resolution 0 dpi. Using 70 instead. Estimating resolution as 414.

Mit dem überarbeiteten xsane2tess-Skript wird jetzt aus dem intern verwendeten ppm ein png mit fester Auflösung (habe 300 gewählt, für OCR die passende Größe), damit taucht der Fehler nicht mehr auf, und zudem können jetzt auch direkt PDFs aus dem Skript heraus erstellt werden, ohne dass tesseract daraus Riesen-PDFs erstellt.

Die Erkennung mit tesseract 4 dauert allerdings etwas länger, mein Rechner (der allerdings auch schon ca 4 Jahre alt ist) braucht für ein Strichzeichnungs-PDF in Din-A4 etwa 30 Sekunden.

Tests wie immer willkommen!

so long
hank