# Projektskizze Layout-Workbench

[TOC]

## Projektziel

Mit der _Layout-Workbench_ (LW) soll ein Software-Prototyp entstehen, der eine flexibel einsetzbare und auch auf spezifische Arten von Dokumenten anpaßbare optische Layout-Analyse von gescannten oder photographierten Seiten – vorrangig in Druckschrift – ermöglicht. Die Analyse-Ergebnisse sollen sich leicht zur Weiterverarbeitung in OCR und logischer Layout-Analyse und Textanalyse/Dokumentklassifikation eignen, vorzugsweise in einem standardisierten Dokumenten-Annotationsformat vorliegen.

Schwerpunktmäßig geht es dabei um die Erfassung komplexer Layouts mit Formular- und Tabellen-Inhalten in zeitgenössischem Schrifttum.

Die LW selbst soll freie Software sein, und möglichst bereits vorhandene, gut geeignete (Teil-)Lösungen integrieren oder reproduzieren und Daten nachnutzen – vorrangig soweit sie frei sind.

## Motivation

> Der erste Abschnitt kann vielleicht gestrichen werden? [name=Robert Sachunsky]
>
Während der Automatisierungsgrad bei betrieblichen oder behördlichen Datenverarbeitungsprozessen stetig zunimmt, steigen zugleich Komplexität und Volumen der zu prozessierenden Daten – beide Tendenzen bedingen einander. Das bedeutet aber auch, daß die Kosten der manuellen Erfassung von Daten ein immer wichtigerer Faktor werden. Gerade dort, wo Dokumente ausschließlich in Papierform vorliegen, stellen deren Sichtung und Einordnung (und nicht deren Weiterverarbeitung) durch Sachbearbeiter ein Prozeßrisiko dar. Der automatischen Digitalisierung von Dokumenten mittels Texterkennung fällt daher eine Schlüsselrolle zu.

Das technologische Umfeld der _Optical Character Recognition_ (OCR) entwickelt sich gegenwärtig äußerst dynamisch. Dafür gibt es technische Gründe – wie die Ankunft neuerer Verfahren des maschinellen Lernens wie dem _Deep Learning_ mit neuronalen Netzen –, aber auch gesellschaftliche Ursachen – wie die vielen großen nationalen und internationalen Forschungs-Förderprogramme zur Digitalisierung der letzten Jahre (Europeana Newspapers, EMOP, IMPACT, READ). Insgesamt bedeutet dies, daß einerseits immer mehr Forschungsergebnisse den Weg in praktisch nutzbare Werkzeuge und Daten finden, und es andererseits schwieriger wird, Interoperabilität herzustellen und bestmögliche Workflows produktiv zu halten.

Hinzu kommt, daß die Open-Source-OCR-Community groß und vielfältig ist, und es ein offenkundiges Ungleichgewicht zwischen Entwicklern und Nutzern gibt: Relativ wenige Entwickler, meist in kurzfristigen Forschungsprojekten, sehen sich einer riesigen Zahl Nutzer gegenüber, welche von eigenständigen Enthusiasten reichen, die eine alte Zeitung vom Dachboden digitalisieren möchten, über kleine Archive, die eine Menge Dokumente per Volltextsuche verfügbar machen wollen, bishin zu großen wissenschaftlichen Bibliotheken, die hochqualitative Forschungsdaten für Millionen von Seiten bereitstellen sollen.

## Problembeschreibung

Dabei gilt der Bereich der eigentlichen OCR heute allgemein als gelöstes Problem – üblicherweise auf vollständigen Textzeilen mittels vielfach verschachtelter Schichten von CNN und RNN, die teilweise vortrainiert oder von ähnlichen Aufgaben übertragen werden können, zusammen mit einer CTC- oder Attention-Dekodierung. Voraussetzung ist dabei aber stets, daß mit zur Anwendung passenden Groundtruth-Daten in ausreichender Menge _trainiert_ werden kann, sowie – weniger offensichtlich – daß Bildvorverarbeitung (d.h. Beschneidung, Begradigung, Bereinigung, Entzerrung und Binarisierung) und optische _Layout-Analyse_ (d.h. Seiten- und Zeilensegmentierung) in hoher Perfektion zur Verfügung stehen.

