Convertir JPG en JXL

JXL est un codec ISO/IEC 18181, publié en 2021, conçu pour succéder à JPG en offrant une meilleure compression à qualité équivalente. À 82, qualité par défaut partagée avec WebP, AVIF et JPG, un JXL pèse en général 30 à 40 % de moins qu’un JPG de même qualité perçue. Pour une photo d’appareil de 12 mégapixels, on passe de 3,4 Mo en JPG qualité 85 à 1,8 à 2,2 Mo en JXL 82, et la différence visuelle est indétectable sur un écran standard.

Pour un site web qui doit servir des photos, le gain est appréciable. Pour un stock interne, c’est un changement de format qui demande de la chaîne en aval qu’elle sache lire le JXL, et c’est là que ça se complique. Chrome supporte JXL depuis 91 derrière un flag, Firefox en nightly, Safari en lecture seule. Pour un envoi à un tiers, vérifiez que le destinataire peut ouvrir le fichier.

Notre pipeline raster utilise un seul contrôle de qualité, fixé à 82 par défaut, et c’est explicite dans le code source. Pour JPG, WebP, AVIF et JXL, c’est la même valeur. Le commentaire qui justifie ce choix est sans détour : « les contrôles de qualité sont fixés une fois plutôt que par format, pour que la même commande produise un résultat comparable ». Si vous montez à 95, le JXL est presque deux fois plus gros, et la différence est invisible sauf à zoomer à 400 %.

Pour un JXL qui doit servir d’archive, monter à 90 est défendable. Pour un JXL qui doit servir sur un site, 82 est l’équilibre. Pour un JXL qui doit subir d’autres traitements, restez en JPG : le JPG est décodeé en pixels et le JXL est écrit en lossy, donc l’aller-retour ajoute une génération de perte, et la qualité baisse à chaque cycle.

Le pipeline raster décode en pixels et ré-encode sans paramètres de métadonnées. Cela signifie que tout EXIF, XMP, IPTC, ICC de la source est perdu en sortie. Le bloc GPS qui indique où la photo a été prise est perdu. Le profil colorimétrique est perdu, et le JXL est supposé sRGB par défaut. C’est explicite dans la documentation du pipeline, et c’est ce qui fait que le fichier produit est léger et propre.

Pour un envoi qui doit rester confidentiel, c’est une bonne chose : la photo n’indique plus où elle a été prise. 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 }`, et c’est cohérent avec les autres cibles.

JXL définit un mode lossless dans sa spécification, et il est même son mode phare pour l’archivage. Notre pipeline ne l’utilise pas, et c’est explicite dans la liste des formats où la lossless n’est jamais appelée. Le JXL produit est toujours en mode lossy à la qualité demandée. Pour une conversion JPG vers JXL, c’est presque toujours le bon choix, parce que la source est déjà en JPG, donc lossy, et passer en lossless JXL ne récupère rien.

Pour un cas où la source est en PNG lossless et où la cible est en JXL lossless, le gain est réel : on peut gagner 20 à 30 % sur la taille en gardant la fidélité bit-à-bit. Notre pipeline ne fait pas ce chemin. Pour un stock de photos, JPG vers JXL lossy à 82 est l’équilibre, et c’est explicite dans le code source.

JPG ne porte pas d’animation et ne porte pas de transparence. JXL porte les deux. Notre pipeline ignore ces différences, parce que la source n’a rien à offrir sur ce plan. Le JXL produit est un fichier image simple, sans canal alpha, sans animation. Pour une photo, c’est conforme à l’attendu.

Pour un cas où la source JPG avait été aplatie depuis un PNG avec un fond blanc, le JXL reproduit le fond blanc sans le signaler. C’est cohérent, et c’est ce que le destinataire attend. Pour un cas où la source JPG était destinée à un usage avec transparence, c’est un défaut de la source, pas du pipeline, et la conversion ne peut pas l’inventer.

Une photo d’iPhone 12 mégapixels en JPG 85 pèse autour de 3,4 Mo. En JXL 82, elle pèse 1,8 à 2,2 Mo. Le ratio dépend du contenu : une photo de paysage avec beaucoup de détails profite plus du JXL qu’une photo de produit avec des aplats. Pour une photo fortement compressée à 60, le gain est plus faible, parce que JPG a déjà jeté l’information que JXL aurait pu économiser.

Pour un site web, le gain de bande passante est réel. Pour un envoi en pièce jointe, c’est appréciable. Pour un archivage sur disque, c’est un changement de format qui demande de la chaîne en aval qu’elle sache lire le JXL. Le bon usage est de mesurer le gain sur vos propres photos avant de convertir un stock entier.

WebP est supporté par tous les navigateurs, encode à la même qualité, et pèse à peu près la même chose que JXL. AVIF est plus efficace, mais plus lent à encoder et pas supporté par Safari avant macOS Sonoma. JXL est le plus efficace des trois, mais le moins bien supporté. Le choix dépend de la chaîne en aval, pas seulement de la taille de fichier.

Pour un site web qui doit servir des photos à Safari et aux vieux navigateurs, WebP est le choix sûr. Pour un site qui peut se permettre de perdre les vieux navigateurs, AVIF ou JXL sont plus efficaces. Pour un stock interne, JXL est un bon choix, avec un fallback WebP pour les outils qui ne le lisent pas. Le convertisseur peut faire les trois, et c’est explicite dans la liste des cibles raster.

Le JPG 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 photos qui peuvent indiquer où elles ont été prises, parce que la conversion efface le bloc GPS, et c’est utile pour les photos qui ne doivent pas fuiter, parce qu’aucun fichier ne quitte l’appareil.

Les fichiers jusqu’à 100 Mo sont pris en charge, ce qui est très large pour des JPG, 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.