Monthly Archives

5 Articles
Posted by Anna Brandt on

Tools im Layout-Reiter

Release 1.10.

Der Layout-Reiter hat zwei weitere Tools, auf die wir in unserem letzten Post noch nicht eingegangen sind. Sie sind vor allem bei der Layoutkorrektur sehr nützlich und ersparen lästige Kleinarbeit.

Das erste ist dazu da, um die Reading Order zu korrigieren. Wenn eine oder mehrere Textregions ausgewählt sind, werden durch dieses Tool Baselines („children of the selected element“) automatisch nach ihrer Position im Koordinatensystem der Seite geordnet. Also Baseline 1 beginnt links oben und von da weiterzählend bis rechts unten. In dem unten stehenden Beispiel wurde eine TR in mehrere zerschnitten, dabei ist aber die RO der Marginalien durcheinander gekommen. Das Tool erspart in so einem Fall die Arbeit, jede BL einzeln umbenennen zu müssen.

Das zweite Tool („assign child shapes“) hilft die BL der richtigen TR zuzuordnen. Dies kann nach dem Schneiden von Textregionen oder auch bei Baselines, die sich durch mehrere TRs ziehen, notwendig werden. Die BLs müssen dann einzeln im Layout-Reiter markiert und dort in die richtige TR geschoben werden. Alternativ markiert man die TR, in die die BL gehören und startet das Tool. Die Reading Order sollte anschließend noch einmal überprüft werden.

Posted by Dirk Alvermann on

„zwischen den Zeilen“ – Behandlung von Einfügungen

Mindestens genauso häufig wie Streichungen oder Schwärzungen kommen Überschreibungen oder zwischen die Zeilen geschriebene, eingefügte Textpassagen vor. Hier ist es in zweierlei Hinsicht nützlich, wenn man schon zu Anfang eines Projektes klärt, wie diese Fälle behandelt werden sollen.

In diesem einfachen Beispiel könnt Ihr sehen, wie wir solche Fälle handhaben.

Da wir Streichungen und Schwärzungen sowohl im Layout als auch im Text erfassen, ist es nur konsequent, wenn wir die Überschreibungen und Einfügungen ebenso behandeln. Meist werden solche Passagen schon bei der automatischen Layoutanalyse mit separaten Baselines versehen. Hin und wieder muss man da korrigieren. Auf jeden Fall wird jede Einfügung von uns als eigene Zeile behandelt und auch in der Reading Order entsprechend berücksichtigt.

Auf keinen Fall sollte man das transkribiren was über der Streichung steht, da diese Überschreibungen oder Einfügungen eine eigene Baseline haben. Auf diese Weise würde das Trainingsmaterial versfälscht, auch wenn die Präsentation des Textes für das menschliche Auge natürlich gefälliger wäre.

Posted by Dirk Alvermann on

Behandlung von Streichungen und Schwärzungen

HTR-Modelle behandeln gestrichenen Text genauso wie jeden anderen. Sie kennen da keinen Unterschied und bieten also immer ein Leseergebnis. Sie sind dabei sogar erstaunlich gut und lesen auch da noch sinnvolle Inhalte heraus, wo ein Transcriber längst aufgegeben hätte.

Das einfache Beispiel zeigt einen auch für das menschliche Auge noch lesbaren gestrichenen Text, den das HTR-Modell fast fehlerfrei gelesen hat. Richtig wäre die Lesung „billig vormeinet habe“.

Weil wir diese Fähigkeit der HTR-Modelle bereits in anderen Projekten kennenlernen durften, haben wir von Anfang an beschlossen, auch Streichungen und Schwärzungen, so gut es eben geht, zu transkribieren um dieses Potential der HTR ebenfalls auszunutzen. Die entsprechenden Passagen werden von uns im Text einfach als text-style „strike through“ getaggt und bleiben so auch für evtl. interne Suchabfragen kenntlich.

Möchte man diesen Aufwand nicht treiben, hat man schlicht die Möglichkeit, an den entsprechenden Textpassagen, die Streichungen oder Schwärzungen enthalten, in das Layout einzugreifen und bspw. die Baselines zu löschen oder entsprechend zu verkürzen. Dann „sieht“ die HTR solche Passagen nicht und kann sie auch nicht erkennen. Das ist aber nicht weniger aufwendig als der von uns gewählte Weg.

Auf keinen Fall sollte man an Streichungen generell mit dem „beliebten“ Ausdruck „[…]“ arbeiten. Die Transkriber wissen zwar was das Auslassungszeichen bedeutet, die HTR lernt hier aber, wenn viele solche Stellen ins Training kommen, etwas völlig Falsches.

Posted by Elisabeth Heigl on

Testsamples – die unparteiische Alternative

Wenn eine Projektkonzeption es nicht zulässt, den Aufbau von Testsets strategisch zu planen und zu organisieren, dann gibt es eine einfache Alternative: automatisch erstellte Samples. Sie stellen auch eine gute Ergänzung zu den von uns manuell erstellten Testsets dar, denn hier entscheiden nicht wir, sondern die Maschine, welches Material in das Testset kommt und welches nicht. Das läuft darauf hinaus, dass Transkribus einzelne Zeilen aus einer Menge von Seiten auswählt, die ihr natürlich zuvor zur Verfügung gestellt habt. Es handelt sich also um eine mehr oder weniger zufällige Auswahl. Das lohnt sich bei Projekten, die über sehr viel Material verfügen – also auch bei unserem.

Wir verwenden Samples als Gegenprobe zu unseren planmäßig manuell erstellten Testsets und weil Samples den statistischen Verfahren der Stichprobenerhebung vergleichbar sind, die die DFG in ihren Praxisregeln auch für die Überprüfung der Qualität der OCR empfiehlt.

