Eine Testumgebung für die Arbeit mit HTR vorbereiten

Einführung

Bevor wir mit der Erstellung unseres eigenen Ground Truth und dem Training des HTR-Modells beginnen, empfiehlt es sich, eine separate Testumgebung vorzubereiten, in der wir sicher mit digitalisierten Dokumenten, Modellen und individuellen Werkzeugeinstellungen experimentieren können.

Für das erste Experiment ist es nicht notwendig, eine Server-Infrastruktur aufzubauen oder eine leistungsstarke Workstation anzuschaffen. Wichtiger ist es, eine Umgebung zu wählen, die zum Projektziel passt.

Aus praktischer Sicht lassen sich für die Arbeit mit historischen Handschriften drei grundsätzliche Möglichkeiten unterscheiden:

1. Transkribus– der einfachste Weg, ohne unsere eigene HTR-Infrastruktur zu installieren;
2. eScriptorium– eine lokale oder serverbasierte grafische Umgebung, die unter anderem das Kraken-System verwendet;
3. Kraken– ein separates Tool, das hauptsächlich über die Befehlszeile gesteuert wird.

Jede Variante eignet sich für eine andere Arbeitsweise.

1. Bestimmen Sie zunächst den Zweck der Testumgebung

Vor der Installation einer Software empfiehlt es sich, einige grundlegende Fragen zu beantworten.

Wir wollen nur:

• Versuchen Sie es mit der automatischen Erkennung mehrerer Seiten.
• Erstellen Sie Ihr eigenes Ground Truth;
• Trainieren Sie Ihr eigenes Modell;
• experimentieren Sie mit verschiedenen Modellen;
• Dokumente lokal verarbeiten, ohne sie an einen externen Dienst zu senden;
• Automatisieren Sie die Verarbeitung von Hunderten oder Tausenden von Bildern.
• HTR mit Ihrem eigenen Programm oder Ihrer Datenbankumgebung verbinden?

Wenn wir nur das Prinzip der Arbeit mit HTR verstehen wollen, ist ein eigener Server eine unnötige Komplikation.

Wenn wir jedoch mit Datenformaten, Automatisierung, benutzerdefinierten Modellen und Stapelverarbeitung experimentieren möchten, macht die lokale Umgebung allmählich Sinn.

Option A: Transkribus – der einfachste Weg

2. Wann ist Transkribus zu verwenden?

Für einen Anfänger ist Transkribus normalerweise der schnellste Weg zum ersten Experiment.

Es ist nicht erforderlich, Python, Datenbank, Docker oder ein neuronales Netzwerk-Framework zu installieren. Der Benutzer erstellt ein Konto, lädt Dokumente hoch und arbeitet über die Webanwendung.

Transkribus ermöglicht zum Beispiel:

• digitalisierte Dokumente importieren;
• automatische Layoutanalyse;
• Erstellung und Korrektur von Transkriptionen;
• Vorbereitung von Ground Truth;
• Nutzung bestehender HTR-Modelle;
• Training eigener Modelle;
• Auswertung der Ergebnisse;
• Transkripte exportieren.

Für die erste Einführung in HTR ist es daher angebracht, hier zu beginnen.

Was wir brauchen

Das praktische Minimum besteht aus:

• gewöhnlicher Computer;
• moderner Webbrowser;
• Internetverbindung;
• ein Transkribus-Konto;
• mehrere hochwertig digitalisierte Seiten eines historischen Dokuments.

Die Berechnungen selbst müssen nicht auf dem eigenen Computer durchgeführt werden.

Was nicht mehr zum Einbau geeignet ist

Früher gab es einen Desktop-Transkribus eXpert Client. Allerdings gilt es inzwischen als veraltet und wird nicht weiterentwickelt; Neue Funktionen werden in der Webanwendung konzentriert. [1]

Es macht daher keinen Sinn, für ein neues Projekt einen Workflow auf einem Desktop-Client aufzubauen.

Variante B: eScriptorium – eigene grafische HTR Umgebung

3. Was ist eScriptorium

eScriptorium ist eine offene Umgebung für die Arbeit mit historischen Dokumenten. Es bietet eine Webschnittstelle für Bildimport, Segmentierung, Transkription, Anmerkung, Modelltraining und automatische Erkennung.

Für HTR selbst wird hauptsächlich das System Kraken verwendet. [2]

Der Vorteil von eScriptorium liegt in der Kombination zweier Features:

• Benutzer arbeitet in einer grafischen Weboberfläche;
• Die Umgebung selbst kann auf Ihrem eigenen Computer oder Server ausgeführt werden.

