Was Training so ausmacht

Bin dank Clemens Neudecker auf das im Rahmen des succeed Projektes entwickelte Tool ocrevalUAtion gestoßen. Damit kann man seine OCR-Ergebnisse mit dem Original vergleichen und bekommt eine Übersicht über die typischen OCR-Fehler.

Ich habe mal eine Seite aus Bunte Bilder aus dem Sachſenlande genommen und hier sind die Werte für untrainiertes Tesseract 3.02.03 mit dem mitgelieferten "deu-frak":

CER	7,74
CER-DL	7,74
WER	27,65
WER (bag of words)	27,43

Dabei bedeutet CER: Character error rate, CER-DL: Character error rate nach Damerau-Levenshtein und WER: Word error rate.

Hier sind also nur knapp 92% aller Zeichen richtig und gar nur 72% aller Wörter.

Nun die im Laufe des Bunte Bilder Projektes auf den Buchtitel trainierte Variante:

CER	2,83
CER-DL	2,83
WER	7,78
WER (bag of words)	9,07

Es sind nun 97% aller Zeichen richtig und fast 91% aller Wörter! Fazit: Trainieren lohnt sich!

Dies deckt sich auch mit den Berechnung aus meinem früheren Beitrag "OCR Qualität bestimmen" bzw. aus Teil 9, wo die Worterkennungsrate 93% betrug.

Das Tool berechnet aber auch für jedes vorkommende Zeichen die Fehlerwahrscheinlichkeit, was hilft sein Augenmerk auf diese typischen Probleme zu lenken. Hier ein Beispiel des untrainierten Tesseract. Ins Auge fällt, daß dies (wie bereits beschrieben) kein langes-s erkennt. Sichtbar sind auch die Problemzeichen 'n', 'u' und 'ü':

Error rate per character and type

Character	Hex code	Total	Spurious	Confused	Lost	Error rate
	20	463	2	0	1	0,65
!	21	0	1	0	0	Infinity
"	22	0	1	0	0	Infinity
)	29	2	0	0	0	0,00
*	2a	2	0	1	0	50,00
,	2c	33	1	4	2	21,21
-	2d	6	0	2	0	33,33
.	2e	29	0	1	3	13,79
1	31	6	1	0	0	16,67
2	32	4	0	0	0	0,00
5	35	4	0	0	0	0,00
8	38	3	0	0	0	0,00
9	39	5	0	0	0	0,00
A	41	6	0	0	0	0,00
B	42	11	0	1	0	9,09
D	44	10	0	0	0	0,00
E	45	6	0	0	0	0,00
F	46	9	0	0	0	0,00
G	47	6	0	0	0	0,00
H	48	6	0	0	0	0,00
I	49	4	0	4	0	100,00
J	4a	5	0	0	0	0,00
K	4b	8	0	0	0	0,00
L	4c	1	0	0	0	0,00
M	4d	5	0	0	0	0,00
N	4e	4	0	0	0	0,00
O	4f	2	0	0	0	0,00
P	50	3	0	0	0	0,00
R	52	7	0	0	0	0,00
S	53	26	0	3	0	11,54
T	54	5	0	0	0	0,00
U	55	4	0	0	0	0,00
V	56	7	0	0	0	0,00
W	57	7	0	0	0	0,00
Z	5a	7	0	0	0	0,00
a	61	123	0	2	0	1,63
b	62	41	0	1	0	2,44
c	63	66	0	1	0	1,52
d	64	110	0	0	0	0,00
e	65	430	0	4	1	1,16
f	66	40	0	5	0	12,50
g	67	71	0	0	0	0,00
h	68	121	0	4	0	3,31
i	69	178	23	0	0	12,92
j	6a	3	4	0	0	133,33
k	6b	21	0	1	0	4,76
l	6c	91	2	0	0	2,20
m	6d	64	0	19	0	29,69
n	6e	249	7	7	0	5,62
o	6f	48	0	0	0	0,00
p	70	11	0	0	0	0,00
r	72	148	0	0	0	0,00
s	73	37	2	0	0	5,41
t	74	133	0	1	0	0,75
u	75	105	0	11	1	11,43
v	76	18	0	0	0	0,00
w	77	31	0	0	0	0,00
x	78	1	0	0	0	0,00
y	79	1	0	0	0	0,00
z	7a	38	0	0	0	0,00
«	ab	0	1	0	0	Infinity
»	bb	0	1	0	0	Infinity
Ä	c4	2	0	1	0	50,00
ß	df	7	0	0	0	0,00
ä	e4	13	0	0	0	0,00
ö	f6	11	0	0	0	0,00
ü	fc	21	0	9	0	42,86
ſ	17f	90	0	90	0	100,00
–	2013	2	0	2	0	100,00
—	2014	0	1	0	0	Infinity
“	201c	3	0	3	0	100,00
„	201e	3	0	3	0	100,00

