• # Rappel

    Posté par  . Évalué à 5.

    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  (site web personnel) . Évalué à 5.

      Morceaux choisis :

      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.

      Donc WebP est out ?

      • [^] # Re: Rappel

        Posté par  (site web personnel) . Évalué à 3.

        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  . Évalué à 6.

        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 :(

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.