Dies eignet sich beispielsweise dort, wo wir Bilddaten, Ground Truth und Modelle unter unserer eigenen Kontrolle haben möchten.

4. Empfohlene Umgebung für die erste lokale Installation

Der einfachste Weg zu einem lokalen eScriptorium ist derzeit Docker.

In der offiziellen eScriptorium-Dokumentation wird Docker als empfohlene Installationsmethode aufgeführt. [3]

Für einen Testrechner eignet sich beispielsweise folgende Konfiguration:

Betriebssystem

• Linux;
• macOS;
• Windows mit WSL 2.

Für technische Experimente ist Linux in der Regel am bequemsten, beispielsweise die aktuelle LTS-Version von Ubuntu.

Basissoftware

Wir brauchen:

• Git;
• Docker Engine oder Docker Desktop;
• Docker Compose v2;
• Webbrowser.

Docker löst hier ein wichtiges Problem: eScriptorium ist kein einzelnes Programm, sondern ein Set aus mehreren Diensten. Es nutzt unter anderem eine Webanwendung, eine PostgreSQL-Datenbank, Redis und Celery-Worker. Docker führt einzelne Komponenten in separaten Containern aus. [2]

Für einen Anfänger ist dies deutlich einfacher, als alle Abhängigkeiten separat zu installieren.

5. Docker-Prüfung

Nach der Installation von Docker überprüfen wir zunächst, ob es funktioniert.

Im Terminal:

docker --version
docker compose version

Der zweite Befehl ist wichtig. Die aktuelle eScriptorium-Dokumentation verwendet den Befehl:

docker compose

das heißt, Docker Compose v2.

Älteres eigenständiges Programm:

docker-compose

ist bereits veraltet. [3]

Wir können die Funktionalität von Docker zum Beispiel überprüfen:

docker run hello-world

Wenn der Testcontainer erfolgreich gestartet wird, ist die Basisumgebung bereit.

6. Laden Sie eScriptorium herunter

Wir werden die Quelldateien mit Git herunterladen:

git clone https://gitlab.com/scripta/escriptorium.git
cd escriptorium

Dann erstellen wir eine Konfigurationsdatei:

cp variables.env_example variables.env

Die Datei variables.env enthält lokale Instanzeinstellungen.

Vor dem ersten Durchlauf ist es ratsam, mindestens Folgendes zu ändern:

• SECRET_KEY;
• Admin-Name;
• Admin-Passwort;
• Administrator-E-Mail;
• ggf. Domänen- und Netzwerkeinstellungen.

Auch in der Testumgebung ist es nicht ratsam, das Standardpasswort beizubehalten, wenn das System von einem anderen Teil des Netzwerks aus erreichbar ist. [3]

7. Starten von eScriptorium

Aktuelle Container-Images können mit dem Befehl heruntergeladen werden:

docker compose pull

Dann starten wir die Umgebung:

docker compose up -d

Der Parameter -d bedeutet, dass die Container im Hintergrund ausgeführt werden.

Wir prüfen den Status:

docker compose ps

Standardmäßig ist die lokale Schnittstelle im Browser verfügbar unter:

http://localhost:8080/

Wir melden uns mit dem in variables.env festgelegten Administratorkonto an. [3]

8. So stoppen Sie eScriptorium

Wir können die Testumgebung stoppen:

docker compose down

Die Daten bleiben erhalten.

Seien Sie sehr vorsichtig mit dem Befehl:

docker compose down -v

Die Option -v löscht auch Docker-Volumes, sodass die Datenbank und die gespeicherten Instanzdaten gelöscht werden können. [3]

Daher ist es für Anfänger sicherer, das übliche zu verwenden:

docker compose down

Variante C: Kraken – direkt mit der HTR-Engine arbeiten

9. Was ist Kraken

Kraken ist ein Open-Source-System zur automatischen Texterkennung, das sich hauptsächlich auf historische Dokumente und verschiedene Arten von Schriften konzentriert.

Es unterstützt unter anderem:

• Seitensegmentierung;
• Linienerkennung;
• Texterkennung;
• Training eigener Modelle;
• PAGE XML;
• ALT;
• hOCR;
• Arbeiten Sie mit vorab trainierten Modellen. [4]

Es eignet sich besonders für Anwender, die die einzelnen Schritte des HTR-Prozesses unter Kontrolle haben oder in eigene Skripte einbauen möchten.

10. Erstellen einer isolierten Python-Umgebung

Kraken sollte nicht wahllos in System-Python installiert werden.