Helferlein Postkorrektur von 'Und'

Mithilfe eines Scriptes, welches eigentlich Worttrennungen aufsammeln sollte habe ich festgestellt, daß in den schon korrigierten Texten ab und an das Wort 'und' mitten im Satz groß geschrieben war, zB.: 'Der Müller Und sein Sohn…'.

Eigentlich sollte ja, wie in meinem Beitrag "Erkennung von OCR- und Tippfehlern in Textdateien" beschrieben, die Verwendung von DPCustomMono2 solche Fehler bei der Korrektur sichtbar machen. Hat leider in diesem Beispiel nicht gut nicht funktioniert…

Da die korrigierten Texte aber Basis für ein Wörterbuch für Tesseract sind, kam es durch die gehäufte Verwendung von 'Und' zu einer sich selbstverstärkenden Schleife, die in neuen OCR-Texten immer öfter das 'Und' mit Großbuchstaben mitten in den Satz einbaut.

Dank Linux ist das Problem schnell behoben, ich habe jetzt ein Script, in welchen ich solche Kandidaten eintrage (Update: Script nun vereinfacht):

#!/bin/bash
if [ ! -e "$1" ]; then
    echo "needs a file on commandline"
    exit 1
fi
grep "[a-z]\+ Und" $1 && echo "#### found 'Und' (und) in $1"
grep "[a-z]\+U[a-z]\+" $1 && echo "#### found 'xxUxx' in $1"
grep "[a-z]\+ dein" $1 && echo "#### found 'dein' (dem) in $1"
grep "[a-z]\+ init" $1 && echo "#### found 'init' (mit) in $1"

Der Ausdruck '[a-z]\+ Und' im Grep heißt nichts anderes als 'Finde alle Stellen mit einem "Und", vor welchem ein Leerzeichen und davor mindestens ein Kleinbuchstabe steht.'

In einer Schleife lasse ich dies über die OCR-Texte laufen:

$> for i in ../txt/img*.txt; do bash find_typical_errors.sh $i; done| less

Voila! :)

Teil 9, Selbstversuch Ebook - Befreiung am Beispiel "Bunte Bilder aus dem Sachsenlande", Verbesserung Tesseracts Erkennungsrate

Im letzten Blogpost "OCR Qualität bestimmen" habe ich grob beschrieben, wie man beurteilen kann, wie gut die Erkennungsqualität der verschiedenen OCR-Engines ist.
Als Maß hatte ich dort die Worterkennungsrate verwendet, da diese im Vergleich zur Zeichenerkennungsrate genauer ist. Gerade bei Verfahren, die intern Wörterbücher verwenden, kann die Zeichenerkennungsrate hoch sein, der Text bleibt dennoch unleserlich.

Um die Erkennungsqualität von Tesseract 3.02 zu verbessern habe ich mir die Beschreibung der Konfigurationsoptionen unter http://www.sk-spell.sk.cx/tesseract-ocr-parameters-in-302-version angeschaut.

Folgende Werte hatte ich bisher in der Datei deu-frak.config stehen:

