JXL naar TXT omzetten

Elk ander paar op deze site neemt een bestand en schrijft hetzelfde bestand in een andere vorm. Dit doet iets wezenlijk anders: het kijkt naar een afbeelding en schrijft op wat het denkt dat de afbeelding zegt. Er is geen afbeelding van een JPEG XL naar een tekstbestand, want een tekstbestand kan geen beeld bevatten en een beeld bevat geen tekens — alleen vormen die op tekens lijken.

Daarom heet de uitvoer een gok in plaats van een resultaat. Een converter werkt of geeft een fout; een herkenner geeft tekst terug die op tekst lijkt, of die nu klopt of niet. Alles hieronder gaat over het verkleinen van dat gat, en de nuttigste gewoonte is de uitvoer naast het origineel te lezen voordat je erop vertrouwt.

JPEG XL verloor de browserstrijd, maar niet overal, en de plekken waar het overleefde zijn precies de plekken waar documenten leven. De registry noemt archivering en fotografie als toepassingen, en archivering is de eerlijke reden: digitaliseringsprojecten kozen ervoor omdat het verliesvrij goed doet, hoge bitdieptes aankan, en een gescande pagina in minder bytes opslaat dan iets van PNG’s generatie.

De andere gangbare route is Apple. Safari ondersteunt JPEG XL sinds versie 17, dus een bestand dat vanaf het web op een Mac of iPhone wordt bewaard, kan als .jxl aankomen zonder dat iemand ervoor koos. In beide gevallen koos degene die hier terechtkomt niet zelf het formaat — hij kreeg een pagina met woorden verpakt in een beeldformaat en wil de woorden.

Elk ander beeldpad op deze site decodeert het bestand eerst naar pixels. Dit doet dat niet: het bestand gaat als het is naar de herkenningsengine, omdat die engine zijn eigen loader heeft, en het beeld door een canvas duwen zou transparantie afvlakken tot zwart — wat op een scan van wit papier het verschil is tussen leesbaar en onleesbaar.

Het gevolg is dat je browser hier helemaal geen rol in speelt. Het bestand wordt gelezen tot ruwe bytes en rechtstreeks doorgegeven aan de herkenner, dus de enige decoders die erop kunnen werken zijn de zes die in de herkenningsengine zijn ingebouwd: BMP, JPEG, PNG, PBM, WebP en niet-geanimeerde GIF. JPEG XL is daar geen van, en nergens in de WebAssembly-kern die deze site levert bestaat een JPEG XL-decoder.

Deze pagina zei ooit dat het lezen van een JXL afhing van de browser, met Safari als de browser waar het zou werken. Dat was onjuist, en het is beter dat rechtstreeks te corrigeren dan stilzwijgend: Safari toont JPEG XL sinds versie 17, maar de herkenner vraagt de browser nooit om iets te tonen, dus Safari faalt hier precies zoals Chrome dat doet. Niets wat je in je browser verandert, laat de eenstapsversie werken.

Wat wel werkt, is één extra omzetting. Zet de JXL hier eerst om naar PNG, en lees dan de tekst uit die PNG. Die eerste stap heeft zijn eigen naar WebAssembly gecompileerde JPEG XL-decoder in plaats van de browser om er een te vragen, dus die draait in Chrome hetzelfde als in Safari. PNG is het juiste tussenformaat: het is verliesvrij, dus elke lijn die de herkenner nodig heeft blijft behouden, waar JPEG de letters opnieuw zou comprimeren zonder enig voordeel. De PNG is een tussenstap — verwijder hem zodra je de tekst hebt.

Engels, Duits, Frans en Spaans hebben modellen beschikbaar, en de instelling is in de praktijk niet vrijblijvend. De herkenner vergelijkt vormen met de letters en de woordenschat van één taal tegelijk, dus een Franse pagina gelezen als Engels geeft geen foutmelding — het geeft vloeiend ogende onzin, omdat elke vorm werd gekoppeld aan het dichtstbijzijnde ding in het verkeerde woordenboek.

Het maakt het meeste uit bij tekens met accenten en bij gemengde inhoud. Een Duits document met Engelse vaktermen erin leest beter met Duits geselecteerd dan met beide geraden, omdat het model net zo goed tussen kandidaat-woorden kiest als tussen kandidaat-letters. Stel de taal in vóór je omzet; achteraf is aan de uitvoer alleen niet te zien dat het fout stond.

