G Ocr

GOCR — schnelle, kleine deutsche OCR-/Vision-Schicht (CPU)

GOCR liest ein ganzes Dokument zu Text + Position (bbox) als strukturiertes JSON — schnell, ~30 MB, reine CPU (kein GPU).

Gedacht als Vision-/OCR-Schicht für (text-only) LLM-Pipelines und als Tooling: präzise Layout-Boxen + Text rein → dein LLM macht Verständnis/Extraktion.

pip install g-ocr           # Bilder: png/jpg/webp/tiff/bmp ...
pip install "g-ocr[pdf]"    # + PDF (optionales Plugin)

import g_ocr
ocr = g_ocr.from_pretrained()
res = ocr.read("dokument.png")            # ein Bild      -> {text, regions:[{text, box, quad, score}]}
doc = ocr.read_document("rechnung.pdf")   # PDF/mehrseitig -> {n_pages, pages:[...], text}

🔗 Demo: huggingface.co/spaces/Keyven/GOCR-Demo · 🌐 german-ocr.de

Wofür GOCR stark ist

• 🎯 Präzise Bounding-Boxes + ganzes Dokument (Lesereihenfolge) → strukturiertes JSON
• ⚡ CPU, bis ~16× schneller als EasyOCR — kein GPU
• 📦 ~30 MB (Detektor + Recognizer, ONNX)
• 🧱 Fraktur-robust (3× genauer als EasyOCR, s. u.) · on-prem / DSGVO-freundlich
• 🤖 LLM-ready: sauberes JSON (text + box + quad) als Input für text-only LLMs
• 🗂️ Bilder + PDF: png/jpg/webp/tiff/bmp ... und PDF (bis ~500 Seiten) — ein API-Aufruf, JSON je Seite

Benchmarks (deutsche Eval-Sets, CPU)

KSVTRv3-de — deutscher Recognizer, eigene deutsche Eval-Sets (NED ↑ = Zeichen-Ähnlichkeit, höher = besser):

Set	NED ↑	~CER
Modernes Deutsch (clean)	0,91	~9 %
Degradierte Scans (Augraphy)	0,85	~15 %
Fraktur (NewsEye, real)	0,74	~26 %

Einordnung: KSVTRv3-de ist ein deutscher Spezialist — robust auf echten/verrauschten Scans und Fraktur (Realismus-Training mit Augraphy). Trainiert auf deutschen Korpora (Leipzig) + Domänenfeldern (Rechnung/IBAN/USt-IdNr) + 2642 Dokument-Fonts. Auf sauberem modernem Deutsch sind dedizierte Engines (z. B. Tesseract) bei reiner Zeichengenauigkeit teils vorn; GOCRs Stärke ist die robuste, on-prem, integrierte Dokument→JSON-Schicht (CPU, klein, LLM-ready).

JSON-Schema

{
  "engine": "GOCR", "version": "0.2.0",
  "image": {"width": 1414, "height": 2000},
  "text": "...Volltext in Lesereihenfolge...",
  "n_regions": 50,
  "regions": [
    {"id": 0, "text": "Rechnungsnummer", "score": 0.99,
     "box": [217, 723, 465, 752], "quad": [[217,723],[465,723],[465,752],[217,752]]}
  ]
}

Nutzung

g-ocr dokument.png              # JSON (Text + box + quad)
g-ocr dokument.png --text-only  # nur Text (Lesereihenfolge)

Architektur

Zwei Stufen, reines ONNX/CPU: GOCR-Detektor (DB-basiert) + KSVTRv3-de-Recognizer (SVTR-Encoder + CTC, deutscher Charset).

GOCR Architektur

So entsteht der deutsche Recognizer (Daten-Foundation → Training → Deploy):

GOCR Training-Pipeline

Limitationen

• Fokus ist die Layout-+-Text-Schicht für Pipelines, nicht der Spitzenwert bei reiner Modern-DE-Texterkennung.
• Wort-Spacing: Wortgrenzen sind nicht immer korrekt (schwächeres Bag-of-Words) — Zeichengenauigkeit (CER) ist davon kaum betroffen.
• Sehr kleine/verrauschte Schrift + extreme Layouts können Detektion/Erkennung erschweren.
• Reine OCR — kein Sprachverständnis (das macht das nachgelagerte LLM).

Credits & Upstream

GOCR baut auf hervorragender Open-Source-Arbeit auf (jeweils Apache-2.0):

• OpenOCR (Topdu/OpenOCR) — Detektor (DB) + Recognizer (RepSVTR / SVTR-Familie) und Trainings-Framework.
• PaddleOCR (PaddlePaddle/PaddleOCR) — Zeichen-Dictionary (ppocr_keys_v1).

Beide stehen unter Apache-2.0; die Lizenz- und Urheberhinweise gelten fort (siehe NOTICE).

Aktuelles Modell: Der Recognizer ist KSVTRv3-de (deutscher Charset, 144 Zeichen), via Transfer-Learning vom OpenOCR-Encoder auf deutschen Korpora + Domänendaten + Scan-Realismus (Augraphy) trainiert.

Lizenz

Apache-2.0 — siehe LICENSE und NOTICE.

---

Das KI-Büro für Ihre Dokumente → german-ocr.de