OCR im Detail: Wie Computer lernen, Text aus Bildern zu lesen

Öffne ein beliebiges Bild in einem Hex-Editor. Ein Foto eines Straßenschilds, ein Kassenzettel, ein Screenshot einer PDF. Bei Offset null steht der Format-Header. Einige Kilobyte später trifft man auf die Pixeldaten: drei Bytes pro Pixel in RGB, ein Zahlenraster, in dem (128, 52, 19) eine Ziegelwand und (240, 238, 220) Papier sein könnte. Irgendwo in diesem Raster sitzt ein Stoppschild mit dem Wort "STOP" in weißer Highway Gothic auf Rot. Ein Mensch sieht vier Buchstaben. Der Computer sieht einen 47 × 19 Ausschnitt rot-ähnlicher Pixelwerte, bei denen der R-Kanal nahe 200 schwebt und G und B unter 40 fallen. Diesen Ausschnitt auf die Zeichenkette "STOP" abzubilden, ist optische Zeichenerkennung (Optical Character Recognition), und sie ist ein offenes Forschungsproblem, seit Gustav Tauschek 1929 die erste Lesemaschine patentierte.

OCR ist trügerisch schwer, weil Lesen trügerisch einfach ist. Ein sechsjähriges Kind erkennt den Buchstaben A in einem Dutzend Schriftarten, in verschiedenen Größen, bei ungleichmäßiger Beleuchtung, leicht gedreht, teilweise verdeckt und mit Bleistift geschrieben. Ein Computer braucht eine Pipeline: das Bild bereinigen, die Textregionen finden, die Zeichen oder Glyphenfolgen segmentieren und jedes einzelne klassifizieren. Jede dieser Stufen hat einen Fehlermodus, und die Fehler summieren sich.

Was OCR so schwer macht

Das Kernproblem ist nicht die Klassifikation. Ein vorsegmentiertes 28 × 28 Zeichenbild in eine von 62 Klassen (A–Z, a–z, 0–9) einzuordnen, ist eine Aufgabe, die ein LeNet aus den 1990ern mit 99 % Genauigkeit lösen kann. Der schwierige Teil ist alles, was vor dem Klassifikator kommt.

Schriftartvariation. Der Buchstabe "g" hat mindestens vier gängige Strukturvarianten: einstöckig (handschriftlich), zweistöckig (die meisten Serifenschriften), die Schlaufenschwanz-Form in Helvetica und den offenen Schwanz in Futura. Ein auf Tahoma trainiertes Modell wird Univers mit einer messbaren Fehlerrate falsch lesen. Realwelt-OCR deckt Hunderte von Schriftarten ab, dazu Handschrift, die überhaupt keine konsistente Strich-Topologie aufweist.

Geometrische Verzerrung. Fotos von Dokumenten sind selten Flachbettscans. Ein Handyfoto eines Kassenzettels führt zu Perspektivverzerrung, Krümmung und ungleichmäßigem Maßstab. Text in der Nähe des Buchrückens biegt sich. Whiteboard-Fotos fangen den Schatten des Fotografen ein. Eine 10-Grad-Neigung reduziert Tesseracts Genauigkeit von ~97 % auf unter 85 % in Standard-Benchmarks. Entzerrungsalgorithmen (Hough-Linienerkennung, Radon-Transformation, Projektionsprofilanalyse) holen einen Teil dieses Verlusts zurück, aber keinen vollständig.

Beleuchtung und Rauschen. Ungleichmäßige Beleuchtung verwandelt einen einheitlichen Hintergrund in einen Gradienten und bricht die globale Schwellwertbildung. JPEG-Kompressionsartefakte erzeugen Klingeln um scharfe Kanten. In OCR-Begriffen bedeutet das Klingeln um Buchstabenstriche. Salz-und-Pfeffer-Rauschen von Schwachlichtsensoren füllt weiße Flächen mit dunklen Pixeln, die wie Satzzeichen aussehen. Eine Fotokopie einer Fotokopie verschmiert dünne Striche und vereinigt "rn" zu "m" und "cl" zu "d".

Layoutkomplexität. Dokumente haben Spalten, Bildunterschriften, Tabellen, Kopfzeilen, Fußnoten und Seitenleisten. Text fließt um Bilder herum. Manche Sprachen laufen von rechts nach links. Andere mischen Richtungen im selben Absatz. Die Lesereihenfolge zu erkennen (welcher Textblock nach welchem kommt), ist ein von der Erkennung getrenntes Layoutanalyseproblem, und es falsch zu machen, verwürfelt die Ausgabe selbst dann, wenn jedes Zeichen korrekt klassifiziert wurde.

