Convertir JXL en TXT

Toute autre paire de ce site prend un fichier et en écrit le contenu sous une autre forme. Celle-ci fait quelque chose de catégoriquement différent : elle regarde une image et écrit ce qu’elle pense y voir. Il n’existe pas de correspondance entre un JPEG XL et un fichier texte, parce qu’un fichier texte ne peut pas contenir d’image et qu’une image ne contient pas de caractères — seulement des formes qui leur ressemblent.

C’est pourquoi le résultat est affiché comme une estimation et non comme une vérité. Une conversion fonctionne ou renvoie une erreur ; un reconnaisseur rend du texte qui ressemble à du texte, qu’il corresponde ou non à la page. Tout ce qui suit consiste à réduire l’écart entre les deux, et la seule habitude qui compte vraiment est de relire la sortie contre l’original avant de s’en servir.

JPEG XL a perdu la bataille des navigateurs, mais pas partout, et les endroits où il a survécu sont précisément ceux où vivent les documents. Le registre le range dans les usages d’archivage et de photographie, et l’archivage est l’usage honnête : des projets de numérisation l’ont choisi parce qu’il compresse très bien sans perte, accepte des profondeurs de bits élevées, et range une page scannée en moins d’octets que tout ce que la génération PNG proposait.

L’autre voie courante passe par Apple. Safari prend en charge JPEG XL depuis la version 17, si bien qu’un fichier enregistré depuis le web sur un Mac ou un iPhone peut atterrir en .jxl sans que personne l’ait choisi. Dans les deux cas, la personne qui arrive ici n’a pas choisi le format — elle a reçu une page de mots enveloppée dans un format d’image, et elle veut les mots.

Tous les autres chemins d’image sur ce site décode le fichier en pixels d’abord. Pas celui-ci : le fichier va au moteur de reconnaissance tel qu’il est, parce que ce moteur a son propre chargeur et qu’un passage forcé par un canvas aplatirait la transparence en noir — sur une page scannée sur papier blanc, c’est la différence entre lisible et illisible.

La conséquence, c’est que votre navigateur n’intervient pas du tout. Le fichier est lu en octets bruts et transmis directement au reconnaisseur, et les seuls décodeurs qui peuvent le lire sont les six compilés dans le moteur : BMP, JPEG, PNG, PBM, WebP et GIF non animé. JPEG XL n’en fait pas partie, et il n’existe aucun décodeur JPEG XL nulle part dans le cœur WebAssembly que ce site sert.

Cette page disait autrefois que lire un JXL dépendait du navigateur, et nommait Safari comme le cas où cela marchait. C’est faux, et cela vaut la peine d’être corrigé franchement plutôt qu’en silence : Safari affiche bien JPEG XL depuis la version 17, mais le reconnaisseur ne demande jamais au navigateur d’afficher quoi que ce soit, donc Safari échoue ici exactement comme Chrome. Rien de ce que vous pouvez changer dans votre navigateur ne fera fonctionner la version en une étape.

Ce qui fonctionne, c’est une conversion de plus. Passez le JXL en PNG sur ce site, puis lisez le texte du PNG. Cette première étape apporte son propre décodeur JPEG XL compilé en WebAssembly et ne demande rien au navigateur, donc elle tourne pareil dans Chrome et dans Safari — et c’est l’inverse de ce que l’ancienne formulation laissait entendre. Le PNG est le bon format intermédiaire : il est sans perte, donc chaque trait dont le reconnaisseur a besoin survit, alors qu’un JPEG recomprimerait les contours pour rien. Le PNG est un fichier de travail — supprimez-le une fois le texte récupéré.

L’anglais, l’allemand, le français et l’espagnol ont un modèle disponible, et le choix n’est pas anecdotique. Le reconnaisseur compare des formes aux glyphes et au vocabulaire d’une seule langue à la fois, si bien qu’une page française lue comme de l’anglais ne produit pas d’erreur — elle produit un texte d’allure fluide et complètement faux, parce que chaque forme a été rapprochée du candidat le plus proche dans le mauvais dictionnaire.

Cela compte surtout pour les lettres accentuées et les contenus mêlés. Un texte français avec des anglicismes techniques passe mieux en français qu’en devinette, parce que le modèle arbitre entre mots candidats autant qu’entre lettres candidates. Choisissez la langue avant la conversion ; après coup, rien dans le résultat ne permet de dire qu’elle était mal réglée.

