Transkribus | FDMLab@LABW

Das FDMLab@LABW: Data-Science-Methoden und -Techniken für den Einsatz im Archiv

Tue, 09 Aug 2022 00:00:00 +0000

Verborgene Datenschätze heben: Das FDMLab experimentiert mit KI im Archiv

Thu, 28 Apr 2022 00:00:00 +0000

Training eines Strukturmodells für Tabellen mit P2PaLA

Tue, 07 Sep 2021 00:00:00 +0000

Transkribus bietet uns gute Werkzeuge an, um das Layout von komplexen Tabellen manuell zu erfassen. Wir möchten aber Bestände mit tausenden von Seiten bearbeiten. Wie können wir die Layoutanalyse auch für komplizierte Tabellenstrukturen automatisieren? Das Tool P2PaLA, welches in die Transkribus-Nutzeroberfläche integriert ist, gibt uns die Möglichkeit, ein spezifisches Strukturmodell für eine Dokumentensammlung zu trainieren.

Unser Anwendungsfall: Stammrollen mit Tabellenlayout

In einem früheren Beitrag haben wir vorgestellt, welche Möglichkeiten Transkribus uns bietet, eine Seite unserer Stammrollen manuell zu segmentieren, um diese für die Texterkennung vorzubereiten. Die Erfahrung zeigte uns: Es funktioniert, aber es kostet auch recht viel Zeit. Transkribus bringt darüber hinaus bereits eine automatische Layoutanalyse mit, die „per Knopfdruck“ ein Ergebnis liefert. In unserem Fall ist die Tabelle jedoch so kompliziert, dass die automatische Analyse kein zufriedenstellendes Ergebnis liefern konnte. Die Stammrollen aus den militärischen Beständen des LABW umfassen insgesamt mehrere Millionen Digitalisate. Da es viel zu aufwändig wäre, tausende von Tabellenseiten händisch zu bearbeiten, möchten wir die Layouterkennung so weit wie möglich automatisieren.

Dazu möchten wir mit dem Tool P2PaLA ein Strukturmodell für das Layout unserer Stammrollen trainieren. Wir wollen uns dabei auf die für uns wesentlichen Informationen konzentrieren und insbesondere die laufende Nummer der Einträge, die Namen der Personen sowie ihre Geburtsdaten erkennen.¹ Ein Blick auf das Tabellenlayout zeigt, dass wir diese Informationen in den ersten drei Tabellenspalten finden. Dabei entspricht eine Tabellenzeile einem Eintrag für eine Person.

Die folgende Abbildung zeigt die sechs Tabellenzellen, die wir auf einer Doppelseite erkennen möchten:

Diese sechs Tabellenzellen sollen auf jeder Doppelseite erkannt werden.

Zusammenstellen eines Trainingsdatensets

Im ersten Schritt muss für das Strukturmodelltraining ein geeignetes Trainingsdatenset zusammengestellt werden. Die Auswahl der Trainingsdaten sollte sorgfältig getroffen werden, denn die spätere Effizienz des Strukturmodells hängt maßgeblich von der Qualität der Trainingsdaten ab. Die Transkribus-Hilfe empfiehlt 50-100 Trainingsseiten, um ein brauchbares Modell zu erstellen. In unserem Fall umfasst das Trainingsdatenset 147 Seiten aus unterschiedlichen Stammrollen der relevanten Bestände.

Sehr wichtig ist, dass die Trainingsdaten wirklich alle Merkmale enthalten, mit denen das Modell später umgehen können soll. Hierbei kommt es durchaus auch auf Kleinigkeiten an: Wenn einige Seiten einen Tabelleneintrag, andere aber zwei Einträge haben, wenn manche Seiten Fußzeilen oder Randbemerkungen aufweisen oder sich auf andere Weise unterscheiden, müssen alle diese Varianten in den Trainingsdaten enthalten sein, damit das Modell sie „erlernen“ kann. Wir haben beispielsweise auch ein paar nicht ausgefüllte Formularseiten und leere, weiße Blätter in unsere Trainingsdaten aufgenommen, da unsere Stammrollen häufig solche Seiten enthalten.

