- Strukturelemente im Ground Truth: TextRegion, GraphicRegion,
SeparatorRegion
- Strukturelemente im Ground Truth: `TextRegion`, `GraphicRegion` (aber nicht `ImageRegion` oder `LineDrawingRegion`), `SeparatorRegion`, `TableRegion` (kommt noch, aber nicht `ChartRegion`), `MathsRegion` (kommt noch, aber nicht `ChemRegion`, `MusicRegion`), nicht `AdvertRegion`.
-(noch) nicht vorhanden: TableRegion, MathsRegion, MusicRegion, AdvertRegion
-Die RegionType-Unterteilung von PageXML ist aus einem sehr spezifischen Projektkontext heraus entstanden, die Klassen sind nicht 1:1 benutzbar (es ist also eine Richtlinie zur Interpretation im OCR-D-Rahmen nötig, weitere oder zusammenfassende Klassen sind nicht ohne weiteres machbar).
- Die Unterteilung in Regions in PageXML sind aus einem Projektkontext heraus entstanden,
in dem Hierachie erstmal nicht vorgesehen ist.
- PrintSpace nicht aus buchdrucktechnischer Sicht (d.h. alles was gesetzt werden muß), sondern abstrakter (alles was den fortlaufenden "Text" des Buches ausmacht)
- Unterscheidung zwischen Textflusselementen und Textfluss unterbrechenden
Elementen
Elementen:
- Erfassung und Klassifizierung der Textfluß-Abfolge der Region-Elemente in `ReadingOrder`
- entweder als `OrderedGroup` oder `UnorderedGroup`
- Erfassung und Klassifizierung der Reading Order
- neuer Struktur-GT (nur Zoning, kein Inhalt)
- Fonts werden grob eingeteilt in alle Antiqua-artigen und "Blackletter" (d.h. gebrochene und historische Schriften)
- mit Statistik zu Page-Typen (d.h. wieviele `content`, `title`, `index` und `other`) und Region-Typen (s.o.)
- In PageXml ist es möglich, unordered/ordered Groups zu verschachteln.
- Konzept: Integration der Tools über die Kommandozeile, aber als spezialisierte, einheitliche CLI mit einer __Workspace__ genannten gekapselten persistenten Datenverwaltung auf Basis von METS/PAGE
Profiler brauchte pro Dokument (Seite) 15 Minuten, Verbesserung auf 7
Minuten
Teilaufgaben abgeschlossen:
- Reranking (also Sprachmodell) und Entscheider (gegen Überkorrektur)
- Protokollierung und Annotation
Profiler brauchte bisher pro Dokument 50 Minuten, jetzt beschleunigt auf 7
Minuten
##### Nachkorrektur (unser Vortrag)
Metadaten, die wir bekommen können:
- Date of Publication (nicht normalisiert)
- Author Information (nicht normalisiert)
Sprache wurde sehr ungenau genutzt/annotiert
Neue studentische Hilfskraft wird ab August die Erzeugung von (PageXML-formatierten) Trainingsdaten aus dem DTA und dem Ground-Truth bearbeiten (also Tesseract- und Ocropy-Modelle).
State zu verwenden, um Informationen über lange Passagen hinweg zu
erhalten, ist technisch gesehen wohl nicht problematisch. Müsste man in der
- Java-Implementation von Steven Price für die Edit-Distance, wohl nicht auf OCR
ausgerichtet
- Im Impact-Projekt sind 4 verschiedene Evaluations-Tools für OCR
- Diskussion:
- Metadaten, die wir bekommen können:
* Erscheinungsdatum (nicht normalisiert)
* Autorschaft (nicht normalisiert)
* Regalnummer (aber fragwürdig)
* Genre: wird noch geklärt
* Sprache: wurde sehr ungenau genutzt/annotiert
- Zustandshafte Integrationsschnittstelle zu verwenden, damit Kontext für uns über lange Passagen hinweg sichtbar ist, wäre technisch gesehen wohl nicht problematisch. Müsste man in der konkreten Anwendung sehen.
* Java-Implementation von Steven Price für die Edit-Distance, wohl nicht auf OCR ausgerichtet
* Im Impact-Projekt sind 4 verschiedene Evaluations-Tools für OCR
entstanden (für verschiedene Teilprobleme). Ursprünglich sollte hiervon
ein Tool beim Entwickler-Workshop gewrappt werden, wurde wegen
technischer Probleme dann nicht gemacht.
##### Tesseract als Komponente in OCR-D (Stefan Weil, Noah Metzger)
Das Team wird jetzt als Maintainer von Tesseract betrachtet und kann
wichtige Entscheidungen treffen und einbringen.
wichtige Entscheidungen treffen und einbringen. Tätigkeit v.a. Robustheit und Wartung.
Planung im [Github](https://github.com/tesseract-ocr/tesseract/wiki/Planning)
Verweis auf [Paper](https://arxiv.org/pdf/1802.05385.pdf) über manipulierte Text-Scans, in denen OCR falsche Texte
erkennt. Eventuell durch Training mit solchen manipulierten Bildern OCR
robuster machen.
Verweis auf eine [Arbeit](https://arxiv.org/pdf/1802.05385.pdf) über Manipulation von Text-Scans, um (neuronale) OCR gezielt zu täuschen. Eventuell durch Training mit solchen manipulierten Bildern OCR robuster machen.
##### Entwicklung eines Modellrepositoriums für Schriftartenerkennung (Saskian Limbach, Vincent Christlein, Mathias Seuret)
##### Entwicklung eines Modellrepositoriums für Schriftartenerkennung (Saskia
Limbach, Vincent Christlein, Mathias Seuret)
Stand:
- Suche nach optisch geeigneten guten Referenzdrucken läuft noch
- Clustering kann erst danach beginnen
- unklar, wann Stelle von Benjamin neu besetzt wird: *Aufbau eines Forschungsdaten-Modellrepositoriums* muß zur Not "nebenbei" improvisiert werden
Wichtige Schriftarten: Texture, Rotunda, Bastarda
Basis-Schriftfamilien wurden schon im 15. Jahrhundert entwickelt und dann immer nur weiterentwickelt und rekombiniert: Textura, Rotunda, Bastarda.
Mit der Zeit gab es weniger unterschiedliche Schriften, da eine
Professionalisierung stattgefunden hat (am Anfang hat jeder Drucker selbst die
Buchstaben geschnitzt).
Mit der Zeit (zumindest bis ins 18. Jahrhundert) reduziert sich die Variabilität der Schriften, da eine Professionalisierung und Mechanisierung der Typenwerkstätten stattfand.
Schrifterkennung braucht vermutlich mehrere Zeilen für akzeptable Genauigkeit, d.h. nicht ohne weiteres auf Wortebene möglich
#### Setup und Test der OCR-D Eigenentwicklungen (Konstantin Baierer)
#### Setup und Test von Werkzeugen der Koordinierungsgruppe (Konstantin Baierer)
[Anleitung für Installation und Setup](https://ocr-d.github.io/docs/cookbook.html)
Inhalt:
Python Virtualenv, Installation von ocrd, Anlegen eines Workspaces,
Hinzufügen und Herunterladen von Dateien
Python virtualenv, Installation von ocrd, Anlegen eines Workspaces,
Hinzufügen und Herunterladen von Dateien, Prozessieren von Dateien
Beispiel: Tool für die Bildkonvertierung
#### Wrapping von Werkzeugen für OCR-D (Kay-Michael Würzner)
Formale Beschreibung von Werkzeugen (Manifest) in `ocrd-tool.json` – beim Ausfüllen besonders wichtig:
-`executable`
-`categories`
-`steps`
- Konstruktor: leite von Prozessor-Klasse ab; ziehe Infos aus ocrd-tool.json
und macht sie zugreifbar (fast immer gleich), importiere Rater (oben bei
den Imports), lege Rater an (spezifisch für rater.py)
- Funktion process: stellt eigentliche Funktionalität zur Verfügung lade
PageXML, gehe mit Python-API bis auf Zeichenebene, schreibe Custom-Attribut
der Glyphe (falsch, gehört eigentlich ins Konfidenz-Attribut vom TextEquiv
+ source-Attribut wird geschrieben, um zu kennzeichnen, welches Tool
Beispiel `rate.py`:
- Konstruktor: leite von Klasse `Processor` ab; ziehe Infos aus `ocrd-tool.json`
und mache sie zugreifbar (fast immer gleich), importiere Tool (oben bei
den Imports), instanziiere usw (spezifisch)
- Funktion `process`: stellt eigentliche Funktionalität zur Verfügung; lade
PageXML, gehe mit Python-API bis auf Zeichenebene, schreibe custom-Attribut
von Glyph (falsch, gehört eigentlich ins conf-Attribut von dessen TextEquiv
- source-Attribut wird geschrieben, um zu kennzeichnen, welches Tool
geschrieben hat), schreibe in neue PageXML-Ausgabedatei
zusätzlich nötig: CLI-Datei, die "Prozessor" zur Verfügung stellt
Verwendung der click-Library: einfaches Erstellen von CLI mit Decorator @ocrd_cli_options
zusätzlich nötig: CLI-Datei, die "Prozessor" zur Verfügung stellt; dabei Verwendung der click-Library: einfaches Erstellen von CLI mit Decorator @ocrd_cli_options
`parameter.json`: wenn man das Tool anwenden will, schreibt man hier die
Parameter für den Aufruf rein
`parameter.json`: wenn man das Tool im Workspace ausführen will, muß man eine solche Datei bereitstellen (mit den Parametern für den Aufruf, also abgesehen von Ein- und Ausgabedateien)
#### Dokumentation mit DITA (Matthias Boenig)
[Anforderungen an die Dokumentation](https://ocr-d.github.io/docs/dita.html)
Dokumentation soll mit DITA durchgeführt werden
DITA ist XML-basiert, aber es gibt auch eine Markdown-DITA-Syntax.
Dokumentation soll mit dem [DITA-Toolkit](https://www.dita-ot.org/) durchgeführt werden.
DITA-Map: Inhaltsverzeichnis für einzelne DITA-Dateien
DITA enthält u.a. Browser und PDF-Export. Es ist XML-basiert, hat aber auch eine Markdown-Syntax. Konzeptuell erstellt man eine Reihe von sog. *Topics* (die sich aufeinander beziehen können). Die DITA-Map ist das Inhaltsverzeichnis der einzelnen DITA-Dateien.
Manche der Informationen werden aus ocrd-tool.json extrahiert.
Man kann nicht alle Informationen darin unterbringen, da man keine
Zeilenumbrüche verwenden kann innerhalb eines Beschreibungstextes.
Für OCR-D sind die einzelnen Teile der Dokumentation vorgeschrieben. Dabei kann auf vordefinierte Topic-Typen zurückgegriffen werden. Dokumentiert wird auf Werkzeug-Ebene, nicht auf Projekt-Ebene. Ein Teil der Informationen läßt sich direkt aus `ocrd-tool.json` extrahieren. (Man kann aber nicht alle Informationen dort unterbringen, da innerhalb der Beschreibungen keine Zeilenumbrüche erlaubt sind.)
Da auch Troubleshooting ein Abschnitt in der Dokumentation ist, kann man
überlegen, das mit Nutzer-Feedback zu verbinden.
Wo Projekt-Gesamtdokumentation?
Da auch Troubleshooting ein Abschnitt in der Dokumentation ist, sollte man
überlegen, dies mit Nutzer-Feedback zu verbinden.
#### World Café
#### Offene Gesprächsrunde
##### Abfrage des Bedarfs an Ground Truth (Matthias Boenig)
Name-Scheme für Dateien: author_publication-date_page-number_line-number
Das Name-Scheme wird noch in der Spezifikation festgelegt werden.
Publication Date bezieht sich auf die veröffentlichung der Edition.
Namens-Schema für Verzeichnisse und Dateien: `author_publication-date_page-number_line-number`
Dieses wird noch in die Spezifikation aufgenommen werden. Das publication-date bezieht sich auf die Veröffentlichung der jeweiligen Ausgabe.
Bis Herbst wird so viel GT wie möglich aligniert (also
Für das künstliche Training von Tesseract wäre es interessant, Schriften aus den
Glyph-Images des Typen-Repositoriums zu erzeugen.
Im [Glossar](https://ocr-d.github.io/glossary) ist die Bedeutung von Begriffen festgelegt.
##### Gespräch mit CIS (Florian Fink, Tobias Englmeier)
##### Gespräch mit CIS München (Florian Fink, Tobias Englmeier)
Wir haben diskutiert, ob wir die Ergebnisse der Alignierung von mehreren
OCR-Outputs mitverwenden können, zum Beispiel durch eine Anreicherung des
Wir haben diskutiert, ob wir die Ergebnisse der *Alignierung* von mehreren
OCR-Outputs im Ground-Truth mitnutzen können, zum Beispiel durch eine Anreicherung des
PageXML mit der Alignierung.
Außerdem war Thema, inwiefern wir ein gemeinsames (neuronales) großes *Sprachmodell* bauen können.
###### Speichern der Alignierung
In PageXML in den TextEquivs kann man nicht mehrere alternative
Wortsegmentierungen angeben.
Würde man die Wortsegmentierung der Master-OCR übernehmen, hätte man noch
In PageXML in den `TextEquiv` kann man nicht mehrere alternative
Wortsegmentierungen angeben, da `Word` obligatorisch und XML hierarchisch ist.
_Würde man die Wortsegmentierung der Master-OCR übernehmen, hätte man noch
immer das Problem, dass man nicht einfach Whitespaces
innerhalb von Tags schreiben kann, da diese vom XML ignoriert werden.
Wir sind zum Schluss gekommen, dass das in PageXML wegen der streng
hierarchischen Gliederung nicht möglich ist, sondern lieber ein anderes
Dateiformat verwendet werden sollte.
Das kann dann einfach zum METS hinzugefügt werden.
innerhalb von Tags schreiben kann, da diese vom XML ignoriert werden._ (?)
Wir sind zum Schluss gekommen, dass das in PageXML nicht möglich ist, also ein anderes Format gewählt werden muß, am besten ein XML-basiertes unter Verweis auf die (Region-/Line-/Word-/Glyph-) IDs der PageXML-Annotation. Diese Annotationen könnten dann einfach zum METS hinzugefügt werden.
Man könnte stattdessen gleichzeitig mehrere PageXML-Dateien (eine für jede OCR)
für eine Seite einlesen und zur Laufzeit alignieren.
Alternativ könnte man stets mehrere PageXML-Dateien (eine pro OCR oder OCR-Modell) auf einmal
einlesen und erst zur Laufzeit alignieren. (Dafür müßte man sich das Tool austauschen. Die CIS-Komponente ist aber in Java implementiert. Und für neuronale Netze ist zur Laufzeit vermutlich ohnehin eine Attention-basierte Alignierung besser geeignet.)
###### Algorithmus
###### Algorithmus der Alignierung
Deren Algorithmus arbeitet greedy und sucht die Alignierung mit den
kleinsten Gaps. Als Maß für die Alignierung kann mit die anteilige
Abdeckung des Alignments ausgeben.
Nur das 1-beste Ergebnise der OCR wird verwendet.
kleinsten Gaps. Als Gütemaß läßt sich die anteilige Abdeckung des Alignments ausgeben.
Nur das 1-beste Ergebnis der OCR wird verwendet, d.h. es werden keine alternativen Hypothesen aligniert.
Man muss zwischen paarweiser und multipler Alignierung unterscheiden.
Das CIS aligniert eine Master-OCR mit der GT und mit jeder anderen OCR.
Das CIS aligniert jeweils paarweise eine Master-OCR mit der GT und dann mit jeder anderen OCR.
Am Anfang und am Ende der Zeile sind spezielle Start-/Ende-Symbole, damit
hier auf jeden Fall aligniert wird.
Das Ergebnis der Alignierung sollte mit dem des Matrix-Algorithmus für die
Levenshtein-Distanz übereinstimmen. Die Laufzeit ist jedoch bei Verwendung
von Suffixbäumen (wie am CIS) besser.
Levenshtein-Distanz übereinstimmen. Die Komplexität ist jedoch bei Verwendung
von Suffixbäumen (wie am CIS) besser (polylogarithmisch statt quadratisch).
Bei sequentieller Darstellung des Ergebnisses mittels Gap-Symbolen läßt sich nicht eindeutig vorhersagen/bestimmen, ob Gap links oder rechts steht (z.B. "in" → "\_m" oder "m\_"). Darum wird die Alignierung durch Verweise zwischen Knoten (Standoff-Pointern) des Token-Graphen ausgegeben. (Anstelle Tokens könnte man ebenso Glyph-IDs verwenden.)
Im GT und im OCR-D-Workflow gibt es (durch die einheitliche Vorverarbeitung) eine einheitliche Zeilenerkennung bzw. Segmentierung in Zeilen. Daher ist die Zeilennumerierung über die verschiedenen OCRs hinweg eindeutig. (Oberhalb der Zeilenebene muß nicht mehr aligniert werden.)
###### Sprachmodell
Wenn man bei Verwendung von Gap-Zeichen nicht eindeutig sagen, ob es links
oder rechts steht (z.B. in -> _m, m_). Darum wird die Ausgabe der
Alignierung als verweise zwischen Knoten vom Token-Graph dargestellt. Für
die Tokens könnte man Glyph-IDs verwenden.
Am CIS wird immer auf Wort-Ebene gerechnet und modelliert. Bei unserem FST-Ansatz wäre das auch der Fall. Beide könnten ein gutes wortbasiertes Sprachmodell gebrauchen, doch Trainingsdaten für (korrigierte) historische Texte sind wohl nicht ausreichend vorhanden.
Es gibt eine einheitliche Zeilenerkennung bzw. Segmentierung in Zeilen.
Darum ist die Zeilenanzahl und -nummerierung über die verschiedenen OCRs
hinweg eindeutig. Die Zeilen müssen einander nicht mehr durch Alignierung
zugeordnet werden.
Unser RNN-Ansatz kann möglicherweise beiden hilfreich sein: durch die Extraktion einer Domänen-Diskretisierung aller Kontextvariable, und durch direkte Nutzung des RNN-Decoders als Sprachmodell (allerdings zunächst nur auf Byte-Ebene). Letzterer müßte also stets mit allen Kontextvariablen gefüttert werden – auch am CIS. Genauer gesagt läßt sich auch nicht der Decoder selber benutzen, da dieser ja auf den Encoder konditioniert ist. Ein unabhängiges Sprachmodell läßt sich aber mit denselben Methoden und denselben Trainingsdaten erzeugen. Entscheidende Frage ist der Zeitpunkt der Verfügbarkeit und die Kopplungsmöglichkeiten (graphenbasierte Integration der Suchräume).
###### Fragestellungen
- Macht es bei uns für den Eingabe-String und die Berechnung des Fehlermodells
einen Unterschied, ob wir Gap-Zeichen verwenden oder Knotenverweise im
Graphen?
Graphen? (Es dürfte bei der Auszählung keinen Unterschied machen.)
- Die Metadaten können sich innerhalb einer Zeile ändern. Wie kann man die
Metadaten mit der Alignierung in Zusammenhang bringen?
- Können wir auch mehrere Zeichen-Alternativen für jede OCR-Ausgabe mit
Metadaten mit der Alignierung in Zusammenhang bringen? (Alle Kontextvariable müssen bei der Ausgabe mitverarbeitet werden.)
- Können wir auch Zeichen-Alternativen für jede einzelne OCR-Ausgabe mit
alignieren?
- Können wir ein gemeinsames Sprachmodell nutzen?
- Kopplung von FST mit neuronalem Sprachmodell?
Wir haben beidseitig unseren Wunsch bekräftigt, in München unsere weitere
Zusammenarbeit und Fragestellungen zu besprechen.
Das soll vor dem 15. Oktober stattfinden.
Wir haben beiderseitig unsere Absicht erneuert, demnächst in München unsere weitere
Zusammenarbeit zu besprechen. Das soll vor dem 15. Oktober stattfinden.
##### Gespräch mit Tesseract-Team (Stefan Weil, Noah Metzger)
Wieviele n-beste Zeichen wollen wir für jede Zeichenposition von der OCR
Wieviel-beste Zeichen wollen wir für jede Zeichenposition von der OCR
bekommen?
Bekommt man für eine Zeichenposition auch möglicherweise Alternativen mit
mehreren Zeichen (z.B. m/in)?
Geht bei der Ausgabe Information verloren?
mehreren Zeichen (z.B. m/in), oder geht bei der internen Dekodierung die "zeitliche" Information (Segmentierungsambiguität) verloren? (diesbezüglicher Unterschied Modelle Tesseract 3 vs 4) – Soll demnächst gemeinsam geklärt werden, am besten auf der dev-Mailingliste.
#### Zusammenfassung
Organisatorisches:
- Teilnahme der OCR-D-Modulprojekte am Bibliotheca Baltica Symposium (3.-5. Oktober 2018 in Rostock), Deadline für Call for Posters am 31. Juli 2018
...
...
@@ -815,4 +805,6 @@ Inhalt:
- Vorträge der Modulprojekte
- Vorstellung der Ground Truth
\ No newline at end of file
- Vorstellung der Struktur-Ground-Truth und der Dokumentationsrichtlinien
- Zusammenarbeit mit CIS bei Alignierung und Sprachmodell
