C'est super, il était temps. On a juste perdu 3 ans pour… rien. De même côté Firefox, c'est en Nightly depuis des lustres, ils sont très frileux à l'idée d'avoir enfin un atout face à Chrome.
Bref, l'attente est frustrante, mais apparemment on va y arriver, tant mieux.
Posté par orfenor .
Évalué à 6 (+4/-0).
Dernière modification le 23 novembre 2025 à 12:20.
Non pas pour rien, le code posait des problèmes de sécurité.
D'après les devs Firefox ça venait de la taille du code C++ (100.000 lignes) et la surface d'attaque induite. Dans un billet de forum lu hier, un responsable de Chrome le mentionnait aussi. De mémoire, il ajoutait que l'implémentation d'Apple et l'implémentation en Rust (plus une semi dispo chez Microsoft et la dispo pour le pdf chez Adobe) poussent Google à retravailler le code proposé — ce que quelqu'un vient de faire.
Google pouvait retravailler le code proposé il y a 3 ans… Je trouve absurde pour Google d'attendre que le format soit adopté ailleurs (Apple, Adobe, un peu Microsoft) avant de le pousser dans Chrome. Il ne faut pas se leurrer, avec l'hégémonie de ce moteur de rendu web, adopter ou non un format d'image a des conséquences très visibles sur l'utilisation de ce format à grande échelle.
Si Google avazt retravaillé le code il y a 3 ans, l'adoption de JXL serait très certainement bien plus avancée aujourd'hui.
Posté par orfenor .
Évalué à 4 (+2/-0).
Dernière modification le 23 novembre 2025 à 14:04.
Justement, Google a retravaillé ce code puisque ce sont principalement leurs équipes de recherche qui développent JPEG-XL. Mais c'est long de reprendre 100.000 lignes qui évoluent encore parce que la libjxl n'est pas finie : la version 0.11.1 est sortie fin novembre 2024, le développement est continu et pourtant il n'y a encore aucune nouvelle version cette année.
Et puis faut pas croire qu'on peut ajouter un tel volume de code sans interventions d'autres équipes de Chrome. L'arrêt de l'intégration il y a 3 ans impliquait certainement plusieurs responsables : sécurité, vitesse, fiabilité, rendu, compatibilité, etc.
Apple et Adobe qui viennent de sortir leur propre code y ont passé du temps, pourquoi Chromne aurait du être plus rapide ?
Tout cet écrit n'est pas pour défendre Google, mais parce que vu l'état du code intégrer jxl dans un navigateur n'est certainement pas facile, d'autant plus que ça doit aussi marcher avec des tel mobiles qui sont moins puissants qu'un PC, voire beaucoup moins, et avec des anciennes versions d'Android.
# Bonne nouvelle
Posté par Christophe . Évalué à 6 (+5/-1).
C'est super, il était temps. On a juste perdu 3 ans pour… rien. De même côté Firefox, c'est en Nightly depuis des lustres, ils sont très frileux à l'idée d'avoir enfin un atout face à Chrome.
Bref, l'attente est frustrante, mais apparemment on va y arriver, tant mieux.
[^] # Re: Bonne nouvelle
Posté par orfenor . Évalué à 6 (+4/-0). Dernière modification le 23 novembre 2025 à 12:20.
Non pas pour rien, le code posait des problèmes de sécurité.
D'après les devs Firefox ça venait de la taille du code C++ (100.000 lignes) et la surface d'attaque induite. Dans un billet de forum lu hier, un responsable de Chrome le mentionnait aussi. De mémoire, il ajoutait que l'implémentation d'Apple et l'implémentation en Rust (plus une semi dispo chez Microsoft et la dispo pour le pdf chez Adobe) poussent Google à retravailler le code proposé — ce que quelqu'un vient de faire.
[^] # Re: Bonne nouvelle
Posté par Christophe . Évalué à 3 (+2/-1).
Google pouvait retravailler le code proposé il y a 3 ans… Je trouve absurde pour Google d'attendre que le format soit adopté ailleurs (Apple, Adobe, un peu Microsoft) avant de le pousser dans Chrome. Il ne faut pas se leurrer, avec l'hégémonie de ce moteur de rendu web, adopter ou non un format d'image a des conséquences très visibles sur l'utilisation de ce format à grande échelle.
Si Google avazt retravaillé le code il y a 3 ans, l'adoption de JXL serait très certainement bien plus avancée aujourd'hui.
[^] # Re: Bonne nouvelle
Posté par orfenor . Évalué à 4 (+2/-0). Dernière modification le 23 novembre 2025 à 14:04.
Justement, Google a retravaillé ce code puisque ce sont principalement leurs équipes de recherche qui développent JPEG-XL. Mais c'est long de reprendre 100.000 lignes qui évoluent encore parce que la libjxl n'est pas finie : la version 0.11.1 est sortie fin novembre 2024, le développement est continu et pourtant il n'y a encore aucune nouvelle version cette année.
Et puis faut pas croire qu'on peut ajouter un tel volume de code sans interventions d'autres équipes de Chrome. L'arrêt de l'intégration il y a 3 ans impliquait certainement plusieurs responsables : sécurité, vitesse, fiabilité, rendu, compatibilité, etc.
Apple et Adobe qui viennent de sortir leur propre code y ont passé du temps, pourquoi Chromne aurait du être plus rapide ?
Tout cet écrit n'est pas pour défendre Google, mais parce que vu l'état du code intégrer jxl dans un navigateur n'est certainement pas facile, d'autant plus que ça doit aussi marcher avec des tel mobiles qui sont moins puissants qu'un PC, voire beaucoup moins, et avec des anciennes versions d'Android.
[^] # Re: Bonne nouvelle
Posté par cosmocat . Évalué à 3 (+1/-0).
Avec Jpeg-XL, il faut être précis quand on parle de Google : car c'est bien Google(Chrome) qui à refusé l'intégration du travail de Google(jxl)…
C'est pas parce qu'ils travaillent sur la version rust (pour justement être inclus dans firefox être autre) ?
https://github.com/libjxl/jxl-rs
# Autres sources
Posté par cosmocat . Évalué à 4 (+2/-0).
https://linuxfr.org/users/cosmocat/liens/google-reexamine-le-support-de-jpeg-xl-dans-chromium
[^] # Re: Autres sources
Posté par Glandos . Évalué à 2 (+0/-0).
Oui, en effet, c'est allez très vite, et j'aurais dû commenter dans ce lien :)
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.