JXL in TXT umwandeln

Jede andere Umwandlung auf dieser Seite nimmt eine Datei und schreibt dasselbe Bild in einer anderen Form. Hier passiert etwas anderes: Ein Bild wird betrachtet, und aufgeschrieben wird, was darin zu erkennen zu sein scheint. Es gibt keine Abbildung von JPEG XL auf Text, weil eine Textdatei kein Bild fassen kann und ein Bild keine Zeichen enthält — nur Formen, die welchen ähneln.

Deshalb heißt das Ergebnis hier bewusst Vermutung und nicht Ergebnis. Eine Umwandlung funktioniert oder meldet einen Fehler; eine Erkennung liefert Text, der wie Text aussieht, egal ob er zur Vorlage passt. Alles Weitere auf dieser Seite dient dazu, den Abstand zwischen beidem zu verkleinern — und die nützlichste Angewohnheit bleibt, das Ergebnis gegen das Original zu lesen, bevor man sich darauf verlässt.

JPEG XL hat den Browserkampf verloren, aber nicht überall. Ausgerechnet dort, wo Dokumente leben, hat es sich gehalten: Digitalisierungsprojekte an deutschen Bibliotheken und Archiven setzen auf das Format, weil es verlustfrei gut komprimiert, hohe Bittiefen erlaubt und eine gescannte Seite in weniger Bytes ablegt als ältere Formate.

Der zweite häufige Weg ist Apple. Safari zeigt JPEG XL seit Version 17 an, sodass eine von einer Webseite gespeicherte Datei auf einem Mac oder iPhone als .jxl landet, ohne dass es jemand bewusst gewählt hätte. In beiden Fällen hat die Person hier nicht das Format ausgesucht — sie hat eine Seite voller Wörter bekommen, verpackt in einem Bildformat, und will die Wörter.

Jeder andere Bildpfad auf dieser Seite dekodiert die Datei zuerst zu Bildpunkten. Dieser nicht: Die Datei geht so, wie sie ist, an die Texterkennung, weil deren eigener Lader benutzt wird und ein Umweg über eine Zeichenfläche im Browser Transparenz zu Schwarz verflachen würde — bei einer gescannten weißen Seite der Unterschied zwischen lesbar und unlesbar.

Die Folge: Der Browser ist hier gar nicht beteiligt. Die Datei wird als Rohbytes gelesen und direkt an die Erkennung gereicht, und die kennt nur sechs Formate: BMP, JPEG, PNG, PBM, WebP und unbewegtes GIF. JPEG XL gehört nicht dazu, und in dem WebAssembly-Kern, den diese Seite ausliefert, steckt kein JPEG-XL-Dekoder.

Wer einfach ein JXL hier ablegt, bekommt nichts zurück. Das liegt nicht am Browser und auch nicht daran, welche Sprache eingestellt ist — es liegt daran, dass keiner der sechs eingebauten Dekoder JPEG XL versteht.

Der Weg, der funktioniert, braucht einen Zwischenschritt: Das JXL zuerst hier zu PNG wandeln, dann aus dem PNG den Text lesen. Dieser erste Schritt bringt seinen eigenen JPEG-XL-Dekoder als WebAssembly mit und fragt den Browser nichts. PNG ist die richtige Zwischenstation, weil es verlustfrei ist — jeder Buchstabenrand bleibt erhalten, während JPEG die Kanten für nichts erneut komprimieren würde. Das PNG ist ein Wegwerfprodukt; sobald der Text da ist, kann es gelöscht werden.

Für Englisch, Deutsch, Französisch und Spanisch gibt es Modelle, und die Wahl ist in der Praxis nicht beliebig. Die Erkennung vergleicht Formen mit den Buchstaben und dem Wortschatz genau einer Sprache — ein deutscher Text, als Englisch gelesen, liefert deshalb keinen Fehler, sondern flüssig aussehenden Unsinn, weil jede Form dem nächstbesten Kandidaten im falschen Wörterbuch zugeordnet wurde.

Das fällt bei Umlauten und ß besonders ins Gewicht, ebenso bei gemischten Texten: Ein deutscher Vertrag mit englischen Fachbegriffen liest sich mit Deutsch eingestellt besser als mit irgendeiner Rätselwahl, weil das Modell zwischen ganzen Wortkandidaten abwägt, nicht nur zwischen Buchstaben. Die Sprache vor dem Umwandeln setzen — danach lässt sich am Ergebnis allein nicht erkennen, dass sie falsch war.

