On nous avait vendu que Google freinerait des deux pieds sur le JPEG XL pour cause de performance médiocre. (conférer discussion ici). Ce nouvel article de propagande semble clairement contredire cet argument.
À moins qu'il ne faille, pour Google du moins, prendre en compte non pas les temps de calcul mais le temps total CPU pour définir le front de Pareto ? Avec 8 threads entre du parfaitement parallélisé et de parallélisé « sans dégâts », ça peut tout de même produire une facteur 8 sur les résultats affichés.
Je voulais poster ce lien mais avec un titre plutôt similaire à "jxl 0.10 : Google tend l'autre joue".
Lecture très intéressante et on y apprend plein de trucs assez intéressants (je conseille fortement la lecture) :
* v0.10 ameliore la vitesse d'encodage et réduit l'utilisation mémoire (surtout en sans perte)
* confirmation que jxl est le meilleur format dans tous les cas (sauf 1 cas d'utilisation de niche pour avif) en vitesse, compression et fonctionnalités.
* Google pour vendre son avantage du webp vente un gain vis à vis du jpeg mais n'a pas utilisé le meilleur encodeur pour la comparaison et utilise aussi une métrique dépréciée qui fausse l'interprétation.
* un nouvel encodeur "jpegli" a été écrit en utilisant des avancées de jxl qui produit des jpeg de plus petite taille que webp.
Mon ressenti du seul point négatif de jxl: difficile de déterminer les bons paramètres d'encodage suivant l'utilisation cible.
# À n'y rien comprendre
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4 (+2/-0).
On nous avait vendu que Google freinerait des deux pieds sur le JPEG XL pour cause de performance médiocre. (conférer discussion ici). Ce nouvel article de propagande semble clairement contredire cet argument.
À moins qu'il ne faille, pour Google du moins, prendre en compte non pas les temps de calcul mais le temps total CPU pour définir le front de Pareto ? Avec 8 threads entre du parfaitement parallélisé et de parallélisé « sans dégâts », ça peut tout de même produire une facteur 8 sur les résultats affichés.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: À n'y rien comprendre
Posté par cosmocat . Évalué à 6 (+4/-0).
Je voulais poster ce lien mais avec un titre plutôt similaire à "jxl 0.10 : Google tend l'autre joue".
Lecture très intéressante et on y apprend plein de trucs assez intéressants (je conseille fortement la lecture) :
* v0.10 ameliore la vitesse d'encodage et réduit l'utilisation mémoire (surtout en sans perte)
* confirmation que jxl est le meilleur format dans tous les cas (sauf 1 cas d'utilisation de niche pour avif) en vitesse, compression et fonctionnalités.
* Google pour vendre son avantage du webp vente un gain vis à vis du jpeg mais n'a pas utilisé le meilleur encodeur pour la comparaison et utilise aussi une métrique dépréciée qui fausse l'interprétation.
* un nouvel encodeur "jpegli" a été écrit en utilisant des avancées de jxl qui produit des jpeg de plus petite taille que webp.
Mon ressenti du seul point négatif de jxl: difficile de déterminer les bons paramètres d'encodage suivant l'utilisation cible.
[^] # Re: À n'y rien comprendre
Posté par cosmocat . Évalué à 3 (+1/-0).
Créé par l'équipe jxl de Google et disponible avec les binaires de jxl
# Ubuntu
Posté par cosmocat . Évalué à 5 (+3/-0).
Sujet un peu lié : Ubuntu 24.04 LTS ne supportera pas jxl par défaut 😕
https://www.phoronix.com/news/Ubuntu-24.04-No-JPEG-XL
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.