La reconnaissance a besoin d’assez de pixels par caractère, et c’est la variable qui sépare un résultat presque parfait d’un résultat inutilisable. Une page scannée à 300 dpi en a largement assez. Une photo de page prise depuis l’autre bout du bureau, une capture d’écran rétrécie pour tenir dans un document, ou une image qu’une messagerie a recompressée au passage peut ne pas en avoir.

Agrandir l’image après coup n’aide pas. Le redimensionnement ajoute des pixels sans ajouter d’information et a plutôt tendance à adoucir les contours que le reconnaisseur essaie de faire correspondre. Quand un résultat revient mauvais, la correction est en amont : rescanner à plus haute résolution, photographier la page de plus près et bien droit, ou retrouver le fichier original plutôt que la copie qui a circulé. L’angle est l’autre moitié du même problème — une page prise en biais et de haut donne à chaque ligne une légère courbure et à chaque caractère un léger cisaillement, et le reconnaisseur n’a aucun modèle de perspective pour le corriger. À plat sur la table, appareil parallèle à la page, vaut mieux que n’importe quel réglage de ce formulaire.

Un fichier texte n’a ni colonnes, ni cellules, ni police, ni position. Ce que vous obtenez, ce sont les caractères trouvés, dans l’ordre où ils ont été lus, et c’est une perte de structure véritable plutôt qu’un choix de mise en forme. Un tableau revient comme une suite de valeurs sans ses colonnes, une page sur deux colonnes peut entremêler ses lignes, et un titre arrive comme une ligne ordinaire parmi les autres.

Les sauts de ligne sont conservés tels que le reconnaisseur les a vus, sans tentative de rejoindre les lignes coupées ni de supprimer les lignes vides. Cela paraît négligé et c’est voulu : un poème, un bloc d’adresse et un tableau perdent tous leur sens quand on redresse leurs sauts de ligne, et le convertisseur n’a aucun moyen de savoir lequel des trois il a sous les yeux. Ce que le reconnaisseur a vu, c’est ce que vous obtenez.

L’échec caractéristique n’est pas un charabia visible, qu’on remarquerait. C’est une substitution plausible isolée, dans un numéro ou un nom — un 5 lu comme un S, un 1 devenu un l minuscule, un zéro pris pour un O majuscule — au milieu d’un paragraphe par ailleurs parfait. Les numéros de référence, les identifiants, les dates et les prix sont là que cette erreur fait le plus de dégâts, parce que ce sont précisément les chaînes sans contexte qui permettrait de les corriger.

La règle qui marche est donc de relire tout ce qui va servir plutôt qu’être lu en diagonale. Parcourir un paragraphe pour le sens attrape les fautes visibles ; vérifier un RIB caractère par caractère est la seule chose qui attrape la faute dangereuse. Une ligne de code ou de commande porte le même risque en plus net, parce que les caractères qui comptent le plus là sont ceux qui se ressemblent — le chiffre 1 contre le l minuscule contre le pipe, le zéro contre le O majuscule — et une mauvaise lecture produit quelque chose qui a l’air correct et ne s’exécute pas. Le reconnaisseur n’a pas de notion de confiance à rendre, et cette limite appartient à cette page plutôt qu’à une note de bas de page.

La reconnaissance de texte est, de loin, le moteur le plus lent d’ici. La première conversion doit aussi télécharger le cœur WebAssembly et le modèle de langue avant de commencer, si bien que la première exécution paraît nettement plus longue que les suivantes — le modèle reste chargé pour le reste de la session.

La barre de progression suit volontairement la reconnaissance seule, pas le téléchargement ni l’initialisation, parce qu’une barre qui se remplit à fond alors que rien n’a encore été lu, puis qui reste immobile, est pire qu’une barre qui démarre tard et signifie quelque chose. Une page unique prend quelques secondes. Un dossier en prend autant par fichier, à la suite, sur votre propre processeur.

Le moteur de reconnaissance, son cœur WebAssembly et les quatre modèles de langue sont tous servis depuis ce site. C’est un choix plutôt qu’un défaut : la bibliothèque sous-jacante va chercher les trois sur un réseau public sinon, ce qui aurait fait, à chaque scan, une requête portant votre adresse et l’adresse de la page consultée vers un tiers.

L’image elle-même ne serait pas partie de toute façon — mais quelqu’un qui lit un bulletin de paie ne devrait pas avoir à annoncer ce fait à un réseau de diffusion. Un scan de quelque chose de privé est traité entièrement sur votre propre machine, sans rien à supprimer ensuite.