Robuste und performante Verfahren für die Layoutanalyse in OCR-D

Status

1. Fortschritt OCR-D (allgemein)
2. Fortschritt OCR-D (effizientes GPU-Pipelining)
3. Fortschritt Detectron2

1 Fortschritt OCR-D (allgemein)

• core: viele Bugfixes
• core: API v3 vorangetrieben, v.a. (95%)
  • Fehlerbehandlung (skip|abort|overwrite|copy) und Timeouts auf Prozessor-/Seitenebene
  • Parallelisierung via Multithreading Multiprocessing
  • Vereinfachung für Prozessoren
• core: Logging gefixt/überarbeitet (95%)

1 Fortschritt OCR-D (allgemein)

• ocrd_all: Build für Fat-Container aktualisiert
  
• ocrd_all: Nachrüstung von CI+CD in allen Modulen für Slim-Container

1 Fortschritt OCR-D (allgemein)

• ocrd_kraken: Anpassung an Kraken v5, inkrementelle Segmentierung
• textract2page: vollständige Layout-Rekursion
• Anpassung an TF 2.[4..15]:
  • ocrd_keraslm (75%)
  • (ocrd-fork-)tfaip (100%)
  • calamari (100%)

1 Fortschritt OCR-D (allgemein)

• Anpassung an core v3:
  • ocrd_tesserocr
  • ocrd_kraken
  • ocrd_segment
  • ocrd_cis
  • ocrd_calamari
    (auch: TF 2.15 und Calamari 2.x)

2 Fortschritt OCR-D (effizientes GPU-Pipelining)

• Vorbild: tfaip, tfx.serving
• am Beispiel:
  • ocrd_detectron2 mit AsyncPredictor
  • ocrd_calamari mit Multiprocessing …

2 Fortschritt OCR-D (effizientes GPU-Pipelining)

• ocrd_calamari mit C1, no MT / MP, arbitrary batch size
  – peaky, low util. to avoid OOM
  

2 Fortschritt OCR-D (effizientes GPU-Pipelining)

• ocrd_calamari mit C1, no MT / MP, batch bucketing
  – peaky
  

2 Fortschritt OCR-D (effizientes GPU-Pipelining)

• ocrd_calamari mit C1, multithreading, batch bucketing
  – peaky
  

2 Fortschritt OCR-D (effizientes GPU-Pipelining)

• ocrd_calamari mit C2, multithreading, predict_pipeline, batch bucketing
  – peaky
  

2 Fortschritt OCR-D (effizientes GPU-Pipelining)

• ocrd_calamari mit C2, multiprocessing, predict_pipeline, batch bucketing
  – less peaky
  

2 Fortschritt OCR-D (effizientes GPU-Pipelining)

• ocrd_calamari mit C2, multiprocessing, predict_on_batch, batch bucketing
  – even less peaky
  

2 Fortschritt OCR-D (effizientes GPU-Pipelining)

• ocrd_calamari mit C2, multiprocessing, custom pipeline, mp.Queue-based generator
  – smooth!
  

3 Fortschritt Detectron2

• qual. Verbesserung der PAGE-Dekodierung (NMS)
• erst jetzt: Zugang HPC-Cluster
• Experimente zu Finetuning, vorw. auf DocLayNet (COCO)
  • extrem viele Hyperparameter, viele mögl. Varianten
  • zunächst pures Mask R-CNN (Instance Segmentation),
    – Panoptic braucht zusätzliche Daten(konversion)
  • nur COCO-Evaluierung (mAP)

3 Fortschritt Detectron2

• Experimente zu Finetuning, vorw. auf DocLayNet (COCO)
  

Baukasten: Segmentierung

