Wie funktioniert OCR im Browser? WebAssembly und lokale Verarbeitung erklärt

Browser waren lange Zeit auf das Ausführen von JavaScript beschränkt, einer Sprache, die für interaktive Webseiten entwickelt wurde, nicht für rechenintensive Aufgaben wie Bildverarbeitung. Das hat sich mit WebAssembly grundlegend geändert.

Was WebAssembly ermöglicht

WebAssembly (kurz: Wasm) ist ein binäres Instruktionsformat, das direkt im Browser ausgeführt werden kann. Es ist nicht JavaScript, sondern ein kompiliertes Format, das wesentlich näher an Maschinencode liegt. Entwickler können Code in Sprachen wie C, C++ oder Rust schreiben und ihn nach WebAssembly kompilieren. Der Browser führt diesen Code dann mit nahezu nativer Geschwindigkeit aus.

Das ist die technische Grundlage für browserbasierte OCR. Die eigentliche OCR-Engine, zum Beispiel Tesseract, ist in C++ geschrieben und wurde nach WebAssembly kompiliert. Beim Aufruf des Tools lädt der Browser diese kompilierte Engine und führt sie lokal aus, genau wie eine installierte Desktop-Anwendung, nur eben innerhalb des Browser-Sandkastens.

Tesseract und Tesseract.js

Tesseract ist die bekannteste Open-Source-OCR-Engine. Sie wurde ursprünglich von HP entwickelt, später von Google übernommen und seit 2006 als Open Source veröffentlicht. Heute wird sie von der Entwicklercommunity aktiv weiterentwickelt.

Tesseract.js ist die WebAssembly-Portierung von Tesseract. Sie stellt dieselbe Engine über eine JavaScript-Schnittstelle bereit und läuft vollständig im Browser. Unter der Haube passiert folgendes:

1. Der Browser lädt die Tesseract-Engine als Wasm-Datei (mehrere Megabyte).
2. Die Engine wird im Arbeitsspeicher des Browsers initialisiert.
3. Das Bild des Nutzers wird aus dem DOM gelesen und als Rohdaten an die Engine übergeben.
4. Die Engine verarbeitet das Bild und gibt den erkannten Text zurück.
5. Der Text wird im Browser angezeigt oder zum Download bereitgestellt.

Der entscheidende Punkt: Schritt 2 bis 5 laufen ausschließlich im Arbeitsspeicher des lokalen Geräts. Keine Netzwerkanfrage, keine Serverinteraktion.

Sprachmodelle und Trainingsdaten

OCR funktioniert nicht nur auf Basis von Bildverarbeitung, sondern nutzt auch Sprachmodelle. Tesseract kennt für jede unterstützte Sprache Trainingsdaten, die statistische Wahrscheinlichkeiten von Buchstabenfolgen enthalten. Wenn die Engine ein Zeichen erkennt, das zwischen “rn” und “m” aussehen könnte, hilft das Sprachmodell bei der Entscheidung.

Diese Trainingsdaten werden beim ersten Einsatz einer Sprache nachgeladen und können dann im Browser-Cache gespeichert bleiben. Für Deutsch sind das je nach Modellgröße zwischen einigen Hundert Kilobyte und mehreren Megabyte. Das Tool zeigt in der Regel an, wenn Sprachdaten geladen werden, und funktioniert danach offline ohne erneuten Download.

Bildvorverarbeitung im Browser

Bevor die OCR-Engine das Bild analysiert, helfen Vorverarbeitungsschritte bei der Verbesserung der Erkennungsrate. Diese Schritte laufen ebenfalls lokal:

Graustufenkonvertierung reduziert die Datenmenge und macht Kontrastkanten schärfer sichtbar. Die meisten OCR-Engines arbeiten mit Graustufenbildern effizienter als mit Farbbildern.

Binarisierung wandelt das Graustufenbild in ein Schwarz-Weiß-Bild um, bei dem jeder Pixel entweder schwarz (Text) oder weiß (Hintergrund) ist. Algorithmen wie Otsus Methode oder Sauvola-Binarisierung bestimmen dabei den optimalen Schwellwert.

Deskewing erkennt und korrigiert leichte Schräglage im Dokument. Eine Seite, die um wenige Grad geneigt fotografiert wurde, wird rechnerisch begradigt, bevor die Texterkennung beginnt.

Grenzen der Browser-Umgebung

Trotz WebAssembly gibt es Einschränkungen. Browser haben Speichergrenzen, die je nach Gerät und Browser unterschiedlich sind. Sehr große Bilder oder Dokumente mit vielen Seiten können zu Speicherproblemen führen. Desktop-Software kann in solchen Fällen effizienter arbeiten, weil sie direkt auf mehr Systemspeicher zugreifen kann.

Parallelverarbeitung ist im Browser ebenfalls begrenzt. Über Web Workers lassen sich zwar mehrere Prozesse parallel starten, aber die Koordination ist komplexer als bei nativen Threads. Das Tool verarbeitet Dokumente deshalb sequenziell, was bei einzelnen Seiten kein Problem ist, bei Stapeln von zwanzig Seiten aber spürbar länger dauert.

Sicherheit durch Sandboxing

Der Browser-Sandkasten, der das Ausführen von WebAssembly auf Systemressourcen beschränkt, ist gleichzeitig ein Sicherheitsvorteil. WebAssembly-Code kann nicht auf das Dateisystem, Netzwerk oder andere Systemressourcen zugreifen, ohne explizite Erlaubnis. Das schützt Nutzer vor bösartigem Code, der in WebAssembly verpackt sein könnte.

Für ein OCR-Tool bedeutet das: Die Engine kann nichts anderes tun, als das ihr übergebene Bild zu verarbeiten und Text zurückzugeben. Kein stiller Upload, kein Zugriff auf andere Dateien.

Fazit

WebAssembly hat browserbasierte OCR von einer Notlösung zu einer vollwertigen Alternative gemacht. Das Tool nutzt diese Technologie, um Texterkennung direkt auf dem Gerät des Nutzers durchzuführen, ohne Kompromisse bei Datenschutz oder Genauigkeit einzugehen. Die technischen Grundlagen sind ausgereift und werden von allen modernen Browsern unterstützt.