Convertir PNG en JXL

JPEG XL définit deux modes de codage : un mode avec perte, comparable à JPEG et WebP, et un mode sans perte qui reconstruit le PNG octet pour octet. Le codec `@jsquash/jxl` utilisé ici appelle le mode avec perte par défaut, et c’est ce qui s’applique sur cette page.

C’est un choix cohérent avec les autres cibles raster de ce site : WebP, AVIF, JXL sont tous écrits à la qualité 82 par défaut, et aucun d’eux n’active son mode lossless. Pour un fichier qui doit être restitué à l’identique, la conversion en JXL n’est pas la bonne réponse, et un outil qui passe réellement le fichier en lossless est ailleurs.

Un PNG encode chaque pixel avec une compression Deflate sans perte. Un JXL à 82 applique une prédiction par contexte, un partitionnement de blocs, et une quantification qui jette les hautes fréquences peu visibles. Pour une photographie, le résultat est typiquement deux à trois fois plus petit que le PNG, à qualité visible comparable.

La compression n’est pas gratuite. Sur un texte, un logo, une capture d’écran avec des arêtes vives, JXL à 82 introduit des artefacts que PNG ne produisait pas. Pour ces contenus, baisser la qualité ne sert à rien : le défaut à conserver est la fidélité des bords, et c’est ce que PNG fait sans débat. La conversion est utile pour les photographies, pas pour les images qui doivent rester nettes à toutes les échelles.

Le PNG source peut porter un profil ICC qui décrit l’espace colorimétrique de l’image. La conversion le retire : la sortie JXL est en sRGB implicite, et tout ce qui interprétait l’ICC en amont reçoit maintenant du sRGB sans le savoir.

Pour un PNG étiqueté sRGB, la perte est nulle : c’est l’espace par défaut de JXL. Pour un PNG étiqueté Adobe RGB, Display P3, ou un espace d’imprimerie, c’est une perte de gamut potentielle : les couleurs hors sRGB sont clippées à la conversion, et il n’y a aucun moyen de les récupérer ensuite. Vérifiez l’étiquette de couleur du PNG avant de convertir un asset qui devait vivre dans un gamut étendu.

Le réencodage reconstruit les pixels et perd tout ce qui voyageait avec eux. L’EXIF qui portait l’appareil, l’objectif, l’exposition, et parfois les coordonnées GPS, est retiré. Le bloc XMP, le bloc IPTC, le profil ICC lui-même, disparaissent avec. C’est la même règle que pour les autres cibles raster du site : décoder en pixels et réencoder en pixels ne porte rien entre les deux.

Pour un envoi ou une vignette, c’est ce qu’il faut. Pour un pipeline qui a besoin de ces informations, le PNG d’origine est l’autorité. Si la conversion fait partie d’un flux qui doit préserver les métadonnées, ce flux n’est pas cette page ; il passe par un outil qui copie le bloc EXIF du PNG vers le JXL après l’opération.

Contrairement à JPEG, JXL supporte un canal alpha. Un PNG avec un canal alpha donne un JXL avec un canal alpha, et la zone transparente reste transparente à la sortie. Le coût en taille est celui du canal supplémentaire, et il est inférieur à ce qu’un PNG équivalent donnerait parce que JXL encode le canal plus efficacement.

Pour un logo, une icône, un asset d’interface qui porte de la transparence, c’est la bonne réponse : la transparence survit et le fichier rétrécit. Pour un JPEG, la question ne se pose pas : JPEG n’a pas d’alpha, et c’est l’une des raisons pour lesquelles PNG existe à côté.

Un ciel uniforme, un mur uni, un dégradé doux : JXL à 82 les rend très bien, sans les bandes que la quantification JPEG introduit à qualité comparable. C’est l’une des raisons pour lesquelles la même valeur 82 paraît meilleure en JXL qu’en JPEG sur les zones plates.

La limite apparaît sur les bords très contrastés : une ligne rouge d’un pixel sur fond blanc est l’endroit où la quantification de fréquence peut laisser une trace légèrement visible. Pour un asset d’interface, un texte en pixel art, un wireframe, c’est plus visible que sur une photographie. PNG gagne sur ce type de contenu précisément parce qu’il ne jette rien.

JPEG XL est plus jeune que WebP et sa pénétration est incomplète. Chrome et Firefox le supportent, Safari le supporte depuis macOS 11 et iOS 14. Les visionneuses d’images système sur Windows ne le lisent pas, les logiciels de retouche historiques non plus, et l’enregistrement en JXL dans les logiciels de retouche grand public reste rare.

Pour un envoi à un destinataire dont la machine est inconnue, JPEG ou WebP sont des paris plus sûrs. Pour un site web, un player qui sait décoder, un pipeline interne qui contrôle ses deux extrémités, JXL est un format viable et sa supériorité technique sur les zones plates est réelle. La conversion est utile dans le second cas et à éviter dans le premier.

Le PNG source peut être en 8 ou 16 bits par canal. La conversion lit en 8 bits et écrit en 8 bits, parce que le pipeline de pixels du site n’a pas de chemin 16 bits. Pour un PNG 16 bits, c’est une perte de profondeur tonale à la lecture : les 256 niveaux de la sortie représentent l’intervalle 0-65535 du source après quantification à 256 valeurs.

Pour une photographie ou une image 8 bits d’origine, c’est sans importance. Pour un asset 16 bits qui doit être ajusté fortement — un master photographique, un scan à graduer, un fichier d’archive avec profondeur tonale — la conversion est destructive. Dans ce cas, garder le PNG, ou exporter un TIFF 16 bits depuis le logiciel d’origine, est la bonne réponse.

Le cas où JXL brille est un pipeline qui doit servir beaucoup d’images, de tailles variées, à des utilisateurs qui regardent et zooment. À qualité visible comparable à JPEG, le fichier est plus petit, le décodage est rapide, et la qualité subjective est meilleure sur les zones plates. Pour un service qui sérialise des images en masse, c’est un format viable.

Pour un site web qui sert des images à des navigateurs inconnus ou à des logiciels qui ne supportent pas JXL, c’est un pari. La décision raisonnable est de servir JXL aux navigateurs qui l’annoncent dans Accept, JPEG ou WebP aux autres, et de garder la source en PNG pour les cas où la fidélité compte.

La conversion tourne dans le navigateur : le PNG est lu, décodé, réencé, et le fichier original n’est jamais transmis. Pour des images sous restriction d’accès, des accords de donateur, des approbations de recherche qui interdisent le transfert, c’est la condition qui rend l’utilisation sûre plutôt qu’à éviter.

C’est vérifiable plutôt que promis. Ouvrez les outils de développement, regardez l’onglet réseau pendant une conversion, ou déconnectez complètement la machine et convertissez quand même. La page continue de fonctionner parce qu’il n’y a jamais rien eu à faire pour le réseau, et c’est l’unique manière dont une telle affirmation peut valoir quelque chose.