Premier jet d'une page assez généraliste sur la compression de fichiers, mais avec malgré tout un conseil majeur: Utilisez 7-Zip !

Je déteste franchement découvrir qu'un PNG possède des artefacts de compression jpeg. Ça veut dire que c'était un jpeg avant.
Donc on a à la fois la perte de qualité du jpeg (sans les avantages de la compression) et la place occupée par le png (sans les bénéfices de la qualité d'image d'une compression non-destructive).
Le pire des deux mondes.
ARRÊTEZ DE CONVERTIR LES JPG EN PNG.

Ah ouais...  si vous avez du temps, zpaq avec l'option -m5 est assez impressionnante. Lente, mais balaise. (voir https://sebsauvage.net/links/?iRMA8Q)

J'avais un peu plus de 36 Go de logs à compresser (un truc que je ne vais pas ouvrir souvent, donc je m'en fout).
En 7z (déjà excellent) ça faisait 1,7 Go en mode max (-mx=9).
Là en zpaq -m5 (max), ça fait seulement 700 Mo. Un giga de moins que 7z ! C'est dingue. 😮

Par un certain hasard, je reporte à nouveau mon attention sur ZPAQ (un logiciel de compression que Pierre Z. m'avait signalé en 2014 : https://sebsauvage.net/links/?5Ql3qg)
Je viens de refaire des essais avec zpaq, et c'est intéressant. C'est un logiciel de compression/archivage/backup qui à mes yeux peut avoir deux utilisations :
- Compresser fortement de gros ensembles de données (>2 Go) mieux que 7-Zip.
- Faire des backups incrémentaux (à la manière de borg) en mode "append only".

Compresser des données, c'est repérer des répétitions. Tous les logiciels de compression utilisent une "fenêtre" de compression à travers laquelle ils "regardent" les données à compresser. Si des répétitions sont vues dans cette fenêtre, on gagne de la place. Pour obtenir une meilleure compression, en plus d'un bon algorithme, il faut donc une grande fenêtre de compression (et donc consommer plus de mémoire).

C'est pour cela que 7-zip est plus efficace que la majorité de ses concurrents (zip, rar, zstd...) car il a non seulement d'excellents algorithmes (dont lzma) mais il utilise une plus grande fenêtre (et donc consomme plus de mémoire à la compression, par exemple si vous utilisez le mode "ultra" (-mx=9)). Il ajoute à cela une "astuce" : il trie les fichiers par extensions et nom. Avec cette astuce, il a donc plus de chance d'avoir dans sa fenêtre des fichiers avec du contenu similaire.

ZPAQ va plus loin: Il n'est pas limité à une fenêtre, mais peut repérer des répétitions sur l'ensemble des données (déduplication). Dans mes essais, zpaq (avec l'option -m4) donne de meilleurs résultats pour un ensemble de données de plusieurs Giga-octets. (Typiquement, il n'y a généralement pas de gain pour un ensemble de données inférieur à 2 Go).

ZPAQ est donc intéressant pour obtenir de meilleurs taux de compression que 7z pour toute donnée supérieure à 2 Go.

Mais ce n'est pas tout: Il possède un mode de fonctionnement très similaire à Borg afin de faire des backups incrémentaux. Le premier archivage/backup est long (puisqu'il compresse toutes les données), et les backups suivants sont plus rapide car il ne sauvegarde que les données modifiées. Avec déduplication et compression, il est très efficace.
On peut ainsi garder plusieurs versions des fichiers dans l'archive.
Tout comme Borg, ZPAQ permet de supprimer les derniers backups ajoutés. Par contre il ne sait pas supprimer d'anciens backups. L'archive ne peut donc que grossir. (C'est pour cette raison que pour un usage "backup", je continue à préférer borg: On peut purger les backups les plus anciens).
En utilisant un taux de compression moins fort (-m1,2 ou 3) il est très rapide pour les backups.

Si on résume :
- Pour compresser mieux que 7-Zip de gros ensembles de données, utilisez l'option -m4 de ZPAQ (Si vous avez du temps, l'option -m5 permet compresser encore mieux, mais avec un temps de compression *beaucoup* plus important).
- Si vous utilisez ZPAQ pour des backups, les options -m1 à -m3 conviennent très bien (compression rapide).
(Astuce : l'option -m du taux de compression doit se mettre en *fin* de ligne de commande.)

ZPAQ est un Logiciel Libre, bien documenté, solide et qui existe sous toutes les plateformes (y compris Windows). L'auteur semble porter grand soin à bien documenter son format et à le rendre pérenne.
Sous Linux, vous trouverez zpaq dans vos dépôts.

zlib est l'un des bouts de code les plus utilisés au monde (comme SQLite). Vous en avez sûrement de multiples exemplaires dans votre périphérique, que ce soit un smartphone ou votre ordinateur. Il y en a dans Firefox, dans les logiciels Adobe, dans Windows, dans Linux, dans les machines Apple, dans Android...
Un bug qui peut faire planter le logiciel à la compression est resté inaperçu pendant 17 ans. Il vient d'être corrigé.

Explications détaillées et bien illustrées (en anglais) du fonctionnement de la compression JPEG. C'est très complet.

Facebook gère des données. D'énormes quantités de données. Les algorithmes deflate/gz ou lzma aident beaucoup, mais Facebook veut aller plus loin avec "Superpack", même si pour le moment il limite son utilisation à la compression de ses applications Android (apk).

L'idée n'est pas de représenter les données sous forme compressée toujours avec le même algo.
L'idée est de représenter les données sous forme d'un programme capable de re-créer ces données 😱
Pour faire un parallèle: Un programme capable de calculer la suite de Fibonacci est une représentation "compressée" de la suite de Fibonacci.
On remplace donc les données par du code, du code capable de reconstruire les données.
Ils arrivent déjà à gagner 20% sur les APK (application Android) par rapport à la compression zip habituelle des APK.

(Article source: https://engineering.fb.com/2021/09/13/core-data/superpack/)

Sous le coude: un format de compression vidéo sans perte.
C'est un peu le FLAC de la vidéo.
Utile pour archiver des vidéo sans perdre en qualité.

Et là j'apprend l'existence de l'algo LZHAM, qui a le même taux de compression que LZMA (l'un des meilleurs algos de compression, celui utilisé dans le format .7z), mais avec une vitesse 1,5 à 8 fois supérieure.
LZHAM vient de passer dans le domaine public: https://richg42.blogspot.com/2020/09/lzham-and-crunch-are-now-in-public.html

Bon... "Basis Universal", encore un nouveau format de compression d'images. 6 à 8 fois plus efficace que jpg/png, et peut être décompressé par les GPU.  Woao.
(Sources: https://github.com/BinomialLLC/basis_universal)

Waouuuu... on y est déjà ?  Neflix a commencé à streamer des vidéos en utilisant le codec AV1 (sur Android pour le moment).
C'est totalement dans l'intérêt de Netflix, puisque cela permet de réduire la quantité de données à envoyer pour une qualité d'image équivalente.
PS: À qualité d'image équivalente, AV1 consomme 50% de bande passante en moins par rapport à H264 (que tout le monde utilise actuellement).

Sous le coude : Comment fonctionne un codec vidéo.

WOAOUUUU.... super site de comparaison des algos de compression (zlib/lzma/lzo/lz4/bzip2/zstd...)
Ils ont 28 jeux de données différents (textes, sources en C, XML, PDF, exécutables...), testés sur différents types de machines (x86 i3/i7, arm).
Vous pouvez sélectionner une archi et voir les débits attendus des différents algos.

Cisco semble avoir réussi à fait de l'encodage en temps réel d'AV1 en 720p (30fps). Ce qui a consommé la moitié de la bande passante de H264 (le codec actuellement le plus utilisé).

Besoin d'archiver rapidement un répertoire sous Linux ? N'utilisez pas tar/gzip: Prenez tar/lzo !
Lzo compresse un peu moins bien que gzip, mais il est *beaucoup* plus rapide. Vraiment beaucoup.

Petit test rapide: Avec 1,1 Go de données sur un core-i7:
 - tar/gzip prend 40 secondes pour compresser.
 - tar/pigz prend 15 secondes.
 - tar/lzo ne prend que 3,7 secondes (!)
(Pour une taille finale: tar/gz : 754 Mo, tar/lzo : 849 Mo).

Donc si vous voulez compresser un répertoire pour gagner rapidement de la place ou en faire une copie avant de faire des opérations risquées dedans, tar/lzo est rapide comme l'éclair !

La syntaxe:
tar --lzop -cvf archive.tar.lzo dossier/
( Pour la décompression, c'est juste: tar xvf archive.tar.lzo )

Des gens de chez Facebook (qui a *fortement* besoin de bonne compression étant donné le volume effarant de données qu'ils traitent) ont comparé le codec vidéo AV1 à H264 et VP9.
À qualité égale, les vidéos sont 50% plus petites que le H264 ! (Qui est le codec actuellement le plus utilisé.)
Excellent.
L'avenir semble enfin s'éclaircir: Et avec AV1 on risque moins d'avoir une guerre des brevets comme l'immense bordel passé (H264, Theora, VP8/VP9...)

Pourquoi ? Parce que les membres de Alliance For Open Media ont désespérément besoin d'un meilleur codec vidéo.
Et cette fois-ci, tout le monde participe: Mozilla, Amazon, ARM, Cisco, Facebook, Google, Microsoft, Intel, NVidia... et même Apple !

Perso pour optimiser les PNG j'utilise deux outils:
optipng re-compresse les PNG en essayant plusieurs paramètres de compression différents pour une compression maximum.
Selon les png, tu peux ajouter pngnq avant optipng: pngnq réduit le nombre de couleurs du png, ce qui peut augmenter de manière spectaculaire le taux de compression.
J'ai fait une mini doc là: http://sebsauvage.net/wiki/doku.php?id=en_vrac#optimiser_les_fichiers_png

Le dernier brevet concernant MPEG-2 vient d'expirer. On peut donc officiellement l'utiliser dans Linux sans enfreindre de brevet.
Pour mémoire, MPEG-2 c'est l'algo de compression des DVD. Ça date et ça ne compresse pas très bien.
Heureusement que depuis tout ce temps on a ffmpeg et VLC !

Bien bien bien.
Le format vidéo H264 est actuellement le plus répandu (La plupart des fichiers mp4 sont des H264).
Le nouveau codec H265 (ou HEVC) du consortium MPEG est 40% plus efficace en compression que le H264. C'est énorme ! Mais c'est encore un codec bardé de brevets et la licence coûte toujours des millions de dollars.

Mozilla, Microsoft, Netflix, Amazon, Google (et d'autres) travaillent actuellement sur un nouveau codec vidéo appelé "AV1" qui est 35% plus efficace que le H265. C'est absolument énorme !
Il n'est pas encore assez aboutit pour être distribuable en l'état, mais les premiers résultats sont très encourageant.
(Quand je dis "pas encore abouti", rien que l'encodeur actuel est lent: 150 secondes pour encoder 1 seconde de vidéo, c'est très lent !)

Couplé à Opus pour l'audio (dont je vous avais parlé là: http://sebsauvage.net/rhaa/?2012/09/12/08/30/48), cela augure des vidéos formidablement compactes.

Actuellement, seule la version "nightly" de Firefox peut lire ces vidéos.

(Comme d'habitude, ce gros con d'Apple boude tout seul dans son coin et s'accroche à son H265. Va mourir, Apple !)

EDIT: Autre article en français: http://www.01net.com/actualites/firefox-defie-apple-avec-un-codec-taille-pour-la-4k-sur-le-web-1315470.html
EDIT: Grosse surprise: Apple dit rejoindre l'effort AV1 ! http://sebsauvage.net/links/?eb4zSA

Un codec audio pour la voix capable de descendre à seulement 700 bits par secondes !

Et pouf ! Encore un nouvel algo de compression (cette fois-ci, venant de Facebook).
Décidément, nous avons plein de nouveaux algos qui sortent ces derniers temps, et des bons !
(via https://twitter.com/sam_et_max/status/771039591545659392)

Lepton est un format de stockage d'image 22% plus compacte que le JPEG.
Il faut bien comprendre que cet algo n'améliore pas la taille des images JPEG. C'est un format à part entière. La lib permet de faire la conversion JPEG-->Lepton ou Lepton-->JPEG, vous rendant au final votre JPEG identique bit à bit.
Ce qui est globalement intéressant pour le stockage en masse d'images JPEG, d'autant que la vitesse de décompression est assez bonne.
C'est ce qu'on appelle un trade-off : Vous troquez de l'espace de stockage contre de la consommation CPU. (Ce qui n'est pas déconnant étant donnée la masse énorme de données que doit stocker DropBox.)

Et concrètement, il est où cet algo ? On peut voir l'implémentation ? Il a un petit nom ?
Non parce qu'annoncer un algo 10 000 fois plus rapide que LZW et plus efficace, je demande à voir.
Ou alors il est efficace sur certains type de données bien spécifiques.
Quand on a entendu parler de LZMA, FLIF, BGP, Zstd ou Brotli, on avait des exemples concrets.

Très fun: Le principe de la compression LZ77 (et de la plupart des compressions non destructives) est de trouver des similarités. Chaque fois que l'algorithme tombe sur du texte déjà rencontré, il mémorise la référence au texte précédent (plutôt que le texte lui-même).
Ici, on assiste à la décompression: Les bouts de texte déjà rencontré sont affichés entre accolades. On voit que plus on progresse dans le texte, plus il réutilise des bouts précédents.

Rhhaaa... Fabrice Bellard, c'est une brute !
Déjà à l'origine de QEMU, FFmpeg et autres merveilles, il a pondu un format d'images à lui (BPG), bien meilleur que le JPEG. Et qui en prime supporte la transparence.
Il a même implémenté un décodeur en pur javascript (76ko) ce qui permet aux navigateurs de supporter ce format d'image directement.

Comparaison avec le JPEG: http://bellard.org/bpg/lena.html
(BPG à gauche, JPEG à droite, pour la même taille de fichier.)
Les images que vous voyez en BPG sont directement décodées dans votre navigateur par le code javascript.

Et c'est un format qui est également plus intéressant que le PNG pour la transparence (comparez les tailles de fichiers !):
http://bellard.org/bpg/gallery2.html

(via https://news.ycombinator.com/item?id=8704629)

EDIT: ça énerve Mitsu (http://root.suumitsu.eu/links/?D9jv8A). Oui au niveau des brevets BPG n'est peut-être pas inattaquable, mais je voulais surtout saluer la réalisation technique :)
(Non mais sérieux, il y en a vraiment qui s'amusent à faire des WebM de 1 frame pour faire ça ???)

EDIT: Si vous voulez comparer BPG avec JPEG ou WebP, il y a une page pour ça: https://xooyoozoo.github.io/yolo-octo-bugfixes/ (Les images de test sont particulièrement bien choisies)