- Strukturelemente im Ground Truth: TextRegion, GraphicRegion,
- 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`.
SeparatorRegion
-(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,
- PrintSpace nicht aus buchdrucktechnischer Sicht (d.h. alles was gesetzt werden muß), sondern abstrakter (alles was den fortlaufenden "Text" des Buches ausmacht)
in dem Hierachie erstmal nicht vorgesehen ist.
- Unterscheidung zwischen Textflusselementen und Textfluss unterbrechenden
- 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
##### Nachkorrektur (unser Vortrag)
Teilaufgaben abgeschlossen:
- Alignierung (Multi-OCR)
- Profileranpassungen (Beschleunigung)
- Lexikonerweiterung (Eigennamen)
- CLI-Unterstützung (OCR-D)
Metadaten, die wir bekommen können:
Teilaufgaben abgeschlossen:
-Date of Publication (nicht normalisiert)
-Reranking (also Sprachmodell) und Entscheider (gegen Überkorrektur)
-Author Information (nicht normalisiert)
-Protokollierung und Annotation
Sprache wurde sehr ungenau genutzt/annotiert
Profiler brauchte bisher pro Dokument 50 Minuten, jetzt beschleunigt auf 7
Minuten
State zu verwenden, um Informationen über lange Passagen hinweg zu
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).
erhalten, ist technisch gesehen wohl nicht problematisch. Müsste man in der
konkreten Anwendung sehen.
Mögliche Evaluations-Tools:
##### Nachkorrektur ASV (wir)
- Java-Implementation von Steven Price für die Edit-Distance, wohl nicht auf OCR
- 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.
- 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)
##### Tesseract als Komponente in OCR-D (Stefan Weil, Noah Metzger)
Das Team wird jetzt als Maintainer von Tesseract betrachtet und kann
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)
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
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.
erkennt. 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
Stand:
Limbach, Vincent Christlein, Mathias Seuret)
- 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
Mit der Zeit (zumindest bis ins 18. Jahrhundert) reduziert sich die Variabilität der Schriften, da eine Professionalisierung und Mechanisierung der Typenwerkstätten stattfand.
Professionalisierung stattgefunden hat (am Anfang hat jeder Drucker selbst die
Buchstaben geschnitzt).
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)
[Anleitung für Installation und Setup](https://ocr-d.github.io/docs/cookbook.html)
Inhalt:
Inhalt:
Python Virtualenv, Installation von ocrd, Anlegen eines Workspaces,
Python virtualenv, Installation von ocrd, Anlegen eines Workspaces,
Hinzufügen und Herunterladen von Dateien
Hinzufügen und Herunterladen von Dateien, Prozessieren von Dateien
Beispiel: Tool für die Bildkonvertierung
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
Beispiel `rate.py`:
und macht sie zugreifbar (fast immer gleich), importiere Rater (oben bei
- Konstruktor: leite von Klasse `Processor` ab; ziehe Infos aus `ocrd-tool.json`
den Imports), lege Rater an (spezifisch für rater.py)
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
- Funktion `process`: stellt eigentliche Funktionalität zur Verfügung; lade
PageXML, gehe mit Python-API bis auf Zeichenebene, schreibe Custom-Attribut
PageXML, gehe mit Python-API bis auf Zeichenebene, schreibe custom-Attribut
der Glyphe (falsch, gehört eigentlich ins Konfidenz-Attribut vom TextEquiv
von Glyph (falsch, gehört eigentlich ins conf-Attribut von dessen TextEquiv
+ source-Attribut wird geschrieben, um zu kennzeichnen, welches Tool
- source-Attribut wird geschrieben, um zu kennzeichnen, welches Tool
geschrieben hat), schreibe in neue PageXML-Ausgabedatei
geschrieben hat), schreibe in neue PageXML-Ausgabedatei
zusätzlich nötig: CLI-Datei, die "Prozessor" zur Verfügung stellt
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
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.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)
Parameter für den Aufruf rein
#### Dokumentation mit DITA (Matthias Boenig)
#### Dokumentation mit DITA (Matthias Boenig)
[Anforderungen an die Dokumentation](https://ocr-d.github.io/docs/dita.html)
[Anforderungen an die Dokumentation](https://ocr-d.github.io/docs/dita.html)
Dokumentation soll mit DITA durchgeführt werden
Dokumentation soll mit dem [DITA-Toolkit](https://www.dita-ot.org/) durchgeführt werden.
DITA ist XML-basiert, aber es gibt auch eine Markdown-DITA-Syntax.
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.
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.)
Man kann nicht alle Informationen darin unterbringen, da man keine
Zeilenumbrüche verwenden kann innerhalb eines Beschreibungstextes.
Da auch Troubleshooting ein Abschnitt in der Dokumentation ist, kann man
Wo Projekt-Gesamtdokumentation?
überlegen, das mit Nutzer-Feedback zu verbinden.
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)
##### Abfrage des Bedarfs an Ground Truth (Matthias Boenig)
Name-Scheme für Dateien: author_publication-date_page-number_line-number
Namens-Schema für Verzeichnisse und Dateien: `author_publication-date_page-number_line-number`
Das Name-Scheme wird noch in der Spezifikation festgelegt werden.
Dieses wird noch in die Spezifikation aufgenommen werden. Das publication-date bezieht sich auf die Veröffentlichung der jeweiligen Ausgabe.
Publication Date bezieht sich auf die veröffentlichung der Edition.
Bis Herbst wird so viel GT wie möglich aligniert (also
Bis Herbst wird so viel GT wie möglich aligniert (also
Struktur-Informationen annotiert).
Struktur-Informationen annotiert).
Für das künstliche Training von Tesseract wäre es interessant, Schriften aus den
Für das künstliche Training von Tesseract wäre es interessant, Schriften aus den
Glyph-Images des Typen-Repositoriums zu erzeugen.
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 im Ground-Truth mitnutzen können, zum Beispiel durch eine Anreicherung des
Wir haben diskutiert, ob wir die Ergebnisse der Alignierung von mehreren
OCR-Outputs mitverwenden können, zum Beispiel durch eine Anreicherung des
PageXML mit der Alignierung.
PageXML mit der Alignierung.
Außerdem war Thema, inwiefern wir ein gemeinsames (neuronales) großes *Sprachmodell* bauen können.
###### Speichern der Alignierung
###### Speichern der Alignierung
In PageXML in den TextEquivs kann man nicht mehrere alternative
In PageXML in den `TextEquiv` kann man nicht mehrere alternative
Wortsegmentierungen angeben.
Wortsegmentierungen angeben, da `Word` obligatorisch und XML hierarchisch ist.
Würde man die Wortsegmentierung der Master-OCR übernehmen, hätte man noch
_Würde man die Wortsegmentierung der Master-OCR übernehmen, hätte man noch
immer das Problem, dass man nicht einfach Whitespaces
immer das Problem, dass man nicht einfach Whitespaces
innerhalb von Tags schreiben kann, da diese vom XML ignoriert werden.
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
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.
Dateiformat verwendet werden sollte.
Das kann dann einfach zum METS hinzugefügt werden.
Man könnte stattdessen gleichzeitig mehrere PageXML-Dateien (eine für jede OCR)
Alternativ könnte man stets mehrere PageXML-Dateien (eine pro OCR oder OCR-Modell) auf einmal
für eine Seite einlesen und zur Laufzeit alignieren.
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
Deren Algorithmus arbeitet greedy und sucht die Alignierung mit den
kleinsten Gaps. Als Maß für die Alignierung kann mit die anteilige
kleinsten Gaps. Als Gütemaß läßt sich die anteilige Abdeckung des Alignments ausgeben.
Abdeckung des Alignments ausgeben.
Nur das 1-beste Ergebnise der OCR wird verwendet.
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.
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
Am Anfang und am Ende der Zeile sind spezielle Start-/Ende-Symbole, damit
hier auf jeden Fall aligniert wird.
hier auf jeden Fall aligniert wird.
Das Ergebnis der Alignierung sollte mit dem des Matrix-Algorithmus für die
Das Ergebnis der Alignierung sollte mit dem des Matrix-Algorithmus für die
Levenshtein-Distanz übereinstimmen. Die Laufzeit ist jedoch bei Verwendung
Levenshtein-Distanz übereinstimmen. Die Komplexität ist jedoch bei Verwendung
von Suffixbäumen (wie am CIS) besser.
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
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.
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.
Es gibt eine einheitliche Zeilenerkennung bzw. Segmentierung in Zeilen.
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).
Darum ist die Zeilenanzahl und -nummerierung über die verschiedenen OCRs
hinweg eindeutig. Die Zeilen müssen einander nicht mehr durch Alignierung
zugeordnet werden.
###### Fragestellungen
###### Fragestellungen
- Macht es bei uns für den Eingabe-String und die Berechnung des Fehlermodells
- Macht es bei uns für den Eingabe-String und die Berechnung des Fehlermodells
einen Unterschied, ob wir Gap-Zeichen verwenden oder Knotenverweise im
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
- Die Metadaten können sich innerhalb einer Zeile ändern. Wie kann man die
Metadaten mit der Alignierung in Zusammenhang bringen?
Metadaten mit der Alignierung in Zusammenhang bringen? (Alle Kontextvariable müssen bei der Ausgabe mitverarbeitet werden.)
- Können wir auch mehrere Zeichen-Alternativen für jede OCR-Ausgabe mit
- Können wir auch Zeichen-Alternativen für jede einzelne OCR-Ausgabe mit
alignieren?
alignieren?
- Können wir ein gemeinsames Sprachmodell nutzen?
- 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
Wir haben beiderseitig unsere Absicht erneuert, demnächst in München unsere weitere
Zusammenarbeit und Fragestellungen zu besprechen.
Zusammenarbeit zu besprechen. Das soll vor dem 15. Oktober stattfinden.
Das soll vor dem 15. Oktober stattfinden.
##### Gespräch mit Tesseract-Team (Stefan Weil, Noah Metzger)
##### 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?
bekommen?
Bekommt man für eine Zeichenposition auch möglicherweise Alternativen mit
Bekommt man für eine Zeichenposition auch möglicherweise Alternativen mit
mehreren Zeichen (z.B. m/in)?
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.
Geht bei der Ausgabe Information verloren?
#### Zusammenfassung
#### Zusammenfassung
Organisatorisches:
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
- 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:
...
@@ -815,4 +805,6 @@ Inhalt:
- Vorträge der Modulprojekte
- Vorträge der Modulprojekte
- Vorstellung der Ground Truth
- Vorstellung der Struktur-Ground-Truth und der Dokumentationsrichtlinien
\ No newline at end of file
- Zusammenarbeit mit CIS bei Alignierung und Sprachmodell