• ocrd_segment – OLR-Werkzeuge
  • Formatkonvertierung (Segmentmasken, COCO, PAGE)
  • robuste Polygon-Verarbeitung ("Shapely-Frontend")
  • repair: (semantische) PAGE-Validierung und -Korrektur
  • repair/"plausibilize": Segmentkonflikte auflösen ("hierarchische NMS")
  • repair/"sanitize": Hüllkontur der Vg-Pixel
  • project: Hüllkontur der Kind-Segmente
• zus. mit ocrd-cis-ocropy-resegment: Layout-Nachverarbeitung
• viele manuell optimierte OCRD-Workflows (u.a. für Zeitungen)
• Vgl. mit AWS Textract

Baukasten: Evaluierung

• Diskussion zu Metriken…
• ocrd-segment-evaluate | page-segment-evaluate:
  • effiziente IoU-Berechnung: pycocotools.cocoeval
  • Matching, Metriken, Aggregation: eigener Code, denn
    • Alignment von pycocotools inadäquat
    • n:m statt nur 1:1
    • auch FN/FP (bzw. Recall/Precision)
    • auch Instanz- statt nur Pixel-Metriken
    • auch Maße für Über-/Untersegmentierung
    • Micro-averaging, relative Maße
  • Optionen: Zeilen/Regionen, mit/ohne Klassen, Vordergrund/alles
  • noch nicht: Allowable Split / Merge (PRImA)
• PRImA-Layout-Eval:
  partielle Quellen, Doku, Zusage von C. Clausner zur Mithilfe

Diskussion Struktur-GT

• DTA/1000 mit Qualitätsproblemen (und zu wenig)…
• Reparatur-Workflows…

Diskussion Struktur-GT

• PubLayNet, DocLayNet, TableBank, DocBank, ReadingBank etc.
  → zu homogen/modern

Ideen SLUB (1)

• ocrd-segment: Template-basierte Analyse, Notebook von @hnesk

• eigene(s) Detectron2-Modell(e) für Regionen
  (Mask-RCNN Panoptic; evtl. Spezialmodelle)

• eigenes Kraken-Modell für Zeilen
  (aber Handschrift und Print in allen Varianten; nur auf Regionen-Ebene, damit robust und modular)

Ideen SLUB (2)

• ocrd-segment-evaluate ausbauen
  → Arbeit an GT mit OCR-Workflows
• Werkzeuge für Phänomenologie und Exploration
  → dynamische Qualitätsabschätzung ohne GT
  • Binarisierung: CC-Statistik
  • Layout: ?

Ideen SLUB (3)

• trainierbare ReadingOrder?
• Wrapper für Origami?
• Wrapper für Pero-OCR?
• Experimente mit Laypa?
• Artikelseparierung?

Ziele

• Problemklassen in den VD
  • identifizieren (Merkmale, Abgrenzung)
  • quantifizieren (Häufigkeit, Schwierigkeit)
  • priorisieren
• Ground-Truth-Daten
  • für Training, für Evaluierung – gemeinsame Referenz für Experimente
  • prüfen, aufbereiten, harmonisieren, erstellen
  • Erstellung mit eigenen Werkzeugen leichter, konsistenter
• OLR-Modelle und -Werkzeuge
  • weiterentwickeln, optimieren, kombinieren
• OLR-Evaluation
  • Methoden, Metriken bereitstellen
  • anwenden und auswerten
• Integration in OCR-D
  • modulare, effiziente, robuste Prozessoren
  • Implikationen für Spezifikation und Workflows

Planung

• AP 2 priorisieren, da Abhängikeit der Partner
• möglichst früh AP4 dazunehmen, Anteil steigt schrittweise
• AP2 schrittweise übergehend in AP5
• AP6 nebenläufig, aber vermutlich mehr Aufwände als erhofft (Erbschaft Phase III)
  • OCR-D → SLUB ?
  • GPU → SBB ?

Planung

• Entwicklung im Spiralmodell, mögl. frühzeitig Train-Eval-Loop?
• monatliche Hackathons zu einzelnen Tools, um Entwicklungskultur zu fördern?