Convertir ICO en JXL

Un fichier .ico contient plusieurs tailles d’une seule image, le plus souvent 16, 32 et 48 pixels. Notre encodeur lit la plus grande, parce que c’est ce qu’un utilisateur verrait en l’ouvrant directement, et c’est ce bitmap qui devient l’image JXL. Le fichier produit n’est pas multi-tailles, et il n’embarque pas non plus la table de tailles : c’est un JXL simple, à la résolution de la taille lue.

Pour la majorité des icônes système, cette taille lue est 32 pixels. Le JXL produit est donc un fichier minuscule, souvent 2 à 4 Ko, et la compression à 82 ne sert à rien dessus. La conversion a du sens seulement si l’ICO source est lui-même déjà une grande image : une icône d’application Mac, un splash screen, un logo extrait d’un fichier de ressources. Pour les icônes Windows classiques, visez plutôt le PNG encapsulé.

Le contrôle de qualité est partagé par les quatre codecs modernes qui l’acceptent, et notre valeur par défaut est 82, fixée une fois dans le pipeline plutôt que par format. Sur une icône, 82 est très conservateur : à cette qualité, un JXL 256 × 256 tient en 8 à 12 Ko, et la différence avec 95 est invisible sur un visuel qui n’a pas de dégradé. Baisser à 60 économise quelques kilo-octets et commence à baver les contours.

La vraie raison d’utiliser JXL plutôt qu’un autre format est ailleurs : JXL est spécifié pour l’archivage, c’est un codec ISO/IEC 18181, et il est conçu pour rester lisible longtemps. Une icône en JXL dans un système d’archivage interne sera lisible dans dix ans, ce que WebP ne garantit pas. Le navigateur le supporte partiellement, ce qui limite l’usage web direct, mais pour un asset interne, c’est une cible stable.

JXL supporte un canal alpha, et notre encodeur le porte. Une icône avec ses coins arrondis et son ombre portée arrive donc en JXL avec sa transparence, posée sur rien, prête à être intégrée dans une interface qui sait la rendre. C’est la sortie correcte quand vous voulez un asset moderne d’une icône qui a été pensée pour être détourée.

La nuance, c’est que le PNG encapsulé dans l’ICO est lui-même lossless, et JXL est ici en mode lossy. La compression JXL à 82 sur un PNG lossless produit un fichier plus petit, et la décompression redonne les mêmes pixels au sens perceptuel, mais pas au sens binaire. Pour un asset graphique final, c’est sans importance. Pour un asset qui doit subir un round-trip sans dérive, restez en PNG.

JXL est un format jeune, publié en 2021, et les navigateurs l’abordent avec prudence. Chrome le supporte depuis la version 91 derrière un flag, Firefox en nightly, Safari en lecture seulement. Pour un fichier que vous voulez servir directement à un navigateur web, JXL est risqué. Pour un fichier que vous stockez et que vous convertissez à la demande en un format web-friendly, JXL est excellent.

La conséquence pratique est que la conversion ICO en JXL est pertinente dans un pipeline interne, pas dans un envoi. Si vous devez servir l’icône à des visiteurs, restez en PNG ou en WebP. Si vous devez stocker l’icône dans un corpus où vous voulez le meilleur compromis taille/qualité, JXL est une cible. Les deux usages sont valables, et le bon choix dépend du flux en aval.

JXL a un mode animation, et un ICO peut embarquer une animation : la convention est rare, et c’est plutôt un .cur (curseur) qui le fait. Notre pipeline lit l’ICO comme une image fixe, prend la première taille, et la passe au codec. Si l’ICO source avait plusieurs frames, seule la première arrive en sortie, et le JXL est un fichier image simple, pas une animation.

Pour les rares cas où l’ICO source est animé, le bon pipeline est un outil spécialisé qui sait lire l’animation. Notre convertisseur ne le fait pas, et la page affiche le résultat comme si l’ICO était une image fixe, ce qui est le cas pour 99,9 % des fichiers .ico en circulation. Si votre ICO bouge, vous le savez probablement déjà, parce que c’est inhabituel.

L’ICO encapsule un PNG, qui peut porter EXIF, XMP, ICC. Notre pipeline décode en pixels, ré-encode en JXL, et tout ce qui n’est pas pixel disparaît. Le profil colorimétrique est perdu, ce qui pose peu de problème pour un asset graphique destiné à être réinterprété. Les informations d’auteur, de date, de logiciel source sont perdues, ce qui est en général une bonne chose pour un envoi.

La seule métadonnée que JXL pourrait porter : EXIF, XMP, ICC : n’est pas écrite par notre encodeur, parce que le pipeline raster n’accepte que `ImageData` et `{ quality }` comme paramètres. C’est cohérent avec les autres cibles de la même famille, et c’est ce qui fait que le fichier produit est léger et propre. Si vous avez besoin de préserver un profil colorimétrique, c’est le mauvais pipeline.

Un ICO 32 × 32 devient un JXL de 1 à 2 Ko à 82, plus petit qu’un PNG équivalent. Un ICO 256 × 256 d’une icône Mac moderne tient en 8 à 12 Ko, contre 15 à 20 pour le PNG encapsulé. La différence est modeste parce que les icônes sont déjà bien compressées, et le gain réel est ailleurs : dans la pérennité du format et dans la qualité d’archivage.

Pour un logo d’application en 512, la compression JXL à 82 devient intéressante : on tombe à 25-40 Ko, contre 60-80 en PNG. Le ratio se dégrade sur les visuels avec beaucoup de dégradés, parce que JXL encode mieux les aplats. C’est un bon outil pour les logos d’application, pas pour les screenshots.

L’ICO source n’est pas uploadé, le JXL produit n’est jamais transmis : la conversion se fait dans l’onglet, en mémoire, par les encodeurs chargés à la demande. C’est important pour les icônes d’application qui peuvent indiquer une suite logicielle interne, un set d’icônes client, un sigle propriétaire. Aucun fichier ne quitte l’appareil, et l’onglet réseau reste vide pendant la conversion.

Les fichiers jusqu’à 100 Mo sont pris en charge, ce qui est très large pour ce format, et l’ensemble du calcul est client pour cette paire. C’est la seule forme sous laquelle la phrase « privé » signifie quelque chose : aucune requête vers l’extérieur pendant que la conversion tourne, et l’assertion se vérifie dans l’onglet réseau des outils de développement.