Convertir JXL en ICO

Un fichier .ico n’est pas une image, c’est un répertoire de tailles d’une seule image. Notre convertisseur prend le JXL source, le décode, et le ré-encode en plusieurs tailles d’ICO, par défaut 16, 32 et 48 pixels. Le fichier produit est un véritable ICO multi-tailles, lisible par Windows et macOS comme icône d’application. Pour un asset destiné à un logiciel, c’est la cible.

Le format ICO est ancien (1985), et il reste en usage parce que Windows et macOS le lisent nativement. Pour un site web moderne, le favicon est plutôt un PNG 32 ou un SVG, et l’ICO est tombé en désuétude. Pour un installateur de logiciel, un exécutable, un raccourci, c’est encore la cible. Notre pipeline produit un ICO conforme, avec une table d’icônes correctement déclarée.

Notre encodeur ICO a un cap dur de 256 pixels, appliqué au plus grand côté de l’image. Un JXL 512 est donc ramené à 256 (avec la même proportion, letterboxé). Un JXL 1024 est aussi ramené à 256. Un JXL 128, lui, est conservé à 128. Le code source est explicite sur ce point, et le commentaire qui justifie le cap est sans détour : « un ICO est un format d’icône, pas de visuel de fiche produit ».

Pour un asset qui doit être affiché en grand, c’est une limite. Pour une icône d’application, c’est conforme à l’usage. Si la chaîne en aval exige une icône 512, il faut un outil qui sort du pipeline standard. Le cap est documenté, et c’est explicite dans le code source, et c’est la raison pour laquelle un JXL de grande taille perd en définition après conversion.

Quand une image n’est pas carrée, notre encodeur la letterboxe plutôt que de l’étirer. Un JXL 16/9 devient un ICO avec des bandes vides en haut et en bas, à la taille carrée demandée. Le mécanisme est explicite dans le code source. `square()` calcule `Math.min(edge/width, edge/height)` et centre. Pour un logo qui doit apparaître centré, c’est ce qu’il faut. Pour un visuel qui doit remplir toute la zone, c’est un défaut.

Pour les images qui doivent apparaître étirées (un fond d’icône qui doit couvrir la zone), le pipeline ne le fait pas. Le letterboxing est le comportement par défaut et documenté. Pour un asset d’interface qui doit avoir un fond coloré plein, il faut aplatir la transparence sur un fond avant la conversion, et c’est explicite dans la liste des options offertes pour les sources avec alpha.

Si la source JXL est plus petite que la taille ICO demandée, le pipeline agrandit l’image, et c’est explicite dans le code source. Le commentaire qui le dit est sans détour : « la première version de ce commentaire prétendait le contraire, et onze pages l’ont répété ». Le pipeline n’invente pas de pixels, mais il les interpole par un redimensionnement bilinéaire. Le résultat est une icône floue, pas une icône nette.

Pour un JXL 16, demander un ICO 32 donne un ICO 32 visuellement flou. Pour un JXL 8, demander un ICO 48 donne un ICO 48 très flou. C’est explicite, et c’est la raison pour laquelle un asset graphique destiné à être icônifié doit être conçu dès le départ à la taille de sortie. Le pipeline fait ce qu’on lui dit, et c’est à l’utilisateur de demander la bonne taille.

L’ICO supporte un canal alpha, et notre encodeur le porte. Le PNG encapsulé dans l’ICO peut avoir de la transparence, et c’est conservé. Un JXL avec un canal alpha arrive en ICO avec sa transparence, prêt à être posé sur le thème de l’interface. C’est conforme à l’usage moderne des icônes d’application, et c’est explicite dans le code source.

Pour un logo d’entreprise qui doit apparaître détouré sur un fond Windows ou macOS, c’est la sortie correcte. Pour un asset qui doit apparaître sur un fond uni, aplatir la transparence sur ce fond avant la conversion est une bonne idée, parce que le letterboxing ne gère pas le cas d’un fond implicite. L’option de fond est proposée sur les paires où la source peut avoir de l’alpha, et c’est explicite dans le code source.

ICO est lisible par Windows et macOS comme icône d’application, ce que PNG et WebP ne sont pas. Pour un installateur de logiciel qui doit embarquer son icône dans l’exécutable, ICO est la cible. Pour un raccourci, ICO est la cible. Pour une icône de barre de tâches, ICO est la cible. Pour un favicon, ICO est ancien et le PNG est plus moderne.

Pour un site web moderne, le favicon est en PNG 32 ou en SVG, et l’ICO est conservé comme fallback pour les navigateurs anciens. Notre pipeline produit un ICO multi-tailles conforme, prêt à être embarqué. Pour un usage web, le PNG suffit. Pour un usage système, l’ICO est la bonne cible.

Le JXL source peut porter EXIF, XMP, ICC. Notre pipeline décode en pixels, ré-encode en ICO, 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.

Pour un archivage qui doit conserver la trace de la création, c’est un défaut, et il faut un outil qui accepte les métadonnées comme paramètre. Notre pipeline ne le fait pas, parce que le raster n’accepte que `ImageData` et `{ quality }`. C’est cohérent avec les autres cibles raster, et c’est ce qui fait que le fichier produit est léger et propre.

Le JXL source n’est pas uploadé, l’ICO 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 assets graphiques qui peuvent indiquer une marque, un design en cours, un sigle client. 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.