Convertir WebP en JXL

WebP a été publié par Google en 2010. JPEG XL a été standardisé en 2022 sous la référence ISO/IEC 18181, après une fusion entre le projet Pik de Google et le JPEG XL du JPEG Committee. Le décalage est de douze ans, et c’est tout l’intérêt de la migration : un codec plus récent fait mieux à qualité visible égale, supporte le HDR et les espaces colorimétriques étendus, et conserve la transparence du WebP sans perte significative.

Pour un pipeline moderne qui a explicitement migré vers JXL — une archive d’images, un outil de comparaison, une équipe qui a fait le pari de la nouvelle génération — la conversion sert le temps que la migration amont rende la conversion inutile. Pour un cas isolé où la cible demande du JXL et que vous avez du WebP, c’est une conversion honnête qui sort ce qui est attendu.

À qualité visible égale, un fichier JXL est en général 20 à 30 pour cent plus petit qu’un WebP, et la différence est plus marquée sur les contenus photographiques que sur les contenus d’interface. Le codec de base est l’intra-image d’un codec vidéo récent, et les outils de prédiction disponibles sont plus performants.

Pour un site qui sert des milliers d’images, c’est un gain de bande passante réel. Pour un fichier isolé qui va voyager une fois, c’est un gain d’une seule fois. La migration vaut la peine d’être faite quand le pipeline aval a déjà adopté JXL, et neutre quand il ne l’a pas fait et qu’une re-conversion attend de toute façon. C’est la cible qui décide.

Les deux formats supportent un canal alpha en première classe, et la conversion préserve la transparence sans l’aplatir. Un logo avec un fond transparent, une photo de produit détourée, un pictogramme avec une ombre douce arrivent en JXL exactement comme ils étaient.

C’est l’une des propriétés qui rend le JXL un bon remplaçant du WebP pour les assets UI : la transparence est aussi bien supportée, le fichier est plus petit à qualité égale, et la migration est sémantiquement neutre. Pour un format qui ne supporte pas l’alpha — JPG, par exemple —, la conversion perdrait la transparence, et c’est explicite sur la page de cette conversion-là.

WebP supporte jusqu’à Rec. 709 et le SDR. JXL supporte Rec. 2020 et le HDR, et la conversion préserve ce qui est dans la source. Une image capturée en large gamut et stockée en WebP est déjà réduite en gamut — la perte a eu lieu en amont — et la conversion vers JXL ne la ré-étend pas.

Pour une image qui était en sRGB à la source — la grande majorité des images web —, c’est sans importance : le JXL est aussi en sRGB et l’échange est neutre. Pour une image qui a été capturée en HDR, le bon flux est de la source HDR directement vers JXL, pas de WebP vers JXL. La conversion préserve ce qui est dans la source, et ce qui se perd à l’encodage ne se récupère pas au transcodage.

JPEG XL a un support logiciel plus étroit que le WebP, et c’est l’angle à vérifier avant de convertir. Chrome a annoncé son intention de retirer le support JXL en 2022 puis a fait machine arrière ; le support actuel est incertain. Firefox a implémenté JXL derrière une préférence dans les versions récentes. Safari a annoncé le support en 2022. Les navigateurs d’images, les visionneuses, les outils de retouche : support très variable.

Pour une cible spécifique qui a explicitement adopté JXL, c’est le bon format. Pour un téléchargement destiné à être ouvert ailleurs, c’est un pari, et le pari est perdant contre le WebP dans la grande majorité des cas. La destination doit être capable d’ouvrir le JXL avant que la conversion serve à quelque chose.

Le mode sans perte de JXL existe, et il est meilleur que le PNG à taille égale sur la plupart des contenus. La conversion n’offre pas ce mode : la sortie est avec perte à la qualité standard, et c’est une seconde génération de compression sur une image qui a déjà été compressée une fois.

Pour un asset qui doit être retravaillé par la suite, partez de la source originale plutôt que du WebP déjà compressé. Pour un asset terminé qui doit être stocké ou livré, le WebP vers JXL est une conversion raisonnable et la perte supplémentaire est en général invisible au réglage par défaut. Pour un cas où le sans perte compte, le PNG reste le format de référence, et le WebP vers PNG est l’autre conversion disponible sur ce site.

EXIF, GPS, XMP, IPTC et le profil ICC sont tous deux perdus dans la conversion, parce que les pixels sont décodés puis ré-encodés sans que rien de ce qui les accompagnait traverse. Un WebP qui portait des coordonnées GPS les perd, et c’est explicite dans le code source : c’est par construction de la chaîne, et il n’y a pas d’option pour l’éviter.

Pour une image sans métadonnées — un asset UI, une capture d’écran, un pictogramme — c’est sans importance. Pour une photographie prise avec un téléphone et qui portait des informations de localisation, c’est une perte réelle, et le bon outil est la page de suppression des métadonnées sur le WebP source si la destination ne doit rien recevoir, ou de garder le WebP si elle doit recevoir les métadonnées.

WebP et JXL supportent tous deux l’animation, et la conversion préserve le mouvement plutôt que de figer la première image. Un WebP animé devient un JXL animé avec la même durée totale, la même fréquence d’images, et la même séquence de frames dans le même ordre.

C’est utile pour les assets UI animés, les bannières, les avatars qui s’animent en boucle. Pour un asset qui doit animer ailleurs, c’est presque toujours mieux que de tomber sur la première image. Pour un cas où l’animation a été perdue quelque part en amont, c’est ce qui sort, et la correction est ailleurs dans la chaîne d’outillage qui a produit le WebP.

Déposez jusqu’à cent WebP en une seule passe, et chacun sort en JXL avec sa propre progression. Pour une migration de pipeline où des dizaines ou des centaines d’images doivent basculer, c’est une conversion qui revient.

Comme rien n’est téléversé, un lot ne coûte pas de bande passante et ne heurte aucun quota quotidien. Le ZIP qui sort contient tous les fichiers, nommés d’après les sources. La conversion est entièrement locale, et c’est ce qui rend la migration possible sans dépendance à un service tiers ou à une API avec quota.

Le navigateur décode le WebP avec les codecs qu’il a déjà, encode le JXL avec @jsquash/jxl chargé à la demande, et le résultat est écrit dans le même onglet. Aucun octet de l’image n’est envoyé à un serveur, et la conversion n’a pas de compte à reconnaître ni de quota à dépenser.

Pour une migration où des fichiers peuvent porter des métadonnées privées ou un asset de marque, c’est une garantie qui compte. La vérification se fait dans l’onglet réseau des outils de développement pendant qu’une conversion tourne : c’est la seule forme sous laquelle l’affirmation « privé » signifie quelque chose, et c’est explicite dans le code source de cette conversion que c’est ce qui est garanti.