Was OCR tatsächlich tut – und was nicht
OCR erkennt Formen und gibt Zeichen zurück. Sie liest nicht. Dahinter steckt kein Verständnis der Wörter, also kommt eine „1“, die für ein „l“ gehalten wurde, genauso sicher zurück wie jedes korrekte Zeichen drumherum. Deshalb zeigen diese Seiten die eigene Zuverlässigkeit der Erkennung neben dem Text an, statt Ihnen ein sauber aussehendes Ergebnis zu geben und Sie die Fehler selbst suchen zu lassen. Bei klarem Drucktext, gerade und scharf fotografiert, liegt die Fehlerquote bei ein paar Zeichen pro tausend. Bei Spiegelungen, einem Schatten oder einer ungewöhnlichen Schrift kann sie sehr viel schlechter sein – und nichts am Ergebnis sieht dann anders aus.
Hinter diesen Seiten stehen zwei Leser. Der eine findet Text, wo immer er auf der Seite steht, ohne zu wissen, in welcher Schrift er geschrieben ist, und liest gut fünfzig Sprachen aus einem einzigen Wörterbuch. Der andere, für jede Sprache einzeln trainiert, steht dahinter und deckt über 120 ab. Bleibt die Sprache auf „Automatisch“, darf der erste Leser es versuchen – wichtig, weil die falsche Sprache anzugeben der klassische Weg ist, nichts zurückzubekommen: Eine polnische Speisekarte, die als Kyrillisch erkannt und als Russisch gelesen wird, liefert eine leere Seite, und zwar mit voller Überzeugung. Geben Sie selbst eine Sprache an, wird die Aufgabe an den Leser dieser Sprache gebunden – genau das, was Sie wollen, wenn Sie wissen, was Sie vor sich haben.
Es kommt auf die Auflösung an, nicht auf die Dateigröße. Der Leser möchte eine bestimmte Buchstabenhöhe, und alles wird so skaliert, dass sie erreicht wird: Seiten eines gescannten PDFs werden zum Lesen mit 300 DPI gerendert, und bei einem Bild wird die Schrift selbst vermessen statt der Bildabmessungen und das Bild dann passend vergrößert oder verkleinert. Bildschirmtext ist der Fall, bei dem man sich irrt – in normaler Größe ist ein Buchstabe etwa zehn Pixel hoch, rund ein Drittel dessen, was der Leser möchte, also wird ein Screenshot vor dem Lesen hochskaliert. Unter etwa acht Pixeln pro Buchstabe bleibt kein Detail mehr zum Vergrößern, und keine Verarbeitung der Welt erfindet es. In der anderen Richtung ist ein 48-Megapixel-Foto einer Speisekarte nicht genauer als ein scharfes kleines; ab einem gewissen Punkt kosten mehr Pixel Zeit und bringen nichts.
Schräglage und ungleichmäßiges Licht richten mehr Schaden an, als man meinen würde. Eine fotografierte Seite ist ein, zwei Grad schief und von einer Seite beleuchtet, also messen Bild in Text und Dokument scannen diesen Winkel über die ganze Seite und gleichen ihn aus, schätzen dann die Helligkeit des Papiers hinter der Tinte stückweise und heben sie auf ein einheitliches Weiß an. Das ist keine Kosmetik. Gerade Linien sind das, was eine Tabelle überhaupt als Raster auffindbar macht, und gleichmäßiger Kontrast verhindert, dass der Schatten Ihrer Hand als Tinte gelesen wird. Ein Screenshot bekommt bewusst keine dieser Behandlungen: Er ist bereits gerade und gleichmäßig beleuchtet, und ihn wie ein Foto aufzubereiten, erzeugt nur Fehler.
Tabellen und mehrspaltige Layouts sind der wirklich schwierige Fall, und die Zahlen lohnen sich. Als Fließtext über die ganze Seite gelesen, lief bei einem Formular mit Linien der Zelltext in die nächste Spalte, und ein Drittel der Beschriftungen fiel weg – fünfzehn bis zwanzig Prozent der Zeichen waren falsch. Zuerst die Linien zu finden und jede Zelle einzeln zu lesen, brachte das auf etwa fünf Prozent. Eine Tabelle mit sichtbaren Linien wird also als Raster erkannt und kommt als tabulatorgetrennte Zeilen zurück, die sich direkt in eine Tabellenkalkulation einfügen lassen, und Textspalten werden in Lesereihenfolge gelesen statt quer über die Seite. Eine Tabelle, die nur mit Abständen gesetzt ist, hat keine Linien, die sich finden ließen, und übersteht das Einfügen eher durch Glück als nach Plan.
Ein durchsuchbares PDF und extrahierter Text sind zwei verschiedene Dinge. PDF-OCR und Dokument scannen lassen das Bild genau so, wie es war, und legen die erkannten Wörter unsichtbar darüber: Die Seite sieht identisch aus, Strg+F findet plötzlich etwas, und Sie können markieren und kopieren. Auf die Seite wird nie etwas gemalt – was auch heißt, dass sich ein Lesefehler in einem Dokument versteckt, das perfekt aussieht. Bild in Text und Text aus Screenshot tun das Gegenteil: Sie erhalten die Zeichen und sonst nichts, ohne Schriftarten, ohne Farben, ohne Fettdruck und ohne das Bild. Ein Vorbehalt zur Textebene, weil er leicht übersehen wird: Sie kann nur Zeichen tragen, die eine mitgelieferte Schrift darstellen kann, chinesische, japanische und koreanische Wörter werden Ihnen also gezählt statt geschrieben, bis eine Schrift dafür ausgeliefert wird.
Wo ein Browser wirklich das falsche Werkzeug ist
Dass das Bild Ihr Gerät nie verlässt, ist das ganze Argument dafür, es hier lesen zu lassen – und es kostet bei schwierigen Dokumenten Genauigkeit. Dieser Kompromiss ist real, und wir sprechen ihn lieber offen aus, als ihn zu verstecken.
Schreibschrift wird nicht erkannt – weder hier noch von irgendeinem allgemeinen OCR-Tool. Das sind Leser für Druckschrift: Sie erkennen Buchstabenformen, und Schreibschrift hat keine getrennten Buchstabenformen, die sich erkennen ließen. Handgeschriebene Druckbuchstaben kommen oft gut genug zurück, um sie zu korrigieren statt neu abzutippen – Blockbuchstaben, ein von Hand ausgefülltes Formular, eine sorgfältig geschriebene Notiz –, und deshalb gibt es Handschrifterkennung, die den Zuverlässigkeitswert direkt neben den Text setzt. Schreibschrift richtig zu lesen erfordert einen Leser, der speziell auf Handschrift trainiert ist, und die guten laufen auf einem Server statt in einem Tab.
Cloud-OCR schlägt das hier bei schwierigen Dokumenten. Google, Amazon und Microsoft betreiben Erkenner, die mit weit mehr Daten trainiert sind, als in einen Browser-Tab passen, und bei einem schlechten Foto, einer dichten mehrspaltigen Seite, einer ungewöhnlichen Schrift oder einem ausgefüllten Formular sind sie spürbar genauer. Das gilt auch für ein kostenpflichtiges Desktop-Programm wie ABBYY FineReader. Wenn Ihnen Genauigkeit bei einem schwierigen Dokument wichtiger ist, als dass das Dokument auf Ihrem Rechner bleibt, nutzen Sie eines davon – das ist der ehrliche Vergleich, und nach diesem Maßstab sollten Sie entscheiden.
Stapelverarbeitung gehört auf die Kommandozeile. Diese Tools lesen ein Dokument, wenn ein Mensch klickt. Zweitausend Scans nach Zeitplan sind eine Aufgabe für ein Desktop-OCR-Tool wie OCRmyPDF, das einem ganzen Ordner voller PDFs mit einem einzigen Befehl eine Textebene hinzufügt – kostenlos, dieselbe Art von Erkennung, nur ohne das Klicken.
Manches wird schlicht nicht gemacht. Die Perspektive wird nicht korrigiert: Eine von der Seite fotografierte Seite behält ihre Trapezform, nur die Drehung wird ausgeglichen – es lohnt sich also, die zusätzliche Sekunde zu investieren und direkt von oben zu fotografieren. Ein starker Knick oder eine Wölbung nahe am Buchrücken bleibt gewölbt. Und es gibt hier keine Kamera – die Code-Leser dekodieren ein Bild, das Sie bereits haben, kein Live-Bild.
Ein praktischer Preis der lokalen Verarbeitung: Leser und Sprachpaket werden beim ersten Einsatz einer Sprache von dieser Website geladen – ein paar Megabyte, die den ersten Durchlauf langsamer machen als die folgenden. Nichts kommt vom CDN eines anderen, und nichts geht zurück.
Die Wahl zwischen ähnlich klingenden Tools
Bild in Text oder Text aus Screenshot? Derselbe Leser, anders vorbereitet, und der Unterschied ist keine Kosmetik. Ein Foto wird begradigt und seine Beleuchtung ausgeglichen; ein Screenshot wird vergrößert und ansonsten in Ruhe gelassen, weil er weder schief noch ungleichmäßig beleuchtet ist und ihn so zu behandeln, als wäre er es, alles verschlechtert. Text aus Screenshot nimmt außerdem Eingefügtes an – Strg+V, oder Cmd+V auf dem Mac, direkt aus der Zwischenablage, ohne vorher etwas auf der Festplatte zu speichern.
Bild in Text oder Dokument scannen? Bild in Text gibt Ihnen die Wörter und verwirft das Bild. Dokument scannen behält das Bild, begradigt es, macht das Papier hinter der Tinte weiß und liefert Ihnen ein PDF, das wie gescannt aussieht – auf Wunsch mit dem Text unsichtbar dahinter. Wenn Sie den Text irgendwo einfügen wollen, das Erste. Wenn Sie jemandem das Dokument schicken wollen, das Zweite.
Dokument scannen oder PDF-OCR? Dokument scannen beginnt mit Fotos und erzeugt ein PDF. PDF-OCR beginnt mit einem bereits vorhandenen PDF und fügt ihm eine Textebene hinzu. Keines von beiden verändert das Aussehen der Seiten. Fotografieren Sie einen Vertrag, wollen Sie das Erste; bekommen Sie einen Scan per E-Mail, das Zweite.
Handschrifterkennung oder Bild in Text? Derselbe Leser, mit abgeschalteter Tabellensuche und mit dem Zuverlässigkeitswert so prominent, wie er es verdient – denn bei Handschrift ist diese Zahl der nützliche Teil des Ergebnisses. Ist die Schrift verbunden, liest sie keine der beiden Seiten, und die Handschrift-Seite sagt das, statt plausiblen Unsinn zu liefern.
QR-Code lesen oder Barcode lesen? Quadratische Codes gegen gestreifte – und es lohnt sich zu wissen, welchen Sie vor sich haben. Die QR-Seite liest QR, Micro QR, Data Matrix, Aztec und PDF417 – das deckt Bordkarten und Führerscheine ab, deren Codes zum quadratischen Typ gehören, auch wenn sie wie ein verschmierter Punkthaufen aussehen. Die Barcode-Seite liest die gestreiften Formate aus Handel und Logistik – EAN, UPC, Code 128, Code 39, ITF – und prüft die Prüfziffer, die letzte, aus den übrigen berechnete Ziffer; sie macht den Unterschied zwischen einer Nummer, der Sie trauen können, und einer, die nur richtig aussieht. Keines von beiden ist OCR: Ein Code ist ein Symbol mit bekannter Geometrie, ihn zu dekodieren ist also Rechnen und kein Raten von Buchstabenformen. Sie scheitern auch unterschiedlich. Quadratische Codes haben eine Fehlerkorrektur und überstehen einen Kratzer oder ein Logo mitten darauf; gestreifte haben gar keine, eine Spiegelung quer über die Balken bedeutet also kein Ergebnis statt einer falschen Nummer.