hOCR Editor ist ein geplanter grafischer Editor zur Bearbeitung von OCR-Ergebnissen im offenen Standardformat hOCR 1.2. Damit sollen die Ergebnisse originalgetreu und verlustfrei bearbeitbar sein.

Die Idee entstand aus meiner Bachelor-Thesis über die „Entwicklung eines hOCR-Editors zur Bearbeitung von OCR-Ergebnissen“. Ein Wireframe zur Verdeutlichung meiner Idee:

Wireframe

Einleitung Link zu Überschrift

OCR-Engines können Ergebnisse in offenen Formaten wie hOCR, ALTO und PAGE ausgeben.
Die Formate können den reinen Text um weitere Informationen anreichern, z.B. mit:

  • Bounding-Boxes (dt. Begrenzungsrechtecke) (hOCR: bbox) für Positionen und Maße von Absätzen, Abbildungen, Zeilen, Wörtern oder gar Buchstaben. Damit lässt sich das Layout definieren.
  • Confidence-Werten, die widerspiegeln, mit welcher Gewissheit Zeichen/Wörter erkannt wurden.
  • typographischen Details wie z.B. die Baseline (dt. Grundlinie).

Aus den OCR-Ergebnissen können z.B. durchsuchbare PDFs erzeugt werden, z.B. mithilfe von OCRmyPDF. Das PDF besteht dann aus den eingescannten Seiten als Rastergrafik mit überlagerter unsichtbarer, durchsuchbarer und markierbarer Textebene.

❓ Problem Link zu Überschrift

Ein grundsätzliches Problem der OCR ist die Fehleranfälligkeit. Es werden oft falsche Wörter erkannt. Die Korrektheit der Ergebnisse ist mitunter aber sehr wichtig, je nach Anwendungsfall. Ein paar Beispiele:

  • beim Training von OCR-Engines: Der sogenannte Ground-Truth muss stimmen.
  • in Gedächtnisinstitutionen bei der Digitalisierung von historischem Schriftgut
  • bei der Retrodigitalisierung in Unternehmen und Behörden (z.B. Zahlungsdetails bei Rechnungen)

Außerdem betrifft Datenverlust viele OCR-Workflows. Bei der Weiterverarbeitung der OCR-Ergebnisse (zum Beispiel der PDF-Erzeugung) geht ein Großteil der Daten (z.B. typografische Details) verloren. Die Umwandlung von Scan zu hOCR zu PDF ist verlustbehaftet.

Selbst bei der Round-Trip-Serialisierung kann es zu Datenverlust kommen: Werden hOCR-Daten geladen und direkt wieder gespeichert kommt es meist zu unerwünschten Änderungen im hOCR-Dokument. Wenn beispielsweise eine Bounding-Box vertikal verschoben wird, sollte sich in den hOCR-Daten eigentlich nur eine Zahl ändern. Das ist insbesondere für sinnvolle textbasierte Versionskontrolle (z.B. mit Git) notwendig. Versionskontrolle wiederum ist im Bereich der Datenintegrität (z.B. in Gedächtnisinstitutionen) generell wichtig. Außerdem erlaubt ein sauberer Round-Trip vernünftige Integrationstests, welche prüfen, dass die Daten unverändert bleiben.

Es gibt derzeit keinen einzigen ausgereiften grafischen Editor für OCR-Ergebnisse in offenen Standardformaten wie hOCR, ALTO oder PAGE, welcher nicht vom Problem des Datenverlusts betroffen ist. Es gibt zwar Editoren für OCR-Ergebnisse (z.B. Adobe Acrobat, OmniPage, ABBYY FineReader), diese sind allerdings kostspielig und basieren auf proprietären Formaten für OCR-Ergebnisse. Institutionen wie Archive setzen aber auf offene Standards zur Vermeidung von Lock-in-Effekten.

💡 Lösung Link zu Überschrift

Die Basisbibliothek HocrSharp modelliert den gesamten hOCR-Standard (mitsamt seiner Dialekte) auf Datenebene und löst das Problem der verlustbehafteten Round-Trip-Konvertierung. Ich habe in meiner beruflichen Laufbahn mehrfach an Projekten gearbeitet, bei denen es um die Lösung genau dieses Problems ging, und lasse mein Wissen hier einfließen.

Der darauf aufbauende HocrSharp.Editor ist GUI-Frontend und erlaubt die visuelle Bearbeitung der OCR-Ergebnisse: Bounding Boxes, Text, Properties, Struktur und Layout können bearbeitet werden. Korrekturlesen ist möglich. Reaktive Programmierung mittels Avalonia UI und saubere MVVM-Architektur lösen das Round-Trip-Problem selbst auf der höheren GUI-Ebene.

🎯 Zielgruppen Link zu Überschrift

Anwendungsfälle sind OCR-Workflows, die vollständige Kontrolle und Datenintegrität und Tauglichkeit für Langzeitarchivierung priorisieren, also Wert auf minimal-invasive Bearbeitung von OCR-Ergebnissen legen. Daher zählen zu den Zielgruppen vor allem:

  • Gedächtnisinstitutionen, wie z.B.:
  • Dienstleister für (Retro-)Digitalisierung
  • Wissenschaftler in den Digital Humanities
  • Nutzer von OCRmyPDF und Tesseract

Auch ich selbst habe Bedarf für solch eine Software. Mit einer Leidenschaft für Genealogie habe ich heimatkundliche Bücher für private Zwecke eingescannt und mittels Tesseract 4.0.0-beta.1 OCR durchgeführt und die hOCR-Daten bereits teilweise händisch/programmatisch korrigiert. Ich benötige aber auch einen visuellen Editor für weitere Korrekturen und Annotationen ohne „Nebenwirkungen“ beim Bearbeiten.

🔍 Status Link zu Überschrift

  • Entwicklung seit Anfang 2025 wieder aufgenommen
  • Basisbibliothek HocrSharp:
    • weitreichende Testabdeckung, inkl. Tests für Standard-Compliance
    • praktisch fertiggestellt
  • Frontend HocrSharp.Editor
    • in Arbeit, Mockups vorhanden
  • offen für Open-Source

🤝 Aktuelles Ziel Link zu Überschrift

Ich suche derzeit fachliche Rückmeldung aus der Praxis:

  • Gibt es in Ihrem Umfeld Bedarf für einen solchen Editor?
  • Welche Funktionen wären aus Ihrer Sicht unverzichtbar?
  • Welche Stolpersteine haben Sie mit hOCR bisher erlebt?

📬 Kontakt: mail@akopetsch.de