HEIF in TXT umwandeln

Wer Belege fürs Rechnungswesen aufbewahrt, kennt die Vorgabe der GoBD, digitalisierte Unterlagen lesbar und nachvollziehbar zu archivieren — und in der Praxis heißt das oft: ein Kassenbon oder eine Rechnung wird schnell mit dem iPhone fotografiert, landet als .heif in einem Ordner, und irgendwann soll der Betrag oder die Rechnungsnummer daraus in eine Tabelle. Das Bild allein reicht dafür nicht, das Wort im Bild schon.

Genau diese Lücke füllt die Texterkennung. Sie liest, was auf dem Foto steht, und gibt es als reinen Text zurück — kein Beleg-Layout, keine Spalten, nur die Zeichen. Für eine Zahl aus einer Rechnung ist das oft schon genug, wenn man weiß, dass sie am Ende noch mit dem Original abgeglichen werden muss.

Die Erkennungssoftware bekommt die Datei so, wie sie ist, ohne dass vorher etwas dekodiert — das ist Absicht, weil ein Bild vorab durch eine Bildfläche zu schicken Transparenz zu Schwarz verflachen würde, und bei einem Scan auf weißem Papier ist das der Unterschied zwischen lesbar und unlesbar. Es bedeutet aber auch, dass nur die sechs fest eingebauten Bildleser zum Zug kommen: BMP, JPEG, PNG, PBM, WebP und nicht animiertes GIF. HEIF ist keiner davon, und es gibt im gesamten hier ausgelieferten Erkennungskern keinen HEIF-Leser.

Der Job ist also zweistufig statt einstufig. Zuerst das HEIF hier zu PNG umwandeln, dann den Text aus dem PNG lesen. Der Dekoder, der den ersten Schritt übernimmt, ist eine eigene Software und liest HEIF durchaus — deshalb funktionieren HEIF-zu-PNG und HEIF-zu-JPG auf eigenen Seiten. PNG ist dabei die richtige Wahl als Zwischenschritt: Das Foto ist auf dem Handy schon einmal verlustbehaftet komprimiert worden, und ein zweiter verlustbehafteter Durchgang träfe genau die feinen Linien, an denen sich die Erkennung orientiert.

Jede andere Umwandlung auf dieser Website funktioniert entweder oder schlägt laut fehl. Ein Bild wird zu einem anderen Bild, und wenn der Encoder es nicht schafft, gibt es einen Fehler. Erkennung ist anders: Sie liefert Text, der genauso aussieht wie richtiger Text, egal ob er stimmt.

Das Ergebnis ist also eine Lesung, keine Abschrift, und muss gegen das Original geprüft werden. Das ist keine Fußnote zum Überlesen, sondern die wichtigste Tatsache zu diesem Werkzeug — und sie entscheidet, wofür der Text taugt und wofür nicht.

Vier Modelle stehen zur Verfügung: Englisch, Deutsch, Französisch und Spanisch. Jedes ist ein trainiertes Modell für die Buchstabenformen und den Wortschatz dieser Sprache, und die Erkennung arbeitet strikt innerhalb der gewählten.

Eine falsche Wahl erzeugt keinen Fehler, was diesen Punkt so wichtig macht. Sie liefert die beste Antwort aus einem Vokabular, das die richtige gar nicht enthält — flüssig lesbar, plausibel geformt und falsch. Sieht ein Ergebnis merkwürdig aus, ohne dass sich das erklären lässt, ist die Spracheinstellung der erste Verdacht und meistens auch die Ursache.

Erkennung ist mit Abstand die langsamste Funktion dieser Website, und der meiste Teil der Wartezeit beim ersten Beleg ist nicht das Lesen selbst — es ist das Herunterladen und Kompilieren mehrerer Megabyte WebAssembly und eines Sprachmodells.

Diese Kosten fallen einmal pro Sprache an und bleiben für den Rest der Sitzung erhalten, das Modell wird danach im Browser zwischengespeichert, sodass ein Beleg morgen es nicht erneut herunterlädt. In der Praxis bedeutet das: einen ganzen Ordner mit zwanzig Belegen auf einmal abzulegen, ist pro Beleg deutlich effizienter als einen einzelnen umzuwandeln — also stapelweise arbeiten statt Datei für Datei.

Auflösung ist beim Handyfoto selten das Problem — zwölf Megapixel geben reichlich Pixel pro Zeichen, selbst wenn der Beleg nur einen Teil des Bildausschnitts füllt. Geometrie und Licht sind die eigentlichen Probleme.

Den Beleg flach fotografieren statt gewellt, senkrecht von oben statt schräg von der Seite, und mit seitlichem Licht, damit der eigene Schatten nicht über der Schrift liegt. Diese drei Dinge verändern das Ergebnis mehr als jede Einstellung auf dieser Seite — ein schräg aufgenommener Beleg erzeugt Fehler, die keine Auflösung mehr ausgleicht.

