Ensuite rien n'empêche de poursuive plusieurs pistes en parallèle pour être à même de faire le bon choix (un choix "éclairé" comme on dit). Et c'est d'ailleurs justement pour cette raison que j'ai relancé le mainteneur de mozjpeg en fait (en réaction à cette alternative et pour avoir le choix d'implémentation au final).
Ensuite si la déclaration est vraie (jpegli prétendent être plus rapide que mozjpeg tout en produisant en plus des fichiers plus petits pour une qualité visuellement identique), alors oui mozjpeg n'est plus si intéressant.
Mais dans tous les cas, il faudra tester. Parce que les déclarations tonitruantes où un nouveau logiciel prétend enterrer tous les autres, on connaît. Mais il faut toujours vérifier si la réalité suit. Même mozjpeg par exemple, si je me souviens bien, au début le développeur semblait ne pas comprendre pourquoi vouloir savoir si on utilise jpeg-turbo ou mozjpeg (genre "c'est juste un remplacement drop-in"), sauf qu'après avoir testé, j'ai eu des différences de vitesse de codage quasi facteur 10 dans certains cas (cf. mon message de commit où je donne quelques infos sur mes tests; et encore je suis pas monté sur des images de tailles extrêmes), genre une image qui s'exporte en moins de 4 secondes avec jpeg-turbo s'exporte en plus de 30 secondes avec mozjpeg sur ma machine. Alors certes, on va gagner quelques KiB et pour certains, c'est important, mais pour énormément d'autres, la possibilité d'exporter rapidement est bien plus importantes.
C'est toujours le problème avec ceux qui ont une vision très restreinte sur leur cas d'usage uniquement. Et c'est pourquoi il faut bien tester avant de pouvoir confirmer si réellement jpegli aussi rend mozjpeg absolument obsolète comme ils le disent.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: JPG
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.99.18 (version de développement). Évalué à 10.
Peut-être pas en effet. J'en parlais justement là aujourd'hui (et sur notre canal IRC): https://gitlab.gnome.org/GNOME/gimp/-/issues/11212#note_2076805
Ensuite rien n'empêche de poursuive plusieurs pistes en parallèle pour être à même de faire le bon choix (un choix "éclairé" comme on dit). Et c'est d'ailleurs justement pour cette raison que j'ai relancé le mainteneur de mozjpeg en fait (en réaction à cette alternative et pour avoir le choix d'implémentation au final).
Ensuite si la déclaration est vraie (jpegli prétendent être plus rapide que mozjpeg tout en produisant en plus des fichiers plus petits pour une qualité visuellement identique), alors oui mozjpeg n'est plus si intéressant.
Mais dans tous les cas, il faudra tester. Parce que les déclarations tonitruantes où un nouveau logiciel prétend enterrer tous les autres, on connaît. Mais il faut toujours vérifier si la réalité suit. Même mozjpeg par exemple, si je me souviens bien, au début le développeur semblait ne pas comprendre pourquoi vouloir savoir si on utilise jpeg-turbo ou mozjpeg (genre "c'est juste un remplacement drop-in"), sauf qu'après avoir testé, j'ai eu des différences de vitesse de codage quasi facteur 10 dans certains cas (cf. mon message de commit où je donne quelques infos sur mes tests; et encore je suis pas monté sur des images de tailles extrêmes), genre une image qui s'exporte en moins de 4 secondes avec jpeg-turbo s'exporte en plus de 30 secondes avec mozjpeg sur ma machine. Alors certes, on va gagner quelques KiB et pour certains, c'est important, mais pour énormément d'autres, la possibilité d'exporter rapidement est bien plus importantes.
C'est toujours le problème avec ceux qui ont une vision très restreinte sur leur cas d'usage uniquement. Et c'est pourquoi il faut bien tester avant de pouvoir confirmer si réellement jpegli aussi rend mozjpeg absolument obsolète comme ils le disent.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]