Ein weiterer vorbereitender Schritt ist in unserem Anwendungsfall, dass die Trainingsseiten zunächst zurechtgeschnitten werden müssen. Denn die Digitalisate weisen, da vom Mikrofilm digitalisiert wurde, am oberen Rand einen Streifen mit Verfilmungsinformationen auf. Für das Abschneiden der Bildränder nutzen wir das kostenlose Programm XnView, mit dem auch eine Stapelverarbeitung möglich ist. Alternativ kann für diese Aufgabe auch jedes andere Bildbearbeitungsprogramm genutzt werden.

Seite mit und ohne Verfilmungsstreifen.

Erstellung von Ground Truth

Anschließend legen wir für die Trainingsseiten in Transkribus eine Dokumentensammlung an und laden die Seiten in die Sammlung hoch. Wir kennzeichnen auf den Trainingsseiten die relevanten Textteile durch das Einzeichnen von Textregionen um diese Textteile. Wie das genau geht, zeigt die Transkribus-Anleitung. Diese intellektuell geprüften, „richtigen“ Beispiele werden auch als Ground Truth bezeichnet. Sie dienen dem Algorithmus als Referenzmaterial, um die „richtige“ Segmentierung“ unseres Tabellenlayouts zu lernen.

Es hat sich gezeigt, dass man bessere Ergebnisse erzielt, wenn man die Textregionen eher eng um den Text zeichnet, als wenn man den gesamten Zellenbereich inklusive Leerraum kennzeichnet. Unsere Vermutung ist, dass dies darin begründet ist, dass der Algorithmus nach Textbereichen „sucht“ und es deshalb nicht hilft, ihm Tabellenzellen „zeigen“ zu wollen.

Tagging mit Strukturelementen

Über die Registerkarte „Metadata“ legen wir drei benutzerdefinierte Strukturtags „zelle-nummer“, „zelle-name“ und „zelle-geburt“ an. Danach zeichnen wir alle eingezeichneten Textregionen mit dem passenden Strukturtag aus. Eine ausführliche Anleitung zur Verwendung der Funktion des Structural Tagging gibt es auf der Transkribus-Hilfeseite. Die Strukturtags werden wir im nächsten Schritt brauchen, um beim Modelltraining anzugeben, welche Elemente trainiert werden sollen (s.u.).

Durchführung des Modelltrainings mit P2PaLA

Nun können wir das eigentliche Modelltraining mit P2PaLA anstoßen. In der Eingabemaske von P2PaLA wählen wir dafür die drei Strukturtags an, die trainiert werden sollen („zelle-nummer“, „zelle-name“, „zelle-geburt“). Außerdem geben wir dem Modell einen Namen und fügen eine Kurzbeschreibung bei, die erläutert, für welche Dokumente das Modell geeignet ist. Wir trainieren ausschließlich Textregionen und nicht die Erkennung von Textzeilen. Dies reduziert den Aufwand beim Erstellen der Ground Truth deutlich, da für das Training von Zeilen auch die Zeilen manuell gekennzeichnet werden müssten. Anschließend stoßen wir das Training an. Je nach Auslastung des Transkribus-Servers kann es etwas dauern, bis die Ergebnisse eines Trainings vorliegen. Den Status unseres Trainings können wir in der Jobübersicht in der Transkribus-Oberfläche nachverfolgen.

Anwendung des Modells auf Testdaten

Nach Abschluss des Trainings wenden wir unser Stammrollen-Strukturmodell auf ein Testdatenset an, das wir aus fünf Stammrollen zusammengestellt haben, die noch nicht Teil der Trainingsdaten waren, um zu sehen, wie gut das Modell unbekannte Daten tatsächlich verarbeiten kann.

Das Ergebnis zeigt, dass unser Strukturmodell die sechs trainierten Textregionen in allen Stammrollen des Testdatensets findet. Es treten jedoch auch noch Fehler auf. Besondere Seiten, die nicht dem Standard-Layout entsprechen, können nicht erkannt werden, da sie nicht trainiert wurden. Teilweise sind auch auf Seiten, die dem trainierten Layout entsprechen, Fehler zu finden. So wurden stellenweise einzelne Buchstaben oder Wortteile nicht in die Textregion aufgenommen, wenn sie über den Zellenrand hinausragen. Bei Seiten mit einem Eintrag wird die vorhandene Tabellenzeile stets richtig erkannt, manchmal führen Bemerkungen im unteren Seitenbereich aber zu fälschlicherweise eingezeichneten Textregionen.

