Anwenderdokumentation
Die Integration von Kitodo und OCR-D wurde konzipiert, um den Prozess der Digitalisierung des kulturellen Erbgutes und der Texterkennung zu erleichtern und zu beschleunigen. Das weit verbreitete Softwareprodukt Kitodo(-Production) unterstützt alle Phasen der Digitalisierung, aber die Texterkennung und Veröffentlichung mussten bisher separat und manuell durchgeführt werden, was einen enormen Zeitaufwand bedeutete. Eine Erweiterung des Kitodo-Workflows durch OCR-D und autonome Textveröffentlichung ermöglicht es, alle Schritte der Verarbeitung von historischen Texten zu automatisieren und den gesamten Zyklus von der Digitalisierung bis zur Veröffentlichung des Textes erheblich zu vereinfachen und zu beschleunigen.
Für eine qualitativ hochwertige Texterkennung ist es erforderlich, bestimmte OCR-D-Schritte durchzuführen. Die Menge der Schritte und ihre Reihenfolge werden durch Textparameter (Druckqualität, Schriftart und -größe usw.) bestimmt. OCR-D erlaubt es den AnwenderInnen, die OCR-D-Schritte und ihre Parameter beliebig zu kombinieren, um die besten Ergebnisse zu erreichen. In der integrierten Kitodo/OCR-D-Version können die AnwenderInnen (aktuell) die Schritte jedoch nicht selbst kombinieren, sondern müssen aus vordefinierten Optionen wählen, die aber mit den Administratoren abgestimmt werden können. Derzeit sind (an der UB Braunschweig) zwei Optionen implementiert, die hier als "simple" und "complex" bezeichnet werden.
Der „simple“ Workflow besteht aus zwei Teilen: die Texterkennung selbst und die Umwandlung der PAGE-XML Dateien (ein standart OCR-D Output) ins Format ALTO-XML:
tesserocr-recognize -P segmentation_level region -P model frak2021 -I OCR-D-IMG -O OCR-D-OCR
fileformat-transform -P from-to "page alto" -P script-args "--no-check-border --dummy-word" -I OCR-D-OCR -O FULLTEXT
Die Texterkennung wurde durch den Prozess ocrd-tesserocr-recognize
realisiert. In diesem Prozess werden die Binarisierung, die
Segmentierung von Regionen, die Erkennung von Tabellen und die
Texterkennung in einer bestimmten Reihenfolge durchgeführt. Als Ergebnis
dieses Prozesses bekommt man für jede Seite eine PageXML-Datei, die den
erkannten Text beinhaltet und weiter benutzt werden kann. Um die
Ergebnisse auf einem Publikationsserver veröffentlichen zu können,
benötigt man ggf. kein PAGE-XML, sondern ALTO-XML. Der zweite
Schritt des simplen Workflows – ocrd-fileformat-transform – generiert
daher aus PAGE- jeweils ALTO-Dateien.
Im „complex“ Workflow werden die einzelne OCR-D Schritte (Binarisierung,
Segmentierung, Dewarping und Erkennung) separat durchgeführt. Am Ende,
genauso wie im simplen Workflow, werden die PageXML-Daten mithilfe von
ocrd-fileformat-transform ins ALTO-Format umgewandelt:
sbb-binarize -P model default-2021-03-09 -I OCR-D-IMG -O binar
cis-ocropy-segment -I binar -O segment -P level-of-operation page
segment-repair -I segment -O repair
cis-ocropy-dewarp -I repair -O dewarp
tesserocr-recognize -P textequiv_level word -P find_tables true -P model frak2021 -I dewarp -O output
fileformat-transform -P from-to "page alto" -P script-args "--no-check-border --dummy-word" -I output -O FULLTEXT
Der Vorteil des simplen Workflows ist die Geschwindigkeit: Die Texte werden am schnellsten erkannt. Für die meisten Texte, insbesondere für deutlich gedruckten Bücher, liefert dieser Workflow bereits sehr gute Ergebnisse in kurze Zeit. Jedoch im Fall einer Mehrspaltigkeit, durchgedruckten Seiten, verschiedenen Papier- und Druckdefekte, usw., kann die Erkennungsqualität sehr schlecht sein. In diesem Fall wird dem Anwender der „complex“ Workflow empfohlen.
Dieser Workflow erlaubt es auch schlecht lesbaren Texte zu erkennen, braucht jedoch mehr Zeit dafür. Deswegen ist zu empfehlen, immer erst mit dem simplen Workflow anzufangen, Ergebnisse anzuschauen und bewerten (s. Kapitel „Ergebnisse anschauen und bewerten“) und im Fall unzureichender Erkennungsqualität, Werke mit dem complex Workflow erneut zu prozessieren.
Um die Texterkennung zu starten, ist im Kitodo.Production der Metadateneditor zu öffnen. In der Liste von Metadaten findet man den „OCR Workflow“-Parameter und wählt die gewünschte Option („simple“ oder „complex“) aus. Nachdem die Option gewählt wurde, sollte oben rechts die Taste „Speichern und Schließen“ gedrückt werden.
In der Tabelle der Vorgänger sollte der Vorgang links mit dem grünen Häkchen markiert werden.
Dann drückt man die Taste „Aktionen“ unten links und wählt aus dem Menü
die Option „KitodoScript ausführen“. Als Scriptname trägt man
action:runscript stepname:OCR script:OCR (die Namen hier sind nur
Beispiele) ein und drückt die Taste „KitodoScript ausführen“.
Damit wurde Texterkennung gestartet und läuft auf dem Server durch.
Wie bereits oben beschrieben, stehen als Ergebnis stehen am Ende des OCR-D-Prozesses das Verzeichnis mit PAGE-Dateien als auch das Verzeichnis mit den ALTO-Dateien. Außerdem gibt es ein zusätzliches Verzeichnis, das auch die alto-Dateien beinhaltet, die speziell dafür formatiert sind in s. g. OCR-D-Browser visualisiert zu werden. OCR-D-Browser ermöglicht die Ergebnisse direkt nach dem Prozessieren ohne zusätzlichen Aufwand anschauen und bewerten zu können. Dafür sollte man direkt nach dem Prozessieren dem CR-D-Browser Link folgen. Im angezeigtem Menü kenn man das Item „Jobs“ und dann aus
der Spalte „Workspace“ erschienener Tabelle die Job-ID (bzw. Kitodo-ID) auswählen.
Im geöffneten Fenster links sieht man alle Seiten des Vorgangs. Mit dem Mausklick wird die gewünschte Seite auf gemacht. Die grün markierten Bereiche verweisen auf die erkannten Textabschnitte.
Um die Texte in einem separaten Fenster zu sehen, soll man in obere Spalte eine „Auge“ anklicken und im Menü die Option „Text“ wählen.
In der rechten Seite des Fensters erscheint damit der erkannte Text.
Daraus kann man die Qualität der Texterkennung bewerten und die Entscheidung treffen, ob der Text publiziert werden kann, oder soll das OCR-D Prozess mit dem anderen („complexen“) Workflow wiederholt werden.
Um die erkannten Texte auf einer Präsentations-Platform zu veröffentlichen, kann man verschiedene Skripte ausführen, bspw., für das Veröffentlichen des eigentlichen Werks und ein Weiteres Skript für das (nachträgliche) anreichern der Texterkennung mit z.B. den alto-Dateien.
Um alle fürs Prozessieren benötigten Komponenten (Controller auf OCR-D-Server, Manager und Monitor auf Kitodo-Test-Server) neu zu starten, kann bspw. ein Ansible-Script genutzt werden. So können bspw. alle im Kitodo/OCR-D beteiligte Container (neu) gestartet werden.
Wie bereits im Kapitel „OCR-D Workflows“ beschrieben, gibt es zwei Workflows - „simple“ und „complex“ - zur Auswahl. Bei Bedarf kann man aber die bestehenden Workflows anpassen oder diese neue implementieren. Es ist zu empfehlen, solche Anpassungen bzw. Änderungen mit den anderen Kitodo/OCR-D NutzerInnen abzustimmen.
Es ist empfohlen, für jeden ocrd-workflow eine Datei zu erstellen und
diese dann z.B. mit einem Script ocr-workflow-simple.sh oder
ocr-workflow-complex.sh zu nutzen. Je nach der gewählter
Workflow-Option wird das passendes Skript aufgerufen. Die in den
Skripten eingetragenen Workflow-Schritte oder dessen Parametern können
(siehe Workflow-Guide) neu
kombiniert werden. Falls die neu eingetragene Workflow-Schritte das
Hochladen eines neuen Modell benötigen, muss man sich auf dem OCR-D
Server im OCR-D-Controller einloggen und dort entsprechend
Model-Guide
das neue Modell hochladen. Die bereits
hochgeladenen Modelle befinden sich auf dem OCR-D-Server im einem
entsprechenden Verzeichnis.
Bei Bedarf kann man auch auch die neuen Workflows einzuspielen. Dafür muss eine neue Workflow-Datei erstellt werden in der die OCR-D Befehle enthalten sind (Hinweis: Dies ist nur für OCR-D erfahrenden AnwenderInnen empfohlen, siehe Workflow-Guide). Der Namen dieser Datei sollte entweder im Befehl for_production.sh stehen (beim Starten aus der Kommandozeile), oder im Startscript (beim Starten durch Ausführen vom Skript) oder im Kitodo-Scrpit (beim Starten durch Ausführen von Kitodo-Script).
Ein OCR-D Prozess kann nicht nur durch Ausführen des Kitodo-Scripts, sonder auch direkt auf dem Server gestartet werden. Um die Texterkennung aus der Kommandozeile zu starten, sollte man sich mit dem Befehl
docker exec -u ocrd ocrd_kitodo-ocrd-manager-1
im OCR-D-Manager einloggen und dort das Script for_production.sh mit
den folgenden Parametern auszuführen:
for_production.sh --ocr-subdir alto/images --proc-id <Kitodo-ID> --task-id <Task-ID> --lang deu --script Fraktur --workflow <path> /data/<Kitodo-ID>
Der gestartete Prozess kann aus einer anderen Serversession verfolgt werden (s. Abschnitt „Log-Daten verfolgen“). Der Parameter Task-ID kann in diesem Fall (noch) beliebig gewählt werden. Ändern sich die Parameter wenig, kann natürlich durch weitere Skripte der Aufruf gekapselt werden, z.B.:
<Script-Name>.sh <Kitodo-ID> <Task-ID>
Um mehrere Vorgänge automatisch nacheinander starten zu können, kann man ein Skript mit einer Schleife verwenden. Der Inhalt dieses Skriptes sollte so gestaltet sein, dass es über eine Liste mit allen relevanten Kitodo-IDs geht. Das Script startet das Ausführen der Kitodo-Vorgänge am besten automatisch nach der Prüfung, ob das Vorgangsverzeichnis schon die alto-Dateien beinhaltet (bereits prozessierte Vorgänge werden nicht noch mal prozessiert, das spart viel Zeit).
Um den OCR-D Prozess zu kontrollieren (und auch zu erkennen ob das Prozess noch läuft oder schon beendet wurde), kann man auf dem Server die Log Daten aufrufen. Dafür führt man den Befehl
docker logs --follow ocrd_kitodo-ocrd-manager-1
aus. Als Ergebnis werden die Log-Daten fortlaufend gezeigt.
Nach dem erfolgreich abgeschlossenen OCR-D Prozess findet man die
Ergebnisse der Texterkennung (alto-Dateien) im Kitodo-Verzeichnis
.../<Kitodo-ID>/alto/images. Diese Dateien werden benutzt um die Texte
zu veröffentlichen (s. Kapitel „Ergebnisse veröffentlichen“). Darüber
hinaus erscheint das Verzeichnis <path>/ocr-d/data/Kitodo-ID, wo
die OCR-D Ergebnisse ebenso gespeichert werden. Das Unterverzeichnis
FULLTEXT beinhaltet die alto-Dateien, die mit den alto-Dateien aus dem
Kitodo-Verzeichnis (s. oben) inhaltlich identisch, aber anders benannt
sind. Die werden von OCRD-Browser benutzt um die Ergebnisse zu
visualisieren (s. Kapitel „Ergebnisse anschauen und bewerten“). Weitere
Unterverzeichnisse beinhalten andere zwischenzeitliche Ergebnisse des
Prozessierens (PAGE-XML Dateien; bei dem „complexen“ Prozessieren auch
die Ergebnisse aller Zwischenschritten, wie z. Bsp. Dewarping,
Segmentierung und Binarisierung). Diese Daten können bei Bedarf weiter
benutzt werden um die Texte auf den alternativen Plattformen zu
veröffentlichen.