Für experimentelle Arbeiten ist es besser, eine separate virtuelle Umgebung zu erstellen.

Zum Beispiel:

python3 -m venv htr-env

Aktivierung unter Linux und macOS:

source htr-env/bin/activate

Dann aktualisieren wir die Installer:

python -m pip install --upgrade pip

und installieren Sie Kraken:

pip install kraken

In der aktuellen Dokumentation von Kraken wird die Installation über pip als standardmäßig unterstützter Pfad aufgeführt. [4]

11. Kraken Installationsüberprüfung

Nach der Installation:

kraken --help

Wenn Hilfe angezeigt wird, funktioniert die Grundinstallation.

Kraken hat außerdem Zugriff auf ein Repository vorhandener Modelle. Verfügbare Modelle können zum Beispiel besichtigt werden:

kraken list

Informationen zu einem bestimmten Modell erhalten Sie über:

kraken show IDENTIFIKATOR_MODELU

Kraken ermöglicht Ihnen somit das Experimentieren nicht nur mit Ihren eigenen Modellen, sondern auch mit vorhandenen frei verfügbaren Modellen. [4]

12. Erster Texterkennungstest

Bevor Sie Ihr eigenes Modell trainieren, empfiehlt es sich, die gesamte Verarbeitungspipeline an einem Bild zu überprüfen.

Das Verarbeitungsprinzip ist:

Bild → Segmentierung → Erkennung → Text/XML

Mit einem passenden Modell können Sie zum Beispiel verwenden:

kraken -i strana.tif vystup.txt segment -bl ocr -m model.mlmodel

Kraken ermittelt zunächst die Linienstruktur und führt dann die Erkennung anhand des angegebenen Modells durch. [4]

Das Ziel dieses ersten Experiments besteht nicht darin, ein perfektes Transkript zu erhalten.

Wir müssen nur Folgendes überprüfen:

• Der Kraken kann gestartet werden;
• Eingabebild kann geladen werden;
• Modell kann geladen werden;
• es kommt zu einer Segmentierung;
• Es wird ein Ausgabetext generiert.

Erst dann macht es Sinn, das eigene Training in Angriff zu nehmen.

13. CPU oder GPU?

Eine der häufigsten Fragen beim Erstellen einer HTR-Umgebung ist, ob eine Grafikkarte erforderlich ist.

Allein für folgende Aufgaben:

• Dokumentenanzeige;
• Vorbereitung von Ground Truth;
• Korrektur von Transkriptionen;
• kleine Erkennungstests;

Eine leistungsstarke GPU ist keine Voraussetzung.

Beim Training neuronaler Modelle kann eine kompatible GPU den Prozess jedoch erheblich beschleunigen.

eScriptorium ermöglicht dem Schulungsmitarbeiter die Verwendung von NVIDIA-GPUs über das NVIDIA Container Toolkit. Die aktuelle Dokumentation verwendet ein Gerätesetup des Typs:

KRAKEN_TRAINING_DEVICE=cuda:0

und GPU-Konfiguration in Docker Compose. [3]

Für das erste Experiment ist es jedoch nicht ratsam, zunächst CUDA und Treiber zu installieren, wenn nicht sicher ist, ob wir diese benötigen.

Eine sinnvollere Vorgehensweise ist:

Lassen Sie das System zuerst auf der CPU laufen → erstellen Sie ein kleines Experiment → konfigurieren Sie dann erst eine GPU.

Dadurch wird die Anzahl möglicher Ursachen für Installationsprobleme erheblich reduziert.

14. Empfohlene Struktur von Projektverzeichnissen

Unabhängig davon, für welches Tool Sie sich entscheiden, ist es nützlich, Ihre Daten von Anfang an organisiert zu haben.

Zum Beispiel:

htr-projekt/
│
├── images-oderiginal/
│   └── ursprüngliche Digitalisate
│
├── images-woderking/
│   └── Arbeitskopien der Bilder
│
├── ground-truth/
│   └── überprüfte Transkriptionen
│
├── pagexml/
│   └── PAGE XML
│
├── models/
│   ├── model-001/
│   ├── model-002/
│   └── model-003/
│
├── test/
│   └── unabhängige Testdaten
│
├── results/
│   └── Versuchsergebnisse
│
└── documentation/
    ├── transcription-rules.md
    └── experiment-log.md

Eine solche Aufteilung ist keine technische Bedingung des HTR-Systems. Es handelt sich um eine organisatorische Maßnahme, die sich sehr schnell auszahlen wird.