Kontextuelle Mehrdeutigkeit. Nur anhand des Pixelmusters sind "0" (Ziffer null), "O" (Großbuchstabe O) und "o" (Kleinbuchstabe o) in vielen serifenlosen Schriften identisch. "1", "l", "I" und "|" teilen sich einen vertikalen Strich. Die Auflösung fügt eine weitere Dimension hinzu: Bei 12 Pixel Höhe unterscheiden sich "e" und "c" nur durch einen drei Pixel breiten horizontalen Strich. Menschliche Leser lösen dies aus dem Kontext. Maschinen brauchen Sprachmodelle, statistisch oder gelernt, um denselben Schluss zu ziehen.

Die traditionelle OCR-Pipeline

Vor Deep Learning war OCR eine Abfolge handentworfener Stufen. Jede Stufe wurde unabhängig entwickelt, oft von verschiedenen Forschungsgruppen, und auf eine spezifische Verschlechterung abgestimmt. Die Pipeline sah so aus:

Rohbild → Vorverarbeitung → Binarisierung → Entzerrung → Layoutanalyse
  → Zeichensegmentierung → Merkmalsextraktion → Klassifikation
  → Nachbearbeitung (Sprachmodell) → Textausgabe

Vorverarbeitung und Binarisierung

Farbbilder werden in Graustufen umgewandelt. Rauschunterdrückung glättet das Signal vor der Schwellwertbildung. Medianfilterung behandelt Salz-und-Pfeffer-Rauschen. Gaußscher Weichzeichner behandelt Sensorrauschen. Bilaterale Filterung wird eingesetzt, wenn Kantenerhaltung wichtig ist.

Die Binarisierung verwandelt das Graustufenbild in schwarzen Text auf weißem Hintergrund. Der Standardalgorithmus ist Otsus Methode (1979): Sie durchsucht erschöpfend den Schwellwert, der die Intra-Klassen-Varianz zwischen Vordergrund- und Hintergrund-Pixelverteilungen minimiert. Otsu setzt ein bimodales Histogramm voraus (Textpixel gruppieren sich bei einer Intensität, Hintergrundpixel bei einer anderen), was für Flachbettscans unter kontrollierter Beleuchtung funktioniert und für Handyfotos mit Schatten versagt. Lokale adaptive Methoden (Sauvola, Niblack) berechnen einen anderen Schwellwert pro Pixel basierend auf Nachbarschaftsstatistiken und behandeln ungleichmäßige Beleuchtung auf Kosten von Artefakten nahe Kanten.

Entzerrung und Layoutanalyse

Die Dokumentneigung wird durch das Finden von Linien erkannt: entweder Hough-Transformation auf Kantenpixeln oder Projektionsprofilanalyse, bei der das Dokument durch einen Winkelbereich rotiert wird und der Winkel mit den schärfsten horizontalen Projektionsspitzen gewählt wird. Sobald der Neigungswinkel bekannt ist, dreht eine affine Transformation das Bild zurück.

Die Layoutanalyse segmentiert die Seite in Textblöcke. Der klassische Ansatz führt eine Connected-Component Analysis (CCA) durch, um Blobs von Vordergrundpixeln zu finden, gruppiert sie nach Nähe zu Wörtern und dann Wörter zu Zeilen und Zeilen zu Blöcken. Der XY-Cut-Algorithmus teilt die Seite rekursiv, indem er Weißraumlücken entlang horizontaler und vertikaler Projektionen findet und einen Baum von Regionen aufbaut. Moderne Implementierungen verwenden einen Hybrid: CCA für anfängliche Blobs, dann ein gelerntes Modell, um jeden Blob als Text, Bild, Tabelle oder Trenner zu klassifizieren.

Zeichensegmentierung

Für maschinengedruckten Text bedeutet Segmentierung, Wortbilder in einzelne Zeichen zu schneiden. Das vertikale Projektionsprofil (ein Histogramm der Vordergrundpixel pro Spalte) erzeugt Spitzen an Zeichenzentren und Täler an Zeichengrenzen. Das funktioniert, bis zwei Zeichen sich berühren oder ein Zeichen unverbundene Teile enthält ("i", "j", ":", "%"). Übersegmentierung (zu aggressives Schneiden) gefolgt von Zusammenführung basierend auf Klassifikator-Konfidenz ist eine Lösung. Eine andere ist, die Segmentierung ganz zu überspringen und ganze Wörter zu erkennen — das ist, was moderne sequenzbasierte Methoden tun.