enable_new_segsearch 1
textord_space_size_is_variable 1
load_bigram_dawg 1

Die Worterkennungsrate betrug damit 86% (die Diskrepanz zum Wert 60% aus Blogpost rührt daher, daß die Wörter der benutzten Seite da noch nicht im fürs Training verwendeten Wörterbuch steckten. Dies zeigt, wie wichtig die Pflege eines korrekten Wörterbuches für die Erkennungsrate von Tesseract ist).

Im ersten Schritt habe ich nur einzelne der ff. Parameter (* zeigt Default an) verändert:

Parameter	0	1
enable_new_search	92%	(*) 86%
language_model_ngram	(*) 86%	36%
textord_old_baselines	89%	(*) 86%

Die Werte textord_space_size_is_variable, load_bigram_dawg, edges_use_new_outline_complexity, permute_script_word, ngram_permuter_activated, use_new_state_cost führten zu keiner Änderung der Erkennungsrate von 86%.

Warum die Erkennungsrate bei  language_model_ngram so stark einbricht, verstehe ich noch nicht.

Im zweiten Schritt habe ich die beiden Parameter, die eine Verbesserung zeigten, kombiniert. Voila!, die Worterkennungsrate steigt auf 93%!

Wer noch Hinweise für sinnvolle Kombinationsmöglichkeiten anderer Parameter hat, immer her damit! :)

OCR Qualität bestimmen

wdiff

Mit 'wdiff' habe ich nun mal den Vergleich gemacht zwischen trainiertem Tesseract, trainiertem Ocropus, und Tesseract in Standardauslieferung mit Deutsch (deu).

Dazu habe ich eine Seite als Vergleich herangezogen, die ich schon in http://art1pirat.blogspot.de/2013/01/teil-8-selbstversuch-ebook-befreiung-am.html voll korrigiert hatte.

Der Aufruf sieht so aus: "wdiff -s $CORRECT $OCRED | tail -1"

Ergebnisse

Tesseract (trainiert)
img110_tesseract.txt: 322 Wörter  193 60% gleich  0 0% eingefügt  129 40% verändert

Tesseract (deu)
img110_tesseract.txt: 322 Wörter  62 19% gleich  0 0% eingefügt  260 81% verändert

Ocropus 0.7 (trainiert)
img110_ocropus.txt: 419 Wörter  108 26% gleich  0 0% eingefügt  311 74% verändert

Fazit

Wie man sieht, Training lohnt sich. ;)
 
Ocropus 0.7 stürzt beim Training (sh. http://art1pirat.blogspot.de/2013/05/ocropus-07-training.html) ab, ich habe den letzten funktionierenden Zwischenstand (nach 5190 Schritten) des Modells genommen, den man via ff. Aufruf bekommt:

ocropus-rtrain 'ocropus/*/*.bin.png' -F 30 -d 1 -o bbads_fraktur

Dabei sorgt die Option -F 30 dafür, daß aller 30 Schritte das Modell (bbads_fraktur) gesichert wird.

Tesseract hat noch einen vermutlich für Fraktur besser arbeitenden Trainingsmodus namens Cube. Wer dazu Infos hat, immer her damit.

Ansonsten habe ich jetzt ein Werkzeug an der Hand die Auswirkungen der verschiedenen Optionen der OCR-Engines und der Vorverarbeitungen quantitativ zu überprüfen.

Erkennung von OCR- und Tippfehlern in Textdateien

Um Fehler in den Textdateien besser zu erkennen, haben die Distributed Proofreaders, ein internationales Projekt zur verteilten Korrekturlesung gescannter Dokumente, den Zeichensatz DPCustomMono2 entwickelt, der zu verwechselnde Zeichen in besonders prägnanter Weise darstellt.

Hier ein Beispiel der Seite 6 meines Projektes »Bunte Bilder aus dem Sachsenlande«

Einen Vergleich, wie gut DPCustomMono2 Fehler sichtbar macht, kann man auf der Font-Seite der Distributed Proofreaders selber vornehmen.