Das ist Ihnen bei der Arbeit wahrscheinlich schon passiert: Sie halten Chatverläufe oder Webseiten als Screenshots fest, um später darauf zurückzukommen, und stellen dann fest, dass der Text in diesen Bildern nicht durchsuchbar ist. Oder ein wichtiger unterschriebener und gestempelter Vertrag muss als PDF gescannt werden, um den Originalnachweis zu sichern. Doch wenn Sie später etwas nachschlagen oder eine Passage zitieren möchten, können Sie darin nicht suchen, nichts daraus kopieren und müssen am Ende Seiten durchblättern und alles von Hand abtippen.
Genau dieses Problem soll Getys eingebaute OCR lösen.
Um herauszufinden, wie gut ihr das gelingt, haben wir die Dokumentbilder aus zwei öffentlichen Datensätzen (MDPBench und OmniDocBench) genommen und darum herum unsere eigene Evaluation aufgebaut, die gezielt auf OCR ausgerichtet ist, die auf dem eigenen Rechner läuft. Wir haben Gety gegen die wichtigsten lokalen OCR-Optionen antreten lassen, die Nutzer in echten Arbeitsabläufen antreffen dürften: PaddleOCR (PP-OCRv6), der stärkste Open-Source-Kandidat; Tesseract, die bekannte Baseline mit langer Geschichte; und die OCR, die in macOS und Windows integriert ist. Cloud-OCR und Cloud-Modelle wie Gemini sind bewusst nicht dabei. Sie erfordern Uploads, API-Aufrufe, eine Internetverbindung und oft nutzungsabhängige Kosten, während Gety vollständig on-device läuft.
Die Ergebnisse zeigen zwei klare Vorteile:
- Unter den lokalen On-Device-OCR-Engines belegt Gety bei der mehrsprachigen Genauigkeit den ersten Platz und liegt über 17 Sprachen hinweg insgesamt vorn.
- Es benötigt nur etwa ein Fünftel des Speichers vergleichbarer On-Device-Modelle, sodass dauerhaft laufende OCR im Hintergrund und Echtzeit-Indexierung praktisch möglich werden.
1. Mehrsprachigkeit: wo Gety den größten Vorsprung herausarbeitet
Viele Engines bewältigen Englisch und Französisch gut genug. Die Schwierigkeiten beginnen, wenn sich die Schrift ändert. Wechselt man zu Koreanisch, Russisch, Thailändisch oder Hindi, stürzen die meisten Modelle von über 0.9 auf 0.2 oder 0.1 ab, also auf Werte, die für die Praxis kaum noch brauchbar sind. So schneidet das Feld über die 17 Sprachen hinweg ab, anhand der Dokumentbilder aus MDPBench:
| Sprache / Metrik | Gety OCR (built-in) | Apple Vision (built-in) | PP-OCRv6(small) | PP-OCRv6(tiny) | Windows OCR | Tesseract |
|---|---|---|---|---|---|---|
| Gesamt (F1) | 0.903 | 0.881 | 0.724 | 0.686 | 0.609 | 0.541 |
| Lateinische Schriften (Durchschn.) | 0.966 | 0.940 | 0.967 | 0.957 | 0.847 | 0.901 |
| Englisch | 0.978 | 0.962 | 0.972 | 0.972 | 0.882 | 0.919 |
| Deutsch | 0.959 | 0.967 | 0.992 | 0.991 | 0.923 | 0.962 |
| Französisch | 0.947 | 0.799 | 0.982 | 0.977 | 0.795 | 0.940 |
| Spanisch | 0.920 | 0.923 | 0.927 | 0.923 | 0.819 | 0.872 |
| Italienisch | 0.980 | 0.976 | 0.985 | 0.979 | 0.887 | 0.932 |
| Portugiesisch | 0.978 | 0.983 | 0.980 | 0.972 | 0.797 | 0.840 |
| Niederländisch | 0.994 | 0.924 | 0.995 | 0.995 | 0.967 | 0.974 |
| Indonesisch | 0.974 | 0.966 | 0.987 | 0.987 | 0.892 | 0.959 |
| Vietnamesisch | 0.967 | 0.958 | 0.884 | 0.814 | 0.661 | 0.716 |
| Nicht-lateinische Schriften (Durchschn.) | 0.832 | 0.814 | 0.452 | 0.382 | 0.343 | 0.136 |
| Chinesisch (vereinfacht) | 0.946 | 0.912 | 0.965 | 0.957 | 0.800 | 0.180 |
| Chinesisch (traditionell) | 0.924 | 0.805 | 0.939 | 0.862 | 0.853 | 0.142 |
| Japanisch | 0.916 | 0.804 | 0.924 | 0.525 | 0.454 | 0.173 |
| Koreanisch | 0.970 | 0.961 | 0.276 | 0.248 | 0.211 | 0.190 |
| Russisch | 0.954 | 0.960 | 0.155 | 0.106 | 0.096 | 0.102 |
| Thailändisch | 0.951 | 0.974 | 0.155 | 0.137 | 0.150 | 0.125 |
| Hindi | 0.958 | 0.136 | 0.191 | 0.178 | 0.140 | 0.147 |
| Arabisch | 0.039 | 0.962 | 0.011 | 0.046 | 0.037 | 0.031 |
Die Zeile, auf die es ankommt, ist die nicht-lateinische. Hier fallen die Open-Source-Modelle auseinander und brechen in den Bereich von 0.1 bis 0.4 ein, während Gety bei 0.832 bleibt. Für Sie ist das der Unterschied zwischen der Möglichkeit, ein chinesisches, japanisches, koreanisches oder russisches Dokument zu durchsuchen, und der Erkenntnis, dass allein die Schrift den Inhalt für die Suche praktisch unsichtbar macht. Dokumente in diesen Sprachen werden mit Gety sehr viel seltener zu blinden Flecken in Ihrer Suche.
Fotos sind eine Geschichte für sich. Wenn die Eingabe ein Foto eines Dokuments ist, also unscharf, schief oder von Blendung ausgewaschen, statt einer sauberen digitalen Datei, tut sich jedes Modell schwer:
| Modell | Digital erzeugt (F1) | Abfotografiert (F1) |
|---|---|---|
| Gety OCR (built-in) | 0.903 | 0.322 |
| Apple Vision (built-in) | 0.881 | 0.421 |
| PP-OCRv6(small) | 0.724 | 0.301 |
| PP-OCRv6(tiny) | 0.686 | 0.289 |
| PP-OCRv5 mobile | 0.707 | 0.278 |
| PaddleOCR (PP-OCRv4) | 0.630 | 0.172 |
| Windows OCR | 0.609 | 0.185 |
| Tesseract | 0.541 | 0.192 |
In diesem Szenario ist noch niemand wirklich gut. Die Werte fallen durchweg vom Bereich um 0.9 in das Band von 0.2 bis 0.4, und Apple Visions 0.421 ist der beste Wert im Feld. Gety liegt hier knapp vor den Open-Source-Modellen, aber für die alltägliche Suche ist diese Spalte weniger entscheidend, als sie auf den ersten Blick wirkt: Die Dateien, die Sie meistens durchsuchen wollen, sind saubere Screenshots und Scans, keine schiefen Fotos. Dafür steht die linke Spalte.
2. Komplexe Layouts: in derselben Spitzengruppe wie das beste Open-Source-Modell
Sprache ist die eine Achse. Layout ist die andere. Mehrspaltige Seiten, Tabellen, laufende Kopf- und Fußzeilen: Das sind die Dokumente, bei denen ein schwächeres Modell anfängt, Zeilen zu verlieren oder deren Reihenfolge durcheinanderzubringen. OmniDocBench ist genau darauf ausgelegt, das zu belasten:
| Modell | Layout-Genauigkeit (F1) |
|---|---|
| Gety OCR (built-in) | 0.963 |
| PP-OCRv6(small) | 0.968 |
| PP-OCRv6(tiny) | 0.963 |
| Apple Vision (built-in) | 0.948 |
| Windows OCR | 0.855 |
| Tesseract | 0.538 |
Getys 0.963 liegt einen halben Prozentpunkt hinter PP-OCRv6 small (0.968), ein Abstand, den Sie im Einsatz kaum spüren werden. Die beiden Modelle liegen an der Spitze praktisch gleichauf, und beide lassen die eingebauten System-Engines deutlich hinter sich.
3. Dieselbe Genauigkeit, ein Bruchteil des Ressourcenverbrauchs
Gut zu lesen ist das eine. Gut zu lesen und dabei sparsam genug zu bleiben, um den ganzen Tag laufen zu können, ist das andere. Wir haben auf derselben Maschine, mit denselben Eingaben, demselben Thread-Budget und auf der CPU gemessen:
| Modell | Mehrsprachige Genauigkeit (F1) | Medianzeit pro Seite | Spitzenspeicher pro Seite |
|---|---|---|---|
| Gety OCR (built-in) | 0.903 | 862 ms | 908 MB |
| PP-OCRv6(tiny) | 0.686 | 607 ms | 4736 MB |
| PP-OCRv6(small) | 0.724 | 2594 ms | 6304 MB |
Gety braucht rund 908 MB pro Seite. Die tiny- und small-Builds von PP-OCRv6 brauchen 4.7 GB und 6.3 GB, fünf- bis siebenmal mehr. Das ist der Unterschied zwischen einem Modell, das dauerhaft im Speicher bleiben kann, und einem, das eher für Aufgaben gedacht ist, die man bei Bedarf startet. Weil Gety leicht ist, kann die OCR dauerhaft aktiv bleiben, jede neue Datei erfassen, sobald sie eintrifft, und sie indexieren, ohne dass Sie einen Finger rühren.
(Apple Vision und Windows OCR laufen innerhalb ihrer eigenen Plattformen auf anderer Hardware, weshalb ein Speicher- oder Geschwindigkeitsvergleich nicht fair wäre. Sie erscheinen nur in den Genauigkeitstabellen.)
4. Worauf und wogegen wir getestet haben
Die Datensätze
Wir haben die Dokumentbilder aus zwei öffentlichen Datensätzen genommen und darum herum unsere eigene Evaluation aufgebaut. Jeder Datensatz beantwortet eine andere Frage, deshalb berichten wir die Ergebnisse getrennt, statt sie zu einer einzigen Zahl zu vermischen, die wenig aussagen würde:
| Datensatz | Die Frage, die er beantwortet |
|---|---|
| MDPBench | Hält die Genauigkeit über 17 Sprachen hinweg stand, sowohl bei sauberen als auch bei abfotografierten Seiten? |
| OmniDocBench | Bleibt sie genau, wenn das Layout kompliziert wird? |
Um klarzustellen, worum es geht: Wir haben diese Datensätze als Quelle für echte Dokumente verwendet. Die Evaluationsmethode, die Metriken und die Auswahl der Modelle stammen von uns selbst und unterscheiden sich von den offiziellen Auswertungen, die die Autoren der Datensätze veröffentlichen.
Wie wir bewerten
Wir bewerten die OCR-Ausgabe mit einem layout-unabhängigen F1 auf Zeichenebene. Es misst nur, ob der Text korrekt erkannt wurde, nicht das Layout, Zeilenumbrüche, die Absatzstruktur oder wo der Text auf der Seite steht.
Wir halten es layout-unabhängig, weil für die Anwendungen, die zählen (Suche, Kopieren, Indexierung), entscheidend ist, ob jedes Zeichen korrekt gelesen wurde, und nicht, ob das Layout rekonstruiert wurde. Text, der vollständig korrekt ist, aber in anderer Reihenfolge oder mit anderen Zeilenumbrüchen vorliegt, sollte nicht bestraft werden. Dies ist ein OCR-Test, kein Layout-Test.
Für jede Seite vergleichen wir die OCR-Ausgabe mit dem von Hand annotierten Text und berechnen:
Vor der Bewertung durchlaufen sowohl der Referenztext als auch die OCR-Ausgabe dieselbe Normalisierung: Unicode-Normalisierung, Entfernen unsichtbarer Zeichen, Vereinheitlichen von Leerraum und Entfernen von Seitenbestandteilen wie Kopfzeilen, Fußzeilen und Seitenzahlen.
Der Zeichenabgleich verwendet Multiset-Zählung: Ein Zeichen, das mehrfach vorkommt, wird jedes Mal gezählt. Dadurch beeinflussen Unterschiede in Lesereihenfolge, Zeilenumbrüchen und Absatztrennungen den Wert nicht, sodass die Metrik darauf fokussiert bleibt, ob die OCR die Zeichen der Seite korrekt gelesen hat.
Die Endwerte sind F1 pro Seite, makro-gemittelt über Sprachen und Datengruppen; der vollständige Bericht gibt zudem ein bootstrap 95%-Konfidenzintervall an.
Womit wir verglichen haben
Als Vergleichsfeld haben wir die wichtigsten Optionen gewählt, denen Nutzer in realen Arbeitsabläufen wahrscheinlich begegnen:
- PaddleOCR (PP-OCRv6), das Beste, was Open Source zu bieten hat. Es kommt in tiny, small und medium; wir haben die beiden On-Device-Builds, tiny und small, getestet. Medium ist ein Modell mit 34.5M Parametern für Server-GPUs, und es in einen On-Device-CPU-Test zu werfen, hieße, die falschen Dinge zu vergleichen.
- Tesseract, das alte Arbeitstier, überall standardmäßig vorhanden, die Baseline, die die meisten kennen.
- Apple Vision und Windows OCR, die OCR, die Sie schon haben, wenn Sie gar nichts installieren.
5. Genauigkeit ist die Grundlage. Nutzbarkeit ist der eigentliche Punkt.
Die Zahlen sagen, dass Gety genau liest. Doch Genauigkeit ist nur der Eintrittspreis, nicht der Grund, warum das alles zählt.
Denken Sie daran, wie Sie ein normales OCR-Tool benutzen:
Bild finden -> In einem OCR-Tool öffnen oder hineinziehen -> Erkennung manuell starten -> Auf das Ergebnis warten -> Nutzbaren Text erhaltenSie müssen also zuerst bemerken, dass es Text gibt, der es wert ist, herausgeholt zu werden, dann die Datei finden, sie in ein anderes Tool bringen, die Erkennung starten, warten und das Ergebnis weiterverwenden. Fast immer beginnt diese Kette nie. Der Scan, der Screenshot, der abfotografierte Vertrag liegen einfach da, vom Tag ihrer Ankunft an, für die Suche dauerhaft unsichtbar.
Genau diese Lücke ist das ganze Problem, das Gety schließen wollte. Die OCR läuft im Hintergrund, sodass eine Datei in dem Moment, in dem sie eintrifft, automatisch gelesen und indexiert wird. Nichts zu konvertieren, nichts anzuklicken. Sie tippen ins Suchfeld, und der Text im Bild ist einfach da.
Genauigkeit entscheidet also, ob etwas gefunden werden kann; das stille Laufen im Hintergrund entscheidet, ob es je gefunden wird. Wir wollten nicht einfach noch eine weitere OCR-Engine veröffentlichen. Wir wollten dafür sorgen, dass „die Wörter in diesem Bild sind nicht durchsuchbar“ auf Ihrem Computer nicht mehr vorkommt.
Dies sind unsere eigenen internen Ergebnisse. Wir haben die Dokumentbilder aus den öffentlichen Datensätzen MDPBench und OmniDocBench als Testmaterial verwendet, aber die Evaluationsmethode und die Metriken stammen von uns selbst und unterscheiden sich von den offiziellen Evaluationen, die die Autoren der Datensätze veröffentlichen. Jeder Datensatz unterliegt eigenen Lizenz- und Nutzungsbedingungen, einige nur für Forschungszwecke; wir berichten hier über Ergebnisse und verteilen keine Datensätze weiter.