Schlecht erkannt werden Seiten, bei denen die darunterliegenden Seiten noch sichtbar sind oder in die Zettel eingeklebt wurden (siehe Abbildung). Auch durch ein erneutes Training mit zusätzlichen Trainingsbeispielen dieser Art konnte dieses Problem bisher nicht behoben werden.

Wenn im Original die Schrift blass und selbst für das menschliche Auge schwer lesbar ist, wirkt sich dies auch negativ auf die Layoutanalyse aus. Eventuell könnte eine erneute Digitalisierung in höherer Auflösung zu einem besseren Ergebnis führen.

Blasse Schrift oder eingeklebte Zettel erschweren die Segmentierung der Textregionen.

Auf vielen Seiten fanden sich nach der ersten Anwendung unseres Modells sehr kleine Textregionen, die fälschlicherweise an unterschiedlichen Stellen eingezeichnet wurden. Dieses Problem ließ sich sehr leicht beheben, indem wir den minimalen Wert für Textregionen („min area“) in den Einstellungen von P2PaLA heraufgesetzt haben.

Fazit und nächste Schritte

Das Trainieren von Strukturmodellen mit P2PaLA ist für Archive sehr interessant, da die Archive über vielfältige Unterlagen verfügen, die Formulare und Tabellen enthalten. Der beschriebene Anwendungsfall steht daher exemplarisch für viele Anwendungskontexte.

Im FDMLab konnte mit P2PaLA ein Strukturmodell für Stammrollen trainiert werden, welches es ermöglicht, bestimmte, besonders relevante Informationen (laufende Nummer, Namen, Geburtsdaten) zu finden.

Eine noch offene Aufgabe für das FDMLab ist die Automatisierung der richtigen Lesereihenfolge der analysierten Textregionen. Aktuell liest Transkribus die Textregionen spaltenweise von oben nach unten. In unserem Anwendungsfall wünschen wir uns aber ein zeilenweises Auslesen. Transkribus gibt uns die Möglichkeit, die automatisch erstellte Lesereihenfolge nachträglich manuell zu korrigieren. Wir möchten für diesen Schritt jedoch eine maschinelle Lösung finden.

Insgesamt kann gesagt werden, dass wir einen semiautomatischen Prozess realisieren können, da die Ergebnisse unserer Layoutanalyse einer manuellen Nacharbeit bedürfen. Der Aufwand für manuelle Arbeiten ist jedoch sehr viel geringer, als wenn ohne eine automatische Layoutanalyse gearbeitet würde.

Der nächste anstehende Arbeitsschritt wird die Analyse der Textzeilen in den Textregionen sein. Danach wird die eigentliche Handschriftenerkennung durchgeführt werden, die auf Basis der Textzeilen arbeitet.

Es bleibt abzuwarten, wie die Layoutanalyse in Transkribus künftig weiterentwickelt werden wird. Derzeit bietet das Segmentierungsmodul von Transkribus spezielle Funktionalitäten für die manuelle Segmentierung von Tabellen an. Da P2PaLA bisher aber noch keine Tabellenelemente, sondern nur Textregionen erkennen und verarbeiten kann, können diese spezifischen Werkzeuge für das Training von Strukturmodellen leider nicht genutzt werden. Eine Weiterentwicklung der Layoutverarbeitungsmöglichkeiten für Tabellen wäre in hohem Maße wünschenswert.²

Mit Hilfe eines Volltextes, der diese Basisinformationen enthält, kann man die Fundstelle für eine Person schnell recherchieren und weitere Informationen direkt aus der Stammrolle entnehmen. ↩︎
Dies wurde exemplarisch von Naver Labs Europe umgesetzt und sollte in Transkribus integriert werden, jedoch scheint sich die Integration zu verzögern. ↩︎

Analyse tabellarischer Layoutstrukturen mit Transkribus

Tue, 13 Jul 2021 00:00:00 +0000

