Il y a pas mal de contraintes en jeu : les performances, mais aussi la qualité des vignettes, le poids des fichiers générés, la prise en charge des différents formats d'image et cas particulier (l'orientation EXIF par exemple), la facilité de déploiement, etc. Image Magick reste le meilleur compromis sur tout ça.
Un des "mensonges" de ce genre de benchmark est la parallélisation. Certains outils n'utilisent pas de parallélisation (un seul cœur), tandis que d'autres profitent de tous les cœurs disponibles sur un même traitement. En pratique, quand on déploie sur un serveur, on désactive systématiquement la parallélisation, on préfère traiter plusieurs images en parallèle pour occuper les cœurs. Pour donner quelques ordres de grandeur, si on prend un CPU avec 8 cœurs, un outil capable de faire un traitement en parallèle sur une même image va utiliser 100% du CPU sur les 8 cœurs pendant disons 100ms. Le même outil sans parallélisation (un seul cœur) va mettre plus de temps, de l'ordre de deux fois plus, 200ms. Mais comme il laisse les autres cœurs libres, on peut traiter 8 images comme ça en même temps. Du coup, en utilisant du multi-thread, on va traiter 2 images sur une période de 200ms, alors qu'avec 8 images traitées chacune par un processus/thread, on peut traiter 8 images sur cette même période, soit 4 fois plus.
En gros, de ce que j'ai vu voir, on a :
Epeg, le plus performant (CPU / RAM), mais la qualité des vignettes n'est pas toujours terrible, ça ne fait que du JPEG, ça n'est pas packagé pour les différentes distributions Linux et il me semble que ça ne gère pas bien l'orientation EXIF. À utiliser uniquement quand on veut vraiment aller chercher le maximum de performances.
OpenCV est dans le même style : performant mais en retrait sur les autres critères.
Vips est globalement plus performant qu'Image Magick mais un peu moins bon sur d'autres aspects.
Image Magick a un bon compromis global.
Graphics Magick est proche d'Image Magick, avec quelques en bugs en plus et, de mon expérience, n'est pas plus rapide qu'Image Magick.
Enfin, les bibliothèques en go sont toutes bien plus lentes que les programmes cités au-dessus.
[^] # Re: raspberrypi ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Cozy, votre domicile numérique. Évalué à 10.
Il y a pas mal de contraintes en jeu : les performances, mais aussi la qualité des vignettes, le poids des fichiers générés, la prise en charge des différents formats d'image et cas particulier (l'orientation EXIF par exemple), la facilité de déploiement, etc. Image Magick reste le meilleur compromis sur tout ça.
Si on prend en compte juste l'aspect performances, un même outil comme Image Magick peut se comporter de façon très différente selon les options passées. Voici un petit benchmark, à ne pas prendre trop sérieux, c'est juste pour illustrer ces propos : https://github.com/fawick/speedtest-resize/commit/afea1a69f1791d779001f572d39ce5651f12e2e6.
Un des "mensonges" de ce genre de benchmark est la parallélisation. Certains outils n'utilisent pas de parallélisation (un seul cœur), tandis que d'autres profitent de tous les cœurs disponibles sur un même traitement. En pratique, quand on déploie sur un serveur, on désactive systématiquement la parallélisation, on préfère traiter plusieurs images en parallèle pour occuper les cœurs. Pour donner quelques ordres de grandeur, si on prend un CPU avec 8 cœurs, un outil capable de faire un traitement en parallèle sur une même image va utiliser 100% du CPU sur les 8 cœurs pendant disons 100ms. Le même outil sans parallélisation (un seul cœur) va mettre plus de temps, de l'ordre de deux fois plus, 200ms. Mais comme il laisse les autres cœurs libres, on peut traiter 8 images comme ça en même temps. Du coup, en utilisant du multi-thread, on va traiter 2 images sur une période de 200ms, alors qu'avec 8 images traitées chacune par un processus/thread, on peut traiter 8 images sur cette même période, soit 4 fois plus.
En gros, de ce que j'ai vu voir, on a :