Erkennung braucht genug Bildpunkte je Zeichen, und das ist die Variable, die ein fast perfektes Ergebnis von einem unbrauchbaren trennt. Eine mit 300 dpi gescannte Seite hat davon reichlich. Ein Foto einer Seite vom anderen Ende des Schreibtischs, ein verkleinerter Screenshot oder ein Bild, das ein Messenger auf dem Weg nachkomprimiert hat, oft nicht.

Nachträgliches Vergrößern hilft nicht — es fügt Pixel ohne neue Information hinzu und weicht die Buchstabenformen eher noch auf. Bei einem schwachen Ergebnis liegt die Lösung vorher: schärfer scannen, näher und gerade fotografieren, oder das Original statt einer weitergereichten Kopie suchen. Auch der Winkel zählt: Ein von schräg oben fotografiertes Blatt gibt jeder Zeile eine leichte Krümmung, und dafür hat die Erkennung kein Korrekturmodell.

Eine Textdatei kennt keine Spalten, keine Zellen, keine Schrift und keine Position. Was zurückkommt, sind die gefundenen Zeichen in der Reihenfolge, in der sie gelesen wurden — ein echter Strukturverlust, keine Formatierungsfrage. Eine Tabelle kommt als Aneinanderreihung von Werten ohne Spalten zurück, eine zweispaltige Seite kann sich vermischen, eine Überschrift steht wie jede andere Zeile.

Zeilenumbrüche bleiben genau so, wie die Erkennung sie gesehen hat, ohne dass umgebrochene Zeilen zusammengeführt oder Leerzeilen entfernt würden. Das wirkt unordentlich und ist Absicht: Ein Gedicht, ein Adressblock und eine Tabelle verlieren alle etwas, wenn ihre Umbrüche geglättet werden, und die Erkennung kann nicht wissen, welches der drei sie vor sich hat.

Der typische Fehler ist kein sichtbares Kauderwelsch, das man sofort bemerkt. Es ist eine einzelne plausible Verwechslung mitten in einem sonst tadellosen Absatz — eine 5, die als S gelesen wird, eine 1, die zu einem kleinen l wird, eine Null, die als großes O erscheint. Bei Aktenzeichen, IBANs, Daten und Preisen richtet genau das Schaden an, weil dort kein Kontext existiert, der die Verwechslung korrigieren könnte.

Die praktische Regel lautet deshalb: alles gegenlesen, was verwendet und nicht nur überflogen wird. Für einen Absatz reicht ein schneller Blick auf den Sinn; eine Kontonummer verlangt, jedes Zeichen einzeln zu prüfen. Code-Zeilen tragen dasselbe Risiko in schärferer Form, weil dort gerade die Zeichen entscheiden, die sich ähneln — Eins gegen kleines l gegen Strich, Null gegen großes O.

Texterkennung ist mit deutlichem Abstand das langsamste Werkzeug hier. Die erste Umwandlung lädt außerdem erst noch den WebAssembly-Kern und ein Sprachmodell nach, sodass der erste Durchlauf spürbar länger dauert als jeder folgende — das Modell bleibt für den Rest der Sitzung geladen.

Der Fortschrittsbalken verfolgt bewusst nur die Erkennung selbst, nicht den Download davor, weil ein Balken, der schon voll ist, während noch nichts gelesen wurde, schlimmer ist als einer, der spät startet, dafür aber etwas bedeutet. Eine einzelne Seite dauert Sekunden, ein Ordner voller Seiten dauert dasselbe je Datei, nacheinander, auf dem eigenen Prozessor.

Die Erkennung, ihr WebAssembly-Kern und alle vier Sprachmodelle werden von dieser Seite selbst ausgeliefert. Das war eine bewusste Entscheidung: Die zugrunde liegende Bibliothek lädt sonst alle drei von einem öffentlichen Netzwerk nach, was bei jedem Scan die eigene Adresse und die aufgerufene Seite an einen Dritten verraten hätte.

Das Bild selbst wäre so oder so nirgendwohin gegangen — trotzdem sollte niemand, der eine Gehaltsabrechnung liest, das einem Content-Netzwerk mitteilen müssen. Ein Scan von etwas Privatem wird vollständig auf dem eigenen Gerät verarbeitet, ohne dass danach irgendetwas gelöscht werden müsste.