Die Ausgabe ist reiner Text: die Wörter, in Lesereihenfolge, mit Zeilenumbrüchen. Keine Spalten, keine Tabellenzellen, keine Überschriften, keine Positionen auf der Seite — eine Textdatei hat dafür schlicht keinen Platz.

Ein Brief oder eine einfache Quittung übersteht das gut. Ein Beleg mit zwei Spalten verschachtelt sich, weil die Erkennung alles quer liest, was wie eine Zeile aussieht. Eine Tabelle mit Beträgen wird zu einer Zahlenreihe ohne Spalten, und ein Formular bringt Bezeichnung und Wert in einer Nähe, die sich kaum noch entwirren lässt. Für solche Fälle liefert das fotografieren eines einzelnen Abschnitts nach dem anderen ein brauchbareres Ergebnis.

Leerzeilen zwischen Absätzen bleiben, wie sie sind, und Zeilen, die wie ein umgebrochener Satz aussehen, werden nicht zusammengeführt. Das ist Absicht und keine Unfertigkeit: Beide Arten von Glättung sind Vermutungen über das Layout, und eine Adresse oder eine Tabelle verliert dabei genau die Bedeutung, die in den Zeilenumbrüchen steckt.

Die heruntergeladene Datei ist also genau das, was gelesen wurde, und jedes Umformatieren ist eine Entscheidung, die in einem Editor getroffen wird, wo Original und Text nebeneinanderstehen. Das ist die richtige Reihenfolge — ein Konverter, der ungefragt umformatiert, ist deutlich schwerer zu vertrauen als einer, der genau das herausgibt, was er gefunden hat.

Fließtext verzeiht viel. Ein falsch erkannter Buchstabe in einem Satz fällt meist auf, und man liest automatisch darüber hinweg. Zahlen haben diese Redundanz nicht: eine falsche Ziffer in einem Betrag, einer Rechnungsnummer oder einem Datum sieht exakt aus wie eine richtige, und nichts im Satz widerspricht ihr.

Weil die Dokumente, die auf diese Weise fotografiert werden, überwiegend Zahlen enthalten — Beträge, Kontonummern, Rechnungsnummern, Zählerstände —, ist es sinnvoll, den erkannten Text als Entwurf für die Wörter zu behandeln und jede Zahl vor der Weiterverarbeitung mit dem Foto abzugleichen.

Das Foto wird nie hochgeladen. Ebenso wenig — und das war ein gezielter Aufwand — irgendetwas anderes: Die Erkennungsbibliothek lädt Worker-Skript, WebAssembly-Kern und Sprachmodell normalerweise von einem fremden CDN, sofern nicht jeder dieser Pfade überschrieben wird, und hier sind alle drei von dieser Seite selbst ausgeliefert.

Der Unterschied wirkt sich gerade bei Buchhaltungsbelegen aus. Das Foto hätte diese Website ohnehin nie verlassen, aber wer eine Gehaltsabrechnung oder eine Rechnung mit Kundendaten fotografiert, sollte diese Tatsache nicht nebenbei an ein Content-Netzwerk melden — inklusive der Seite, die er gerade ansieht.

Die Textdatei ist eine Ableitung und eine fehlbare dazu, das HEIF bleibt also der eigentliche Beleg. Es ist zudem unersetzlich: Diese Website kann das Format lesen, aber nicht schreiben, weil der nötige Encoder anders lizenziert ist als der Decoder, den eine statische Website ausliefern darf.

Wenn der Beleg wichtig ist, beide behalten — und für die Ablage in der Buchhaltung eignet sich zusätzlich eine Umwandlung des Fotos in PDF, damit ein lesbares Bild neben dem durchsuchbaren Text steht. Genau diese Kombination — ein Bild zum Vorzeigen, Text zum Durchsuchen — ist meistens das eigentliche Ziel.

Die Modelle sind auf Druckschrift trainiert, und Druckschrift lesen sie entsprechend gut: sauber, gerade, angemessen große Zeichen in einer gängigen Schriftart kommen nahezu perfekt zurück. Ungewöhnliche Schriften, sehr kleine Schrift und starke Kursivschrift kosten Genauigkeit, ein blasses Fax oder eine mehrfache Fotokopie kostet noch deutlich mehr.

Handschrift ist dabei kein Gradmesser, sondern eine harte Grenze. Handnotizen, eine Unterschrift oder ein handschriftlich eingetragener Betrag auf einem Beleg liefern Text, der wie Wörter aussieht und nichts davon trifft. Ist der wertvolle Teil des Fotos handgeschrieben, ist das Ehrliche, ihn selbst abzutippen und die Erkennung nur für die gedruckten Teile drumherum zu nutzen — das Formular, den Briefkopf, die Bedingungen auf der Rückseite.