Merkmalsextraktion und Klassifikation

Sobald man ein Zeichenbild hat, muss man es numerisch für einen Klassifikator beschreiben. Vor-Deep-Learning-Merkmale umfassten:

• Rohpixelwerte als abgeflachter Vektor (einfach, aber anfällig für Verschiebung und Skalierung)
• Zoning: die Zeichen-Bounding-Box in ein N × N-Raster teilen, Vordergrundpixel pro Zelle zählen, die Zählungen als Merkmale verwenden
• Gradientenbasierte Merkmale (HOG): Histogram of Oriented Gradients erfasst Kantenrichtungen, robust gegenüber kleinen Verschiebungen
• Scale-Invariant Feature Transform (SIFT): erkennt und beschreibt Schlüsselpunkte, die invariant gegenüber Skalierung, Rotation und Beleuchtung sind

Der Klassifikator war typischerweise eine Support Vector Machine (SVM) mit RBF-Kernel, trainiert auf Zehntausenden gelabelter Zeichenbilder pro Schriftart. Eine gut abgestimmte SVM + HOG-Pipeline konnte ~98 % zeichengenaue Genauigkeit auf sauberem Drucktext erreichen. Bei verrauschter, schiefer oder handschriftlicher Eingabe in derselben Pipeline fiel die Genauigkeit auf 70–80 %.

Tesseract: von HP Labs zu LSTM

Tesseract ist die Referenz-Open-Source-OCR-Engine. Sie begann als Doktorarbeitsprojekt bei HP Labs Bristol in den 1980ern, wurde 2005 als Open Source veröffentlicht und wird seit 2006 von Google gepflegt. Ihre Architektur teilt sich sauber in zwei Epochen.

Version 3: die klassische Pipeline

Tesseract 3 implementierte die traditionelle Pipeline mit einigen Innovationen. Seine Layoutanalyse verwendete einen Tabstopp-Erkennungsalgorithmus, der Spaltengrenzen durch Ausrichten von Wort-Bounding-Boxen fand — eine pragmatische Heuristik, abgestimmt auf die Art von Dokumenten, die HP in den 1990ern scannte. Die Zeichensegmentierung verwendete eine Chopper/Associator-Logik: Der Chopper übersegmentierte das Wortbild in Kandidatenschnitte, und der Associator verwendete Klassifikator-Konfidenz und ein Wörterbuch, um zu entscheiden, welche Schnitte zusammengeführt werden.

Der Klassifikator war ein Zwei-Durchlauf-System. Der erste Durchlauf (statischer Klassifikator) ordnete segmentierte Blobs Prototypen (geclusterten Trainingsproben) mittels Nächster-Nachbar-Suche zu. Der zweite Durchlauf (adaptiver Klassifikator) feinabstimmte auf das Dokument selbst und lernte die spezifische Schriftart, die in diesem Bild verwendet wurde. Der adaptive Klassifikator benötigte etwa eine Seite Text, um effektiv zu werden, weshalb Tesseract 3 bei Einzelwortbildern wie Straßenschildern und Bildunterschriften schlecht abschnitt.

Tesseract 3 lieferte .traineddata-Dateien: Archive, die die Prototyp-Cluster, Zeichensatzdefinitionen, ein Worthäufigkeitswörterbuch und eine Unichar-Mehrdeutigkeitstabelle enthielten, die verwechselbare Zeichenpaare abbildete. Das Trainieren einer neuen Sprache erforderte, Tesseract Bilder von Text gepaart mit Ground-Truth-Transkriptionen zu füttern, jedes Zeichen einzurahmen und die Trainingswerkzeuge auszuführen. Ein mehrstündiger Prozess pro Sprache.

Version 4/5: LSTM ersetzt die Pipeline

Tesseract 4 (2018) ersetzte den gesamten Erkennungspfad durch ein einzelnes LSTM-neuronales Netzwerk. Das LSTM arbeitet auf einer Sequenz vertikaler Scheiben des Textzeilenbildes, jede Scheibe ein Pixel breit und die volle Textzeilenhöhe. Jede Scheibe wird in einen Stapel bidirektionaler LSTM-Schichten eingespeist. Die Ausgabe ist eine Sequenz von Zeichenwahrscheinlichkeiten mit einem Connectionist Temporal Classification (CTC)-Verlust, der die variable Ausgabesequenz auf den Ground-Truth-Text ausrichtet, ohne vorsegmentierte Zeichenpositionen zu benötigen.