Eine gute Layouterkennung ist die Voraussetzung für eine gute OCR- oder HTR-Erfassung von Dokumenten. Anhand von Stammrollen aus dem LABW testen wir, welche Möglichkeiten Transkribus bei der Layouterkennung komplexer Tabellenstrukturen bietet.

Unser Ausgangsmaterial: Stammrollen mit Tabellen-Layout

Die militärischen Bestände des LABW aus dem Zeitraum zwischen 1871 bis ca. 1920 beinhalten u.a. umfangreiche militärische Personalunterlagen. Dazu gehören die sogenannten Kriegs- und Friedensstammrollen von verschiedenen Regimentern. Diese listen alle Angehörigen einer Einheit mit Daten zur Person, den Angehörigen, mitgemachten Gefechten, Auszeichnungen etc. auf. Die Stammrollen sind für viele unterschiedliche Forschungsfragen interessant und insbesondere auch für Genealogen eine gerne genutzte historische Quelle.

Die Stammrollen sind bereits vollständig digitalisiert und über das Online Findmittelsystem (OLF) des LABW einsehbar.¹ Durch eine zusätzliche Volltexterfassung der Namen und Geburtsdaten aus den Stammrollen könnte man schnell und bequem nach einer bestimmten Person suchen. Das wäre ein echter Mehrwert für genealogische Forschungen! Wir testen, wie wir dies mit Transkribus umsetzen können.

Hier zuerst ein Blick auf das Layout unserer Stammrollen:

Tabellarisches Layout der Stammrollen (Quelle: Landesarchiv Baden-Württemberg, Hauptstaatsarchiv Stuttgart M 439 Band 270).

Layouterkennung als Basis für die Transkription

Die Layoutanalyse ist in Transkribus der erste Schritt, bevor man ein Dokument manuell oder automatisiert transkribieren kann. Bei der Layoutanalyse wird ein Dokument in Textregionen, Zeilen und Basislinien unterteilt. Die Texterkennung arbeitet auf der Basis dieser Segmentierung. Ausführliche Informationen, wie man die automatische Layoutanalyse durchführen kann, gibt es auf der Transkribus-Website.²

Wir testen, wie gut die automatische Layoutanalyse bei unseren Stammrollen funktioniert.

Ergebnisse der automatischen Layoutanalyse

Schon ein kurzer Blick auf eine Seite aus unseren Stammrollen zeigt, dass wir es mit einem komplexen Layout zu tun haben: Unsere Tabelle besitzt 15 Spalten mit Spaltenüberschriften. Auf einer (Doppel-)Seite gibt es in der Regel zwei Einträge, sprich Zeilen. Die Zellen innerhalb einer Zeile sind teilweise noch einmal in zwei kleinere Zellen unterteilt. Was wir als Menschen sofort verstehen, stellt an Transkribus hohe Anforderungen bei der richtigen Erkennung von Textabschnitten und Zeilen und der Festlegung der Lesereihenfolge der einzelnen Elemente. Wir haben Transkribus eine harte Nuss zu knacken gegeben!

Die Ergebnisse der automatischen Layoutanalyse sind dementsprechend fehlerhaft. Der Großteil des Textes wurde als Textzeilen erkannt. Vor allem in den Spaltenüberschriften, vereinzelt auch in den Tabelleneinträgen, gibt es aber auch Textzeilen, die nicht als solche erkannt wurden.

Bei der Erkennung der Textregionen scheint Transkribus sich insgesamt an den Tabellenspalten zu orientieren. Dies hat jedoch nicht zufriedenstellend funktioniert. Während einerseits mehrere Tabellenspalten in einer Textregion zusammengefasst wurden, sind andere Spalten in mehrere Regionen aufgeteilt worden, die sich teilweise auch überlappen.

Auch, wenn das Layout der Tabelle auf jeder Seite dasselbe ist, werden bei jeder Seite unterschiedliche Textregionen erkannt, da die Textverteilung sich auf den Seiten unterscheidet. Das Ergebnis der automatischen Layoutanalyse ist daher bei gleichen Voreinstellung auf jeder Seite etwas anders.

