OCR-D, was bisher geschah
(Überblick, Verlauf, Status)
Robert Sachunsky, Kay-Michael Würzner 
3.3.2023 : https://hackmd.io/@bertsky/ocrd-recap-dfg
Überblick Projekthistorie
Ziel: Volltextdigitalisierung der VD-Bestände (16.-19. Jh.)
- 2015-2017: Phase 1: Bestandsaufnahme, Bedarfsanalyse, Konzeption
- 2018-2020: Phase 2: Entwicklung von Prototypen
- 1 Koordinierungsprojekt
- 8 Modulprojekte (v.a. Universitäten)
- 2021-2023: Phase 3: Integration in Bibliotheksumfeld
- 1 Koordinierungsprojekt
- 4 Implementierungsprojekte (v.a. Uni-Bibliotheken)
- 3 Modulprojekte
Phase 1: Ziele
-
technische Vorbereitung der massenhaften, maschinellen Vervolltextung von digitalisierten Drucken des 16.-19. Jh.
-
Text- und Strukturerfassung zur Schaffung wissenschaftlich nutzbarer Forschungsdaten
-
Antworten auf sich ergebende konzeptionelle, informationswissenschaftliche und organisatorische Fragen
Phase 1: Prämissen
-
Konzentration auf den Sachbefund
(Lückenschluß Forschung→Praxis)- unabhängig von fachspezifischen Interessen
- Auswahl bzw. Anpassung etablierter Standards
-
Offenheit für unterschiedlichste Forschungsinteressen
(Methodenpluralismus) -
Orientierung der Qualität der Text- und Strukturerfassung an (realisierbaren) wissenschaftlichen Ansprüchen
-
Qualitätskontrolle nach den einzelnen Prozessschritten der OCR
-
Angabe nutzungsorientierter Qualitätsstufen
Phase 1: Ergebnisse
-
Sichtung und Charakterisierung des Ausgangsmaterials,
Erfassung des Ist-Standes OCR (Forschung+Praxis) -
Konzeption und Ausschreibung der Modulprojekte
- schematisches Funktionsmodell
- Identifikation von Entwicklungsbedarfen
-
Konzeption der Arbeit des Koordinierungsprojekts
- technisch-organisatorische Betreuung der Modulprojekte
- (weitere) Bearbeitung der Arbeitspakete
Phase 1: Ergebnisse: Ausgangsmaterial
-
Vision: Vervolltextung von ca. 1 Mio. Titeln mit ca. 300 Mio. Bildseiten (VD16-18)
unter Hinzunahme von deutschen Drucken des 19. Jh.: Vervielfachung -
manuelle Vorauswahl / Sichtung bei damals 400 tsd. bilddigitalisierten VD-Titeln mit 120 Mio. Bildseiten unmöglich
-
heterogenes Material (u. a. Qualität der Vorlage u. des Digitalisats) …
Phase 1: Ergebnisse: Ausgangsmaterial
-
unterschiedl. Materialität und Erhaltungszustand des Originals: z.B. Durchscheinen, Flecken, Fehlstellen
-
suboptimale Scans: über Blattrand hinaus (non-textual noise), gegenüberliegende Seite teilweise sichtbar (textual noise)
-
unterschiedl. Drucktypen und Layouts (meist einhergehend mit unterschiedl. Sprache und Funktion): Schriftarten, ein- vs. mehrspaltig, Marginalien, Kolumnentitel, Abbildungen, gattungs- und inhaltsspezifische Layouts
-
Ungleichförmigkeit auch innerhalb der Titel (Titelblatt, Inhaltsverzeichnis, Mengentext, Index etc.)
Phase 1: Ergebnisse: Ausgangsmaterial
Phase 1: Ergebnisse: Ausgangsmaterial
Phase 1: Ergebnisse: Ausgangsmaterial
Phase 1: Ergebnisse: Ausgangsmaterial
Phase 1: Ergebnisse: Ausgangsmaterial
Phase 1: Ergebnisse: Funktionsmodell
-
schematischer OCR-Workflow
- vom Digitalisat bis zur Archivierung des Volltextes
- Integration aller Module
-
verschiedene Verarbeitungsebenen
- Dokument, Seite, Region, Zeile
- Operationen auf mehreren Ebenen
- maximale Adaptivität bzgl. visueller/textueller Charakteristika
- Rekonstruierbarkeit über Metadaten
-
jew. Qualitätssicherung zur möglichst unmittelbaren Intervention
Phase 1: Ergebnisse: Funktionsmodell
Phase 1: Ergebnisse: Funktionsmodell
-
modularer Ansatz
- alle Teilaufgaben separat adressierbar
- standardisierte Schnittstellen und Formate
- Teilprozessierung möglich
-
alternative Implementierungen pro Verarbeitungsschritt
- Auswahl des Moduls bei Workflow-Konfiguration, oder
- Auswahl des besten Ergebnisses durch QS-Schritt, oder
- Vereinigung der Einzelergebnisse (insbesondere bei OCR)
"Nimm die Binarisierung von Ocropus, die Segmentierung von Tesseract und die Texterkennung von Calamari"
-
Leichte Integration neuer Tools
Phase 1: Ergebnisse: Betreuung Modulprojekte
Bedingungen für maximale Interaktion zwischen den MP schaffen:
- Berichtswesen:
- MP kommunizieren inhaltliche Ergebnisse an KP und berichten an DFG
- Inhaltliche Fragen und Ideenaustausch:
- 3 Workshops, Confluence, persönlicher Austausch
- anlassbezogene Arbeitsgespräche
- Einbeziehung der Fach-Community:
- laufende Information zum Stand der MP und OCR-D
- Transparenz und offener Dialog
- Entwicklungsversionen von zu entwickelnden Programmen
- Git-Repositorium, laufende Integration, standardisierte Dokumentation
Phase 1: Ergebnisse: Gesamtintegration
-
Zusammenführung der (Teil-)Ergebnisse
- Erstellung eines funktionierenden, vollumfassenden Beispielablaufs durch das KP – Aufbau während der Projektphase
-
Abschlussbericht mit Evaluation und technischer Dokumentation
-
zeitversetzte Ausschreibung für ein unabhängiges Modulprojekt 10 „Workflow und Datenlogistik“:Zusammenführung der Modulergebnisse zu einem produktiven, modellhaften Workflow
-
DFG-Prüfgruppe:
- Gesamtintegration als zentrale und immanente Aufgabe des KP
- Einbeziehung eines zusätzlichen Partners mit nachgewiesener IT-Kompetenz → KIT
Phase 1: Ergebnisse: Nutzungsszenarien
-
Dienstleister: externe, meist kommerzielle Anbieter; GBV
(Kontakt, Kooperationsvereinbarungen, Wissenstransfer) -
Inhouse-Digitalisierung: Standardworkflows, Standardsoftware
(Zielarchitektur Kitodo) -
spezielle Infrastrukturen und Anwender jenseits Bibliotheken: spezifische Workflows, Eigenentwicklung
(Mitnahmeeffekt im Open-Source-Entwicklungsmodell)
Phase 2: Ziele
- Spezifikation von Schnittstellen, Standards für Daten- und Metadatenformate
- Erstellung von Referenzkorpora (Ground Truth)
- Weiterentwicklung der Optical Layout Recognition (OLR)
- Analyse/Integration vorhandener Tools
- Softwarepaket zur OCR-Verarbeitung von Digitalisaten der VDs
- Erstellung eines Standard-Workflows
- Erstellung von Verfahren zur Qualitätssicherung
Phase 2: Modulprojekte
- Bildoptimierung (DFKI Kaiserslautern)
- Layoutanalyse und Dokumenstruktur (DFKI Kaiserslautern)
- Layoutanalyse (Universität Würzburg)
- Tesseract (UB Mannheim)
- OCR-Nachkorrektur (Universität Leipzig)
- OCR-Nachkorrektur (LMU München)
- Schriftarterkennung (Universitäten Leipzig / Erlangen / Mainz)
- Langzeitarchivierung (SUB Göttingen, GWDG Göttingen)
nicht bewilligt:
- Qualitätssicherung (SBB, BBAW)
Phase 2: Ergebnis
- keine QS, kein Standard-Workflow
- keine Fehlerbehandlung / Performanz / Skalierbarkeit
- etliche integrierte Tools
- praktisch nutzbarer Prototyp (Framework+Module)
- v.a. Monographien, teilw. Zeitungen
- noch nicht Handschriften, Gegenwartsdokumente
- einfach installierbar, gut dokumentiert
- neuartige, große Flexibilität für Workflows
- Community, Spezifikationen, Dokumentation
Phase 2: Ergebnis: Community
- Github-Entwicklungsmodell: release early, release often
https://github.com/topics/ocr-d https://github.com/OCR-D - Offener Chat mit Support: https://gitter.im/OCR-D/Lobby
- 3 Entwicklertreffen, gem. Teilnahme an Tagungen
- regelmäßig offene, virtuelle Treffen:
- zweiwöchentlich Mittwoch 14 Uhr: offener Tech-Call
- monatlich jeden 1. Freitag: OCR-D Forum
- Wiki für nutzergetriebene Dokumentation:
https://github.com/OCR-D/ocrd-website/wiki - Gründung DHd AG OCR
Phase 2: Ergebnis: Spezifikationen
- verbindliche Vorgaben, wie sich die Prozessoren verhalten müssen
- einheitliche Kommandozeilenschnittstellen
- mit Schemasprachen Datenaustausch verifizieren
- Konventionen explizit und validierbar machen
- Software-Richtlinien, Ground-Truth-Richtlinien
- Referenzimplementierung https://github.com/OCR-D/core
- zum Entwickeln von spezifikationsgemäßen Prozessoren
(Python-API, Bashlib) - allgemeine Nutzerwerkzeuge:
ocrd workspace ...ocrd process ...ocrd resmgr ...ocrd zip ...ocrd validate ...
- zum Entwickeln von spezifikationsgemäßen Prozessoren
Phase 2: Ergebnis: Dokumentation
- alle Prozessoren haben ein mehr oder weniger detailliertes README
- alle Prozessoren unterstützen
--help- zeigt Docstrings, CLI und Parameter-JSON
- bspw.:
ocrd-olena-binarize -h
- Umfassende zentrale Dokumentation: https://ocr-d.de
- Setup Guide beschreibt Installation
- User Guide beschreibt allg. Umgang mit Daten und Werkzeugen
- Workflow-Guide beschreibt verfügbare Prozessoren und deren Zusammenspiel
Phase 2: Pilotierung
-
Pilotanwender:
- SLUB Dresden, SBB Berlin, BBAW Berlin, HAB Wolfenbüttel
- SUB Göttingen, ULB Darmstadt
- UB Rostock, UB Heidelberg, UB Halle, UB Mannheim
-
jeweils unabhängig praktische Erprobung und Begutachtung
-
Ergebnis: "brauchbar, aber…"
seither: Entwicklungen OCR-D in der SLUB
- intensives Engagement bei Weiterentwicklung und Support
(Konzeption, Issues, Reviews, PRs, neue Tools, Modelle, Wartung) - github.com/OCR-D, github.com/slub, github.com/bertsky
seither: Anwendungen OCR-D in der SLUB
- GT-Erzeugung und OCR-Training für "Lücken" bei Fraktur und Antiqua
- Obersorbisch → GT-Erzeugung, Modelltraining
- Re-OCR Börsenblatt (Fraktur/Antiqua/Schmuck)
- Herrnhuter Nachrichten (Fraktur)
- Paulusbriefe (Latein-Altgr. interlinear glossiert)
- Hofzuweisungslisten (Typoskript/Formulare)
- Kurrent-Handschriften (Herrnhut, Soldatenbriefe, Preusker…)
Phase 3: Ziele
-
Entwicklung generischer Implementierungspakete
(in unterschiedlichen Integrationsszenarien) – close to ready-to-use -
Optimierung einzelner Module
-
Koordinierungsprojekt:
- techn.-organis. Betreuung der Implementierungs- und Modulprojekte
- Standardisierung und Nachnutzung/Abgrenzung untereinander
- Qualitätsverbesserung OCR-D-Software
- Nachhaltigkeitskonzept
Phase 3: Implementierungsprojekte
- Integration in Kitodo u. DFG-Viewer
(SLUB, UB Braunschweig, UB Mannheim) - Integration in Goobi / auf HPC-Cluster
(GWDG, SUB Göttingen) - Integration in OCR-Suite OCR4all
(GEI Braunschweig, Uni Würzburg) - Einsatz für Re-OCR auf VD18
(UB Halle)
Phase 3: Modulprojekte
- werkspezifisches Training von OCR-Modellen
(UB Mannheim) - Schriftarterkennung für historische Drucke
(JGU Mainz, FAU Erlangen) - Langzeitarchivierung
(GWDG, SUB Göttingen)
Phase 3: Zusammenarbeit mit dem KP
- Planung: Vorlauf gegenüber IP und MP
aber spät besetzt