Da HTR (anders als OCR) zeilenbasiert arbeitet, wandeln wir die Empfehlung der DFG etwas ab. Ich erkläre das am konkreten Beispiel: Für unser Modell Spruchakten_M-3K sollte eine Überprüfung der erzielten Lesegenauigkeit vorgenommen werden. Für unser Sample wurde zunächst eine Stichprobe von 600 Seiten gezogen, verteilt über den Gesamtzeitraum, für den das Modell arbeitet (1583-1627) und ausschließlich aus untrainiertem Material. Dafür wurde jede 20. Seite des Datensets ausgewählt. Bezogen auf das gesamte für diesen Zeitraum zur Verfügung stehende Material von 16.500 Seiten repräsentiert dieses Subset ca. 3,7%. All das geschieht auf dem eigenen Netzlaufwerk. Nachdem dieses Subset in Transkribus hochgeladen und mit der CITlab Advanced LA verarbeitet wurde (16.747 lines wurden insgesamt erkannt), ließen wir Transkribus ein Sample daraus erstellen. Es enthält 900 per Zufallsgenerator ausgewählte Zeilen. Das sind also ca. 5% des Subsets. Dieses Sample wurde nun mit GT versehen und als Testset zur Überprüfung des Modells genutzt.

Und so geht das in der Praxis: Im Menü „Tools“ wird die Funktion „Sample Compare“ aufgerufen. Unser Subset wird in der Collection ausgewählt und mit dem Button „add to sample“ zum Sample Set hinzugefügt. Dabei geben wir auch die Anzahl der Zeilen an, die Transkribus aus dem Subset auswählen soll an. Wir wählen hier mindestens so viele Zeilen, wie Seiten im Subset vorhanden sind, so dass rechnerisch auf jede Seite eine Testzeile kommt. In unserem Fall haben wir uns für den Faktor 1,5 entschieden, um sicher zu gehen. Das Programm wählt die Zeilen nun eigenständig aus und stellt daraus ein Sample zusammen, das als neues Dokument gespeichert wird. Dieses Dokument enthält keine pages, sondern ausschließlich Zeilen. Die müssen nun – wie gewohnt – transkribiert und so GT erzeugt werden. Anschließend kann jedes beliebige Modell über die Compare-Funktion an diesem Testset ausprobiert werden.

Posted by Elisabeth Heigl on

Auflösung

Ein technischer Parameter, der zu Beginn des Scanprozesses einheitlich festgelegt werden muss, ist die Auflösung der Digitalisate, d.h. wie viele Bildpunkte/dots per inch (dpi) das gescannte Bild aufweist.

Die DFG-Praxisregeln zur Digitalisierung empfehlen allgemein 300 dpi (S. 15). Für „Textdokumente mit dem kleinsten signifikanten Zeichen“ von bis zu 1,5 mm kann jedoch eine Auflösung von 400 dpi gewählt werden (S. 22). Tatsächlich können bei den Handschriften – insbesondere den Konzeptschriften – der frühen Neuzeit kleinste Zeichenbestandteile unterschiedliche Lesarten zur Folge haben und sollten also möglichst eindeutig zu erkennen sein. Wir haben uns daher für 400 dpi entschieden.

Neben den Vorteilen für das Entziffern der Schriften muss aber gleichzeitig auch das deutlich größere Speicherformat der 400er (rund 40.000 KB/img.) gegenüber den 300er (rund 30.000 KB/img.) Dateien bedacht und eingeplant werden!

Die gewählte dpi-Zahl hat darüber hinaus auch Auswirkungen auf den Prozess der automatischen Handschriftenerkennung. Unterschiedliche Auflösungen bringen unterschiedliche Ergebnisse der Layout Analyse und der HTR mit sich. Zur Überprüfung dieser These haben wir etwas willkürlich drei Seiten aus einer Spruchakte von 1618 ausgewählt, diese jeweils in 150, 200, 300 und 400 dpi gescannt, sämtliche Seiten in Transkribus bearbeitet und folgende CERs ermittelt:

Seite/dpi 150 200 300 400
2 3,99 3,5 3,63 3,14
5 2,1 2,37 2,45 2,11
9 6,73 6,81 6,52 6,37

Grob gesagt bedeutet eine geringere Auflösung also eine Verschlechterung der CER – wenn auch im Rahmen von unter einem Prozent.

Ehrlich gesagt, hinken solche Vergleiche der HTR-Ergebnisse aber. Schon die Grundlage der HTR – die Layout Analyse – kommt nämlich bei unterschiedlichen Auflösungen zu latent unterschiedlichen Ergebnissen die im Resultat dann die HTR-Ergebnisse (scheinbar gröbere Analysen erzielen schlechtere HTR-Ergebnisse) aber auch die GT-Produktion selbst beeinflusst (z.B. bei abgeschnittenen Wortbestandteilen).

In unserem Beispiel seht ihr dasselbe image in unterschiedlicher Auflösung. Hier verändert sich das Ergebnis der CITlab Advanced LA mit fortschreitend erhöhter Auflösung. Das initiale „V“ der ersten Zeile wird bei höherer Auflösung nicht mehr erkannt, während Zeile 10 bei höherer Auflösung zunehmend „auseinandergerissen wird“. Mit zunehmender Auflösung wird die LA sensibler – das kann Vor- und Nachteile zugleich haben.

Wichtig ist daher in erster Linie eine für das gesamte Projekt einheitliche dpi-Zahl, damit die durchschnittlichen CER-Werte sowie das gesamte statistische Material belastbar bleiben.