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

GOCR liest ein ganzes Dokument zu Text + Position (bbox) als strukturiertes JSON — schnell, ~38 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
📦 ~38 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 (anerkannte Sets, CPU)

Scene-Text-Recognition (Word Accuracy ↑, Standard-Protokoll):

Benchmark	GOCR	EasyOCR
IIIT5K	93,2 %	68,2 %
ICDAR2013	94,1 %	—
ICDAR2015 (incidental)	67,6 %	—

Dokument-OCR (CER ↓ / BoW ↓) — Harness & Referenzwerte: agentic-ai-forge/ocr-benchmark-2025:

🟦 GOCR — #2 von 5 auf Dokument-CER: schlägt EasyOCR, Tesseract & OCR.space, nur knapp hinter PaddleOCR — bei ~38 MB auf reiner CPU.

Engine	SROIE CER	FUNSD CER	SROIE BoW	FUNSD BoW
PaddleOCR	15,2	20,3	25,8	50,5
🟦 GOCR	18,9	22,4	98,9	130,3
EasyOCR	20,4	26,4	81,1	102,1
Tesseract	22,6	32,4	70,2	88,2
OCR.space	44,3	48,2	73,3	84,8

Einordnung: Bei der Zeichengenauigkeit (CER) ist GOCR #2 von 5 — vor EasyOCR, Tesseract und OCR.space, knapp hinter PaddleOCR — bei ~38 MB auf reiner CPU. Auf Scene-Text schlägt GOCR EasyOCR klar (IIIT5K 93,2 % vs 68,2 %). Beim Bag-of-Words liegt GOCR zurück: das ist die Wort-Spacing-Lücke der aktuellen Gewichte (Zeichen stimmen, Wortgrenzen noch nicht) — steht auf der Roadmap.

Messung: FUNSD = exakte 25 Referenz-Samples, SROIE = 60-Beleg-Stichprobe; gescort mit der metrics.py des Referenz-Harness (reproduzierbar via run_gocr.py).

Deutsche Dokumente (CER ↓): Fraktur (NewsEye) GOCR 22,0 % vs EasyOCR 63,0 % (≈3× besser). Modernes Deutsch (synthetisch): hier führen Spezial-Engines — GOCRs aktuelle Gewichte haben noch eine Umlaut-/ß-Lücke (Roadmap: deutscher Recognizer).

JSON-Schema

{
  "engine": "GOCR", "version": "0.1.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 (Text-Detektion, ~12 MB) + KSVTRv3-Recognizer (CTC, ~25 MB). Roadmap: deutscher Recognizer auf realistischeren/diverseren Daten (Generalisierung), optional Sprach-Modul.

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).

Lizenz

Apache-2.0 — siehe LICENSE und NOTICE.

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

Downloads last month: -; Downloads are not tracked for this model. How to track