Das LSTM-Modell behandelt Zeichen variabler Breite, sich berührende Zeichen und Schriftartvariation ohne die Chopper/Associator-Maschinerie. Es verlässt sich weiterhin auf Tesseracts veraltete Layoutanalyse zum Finden von Textzeilen, aber die Zeilenerkennung ist durchgängig neuronal. Im ICDAR 2017-Benchmark erreichte Tesseract 4 eine Zeichenfehlerrate (CER) von 4,4 % bei gedrucktem Englisch, verglichen mit 7,2 % für Tesseract 3. Der Trainingsprozess wechselte vom veralteten Einrahmungswerkzeug zum Kombinieren von Textzeilen mit Transkriptionen. Immer noch überwacht, aber mit einem Label pro Zeile statt pro Zeichen.

Das .traineddata-Format wurde erweitert, um die LSTM-Modellgewichte (mehrere Megabyte) neben den veralteten Daten (Wörterbuch, Unichar-Tabellen) in einer einzigen Datei zu speichern. Das Training eines schnellen LSTM-Modells von Grund auf dauert etwa 24 Stunden auf einer modernen GPU für eine lateinschriftbasierte Sprache mit ~100 Zeichenklassen; CJK-Sprachen dauern aufgrund größerer Zeichensätze länger.

Genauigkeitseigenschaften

Tesseract 5 verbesserte Version 4 mit einem größeren Trainingskorpus und besseren Standardparametern, aber die Architektur ist unverändert. Die Genauigkeit ist stark eingabeabhängig:

Das LSTM-Modell beseitigt die meisten Schriftart-Empfindlichkeitsprobleme von Version 3, aber die Engine verschlechtert sich immer noch bei niedriger Auflösung (unter 200 DPI verliert die Pixel-Scheiben-Eingabe des LSTM Strichdetails), handschriftlichem Text (das Modell wurde auf Druckschriften trainiert; Handschrift hat grundlegend andere Strichstatistiken) und komplexen Layouts (die Layoutanalyse ist immer noch der veraltete Codepfad, nicht der neuronale).

Moderne Deep-Learning-Ansätze

Akademisch bewegte sich OCR um 2019 über das CTC + LSTM-Paradigma hinaus. Drei Architekturen dominieren nun die Literatur.

CRNN + CTC

Das Convolutional Recurrent Neural Network (CRNN), veröffentlicht von Shi et al. 2015, paart einen CNN-Merkmalsextraktor mit einem RNN-Sequenzmodell und CTC-Dekodierung. Das CNN extrahiert räumliche Merkmale aus dem Bild und lernt im Wesentlichen das, was dem LSTM in Tesseract von Hand gegeben wurde (vertikale Scheibenrepräsentationen). Das RNN modelliert Sequenzabhängigkeiten über die extrahierten Merkmale hinweg. CTC behandelt die Ausrichtung. CRNN-CTC wurde zur Standard-Baseline: durchgängig trainierbar, gute Generalisierung, schnelle Inferenz (~20 ms pro Zeile auf GPU).

Attention-basierter Encoder-Decoder

Attention-basierte Modelle passten das seq2seq-Paradigma aus der maschinellen Übersetzung an. Ein CNN- oder Vision-Encoder erzeugt eine Feature-Map des Bildes. Ein RNN-Decoder generiert den Ausgabetext Zeichen für Zeichen und richtet bei jedem Schritt Attention auf relevante räumliche Regionen der Feature-Map. Der Attention-Mechanismus entfernt die Monotonie-Beschränkung von CTC: Der Decoder kann zu früheren Teilen des Bildes zurückspringen, wenn das Sprachmodell ein wiederholtes Muster erwartet, obwohl diese Flexibilität auch ein Halluzinationsrisiko für unlesbare Eingaben einführt. Attention-basierte Decoder erreichen ~1,5–3 % CER auf sauberem gedrucktem Englisch und übertreffen reine CTC-Modelle bei langen Sequenzen und unregelmäßigen Layouts.

Vision Transformers (TrOCR, Donut)