Besonders wichtig ist die Trennung von:

Originalbilder,
Ground Truth,
Trainingsdaten,
unabhängige Testdaten,
einzelne Modellergebnisse.

Ansonsten kann es später leicht passieren, dass wir nicht wissen, ob eine bestimmte Seite Teil des Trainings war oder nicht.

15. Verändern Sie die Originalbilder nicht

Es empfiehlt sich, die digitalisierten Originaldateien in einem separaten Verzeichnis aufzubewahren und nicht zu überschreiben.

Wenn wir etwas ändern müssen:

• Auflösung;
• Kontrast;
• Farbe;
• Bildausschnitt;
• Binarisierung;
• Bildausrichtung;

Wir erstellen eine Arbeitskopie.

Die Originaldatei sollte erhalten bleiben.

Dies ist nicht nur für das HTR-Experiment wichtig, sondern auch für die allgemeine archivische Reproduzierbarkeit der Verarbeitung.

16. PAGE XML als geeignetes Austauschformat

Für längerfristige Arbeiten ist es nicht ratsam, das Projekt nur an das interne Format eines Programms zu binden.

Eines der bekanntesten Formate für historische Dokumente ist PAGE XML.

Es kann zum Beispiel enthalten:

• Seitenabmessungen;
• Textbereiche;
• Zeilenkoordinaten;
• Grundlinien (Baselines);
• Lesereihenfolge;
• Transkription;
• zusätzliche Strukturinformationen.

Kraken unterstützt PAGE XML und das OCR-D-Ökosystem verwendet auch PAGE XML als Hauptformat Ground Truth. [4] [5]

Für ein Archivierungsprojekt empfiehlt es sich daher zu überprüfen, ob Ground Truth und Ergebnisse unabhängig von einer bestimmten Anwendung in ein standardisiertes Format exportiert werden können.

17. Führen Sie Aufzeichnungen über Experimente

Es entsteht ganz leicht eine Situation:

„Modell Nummer 7 war besser als Modell Nummer 6, aber wir wissen nicht mehr warum.“

Daher empfiehlt es sich, vom ersten Experiment an ein einfaches Protokoll einzuhalten.

Zum Beispiel:

Model: statek-001
Datum: 2026-09-09

Training:
45 Seiten
8 742 Wörter

Validation:
5 Seiten
963 Wörter

Base model:
Name / Kennung

Einstellungen:
...

CER validation:
7,4 %

Anmerkung:
Probleme mit Schreiber C.
Verwechselt häufig r/n und e/c.

Nächste Version:

Model: statek-002

Änderung:
+15 GT-Seiten von Schreiber C

CER validation:
5,8 %

Eine solche reine Textdatei kann später wertvoller sein als die Autosave-Protokolle selbst.

18. Versionierung

Git eignet sich für Konfigurationsdateien, Transkriptionsregeln, Skripte und Dokumentation.

Zum Beispiel:

git init

Wir müssen jedoch nicht Tausende großer TIFF-Bilder oder Multi-Gigabyte-Modelle in Git speichern.

Git eignet sich besonders für:

• Transkriptionsregeln;
• Skripte;
• Konfigurationsdateien;
• kleine XML-Dateien;
• Dokumentation von Experimenten.

Große Bilddaten lassen sich besser auf andere Weise archivieren.

19. Sicherung

Ground Truth ist normalerweise teurer als das HTR-Modell selbst.

Wir können das Modell erneut trainieren.

Eine manuell erstellte und überprüfte Transkription von Hunderten oder Tausenden Zeilen kann Dutzende bis Hunderte Stunden menschlicher Arbeit bedeuten.

Daher sollte Ground Truth regelmäßig in mindestens zwei unabhängigen Kopien gesichert werden.

Eine praktische Datenwerthierarchie sieht in der Regel wie folgt aus:

Original digitalisiertes Bild → Ground Truth → Metadaten und Dokumentation → Modell → automatisch generierte Ausgabe

Ein Model zu verlieren ist ärgerlich.

Ein Qualitätsverlust Ground Truth kann bedeuten, dass ein wesentlicher Teil des gesamten Projekts neu erstellt werden muss.

20. Empfohlene Testumgebung für Anfänger

Für den ersten Versuch können zwei Phasen empfohlen werden.

Phase 1 – keine Installation

Wir werden verwenden:

Transkribus + 10 bis 20 Seiten eines Dokuments

Ziel ist es zu verstehen:

• Segmentierung;
• Grundlinien (Baselines);
• Transkription;
• Ground Truth;
• bestehende Modelle;
• CER;
• Trainingsprinzip.