Die fehlerhaften Textregionen stellen deshalb ein Problem dar, weil dadurch auch die Lesereihenfolge der Zeilen durcheinandergerät.

Ergebnis der automatischen Layoutanalyse von Transkribus.

Manuelle Bearbeitungsmöglichkeiten

Um zu einem brauchbaren Ergebnis zu kommen, sind manuelle Nacharbeiten erforderlich. Transkribus stellt uns dafür umfangreiche Möglichkeiten zur Verfügung. Eine detaillierte Anleitung findet sich ebenfalls auf der Transkribus-Website.³ Zuerst müssen die Textregionen korrigiert werden. Sinnvoll ist es hier, jeweils eine Tabellenzelle als eine Textregion zu kennzeichnen.⁴ Nachdem die Lesereihenfolge der Textregionen berichtigt wurde, werden auch die Basislinien innerhalb der Textregionen manuell korrigiert, wo dies nötig ist. Abschließend wird die Lesereihenfolge der Zeilen angegeben.

Manuelle Nachbearbeitung der Layouterkennung.

Tipps für manuelle Layoutkorrekturen

Um fehlerhafte Textzeilen zu korrigieren, müssen Sie die Basislinien korrigieren, an denen sich die Texterkennung orientiert. Die Zeilen werden dann automatisch ebenfalls angepasst.
Wenn Sie Text aus einer Textregion auf zwei unterschiedliche Textregionen aufteilen möchten, nutzen Sie das Werkzeug zum Zerschneiden von Elementen (gekennzeichnet durch das Scherensymbol). Nur so werden die Zeilen korrekt zu zwei Regionen zugeordnet.
Achten Sie darauf, dass sich Textregionen nicht überlappen.

Fazit

Die automatische Layoutanalyse von Transkribus, die bei einfachen Layouts durchaus überzeugend funktionieren mag, kann ein komplexes Tabellenlayout wie das unserer Stammrollen nicht mit ausreichender Qualität verarbeiten. Transkribus bietet uns umfangreiche Möglichkeiten, die Layouterkennung manuell nachzubearbeiten. So haben wir am Ende unseres Tests die Seite aus der Stammrolle zufriedenstellend segmentiert. Die Nacharbeiten nehmen jedoch viel Zeit in Anspruch, sodass dieses Vorgehen nicht geeignet ist, um unseren gesamten Bestand an Kriegs- und Friedensstammrollen im LABW zu bearbeiten.

Um einen effizienteren Weg zu finden, unser Tabellenlayout zu analysieren, werden wir als nächstes das Tool P2PaLA testen, welches in Transkribus integriert und ab Version 1.15.1 für alle Transkribus User freigeschaltet ist. Mit P2PaLA lässt sich ein spezifisches Strukturmodell für die Layouterkennung einer Dokumentensammlung trainieren. Auf diese Weise möchten wir einen höheren Automatisierungsgrad bei der Erkennung unseres Stammrollen-Tabellenlayouts erreichen. Wir werden in einem Folgebeitrag davon berichten.

Die Bestände des Hauptstaatsarchivs Stuttgart HStA M 430/1 - M631 in OLF. ↩︎
Anleitung zur Layoutanalyse mit Transkribus im Transkribus-Ressourcenzentreum der READ COOP. ↩︎
Anleitung „Wie man Dokumente mit Transkribus transkribiert“ im Transkribus-Ressourcenzentreum der READ COOP. ↩︎
Grundsätzlich kennt das von Transkribus verwendete PAGE XML Format auch Tabellen. Jedoch werden rekursive Strukturen (Tabelle -> Zelle -> Text) unserer Erfahrung nach nicht von allen Werkzeugen zuverlässig unterstützt. ↩︎

80. Südwestdeutscher Archivtag 2021

Fri, 18 Jun 2021 11:00:00 +0000

Werkzeuge zur Texterkennung: ein Blick in die digitale Werkstatt des FDMLab am Landesarchiv Baden-Württemberg

Fri, 18 Jun 2021 11:00:00 +0000

2. Workshop des OCR-BW-Projektes 2021

Wed, 09 Jun 2021 11:00:00 +0000

Wie wir Docker einsetzen

Tue, 08 Jun 2021 00:00:00 +0000