TrOCR (Microsoft, 2021) wandte die Transformer-Architektur auf OCR an. Das Bild wird in Patches aufgeteilt, von einem ViT (Vision Transformer)-Encoder kodiert, und der Text wird autoregressiv von einem Transformer-Textdecoder dekodiert. Es ist die Architektur eines standardmäßigen multimodalen Modells, speziell für OCR trainiert. TrOCR erreicht State-of-the-Art-Ergebnisse auf gedrucktem Text (unter 1 % CER auf sauberen Scans) ohne jegliche CNN-Vorverarbeitung, explizites Sprachmodell oder Zeichensegmentierung.

Donut (NAVER, 2022) erweiterte den Ansatz auf Dokumentenverständnis: Die Eingabe ist ein vollständiges Dokumentbild, und die Ausgabe ist strukturiertes JSON, das direkt aus den visuellen Merkmalen extrahiert wird und die OCR → NLP-Pipeline vollständig überspringt. Dies verwischt die Grenze zwischen OCR und Dokumentenparsing auf eine Weise, die für reale Anwendungen bedeutsam ist: Das Extrahieren eines Rechnungsbetrags, einer Passnummer oder einer Tabelle aus einer Forschungsarbeit wird zu einem einzigen Modellaufruf statt OCR + Regex + Heuristiken.

Leistungsvergleich (gedrucktes Englisch, saubere 300 DPI)

Die Lücke zwischen Tesseract und den besten Transformer-Modellen ist in Benchmarks real. In der Praxis verengt sich die Lücke, weil die meisten eingesetzten Systeme Tesseract saubere, gut beleuchtete 300-DPI-Eingaben zuführen, und bei dieser Eingabe bedeuten 1,8 % CER ein falsches Zeichen in jedem 55. Akzeptabel für Suchindizierung, weniger für ein juristisches Dokumententranskript.

Nicht-englisches OCR: warum es schwerer ist

Englisches OCR ist ein gelöstes Problem. Ein Zeichensatz aus 26 Großbuchstaben, 26 Kleinbuchstaben, 10 Ziffern und einer Handvoll Satzzeichen ergibt etwa 70 Klassen. Ein Mehrklassen-Klassifikationsproblem, das bequem innerhalb der Kapazität eines LeNet aus den 1990ern liegt. Die übrigen Schriftsysteme der Welt sind weniger nachsichtig.

CJK: Zeichensatzexplosion

Chinesisch, Japanisch und Koreanisch (CJK) stellen allein durch die Zeichensatzgröße die härteste OCR-Herausforderung dar. Vereinfachtes Chinesisch verwendet etwa 3.500 häufige Zeichen und 6.000+ in allgemeinem Text. Traditionelles Chinesisch fügt weitere tausend Varianten hinzu. Japanisch mischt zwei Silbenschriften (Hiragana, Katakana: je 46 Zeichen) mit ~2.000 häufigen Kanji plus lateinischen Alphanumerika im selben Satz. Koreanisches Hangul ist phonetisch regelmäßig (24 Grundbuchstaben, die sich zu Silbenblöcken kombinieren), aber visuell dicht: Ein einzelner Block kann bis zu sechs einzelne Jamo-Komponenten enthalten, gepackt in einen Raum von etwa der Größe zweier lateinischer Zeichen nebeneinander.

Ein CJK-OCR-System kann Erkennung nicht als 70-Wege-Klassifikation behandeln. Es ist eine 4.000-Wege-Klassifikation für Japanisch, 6.000-Wege für vereinfachtes Chinesisch und über 10.000-Wege für traditionelles Chinesisch, mindestens. Allein die Softmax-Ausgabeschicht hat mehr Parameter als ein gesamtes lateinschriftbasiertes OCR-Modell. Der Trainingsdatenbedarf skaliert mit dem Zeichensatz: ~100 gelabelte Proben pro Klasse für akzeptable Genauigkeit, also beginnen chinesische Trainingssätze bei 600.000 Textzeilenbildern.

Tesseract stellt CJK-Traineddata-Dateien (chi_sim, chi_tra, jpn, kor) zur Verfügung, aber sie sind deutlich größer als lateinische Modelle. chi_sim.traineddata ist ~50 MB gegenüber ~15 MB für eng.traineddata, und die Erkennung ist langsamer, weil der Ausgaberaum größer ist. Die Genauigkeit auf sauberem gedrucktem CJK-Text liegt bei 2–5 % CER für Tesseract 5, etwa das 2–3-fache der Fehlerrate für Englisch unter äquivalenten Bedingungen.

Arabisch und rechts-nach-links-Schriften

