### 4. - 5. Oktober ([Bibliotheca Baltica](https://www.bb2018.uni-rostock.de/) in Rostock)
#### Datenformat für Alignierung und Segmentierungsmehrdeutigkeit
#### ALTO
Die angesammelten Probleme sind großteils spezifisch für Page-XML:
- kein expliziter Whitespace (mögliche Abhilfe wäre eine Erweiterung)
- Redundanz der textlichen Annotation auf 4 Hierarchie-Ebenen ohne garantierte Konsistenz (mögliche Abhilfe wäre eine Validierung der Konsistenz per ocrd-Workspace)
ALTO kann Whitespace repräsentieren.
Bibliotheken benutzen schon ALTO.
Die Verwendung von ALTO würde die Probleme mit PageXML lösen.
PageXML speichert viermal den gleichen Text auf verschiedenen Ebenen (hohe
Redundanz), ALTO nicht.
Bei ALTO-XML wäre beides nicht der Fall. Bibliotheken benutzen ohnehin meist ALTO. Die meisten anderen Gründe, die in der Projektierungsphase von OCR-D gegen ALTO sprachen, sind inzwischen obsolet. Einzig verbleibender Minuspunkt ist, daß die Erweiterung langsamer und aufwendiger ist, weil die Standardisierung auf mehr Parteien Rücksicht nehmen muß. Womöglich wechseln wir aber insgesamt dorthin zurück. Oder wir finden doch noch harte Gründe für Page-XML.
#### Transkribus
Transkribus wir definitiv nicht in die OCR-D-Pipeline eingebaut werden, da
es nicht Open-Source ist (bzw. nur das Desktop-Programm ist OPen-Source,
nicht aber die OCR).
Transkribus wird definitiv nicht in OCR-D integriert werden, da es nicht Open-Source ist (bzw. nur der Client, nicht aber die OCR selber) und dies auch nicht absehbar. Interoperabilität ist allerdings erstrebenswert.
Abgrenzung zum Transkribus-Ansatz:
Abgrenzung von OCR-D zu Transkribus-Ansatz:
Bei Transkribus führt ein einzelner Forscher eine
Spezialisierung für seinen Anwendungsfall durch.
Unser Auftrag ist die Massendigitalisierung.
Optimierung und Spezialisierung für seinen Anwendungsfall durch (teilweise mit selbst-trainierten Modellen), auf einem zentral organisierten und verwalteten System mit vorgegebenen Workflows.
Unser Auftrag ist die Massendigitalisierung unter Einbezug möglichst vieler Werkzeuge und Ressourcen (Methodenpluralismus) in flexibel konfigurierbaren Workflows mit dezentralem Deployment.
#### Metadaten
Metadaten sind problematisch, da es hier sehr viel Varianz gibt und
Menschen nicht verlässlich sind. Nur die Kapiteleinteilung ist verlässlich.
Metadaten sind teilweise problematisch, da es hier sehr viel Varianz und Rauschen gibt und
manuelle Klassifikation/Katalogisierung nicht immer verlässlich und konsistent ist. Am ehesten verläßlich ist die Kapiteleinteilung.
#### Modellrepositorium
Das Modul aus Karlsruhe will bis Ende des Jahres ein System für die
Modellablage ausgesetzt haben.
#### Transfer Learning
#### Lehren aus dem Deeplearning-Bootcamp
Interessant wäre die Verwendung von Transfer Learning, also Training großer
Modelle mit synchronen Daten und eine Spezialisierung mit den DTA-Daten.
* Initialisierung, Regularisierung, Optimierung und andere Hyperparameter können entscheidend sein
* besonders wichtig für tiefe Netze ist Initialisierung durch *Transfer-learning*
1. auf jeweils flacheren Netzen, oder
2. bei uns von großen Mengen synchroner Daten zu kleinen historischen wie DTA-Texten, sowie
3. von unüberwacht trainiertem Autoencoder zu überwacht trainiertem Denoising
[1 und 3 haben wir schon, aber viele Hyperparameter bislang rein heuristisch]
#### Tesseract und Modellierung von Font-Informationen
...
...
@@ -1005,67 +1007,49 @@ Tesseract kombiniert die Ergebnisse über die Konfidenzen.
Auf welcher Ebene möchte man die Metadaten annotieren?
Die Schriftarterkennung hängt von dem Modul aus Erlangen ab.
Sie müssen eine Schnittstelle bereitstellen
Sie müssen eine Schnittstelle bereitstellen, mit der bspw. die OCR passende Modelle laden kann
(Prozess-Metadaten sollten sagen, wohin mit den Workflow-Metadaten).
Zeichensatz als zusätzlichen Parameter im OCR-Wrapper, den die OCR-Engine
nutzen kann?
Es wird mittels einer Richtlinie festgelegt, welche Kodierung
konkurrierender Zeichen (ü als einzelnes Zeichen oder als u + Striche)
gewählt werden soll.
Metadaten auf Wortebene (also v.a. Schriftart und -form) wären nützlich, sind aber sehr schwer zu beschaffen. Die Genauigkeit der Schriftarterkennung sinkt rapide mit der Ortsauflösung. Es wird vermutlich so sein, dass es die Font-Merkmale erstmal nur auf Zeilenebene gibt. Ein späterer zweistufiger Prozeß (zeilenweise Fontklassifikation, OCR, wortweise Fontklassifikation, Nachkorrektur) wäre denkbar, aber aufwendig.
`char_blacklist` und `char_whitelist` nur in Tesseract 3? (nicht in Tesseract 4?)
Zeichensatz als zusätzlichen Parameter im OCR-Wrapper, den die OCR-Engine nutzen kann?
Man kann die OCR-Engines so einstellen, dass sie NUR Zeichenerkennung
durchführen und kein Sprachmodell verwenden.
Nachkorrektur wird dann nur im Modul Nachkorrektur durchgeführt.
Richtlinie zur Kodierung mit Unicode ist Normalform für Kanonische Komposition (NFC), also keine Dekomposition
(z.B. "ü" vs "ü"), aber unklar ob auch Kompatibilität (NFKC), denn GT-Transkriptionsrichtlinien differenzieren dort (z.B. bei Ligaturen ja (Reproduktion durch Textsatzregeln), bei "ſ=s" nein, Blackletter und Superskript ja (Reproduktion durch Fontmerkmale)).
Bei Tesseract kann man Zeichen ins Modell nachtrainieren.
`char_blacklist` und `char_whitelist` bisher nur mit Modellen aus Tesseract 3 (nicht LSTMs), entweder in Tesseract nachholen oder in Wrapper realisieren (bei Wahl des Schriftmodells oder gezielt beim Decoding).
Metadaten auf Wortebene?
Wenn Wortsegmentierung unterschiedlich ist, können beide Metadaten nicht
zusammengebracht werden.
(z.B. bei Multi-OCR mit verschiedenen Segmentierungen)
Bei Tesseract kann man inzwischen einzelne fehlende Zeichen ins Modell nachtrainieren.
Es wird vermutlich so sein, dass es die Font-Features erstmal nur auf
Zeilenebene gibt.
Man kann die OCR-Engines so einstellen, dass sie *nur* Zeichenerkennung durchführen und kein Sprachmodell verwenden.
Dies wird dann erst vom Modul Nachkorrektur durchgeführt, indem von allen Hypothesen der beste Pfad dekodiert wird.
#### Multi-OCR-Alignierung
#### Multi-OCR-Alignierung und Schnittstelle OCR-Nachkorrektur
Was passiert mit den Koordinaten?
Was mit den Font-Metadaten?
Was mit den Font-Metadaten (Schriftart und -form)?
Zum Teil wechselt die Font innerhalb eines einzelnen Wortes, daher müssten
diese Merkmale sogar auf Glyph-Ebene stehen.
Man kann diese Informationen nicht trivial wieder zusammensetzen, v.a. wenn die Segmentierung abweicht. Selbst wenn man die Wortebene "wegläßt", reicht eine direkte lineare Glyph-Annotation nicht aus, um die Koordinaten aus verschiedenen OCR zu integrieren. Die Aufgabe ließe sich zwar durch Verwendung von Zeigern auf `@id` in `TextEquiv/@custom` prinzipiell lösen und die Heuristiken dabei etwas erleichtern:
- Font-Feature-Konflikte werden über Mehrheitsentscheid gelöst.
- Die Koordinaten werden am Ende nur für die visuelle Markierung von Suchbegriffen im Faksimile verwendet. Genauigkeit ist hier also nicht entscheidend.
Man kann diese Informationen nicht trivial wieder zusammensetzen.
Aber solche "Buchhaltung" zwischen der Alignierung und den Referenzen zu den OCR-Ausgaben ist aufwendig, und die quasilineare Form verschenkt bei großen N auch Qualität. Wenn wir die Alignierung in PageXML darstellen wollen, sollten wir es lieber erweitern, da wir auf das Format leicht Einfluß nehmen können.
Bezugseinheit zwischen den OCRs:
- feste Zeilensegmentierung
- die Koordianten sind eine verlässliche Bezugsgröße
- die Koordinaten sind eine verlässliche Bezugsgröße, ebenso die Pixel-Ebene (LSTM-Zeitschritte)
- die Wortebene/Zeichenebene sind nur vage und nicht verlässlich
Wenn wir eine Alignierung in PageXML darstellen wollen, können wir
Möglichkeiten dafür schaffen, da wir über der Format die volle Freiheit
haben.
Wortebene der Eingabe wegwerfen?
Wenn die Zeichenebene auch Koordinaten hat, können wir die Wortebene aus
den Zeichen und deren Koordinaten herstellen.
Font-Feature-Konflikte werden über Mehrheitsentscheid gelöst.
Zum Teil wechselt die Font innerhalb eines einzelnen Wortes, daher müssten
die Font-Features auf Glyph-Ebene stehen.
Die Koordinaten werden nur für das Highlighting von Suchbegriffen
verwendet. Genauigkeit ist hier also nicht entscheidend.
Darstellung der Alignierung durch diff-Format?
Darstellugn als string in PageXML speichern?
Aber diff legt sich auf einen Master fest und beschreibt Editieroperationen
zu Master (wie wird das in der Biologie gelöst?)
Die natürliche Darstellungsform für Multi-OCR ist ein gerichteter azyklischer **Hypothesengraph**. Solche werden von verschiedenen OCR bereits ausgegeben. Für die FST-Nachkorrektur wäre es sehr vorteilhaft. Eine PageXML-Erweiterung `TextSegmentLattice` mit `TextSegmentNode` und `TextSegmentArc` (ähnlich wie GraphML) wäre hier ideal und könnte verschiedene Hierarchieebenen aufnehmen, je nach Betriebsmodus von OCR und Nachkorrektur (von Wörtern über Zeichen bis Pixel).
Für Nachkorrektur mit RNN hingegen wäre ein Attention-basiertes Softalignment direkt auf den N vollen Konfidenz-/ **Konfusionsmatrizen** (also äquidistante LSTM-Zeitschritte, gesamter Zeichensatz) besser geeignet. Hierfür bieten die ersten OCR bereits eine API, weitere Schritte und eine Vereinheitlichung wären aber sinnvoll. PageXML ließe sich auch hierfür erweitern. Koordinaten könnten indirekt aus dem Zeitschritt und Fontmerkmale als zusätzliche Ausgabedimensionen erhalten werden.
Alignment allein mittels Zeichenketten-Distanz (Levenshtein/Needleman-Wunsch/LCS) ist nicht nur fehleranfällig (Zerreißen von decomposed Codepoints, Rekursionstiefe bei sehr schlechter OCR, faire Verteilung der Zeichenmasse auf die Positionen) sondern ignoriert auch die wertvolle Information der Koordinaten. Für allgemeines Multiclass-Alignment (nicht nur paarweise Annäherungen) gibt es ohnehin noch keine allgemeingültigen, nutzbaren Bibliotheken (in Python/C). Wir müssen uns dies also selber paarweise zusammensetzen. Dabei können wir leicht auf Koordinaten-Heuristiken zurückgreifen und ein eigenes Graph-Format erzeugen.
Wir bauen zunächst einen echten Datensatz zu Demozwecken auf. Wir probieren difflib.SequenceMatcher (und das API-gleiche aber auf CER-Minimierung gerichtete edit_distance), sowie python_alignment.sequencealigner. Alle anderen Bibliotheken (einschließlich CIS) kommen erstmal nicht infrage. Als Daten nehmen wir Tesseract- und Ocropus-Ergebnisse auf verschiedenen Modellen. Wir messen die durchschnittlich erreichte Distanz auf größeren Datenmengen, und versuchen einzelne interessante Fälle zu visualisieren (z.B. mittels tikz oder dot, bei difflib-API auch mit paarweisem HtmlDiff). Dann exportieren wir ein Graph-Format und bringen es als Vorschlag ein.
