---
# System prepended metadata

title: Projektskizze Layout-Workbench

---


# Projektskizze Layout-Workbench

[TOC]

## Projektziel

Zwar 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 _Layout-Workbench_ (LW) soll diese Lücke füllen, aber zugleich durch Kombination mit herkömmlichen OLR-Techniken deren Robustheit und Modularität erhalten.

Dabei soll mit der LW 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, da sich so im Fokus verschiedener kommerzieller Anwendungen Wartung und Weiterentwicklung leichter dauerhaft gewährleisten lassen (wie das Beispiel Tesseract beweist). Sie soll möglichst bereits vorhandene, gut geeignete (Teil-)Lösungen integrieren oder reproduzieren und freie Daten nachnutzen, aber auch die Ausnutzung privater Daten ermöglichen.


## Umsetzungsempfehlung

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. 


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.

### Layout-Workbench als Applikation von OCR-D

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.

### Layout-Workbench als Projektbaukasten

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.

(Digital geschaffene Dokumente lassen sich i.A. leicht in solche Form überführen.)

## Vorschlag für Arbeitsprogramm

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


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
   * erste Abdeckungsanalyse für Layout-Probleme
4. Phase: OLR-Training – 2 PM
   * neues Modul `ocrd_layout-alignment`, datengetriebener Teil: verschiedene Klassifikatoren (NN/SVM)
   * entspr. Anpassung und Erweiterung von `ocrd_segment`
   * Experimente: `ocrd_segment` / `ocrd_layout-alignment` auf Trainings-GT trainieren und auf Beispiel-GT evaluieren
   * Trainingsinfrastruktur für `ocrd_segment` und `ocrd_layout-alignment`
   * ggf. Anpassung von Vorverarbeitung (Workflow und Parameter)
   * 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
   * finale Abdeckungsanalyse für Layout-Probleme
   * 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.

```mermaid
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
```