Arabisch fügt zwei Probleme jenseits des Zeichensatzes hinzu (28 Buchstaben mit kontextuellen Formen, die sich je nach Position im Wort ändern). Erstens wird es von rechts nach links geschrieben, also muss die OCR-Engine die Textrichtung erkennen und die Ausgabereihenfolge umkehren. Zweitens ist Arabisch kursiv. Buchstaben innerhalb eines Wortes verbinden sich durch einen Grundlinienstrich, was die Segmentierung inhärent schwieriger macht als bei den meist unverbundenen Buchstabenformen lateinischer und kyrillischer Schriften. Ein arabisches Wortbild ist ein zusammenhängender Blob; zeichenbasierte Segmentierung ist praktisch unmöglich, weshalb der LSTM/CTC-Ansatz (der auf Wortbildern ohne Zeichensegmentierung arbeitet) ein größerer Durchbruch für arabisches OCR war als für englisches.

Hebräisch, Urdu, Farsi und Paschto teilen eine Kombination dieser Herausforderungen. Tesseract bietet arabisches Traineddata, aber die Genauigkeit liegt bei etwa 5–8 % CER auf sauberem gedrucktem Text, etwa 4-mal schlechter als Englisch unter denselben Bedingungen.

Indische Schriften: das Konjunkt-Problem

Devanagari (Hindi, Marathi, Nepali) und andere brahmische Schriften stellen eine besondere Herausforderung dar: Die Schreibeinheit ist nicht das Zeichen, sondern das Konjunkt, ein visuell verschmolzener Cluster aus einem Konsonanten, einem Vokalmodifikator und manchmal einem zusätzlichen Konsonanten. Der Unicode-Devanagari-Block hat 128 Codepunkte, aber die Zahl möglicher Konjunkte übersteigt 1.000. Die "Shirorekha" (die horizontale Kopflinie, die Zeichen in einem Wort verbindet) macht die Segmentierung schwieriger, weil die Kopflinie benachbarte Zeichen zu einer visuellen Einheit verschmilzt.

Tesseracts Hindi-Traineddata (hin) deckt die häufigen Konjunkte ab, aber die Genauigkeit liegt bei gedrucktem Text 3–4-mal hinter Englisch. Tamil, Telugu, Bengali und andere indische Schriften sind weniger gut unterstützt, einige ohne jegliche offizielle Traineddata-Dateien. Die Ursache ist das Trainingsdatenvolumen: Hochwertige annotierte Textzeilenbilder für Hindi existieren in Millionen, während für Kannada die verfügbaren Datensätze in Zehntausenden zählen.

Vertikaler Text und Layouts mit gemischter Richtung

Japanisch und traditionelles Chinesisch werden manchmal vertikal gesetzt, mit Zeilen von oben nach unten und Spalten von rechts nach links. Tesseracts Layoutanalyse setzt horizontalen Text voraus; vertikaler Text erfordert Vorrotation oder eine separate Engine. Gemischter horizontaler und vertikaler Text auf derselben Seite, häufig in japanischen Zeitungen und Manga, bricht die Einrichtungsannahme vollständig und erfordert regionsweise Richtungserkennung vor der Erkennung.

Kleine Sprachen und Trainingsdaten

Für Sprachen mit weniger als 10 Millionen Sprechern existieren hochwertige OCR-Trainingsdaten selten. Das Unicode-Konsortium hat über 150 Schriften kodiert, aber Tesseract liefert Traineddata für etwa 120 Sprachen, viele davon aus synthetischem Text generiert, der mit Standardschriftarten auf sauberen Hintergründen gerendert wurde. Synthetische Daten funktionieren für gedruckten Text in gängigen Schriftarten und versagen bei den Schriftarten, Papieren und Druckqualitäten, die in tatsächlichen Dokumenten dieser Sprachen zu finden sind. Ein auf synthetischem Arial bei 300 DPI trainiertes Modell wird ein maschinegeschriebenes amharisches Dokument aus den 1970ern nicht lesen.

Browserseitiges OCR mit Tesseract.js

OCR im Browser auszuführen, war unpraktisch, bis WebAssembly ausgeliefert wurde. Tesseract.js kompiliert Tesseract 5 (LSTM) über Emscripten nach WebAssembly und verpackt die C++-Engine in eine JavaScript-API, die einen Web Worker pro Erkennungsaufgabe ausführt. Engine, Sprachdaten und Worker werden aus statischen Assets geladen. Kein Server-Roundtrip für Bilddaten.

