planung.md

@@ -522,3 +522,297 @@ Mögliche Titel:
 Planung:
 - Mittwoch – erster Entwurf mit Notizen zu dem, was wir schreiben wollen
 - Montag – Letzte Verbesserungen, Einreichung
+
+### 26. - 27. Juni 2018 (1. Entwicklertreffen)
+
+
+#### Begrüßung (Elisa Herrmann)
+
+- Bitte um Ausfüllen des Kommunikationsprofils und des Questionnaires (erst 4
+Rückmeldungen)
+
+- 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
+
+- Ende der Förderung von OCR-D (Koordinationsteam) am 30. September 2018,
+  Folgeantrag wurde schon eingereicht über weitere 18 Monate
+
+- Da es keine erfolgreiche Einreichung für das Modul Qualitätssicherung
+  gab, wird die BBAW dieses Modul übernehmen.
+
+
+#### Ground Truth (Matthias Boenig)
+
+- Strukturelemente im Ground Truth: TextRegion, GraphicRegion,
+SeparatorRegion
+
+- (noch) nicht vorhanden: TableRegion, MathsRegion, MusicRegion, AdvertRegion
+
+- Die Unterteilung in Regions in PageXML sind aus einem Projektkontext heraus entstanden,
+in dem Hierachie erstmal nicht vorgesehen ist.
+
+- Unterscheidung zwischen Textflusselementen und Textfluss unterbrechenden
+Elementen
+
+- Erfassung und Klassifizierung der Reading Order
+
+- In PageXml ist es möglich, unordered/ordered Groups zu verschachteln.
+
+
+#### OCR-D Eigenentwicklungen (Konstantin Baierer, Kay-Michael Würzner)
+
+Integration der Tools über die Kommandozeile
+
+Erklärung der einzelnen Repositories auf Github:
+- spec: Spezifikation von Ein-/Ausgabeformaten, Schnittstellenanforderungen
+(später: Deployment)
+- docs: Cookbook für die Dokumentation, Metadokumentation
+- core: eigentliches Framework, Implementation von spec als Python-Toolkit,
+  API für PageXML und METS, CLI zur Python-Schnittstelle (später: Wrapping
+  durch Webschnittstelle)
+- assets: Beispiel-Files
+- ocrd_*: Referenz-Implementierungen, Texts von Grundfunktionalitäten,
+  Integrationskonzept
+- slides: Vorträge
+
+Verweis auf [Gitter](https://gitter.im/OCR-D/Lobby) als angebotener Team-Chat
+
+#### Vorträge der Modulprojekte
+
+
+##### Layouterkennung (Christian Reul, Frank Puppe)
+
+- Pixel Classifier mit FCN (Fully Convolutional Network)
+- Pixel Accuracy: 90-94%
+- Häufigste andere Schriften in den DTA-Daten: Latein, Griechisch, Arabisch
+
+
+##### Nachkorrektur (Florian Fink, Tobias Englmeier)
+
+Teilaufgaben:
+- Alignierung
+- Profileranpassungen
+- Lexikonerweiterung
+- Reranking/Decider
+- Protokollierung/Nachkorrektur
+- CLI-Unterstützung
+
+Profiler brauchte pro Dokument (Seite) 15 Minuten, Verbesserung 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
+
+State zu verwenden, um Informationen über lange Passagen hinweg zu
+erhalten, ist technisch gesehen wohl nicht problematisch. Müsste man in der
+konkreten Anwendung sehen.
+
+Mögliche Evaluations-Tools:
+
+- 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.
+
+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.
+
+
+
+##### Entwicklung eines Modellrepositoriums für Schriftartenerkennung (Saskia
+Limbach, Vincent Christlein, Mathias Seuret)
+
+Wichtige Schriftarten: Texture, Rotunda, Bastarda
+
+Mit der Zeit gab es weniger unterschiedliche Schriften, da eine
+Professionalisierung stattgefunden hat (am Anfang hat jeder Drucker selbst die
+Buchstaben geschnitzt).
+
+
+#### Setup und Test der OCR-D Eigenentwicklungen (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
+
+Beispiel: Tool für die Bildkonvertierung
+
+
+#### Wrapping der Tools (Kay-Michael Würzner)
+
+Beispiel: [RNN-Sprachmodell ocrd-keraslm](https://hackmd.io/s/SyWZ0sgfX)
+
+[Anleitung des Wrappings](https://hackmd.io/s/HkZNo2R-7)
+
+Beim Ausfüllen von ocrd-tool.json besonders wichtig: executable,
+categories, steps
+
+`rate.py`
+
+- 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
+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
+
+`parameter.json`: wenn man das Tool anwenden will, schreibt man hier die
+Parameter für den Aufruf rein
+
+#### 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.
+
+DITA-Map: Inhaltsverzeichnis für einzelne 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.
+
+Da auch Troubleshooting ein Abschnitt in der Dokumentation ist, kann man
+überlegen, das mit Nutzer-Feedback zu verbinden.
+
+
+#### World Café 
+
+
+##### 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.
+
+Bis Herbst wird so viel GT wie möglich aligniert (also
+Struktur-Informationen annotiert).
+
+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 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
+PageXML mit der Alignierung.
+
+###### 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
+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.
+
+Man könnte stattdessen gleichzeitig mehrere PageXML-Dateien (eine für jede OCR)
+für eine Seite einlesen und zur Laufzeit alignieren.
+
+###### Algorithmus
+
+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.
+Man muss zwischen paarweiser und multipler Alignierung unterscheiden.
+Das CIS aligniert eine Master-OCR mit der GT und 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.
+
+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.
+
+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.
+
+###### 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?
+- 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
+alignieren?
+- Können wir ein gemeinsames Sprachmodell nutzen?
+
+Wir haben beidseitig unseren Wunsch bekräftigt, in München unsere weitere
+Zusammenarbeit und Fragestellungen zu besprechen.
+Das soll vor dem 15. Oktober stattfinden.
+
+
+##### Gespräch mit Tesseract-Team (Stefan Weil, Noah Metzger)
+
+Wie viele n-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?
+
+
+#### 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
+
+- Ende der Förderung von OCR-D (Koordinationsteam) am 30. September 2018,
+  Folgeantrag wurde schon eingereicht über weitere 18 Monate
+
+- Da es keine erfolgreiche Einreichung für das Modul Qualitätssicherung
+  gab, wird die BBAW dieses Modul übernehmen.
+
+- Besuch des CIS in München ist geplant (vor dem 15. Oktober)
+
+Inhalt:
+
+- Aufsetzen und Test der OCR-D-Eigenentwicklung für die Arbeit mit PageXML
+  und Anwendung der Tools am Beispiel einer Bildkonvertierung
+
+- Demonstration des Wrappings der Tools am Beispiel eines Sprachmodells
+
+- Vorträge der Modulprojekte
+
+- Vorstellung der Ground Truth
\ No newline at end of file