Programme haben Anforderungen an ihre Umgebung. Dies kann ein bestimmtes Betriebssystem sein (Windows, Linux, macOS), eine Laufzeitumgebung für eine Programmiersprache (Python, Java, C#), oder die Verfügbarkeit bestimmter Bibliotheken (GTK, .NET, Qt). Wir wollen uns beim Testen und Evaluieren aber nicht einschränken!

Im FDMLab evaluieren wir Programme und Bibliotheken, die sowohl für den Gebrauch am Rechner, als auch als Serveranwendung entwickelt wurden. Würden wir diese alle auf unserem Testrechner installieren, hätten wir schnell die von Randall Munroe dargestellte Situation erzeugt. Also unser System mit Programmen, Laufzeitumgebungen und Konfigurationsdateien vollgemüllt.

Python Environment von Randall Munroe unter CC BY-NC Lizenz.

Stattdessen versuchen wir - sofern möglich - die zu evaluierenden Programme als Docker Container zu testen. Wie im Eingangsbild symbolhaft dargestellt¹, handelt es sich bei Docker Containern (vereinfacht) um einen Standard um Anwendungen mitsamt ihrer Umgebung zu verpacken und somit auf unterschiedlichen Docker Hosts laufen zu lassen.

Wir verwenden dafür Docker Desktop für Windows.

Docker Container via Browser

--- title: Docker Container via Browser config: look: handDrawn theme: neutral --- flowchart TD subgraph Container[Container] FC[Dateien] Server[[Server]] DB[(Datenbank)] Lib{{Bibliotheken}} end Browser[[Browser]] FU[Dateien] FU <--> FC --> Server Server --> Browser DB --> Server Lib --> Server

Eine Variante Docker zu verwenden, ist mit der Anwendung in dem Container via einer Web GUI im Browser zu interagieren. Ein Beispiel hierfür ist das Projekt OCR4All. Mit dem folgenden PowerShell Befehl wird die Vorlage für einen OCR4All Container (image) aus der Docker Hub Registry heruntergeladen und lokal ein OCR4All Container erstellt.

docker run --rm -it -p 8080:8080 ls6uniwue/ocr4all

Über die Adresse http://localhost:8080 lässt sich die Web GUI des OCR4All Containers aufrufen und bedienen.

Es ist möglich Daten von der eigenen Festplatte mit in den Container einzuhängen (mounten).

docker run --rm -it -p 8080:8080 -v ${PWD}:/var/ocr4all/data ls6uniwue/ocr4all

Docker Container als Skript

Docker Container können ähnliche wie Skripte verwendet werden.

Mit dem folgenden Beispiel wird ein OCR-D Workflow ausgeführt, ohne dass die mehr als 60 unterschiedlichen Prozessoren separat installiert werden müssen.

docker run --rm -v ${PWD}:/data -w /data -- ocrd/all:maximum bash workflow.sh

Das Image ocrd/all:maximum ist mehrere Gigabyte groß!

Wo Docker nicht funktioniert

Es gibt Software, die nicht als Docker Image vorliegt, oder als solche verwendet werden kann. Dazu gehört Software, die eine systemspezifische GUI Bibliothek verwendet.

Beispiele hierfür sind der Page Viewer oder der Transkribus Expert Client. Diese benötigen beide Java als Laufzeitumgebung und stellen ihre GUI mit nativen Betriebssystemkomponenten dar. Docker Container haben keine nativen GUI Komponenten, weshalb diese Programme in einem Docker Container nicht genutzt werden können ².

Unser Fazit

Wir verwenden Docker um schnell und unkompliziert unterschiedlichste Anwendungen evaluieren zu können. Inzwischen kommen Docker Container bei uns auch praktisch zum Einsatz. Zum Beispiel um gemeinsame Projekte reproduzierbar bearbeiten zu können.

Die Standardisierung von Seefracht-Containern zu ISO-Containern optimierte die Transportkette im Güterverkehr. Daher werden standardisierte virtuelle Container häufig mit Fracht-Containern verglichen. ↩︎
Es gibt Bibliotheken, die die nativen GUI Komponenten für Webbrowser darstellen können. Ein Beispiel hierfür ist GTK Broadway. ↩︎