Die API-Oberfläche ist unkompliziert: Einen Worker mit einem oder mehreren Sprachcodes erstellen, ihm ein Bild zuführen und erkannten Text mit zeichenweisen Konfidenzwerten zurückbekommen. Mehrere Worker können parallel laufen, begrenzt durch verfügbare CPU-Kerne. Typischerweise vier parallele Erkennungsjobs auf einem Consumer-Laptop, sechs bis acht auf neueren Handys.

Die Leistung wird durch drei Faktoren begrenzt. Erstens läuft WebAssembly mit etwa 50–70 % der nativen Geschwindigkeit; eine Textzeile, die in nativem Tesseract 100 ms dauert, dauert im Browser etwa 160 ms. Zweitens werden die Traineddata-Dateien über das Netzwerk geladen. eng.traineddata ist ~15 MB, chi_sim.traineddata ist ~50 MB, und beide müssen vollständig heruntergeladen sein, bevor die Erkennung beginnt. Drittens verwendet die Bilddekodierung (JPEG/PNG/WebP/HEIC zu Rohpixeldaten) die eingebauten Decoder des Browsers, die schnell sind, aber je nach Format und Gerät variieren.

Der Datenschutzvorteil ist strukturell. Clientseitiges OCR bedeutet, dass das Bild das Gerät nie verlässt. Ein Foto eines Reisepasses, eines Kontoauszugs, einer Krankenakte. Die Pixel werden im Browser dekodiert, das Textract-Äquivalent läuft in einem Web Worker, und das Ergebnis ist eine Textzeichenkette, die der Benutzer kopieren oder speichern kann. Kein Rechenzentrum verarbeitet das Bild. Das ist kein Feature, sondern die Abwesenheit eines Servers, was sich kategorisch von einer Datenschutzrichtlinie unterscheidet, die verspricht, nicht hinzusehen.

Unser Bild zu Text-Tool betreibt genau diesen Stack: Tesseract.js mit LSTM-Erkennung, Web Workers für parallele Verarbeitung und Traineddata für 12 Sprachen (Englisch, Spanisch, Französisch, Deutsch, Portugiesisch, Italienisch, Chinesisch vereinfacht und traditionell, Japanisch, Koreanisch, Hindi und Russisch). Ein Foto ablegen, Sprachen auswählen, Text erhalten. Das Tool liest JPEG-, PNG-, WebP-, BMP- und GIF-Eingaben, wendet auflösungsbewusste Vorskalierung an (Bilder über 3.000 Pixel auf der längsten Seite werden herunterskaliert, um die Erkennungslatenz angemessen zu halten) und gibt Klartext pro Bild mit zeichenweiser Konfidenz aus.

Die Wahl des Bildformats beeinflusst die OCR-Qualität in der Praxis. HEIC-Fotos von iPhones, vor OCR in JPEG konvertiert, nehmen Kompressionsartefakte um Textkanten auf, die die Erkennungsgenauigkeit verringern. HEIC zuerst in PNG zu konvertieren (verlustfrei, keine Quantisierungsartefakte) bewahrt die scharfen Kanten, auf die das LSTM angewiesen ist. Unsere HEIC zu JPG- und HEIC zu PNG-Konverter führen diesen Vorverarbeitungsschritt direkt im Browser aus. Ebenso profitieren Fotos, die bei schwachem Licht aufgenommen wurden, von der Konvertierung in ein Format, das den vollen Tonumfang vor der Schwellwertbildung bewahrt: JPG zu PNG vermeidet die JPEG-Artefakte der zweiten Generation, die sich ansammeln, wenn eine JPEG-Quelle neu kodiert wird.

Der Browser-OCR-Stack ist im Durchsatz nicht konkurrenzfähig mit GPU-beschleunigten serverseitigen Modellen. Ein Server, der Tesseract auf 32 CPU-Kernen mit nativem C++ ausführt, wird einen Browser-Tab immer überholen. Er gewinnt bei Datenschutz, null Infrastruktur und null Kosten pro Anfrage. Beim Scannen weniger Seiten, eines Kassenzettels oder einer Handvoll Schilder ist der Latenzunterschied zwischen 200 ms und 50 ms unsichtbar.

Wohin sich OCR entwickelt

OCR hörte um 2022 auf, ein eigenständiges Forschungsfeld zu sein, und verschmolz mit dem breiteren Bereich Dokumenten-KI und multimodaler Modelle. Drei Verschiebungen sind im Gange.

