La compression "ultra" de 7-Zip s'utilise comme suit:
🖥️ 7zz a -mx=9 archive.7z répertoire

Mais on peut faire encore mieux. Pour une compression maximale à des fins d'archivage, j'utilise:
🖥️ 7zz a -snl -t7z -m0=lzma2 -mx=9 -myx=9 -mfb=257 -md=1024m -ms=on -mqs=on -mmt=off archive.7z répertoire

Attention, cette solution a des inconvénients:
- 7-Zip fonctionne alors en mono-threadé (-mmt=off). La compression prend donc *beaucoup* plus de temps (et la décompression un peu plus de temps).
- La compression consomme environ 10 Go de RAM, et la décompression 1 Go.

1 Go me semble raisonnable pour les machines d'aujourd'hui.

Si vous voulez aller un peu plus vite, on peut passer à 4 threads avec :
🖥️ 7zz a -snl -t7z -m0=lzma2 -mx=9 -myx=9 -mfb=257 -md=512m -ms=on -mqs=on -mmt=4 archive.7z répertoire
Cette solution consomme 11 Go de RAM à la compression, et compresse légèrement moins bien.

Dans certains cas, 7-Zip ne pourra pas faire mieux que zpaq. Je vous encourage à tester les deux.
🖥️ zpaq a archive.7z répertoire -m4


Notez qu'on peut obtenir des taux de compression supérieurs (zpaq -m5, freearc ou paq8hp5) mais dans ce cas les temps de compression (*et* de décompression) s'envolent (vraiment).


👉 À titre d'exemple, en compressant le jeu "Loophole":
- Taille décompressée : 3,18 Go
- 7z "ultra" (-mx=9) : 1,33 Go
- 7z avec mes réglages : 0,53 Go
- Et zpaq -m4 fait un peu mieux : 0,49 Go

Bien sûr c'est un exemple qui marche bien, le gain ne sera pas forcément aussi bon sur d'autres données.

⏱️ Temps de décompression :
- Archive 7-Zip réglage "ultra" (-mx=9, 1,33 Go) : 9,5 secondes.
- Archive 7-Zip avec mes réglages (0,53 Go) : 23 secondes.
- Archive zpaq (0,49 Go) : 2 minutes 23 secondes.
(sur un SSD, CPU Ryzen 7 5800H, 32 Go de RAM.)

Imaginez que vous voulez compresser la sortie d'un dd, netcat ou scp.
Si vous prenez un taux de compression bas, vous perdez de la place (compression faible).
Si vous prenez un taux de compression élevé, vous risquez d'impacter le débit (puisque votre CPU prendra plus de temps pour compresser).
Comment choisir le taux de compression idéal ?

Et bien zstd possède une option "--adapt" qui lui permet s'adapter dynamiquement au débit (I/O disque ou réseau).
Vous aurez ainsi la meilleure compression possible sans ralentir le débit du transfer !

(À ma connaissance, zstd est le seul compresseur à proposer cette option.)

Exemple:
Faire l'image d'un disque: sudo dd if=/dev/sda | zstd --adapt > image.dd.zst
Restaurer l'image:  zstdcat image.dd.zst | sudo dd of=/dev/sda

(ou si vous avez pv installé, pour suivre la progression:
sudo dd if=/dev/sda | pv | zstd --adapt > image.dd.zst
zstdcat image.dd.zst | pv | sudo dd of=/dev/sda )

Une bonne explication du papa de VLC sur le bordel absolu qu'est le monde des codecs (et pourquoi, en fait, les codecs propriétaires sont juste d'immondes machines à fric).
Le codec AV1 codé par l'équipe de VLC, c'est 200 000 lignes d'assembleur. D'ASSEMBLEUR. 🤯

Si vous n'avez jamais programmé en assembleur vous ne vous en rendez-sans doute pas compte, mais c'est un travail véritablement TITANESQUE.

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.)