Herkenning heeft genoeg pixels per teken nodig, en dat is de variabele die het verschil maakt tussen een bijna perfect resultaat en een onbruikbaar resultaat. Een pagina gescand op 300 dpi heeft ruim voldoende. Een foto van een pagina vanaf de andere kant van een bureau, een screenshot verkleind om in een document te passen, of een afbeelding die een chat-app onderweg opnieuw comprimeerde, mogelijk niet.

De afbeelding achteraf vergroten helpt niet. Opschalen voegt pixels toe zonder informatie toe te voegen en maakt het resultaat meestal slechter door de letters te verzachten die de herkenner probeert te matchen. Als een resultaat matig terugkomt, ligt de oplossing stroomopwaarts: opnieuw scannen op hogere resolutie, de pagina van dichterbij en recht fotograferen, of het origineel zoeken in plaats van de kopie die is doorgestuurd. Hoek is de andere helft van hetzelfde probleem — een pagina schuin van boven gefotografeerd geeft elke regel een lichte kromming en elk teken een lichte scheefstand, en de herkenner heeft geen model van perspectief om dat ongedaan te maken.

Een tekstbestand heeft geen kolommen, geen cellen, geen lettertype en geen positie. Wat je krijgt zijn de tekens die de herkenner vond, in de volgorde waarin hij ze las, en dat is een echt verlies van structuur, geen opmaakvoorkeur. Een tabel komt terug als een reeks waarden zonder de kolommen, en een pagina met twee kolommen kan door elkaar lopen.

De regeleinden blijven precies zoals ze werden gezien, zonder poging om afgebroken regels samen te voegen of lege regels weg te halen. Dat oogt slordig en is bewust: een gedicht, een adresblok en een tabel verliezen alle drie betekenis als hun regeleinden worden opgeschoond, en een converter kan niet weten welke van de drie hij bekijkt.

De typerende mislukking is geen brij die je meteen opvalt. Het is een enkele plausibele verwisseling in een getal of naam — een 5 gelezen als een S, een 1 als een kleine letter l, een nul als een hoofdletter O — midden in een alinea die verder perfect is. Referentienummers, rekeningnummers, data en prijzen zijn waar dit echte schade aanricht, omdat ze precies de tekenreeksen zijn zonder context om zichzelf te corrigeren.

De praktische regel is dus alles na te lezen waarop gehandeld gaat worden, in plaats van wat alleen gelezen wordt. Een teruggewonnen alinea doorlopen op betekenis vangt de duidelijke fouten; een rekeningnummer teken voor teken controleren is het enige dat de gevaarlijke fout vangt. Code en opdrachtregels dragen hetzelfde risico scherper, omdat de tekens die daar het meest tellen precies de tekens zijn die op elkaar lijken.

Tekstherkenning is met afstand het traagste onderdeel hier. De eerste omzetting moet ook eerst de WebAssembly-kern en het taalmodel ophalen voordat hij kan beginnen, dus de eerste run voelt aanzienlijk trager dan de volgende — het model blijft geladen voor de rest van de sessie.

De voortgangsbalk volgt bewust alleen de herkenning zelf, niet het downloaden en initialiseren, omdat een balk die volloopt terwijl er nog niets gelezen is en dan stilstaat erger is dan een balk die laat begint maar wel iets betekent. Eén pagina duurt seconden. Een map ervan duurt seconden per stuk, na elkaar, op je eigen processor.

De herkenningsengine, de WebAssembly-kern en alle vier de taalmodellen worden vanaf de eigen oorsprong van deze site geleverd. Dat was werk, geen standaardgedrag: de bibliotheek haalt alle drie standaard van een publiek CDN, tenzij elk pad is overschreven, wat drie verzoeken naar een externe partij zou betekenen met je adres en de URL van de pagina waarop je zit.

De afbeelding zelf zou sowieso nooit zijn verstuurd, maar iemand die een loonstrook leest, hoeft niet aan een contentnetwerk gemeld te worden dat hij dat doet. Er is een test in de codebase die faalt zodra een CDN-URL terugkeert, omdat een zo handige standaard bij de volgende upgrade terug kan komen.