Multimodale LLMs als Zero-Shot-OCR. GPT-4V, Claude und Gemini können Text aus Bildern ohne explizites OCR-Training lesen. Füttere ein Foto eines Dokuments und frage nach dem Text, und das Modell gibt ihn zurück. Nicht weil es einen dedizierten OCR-Kopf hat, sondern weil Texterkennung aus dem Training auf Milliarden von Bild-Text-Paaren emergiert. Die Qualität ist ungleichmäßig. Auf sauberem gedrucktem Englisch erreicht GPT-4V ~1 % CER, vergleichbar mit einem feinabgestimmten TrOCR. Auf niedrig aufgelösten Handyfotos chinesischer Kassenzettel kann es Tesseract übertreffen, weil das Modell Kontext nutzt (es weiß, wie ein Kassenzettel aussieht und welche Zahlen zu erwarten sind), statt sich allein auf pixelgenaue Evidenz zu verlassen. Bei Handschrift ist es schlechter als ein feinabgestimmter Erkenner, weil die Trainingsverteilung nicht genügend handschriftliche Bilder enthielt.

Der Kompromiss sind Kosten und Latenz. Ein API-Aufruf an GPT-4V für OCR kostet 1–3 Cent pro Seite, abhängig von der Tokenzahl, und dauert 1–3 Sekunden. Tesseract läuft lokal in 100–500 ms und kostet nichts pro Seite. Beim Scannen eines 200-seitigen Dokuments beträgt der Unterschied $2–6 und mehrere Minuten Wanduhrzeit gegenüber null und unter einer Minute. Für den einmaligen Gebrauch (ein einzelner Kassenzettel, ein Whiteboard-Foto) ist das multimodale Modell einfacher und oft genauer.

On-Device-Inferenz. Die Modelle hinter Server-OCR schrumpfen. ONNX Runtime Web führt quantisierte CRNN- und kleine ViT-Modelle im Browser mit 50–100 ms pro Textzeile auf WebGPU aus. Apples Vision-Framework liefert ein kompaktes OCR-Modell on-device für iOS und macOS, zugänglich über VNRecognizeTextRequest ohne Netzwerkaufruf. Die Lücke zwischen "Server-GPU-Modell" und "Browser-Modell" schließt sich, weil beide auf denselben architektonischen Sweet Spot konvergieren: einen kleinen ViT-Encoder (~20–50M Parameter) mit einem schlanken Decoder, quantisiert auf INT8 oder FP16.

Dokumentenverständnis, nicht nur Transkription. Die Ausgabe von OCR ist eine Zeichenkette. Die meisten realen Aufgaben beinhalten das Extrahieren strukturierter Informationen aus dieser Zeichenkette: Rechnungsnummern, Daten, Summen, Namen, Adressen. Der traditionelle Ansatz verkettet OCR mit Regex, Named Entity Recognition und Schema-Mapping. Jede Stufe ist ein separates Modell mit eigenen Fehlermodi. Durchgängige Dokumentenverständnismodelle (Donut, LayoutLMv3, Pix2Struct) überspringen OCR und bilden Dokumentbilder direkt auf strukturierte Ausgaben ab. Ein auf Kassenzettel feinabgestimmtes Donut-Modell erzeugt kein Texttranskript und parst es dann. Es erzeugt {"total": "42.50", "date": "2026-07-27", "vendor": "..."} direkt aus Pixeleingabe. Der OCR-Schritt, der Teil, um den es in diesem Artikel geht, wird zu einem unsichtbaren Implementierungsdetail.

Das macht OCR nicht obsolet. Es macht es zu einem Baustein. Die Pipeline muss immer noch die Randfälle behandeln: den schräg fotografierten Kassenzettel in einem dunklen Restaurant, das 50 Jahre alte maschinegeschriebene Dokument auf vergilbtem Papier, das Schild in einer Sprache, für die kein großes multimodales Modell trainiert wurde. Spezialisierte OCR-Engines, die auf diese spezifischen Verteilungen trainiert sind, werden ein Allzweckmodell jahrelang in Geschwindigkeit und Leistung übertreffen, weil ein Allzweckmodell, das auf dem gesamten Internet trainiert wurde, einen verschwindend kleinen Bruchteil seiner Kapazität dem Lesen amharischer Schreibmaschinenausgaben der 1970er Jahre widmet.

OCR ist kein gelöstes Problem für die meisten Sprachen der Welt und die meisten realen Aufnahmebedingungen. Es ist ein gelöstes Problem für sauberen, 300 DPI, englischen, einspaltigen, maschinengedruckten Text — den engsten und am besten finanzierten Ausschnitt des Problemraums. Der Rest ist noch offen.