Erst wenn wir feststellen, dass wir HTR systematisch nutzen wollen, wechseln wir in eine lokale Umgebung.

Phase 2 – Lokales Labor

Auf einem gewöhnlichen Computer bereiten wir Folgendes vor:

Windows + WSL 2
oder
Linux

+
Git
+
Docker
+
eScriptoderium
+
Kraken
+
source code editoder
+
Git repositodery foder configuration and documentation

Dadurch erhalten wir eine Umgebung, in der wir sowohl über die eScriptorium-GUI als auch direkt mit Kraken experimentieren können.

21. Empfohlenes erstes technisches Experiment

Es ist nicht ratsam, nach der Installation sofort einen 300-seitigen Archivband hochzuladen.

Beispielsweise reichen fünf bis zehn Seiten aus.

Verfahren:

1. Kopieren Sie die Bilder in das Arbeitsverzeichnis.

2. Importieren Sie sie in eScriptorium oder Transkribus.

3. Segmentierung durchführen.

4. Überprüfen Sie die Grundlinien.

5. Probieren Sie ein vorhandenes HTR-Modell aus.

6. Mehrere Seiten manuell reparieren.

7. Ground Truth exportieren.

8. Stellen Sie sicher, dass wir Ground Truth neu laden können.

9. Wenn wir Kraken verwenden, führen Sie die Einzelbilderkennung über die Befehlszeile aus.

10. Notieren Sie die verwendete Software, das Modell und das erzielte Ergebnis.

Erst wenn diese kleine Schleife von Anfang bis Ende funktioniert, können wir das Experiment auf mehrere Dutzend Seiten ausdehnen.

22. Was würde ich für mein eigenes Archivprojekt wählen?

Wenn das Ziel in erster Linie die Verarbeitung historischer Dokumente und nicht das Studium der Serververwaltung ist, würde ich mit Transkribus beginnen.

Wenn sich herausstellt, dass wir Folgendes benötigen:

• volle Kontrolle über die Daten;
• lokale Verarbeitung;
• kundenspezifische Automatisierung;
• Experimentieren mit offenen Modellen;
• Anbindung an kundenspezifische Software;

Ich würde dann eine zweite Testumgebung aufbauen, basierend auf:

Docker + eScriptorium + Kraken.

Ich würde eine separate Installation von Kraken hauptsächlich für Experimente, automatisierte Skripte und detailliertere Arbeiten mit Modellen verwenden.

Dadurch werden drei Ebenen erstellt:

Transkribus
│
│  einfachste Nutzung
│
eScriptoderium
│
│  eigene Umgebung + grafische Oberfläche
│
Kraken
│
│  command line and direct woderk with HTR
│
own scripts and data woderkflows

Für Lehr- und Archivexperimente ist eine solche Anordnung praktischer als der Versuch, vom ersten Tag an eine vollständig benutzerdefinierte HTR-Infrastruktur zu erstellen.

Verwendete Hinweise und Quellen

[1]READ-COOP. How to use Transkribus eXpert (deprecated). Transkribus-Dokumentation. Der Transkribus eXpert-Desktop-Client wird nicht mehr aktualisiert und neue Funktionen werden an die Webanwendung weitergeleitet.
https://help.transkribus.org/downloading-and-installing-transkribus-expert-deprecated

[2]Scripta. eScriptorium. Beschreibung des Quellrepositorys und der Projektarchitektur. eScriptorium integriert Tools zur Transkription, Annotation, Schulung und Erkennung historischer Dokumente und verwendet Kraken.
https://gitlab.com/scripta/escriptorium

[3]Scripta. eScriptorium – Install with Docker. Aktuelle Installationsdokumentation. Es empfiehlt Docker, Docker Compose v2 und beschreibt auch die GPU-Konfiguration mit dem NVIDIA Container Toolkit.
https://gitlab.com/scripta/escriptorium/-/wikis/docker-install

[4]KIESSLING, Benjamin. Kraken 5.3 Documentation. Dokumentation von Installation, Segmentierung, Erkennung, Modellen und unterstützten Ausgabeformaten.
https://kraken.re/5.3.0/

[5]OCR-D. The Ground Truth Guidelines. Ground Truth – und PAGE XML-Dokumentation.
https://ocr-d.de/en/gt-guidelines/trans/

[6]OCR-D. OCR-D Quick Start Guide. Ein Beispiel für die Vorbereitung einer Containerumgebung mit Docker und die Arbeit mit historischen Dokumenten.
https://ocr-d.de/en/start