Gerade auf letztere trifft dies aber im Allgemeinen nicht zu: Komplexe Seitenstrukturen mit Textblöcken in mehreren Spalten, Unter- und Überschriften, Kopf- und Fußzeilen, Randnotizen, Abbildungen, Linien, Tabellen, Formularfeldern mit handschriftlichen Ergänzungen usw. werden meist nicht automatisch erkannt. Doch eine fehlerhafte _optische Layout-Erkennung_ (OLR) zieht fast immer eine stark beeinträchtigte OCR nach sich, und macht eine korrekte _logische_ Layout-Erkennung (d.h. Textbereichs-Klassifikation, Textfluß, Textgliederung und Dokumentstruktur) nahzu unmöglich.

Die heute verbreiteten OCR-Werkzeuge, welche im Kernbereich auf o.g. datengetriebener Modellierung basieren, setzen für die OLR meist noch auf regelbasierte, also heuristische Komponenten. In diesem Bereich gibt es aber in der Forschung durchaus schon vielversprechende Ansätze mit Methoden des _Deep Learning_. Die LW soll diese Lücke füllen, aber zugleich durch Kombination mit herkömmlichen OLR-Techniken deren Robustheit und Modularität erhalten.

## Architektur

Die existierende OCR-Software ist meist entweder auf bestimmte Teilaufgaben spezialisiert und unterstützt nur eine geringe Auswahl an Datenformaten für Ein- und Ausgabe. Oder es ist eine umfassende Lösung (_All-in-One_, wie bspw. [FineReader](https://www.abbyy.com/en-eu/finereader/), [Transkribus](https://transkribus.eu/), [OCR4All](https://github.com/OCR4all)), bietet aber kaum Flexibilität bei Workflows und keine Möglichkeit zur Integration weiterer (modernerer oder besser angepaßter) Werkzeuge für Teilaufgaben.

### OCR-D als Framework

Eine Ausnahme stellt hierbei das Open-Source-OCR-Framework von [OCR-D](https://github.com/OCR-D) dar (_Koordinierte Förderinitiative zur Weiterentwicklung von Verfahren der Optical Character Recognition_). OCR-D ist ein [DFG-gefördertes Projekt](https://www.ocr-d.de), welches die Massen-Volltextdigitalisierung des gedruckten deutschsprachigen Kulturgutes technologisch vorbereiten soll. Das [Framework](https://github.com/OCR-D/core) besteht aus Python/REST-APIs (Programmschnittstellen) und CLIs (Kommandozeilen-Schnittstellen) zur Prozessierung von Daten in allen denkbaren Teilaufgaben von OCR mit flexibel konfigurierbaren, auch komplexen Workflows. Mit diesem Framework wird eine [wachsende Zahl](https://github.com/ocr-d/) existierender OCR-Komponenten integriert (OCR-D-Wrapper) – darunter wichtige wie
* [Tesseract](https://github.com/OCR-D/ocrd_tesserocr) (Vorverarbeitung / OLR / OCR),
* [Ocropus](https://github.com/OCR-D/ocrd_ocropy) (Vorverarbeitung / OLR / OCR),
* [Kraken](https://github.com/OCR-D/ocrd_kraken) (OCR),
* Calamari (OCR),
* ocrad (OCR),
* [OLENA](https://github.com/OCR-D/ocrd_olena) (Binarisierung),
* [ImageMagick](https://github.com/OCR-D/ocrd_im6convert) (Bildkonvertierung),
* LAREX (OLR),
* dhSegment (OLR),
* ocrevalUAtion (Evaluierung) und
* [Taverna](https://github.com/OCR-D/taverna_workflow) (Workflow-Engine) –,

sowie neuer Tools entwickelt – u.a.
* eine [Deeplearning-OLR](https://github.com/OCR-D/ocrd_segment),
* ein [Trainingsdaten-Repositorium](https://github.com/OCR-D/repository_metastore),
* eine [Trainingsinfrastruktur für verschiedene OCR-Engines](https://github.com/OCR-D/okralact),
* mehrere [alternative](https://github.com/cisocrgroup/ocrd-postcorrection) [Verfahren](https://github.com/ASVLeipzig/cor-asv-fst) [zur Nachkorrektur](https://github.com/ASVLeipzig/cor-asv-ann) und
* ein [LSTM-Sprachmodell](https://github.com/OCR-D/ocrd_keraslm),
* ein [Klassifikator für historische Schriftarten](https://github.com/seuretm/typegroups-classification-projection).

Als föderiertes System, bei dem sich im Prinzip alle offenen OCR-Werkzeuge integrieren lassen (einschließlich Webservices und kommerzieller Komponenten), bietet OCR-D weniger eine fertige Lösung mit Fokus auf User-Experience, als eine Infrastruktur zur Beherrschung beliebig großer oder spezieller OCR-Aufgaben. Als Datenformate für die Annotation aller Zwischen- und Endergebnisse werden dabei die im Umfeld von Bibliotheken / Archiven und von akademischer Forschung gut etablierten XML-Standards [METS](http://www.loc.gov/METS/) (für Meta-Daten und Dokumentstruktur) und [PAGE](https://www.primaresearch.org/schema/PAGE/gts/pagecontent/2019-07-15/) (für Inhalt, Form und Struktur von Einzelseiten) verwendet. Die genauen Vorgaben dafür bilden zusammen mit den CLIs und den Transkriptionsrichtlinien für Groundtruth-Daten eine von OCR-D gezielt als offenes System konzipierte, [gut dokumentierte](https://ocr-d.github.io) [Spezifikation](http://github.com/OCR-D/spec), mit der auch andere Implementierungen angeregt und die Langzeit-Verfügbarkeit entsprechender Systeme und Dienste sichergestellt werden soll.

### LW als Applikation

Für die eingangs formulierte Zielstellung erscheint OCR-D somit die ideale Wahl als architektureller Rahmen. Die LW selber wäre hierbei zu verstehen als eine Kombination von
1. `ocrd_segment` (einem z.Zt. unter Anlehnung an `dhSegment` in der Entwicklung begriffenem datengetriebenem OLR-Werkzeug als Deeplearning-Pixelclassifier mit CNN und RNN),
2. den OLR-Prozessoren von `ocrd_tesserocr` und `ocrd_ocropy` (der regelbasierten, auf optischen Filtern und Graph-Algorithmen basierenden Segmentierung und Segment-Klassifikation von Tesseract und Ocropus),
3. einem neu zu schaffenden Tool `ocrd_layout-template` zur inkrementellen Annotation (nahezu) fester Layouts, welche vorab manuell mit einer GUI wie [Aletheia](https://www.primaresearch.org/tools/Aletheia) bequem erstellt werden, sowie
4. einem neu zu schaffenden Tool `ocrd_layout-alignment` zur heuristischen (mittels geometrischer Regeln) oder datengetriebenen (mittels NN- oder SVM-Klassifikatoren) Vereinigung der Ergebnisse beider Ansätze,

– in einem beliebigen Deployment von OCR-D mit entsprechenden weiteren Prozessoren für Bildvorverarbeitung, OCR und Nachkorrektur.

Später könnten zusätzliche Prozessoren für Dokument-Strukturierung und Dokument-Klassifikation geschaffen werden (etwa mittels Topicmodelling) – in einem Anschlußprojekt. Auch eventuelle Bedienoberflächen für Workflow-Konfiguration und Training sind denkbar und entstehen möglicherweise ohnehin innerhalb von OCR-D – aber ebenfalls außerhalb des hier zu behandelnden Rahmens.

### LW als Baukasten

Die vier genannten OLR-Komponenten lassen sich dann auf folgende Weise für spezifische Layout-Probleme wie Adreß-Erkennung oder Tabellen-Erkennung anpassen und erweitern:
* Datengetriebene Teile mit überwachtem maschinellem Lernen (`ocrd_segment`, `ocrd_layout-alignment`) können auf entsprechend zu liefernden spezifischen Groundtruth-Daten trainiert werden, oder ggf. (durch Transfer-Learning-Techniken wie Pretraining oder Finetuning) mit Unterstützung generischer Daten aus leichter verfügbaren Korpora, z.B.:
- [Deutsches Textarchiv](http://www.deutschestextarchiv.de/) – etwa 25,000 Seiten aus über tausend historischen Büchern, die sämtlich manuell ausgewählt, segmentiert und annotiert wurden, um alle Buch-spezifischen Layout-Phänomene repräsentativ abzudecken (PAGE-XML); oder
- [Die Grenzboten](http://brema.suub.uni-bremen.de/grenzboten) – etwa 180,000 Seiten einer 1841-1922 erschienenen, vollständig digitalisierten, manuell annotierten Zeitschrift (PAGE-XML)
* Regelbasierte Teile (`ocrd_tesserocr`, `ocrd_ocropy`, `ocrd_layout-template`, `ocrd_layout-alignment`) können teilweise (wo es lohnenswert erscheint) durch spezialisierte Module erweitert werden (z.B. die bereits vorhandene, aber nicht per API exponierte Tabellenerkennung `StructuredTable` von Tesseract). Darüberhinaus haben solche Komponenten fast immer eine große Anzahl Parameter, die auf die jeweiligen Aufgaben zugeschnitten werden können – wiederum mittels spezifischer Groundtruth-Daten oder allgemeiner Daten wie der [Layout-Challenge aus ICDAR2017](https://diuf.unifr.ch/main/hisdoc/icdar2017-hisdoc-layout-comp), in Verbindung mit einer OLR-Evaluierung, z.B.:
- [DIVA-Evaluator](https://github.com/DIVA-DIA/DIVA_Layout_Analysis_Evaluator) - pixelbasiert; oder
- [PRImA-Evaluator](https://www.primaresearch.org/tools/PerformanceEvaluation) – geometriebasiert.

Damit solche Anpassung leicht möglich und nicht nur für Entwickler nutzbar ist, muß weiterhin eine Trainingsinfrastruktur für OLR angeboten werden – idealerweise in Anlehnung an die in OCR-D bereits implementierte Trainingsinfrastruktur für OCR – sowie natürlich gut dokumentiert.

Groundtruth-Daten (GT) für OLR-Training und OLR-Evaluierung sind entweder:
* für pixelbasierte Ansätze: pixelgenau gelabelte Bilder mit (je nach Aufgabe) Unterscheidungen von z.B.
- Schwarz/Vordergrund vs. Weiß/Hintergrund,
- Schrift vs. Sonstiges,
- Satzspiegel vs. Umrandung,
- (zugehörig zu) Fließtext vs. Überschrift vs. Seitenzahl vs. Verzierung/Linien usw.,
- (zugehörig zu) Adresse vs. Sonstiges,
- (zugehörig zu) Ziffer vs. Buchstabe, Eigenname vs. sonstiges Wort usw.,
- (zugehörig zu) Textzeilen, durchnumeriert;
* für geometriebasierte Ansätze: mit Polygon-Koordinaten (Linien, Rechtecke, Hüllkurven) annotierte Bilder zur Identifikation von z.B.
- Baselines (oder Textzeilen-Umrandung),
- Regionen: Fließtext vs. Überschrift vs. Seitenzahl vs. Verzierung/Linien vs. Graphik vs. Bild vs. Formel vs. Tabelle usw.,
- Satzspiegel usw.

## Umsetzung

Die Programmierung erfolgt vorrangig in Python 3 (Module und Tests), XSLT (PAGE-Manipulation) und Bash (Messungen und Trainings-Skripte).

### Arbeitsprogramm

Folgende Arbeitsschritte sind zur Umsetzung der beschriebenen Lösung erforderlich (jew. mit geschätztem Arbeitsaufwand, untergliedert in Arbeitsphasen):

1. Phase: Aufbau einer Baseline – 1 PM
* Recherche zu integrierbaren vorhandenen Tools und zu nutzbaren Datensätzen (mit Fokus auf Tabellen/Formularen)
*
* `StructuredTable` in Tesseract von außen (und in OCR-D) verfügbar machen und testen
* Durchlauf-Prototyp mit Anfangsstand `ocrd_segment`, `ocrd_tesserocr` und `ocrd_ocropy` (je alternativ) auf Beispiel-GT
* Evaluierung einrichten mit Anfangsstand `ocrd_segment`, `ocrd_tesserocr` und `ocrd_ocropy` (je alternativ) auf Beispiel-GT
*
2. Phase: Optimierung für feste Layouts – 1 PM
* Durchlauf-Prototyp mit ersten Anpassungen von `ocrd_segment`, `ocrd_tesserocr` und `ocrd_ocropy` (je alternativ) einschließlich verschiedener OCR-Konfigurationen auf Beispiel-GT
* Experimente zu optimaler Workflow-Konfiguration
* neues Modul `ocrd_layout-template` anlegen, erstes Layout-Template für Beispiel-GT erzeugen
* Evaluierung mit angepaßtem Stand `ocrd_segment`, `ocrd_tesserocr`, `ocrd_ocropy`, `ocrd_layout-template` (je alternativ) einschließlich verschiedener OCR-Konfigurationen auf Beispiel-GT
3. Phase: dynamische Layout-Kombination – 1 PM
* neues Modul `ocrd_layout-alignment`, heuristischer Teil
* Experimente mit verschiedenen Regeln zur Vereinigung von Ergebnissen
* Durchlauf-Prototyp mit `ocrd_segment`, `ocrd_tesserocr` und `ocrd_ocropy` (vereinigt mit `ocrd_layout-alignment`) einschließlich verschiedener OCR-Konfigurationen auf Beispiel-GT
* ...
4. Phase: OLR-Training – 2 PM
* neues Modul `ocrd_layout-alignment`, datengetriebener Teil: verschiedene Klassifikatoren (NN/SVM) auf Trainings-GT trainieren und auf Beispiel-GT evaluieren
* Erweiterung von `ocrd_segment` ...
* Experimente mit Trainings-GT
* Trainingsinfrastruktur für `ocrd_segment` und `ocrd_layout-alignment`
* ggf. Anpassung von OCR (Modell-Training, Finetuning für zusätzliche Zeichen, Character-Whitelisting / Character-Patterns / User-Dictionary)
* ggf. Training von Nachkorrektur
* ...
5. Phase: Konsolidierung – 1 PM
* Unit-Tests, Dockerfiles, CI
* stichprobenhafte Experimente auf unannotierten zusätzlichen Daten
* Dockerfile-basierte Installation für möglichst alle denkbaren Workflows, mit mehreren vorkonfigurierten Beispiel-Workflows
* Dokumentation Deployment/Konfiguration von OCR-D, neue Module, Training von OLR, Evaluierung
* Präsentation, Einweisung und Betreuung

Summe Personenmonate: 6

### Voraussetzungen

Vonseiten des Auftraggebers wird folgendes benötigt:

* möglichst früh – Beispiel-GT (nicht groß),
* bis spätestens Phase 4 – Konkretisierung von OLR-Aufgaben mit detaillierter Beschreibung möglicher Formen (im Extrem- und im Normalfall), Bereitstellung eines Trainings-GT (ausreichend groß – Größenordnung hängt davon ab, ob Transfer-Learning angewandt wird und wie gut die Qualität sein soll, ist also erst näher zu bestimmen).

Angesichts der Komplexität der Problemstellung versteht es sich, daß Anforderungen und Vorgehen jederzeit eng mit dem Auftraggeber abzustimmen sind.

### Zeitplan

Nachfolgend ein Diagramm mit dem geplanten Zeitverlauf für die einzelnen Arbeitsphasen. Gerechnet wird mit 1 Vollzeit-Arbeitskraft.

gantt
    title Layout-Workbench

    section Arbeitsphase
    Aufbau Baseline           :p1, 2019-12-01, 31d
    Optimierung fest          :p2, after p1, 31d
    Kombination dynamisch     :p3, after p2, 28d
    Training                  :p4, after p3, 61d
    Konsolidierung            :p5, after p4, 31d
    section Daten
    Beispiel-GT               :2019-12-01 , 26w
    Trainings-GT              :2020-03-01 , 13w

> Abschnitt Herausforderungen / Risiken? [name=Robert Sachunsky]

## Anhang und Ergänzungen

[Folien zu Übersichtsvortrag, 8.7.2019](https://git.informatik.uni-leipzig.de/ocr-d/slides-iao-workshop)

:::info
Kommentare?
:::

###### tags: `Templates` `Documentation`