A specific method can be called Pareto-optimal if no other method can achieve the same (or better) compression density in less time. There might be other methods that compress better but take more time, or that compress faster but result in larger files. But a Pareto-optimal method delivers the smallest files for a given time budget, which is why it’s called “optimal.”
Medium Quality
More recently, the JPEG XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere.
High Quality
At this point, mozjpeg no longer beats WebP, though jpegli still does. The Pareto front is now mostly covered by JPEG XL, though for very fast encoding, good old JPEG is still best. At this quality point, AVIF is not on the Pareto front: at its slowest settings (at 0.5 Mpx/s or slower) it matches the compression density of the second-fastest libjxl setting, which is over 100 times as fast (52 Mpx/s).
Conclusion
Meanwhile, the old JPEG is still attractive thanks to better encoders. The new jpegli encoder brings a significant improvement over mozjpeg in terms of both speed and compression. Perhaps surprisingly, good old JPEG is still part of the Pareto front — when extremely fast encoding is needed, it can still be the best choice.
En ce qui concerne la compression avec perte (lossy) de webp, si l'on en juge par la phrase:
When Google first introduced WebP, it outperformed libjpeg-turbo in terms of compression density, as can be seen in the plot above. But Mozilla was not impressed, and they created their own JPEG encoder, mozjpeg, which is slower than libjpeg-turbo but offers better compression results. And indeed, we can see that mozjpeg is actually more Pareto-efficient than WebP (for this corpus, at this quality point).
et le fait que Google a utilisé une vieille (mauvaise?) métrique pour évaluer la qualité de WebP et qui fausse les résultats, si on applique les 2 raisons avancées par Google pour virer jxl de Chrome (cf https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reasons):
There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
on arrive à la conclusion que:
sûrement que webp lossy n'aurait jamais dû être un format inclus dans les navigateurs.
Surtout quand on voit le support de ce format loin d'être universel longtemps après son introduction.
Le format jxl, vu toutes les fonctionnalités offertes et l'adoption, pourrait être le format universel pour quasiment tous les usages pour tourner la pages des nombreux formats plus ou moins bon actuellement utilisés.
Seulement il y a la décision de Google/Chrome qui met un gros caillou dans l'engrenage :(
# Rappel
Posté par cosmocat . Évalué à 5 (+3/-0).
Encoder jpegli qui faisait parti des codecs comparés dans cet article sur jxl:
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#the_lossy_pareto_front
[^] # Re: Rappel
Posté par antistress (site web personnel) . Évalué à 5 (+2/-0).
Morceaux choisis :
Donc WebP est out ?
[^] # Re: Rappel
Posté par Thomas Debesse (site web personnel) . Évalué à 3 (+0/-0).
WebP lossless est toujours mieux que du PNG 8-bit, donc si JpegXL n’est pas dispo pour faire du sans-perte, WebP reste une bonne option.
WebP n’est pas que un concurrent à JPEG, mais aussi à PNG.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Rappel
Posté par cosmocat . Évalué à 6 (+4/-0).
En ce qui concerne la compression avec perte (lossy) de webp, si l'on en juge par la phrase:
et le fait que Google a utilisé une vieille (mauvaise?) métrique pour évaluer la qualité de WebP et qui fausse les résultats, si on applique les 2 raisons avancées par Google pour virer jxl de Chrome (cf https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reasons):
on arrive à la conclusion que:
sûrement que webp lossy n'aurait jamais dû être un format inclus dans les navigateurs.
Surtout quand on voit le support de ce format loin d'être universel longtemps après son introduction.
Le format jxl, vu toutes les fonctionnalités offertes et l'adoption, pourrait être le format universel pour quasiment tous les usages pour tourner la pages des nombreux formats plus ou moins bon actuellement utilisés.
Seulement il y a la décision de Google/Chrome qui met un gros caillou dans l'engrenage :(
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.