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 (L'option -m5 est beaucoup, beaucoup trop lente).
- 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)

[Mode feignasse] Pour avoir la compression 7z sous OSX, il suffit d'installer Keka (http://www.kekaosx.com/fr/).  Utilisation: Glisser un fichier ou dossier sur la fenêtre de Keka pour compresser (Super-intuitif, bravo  :/ )
Et comme Keka contient 7zip, on peut l'appeler en ligne de commande (pour vos scripts): /Applications/Keka.app/Contents/Resources/keka7z  (C'est l'exécutable standard 7zip avec les options habituelles.)

Quand je regarde ces évolutions abracadabrantesques de la norme HTML pour faire face aux écrans à multiples résolutions, je ne peux pas m'empêcher de rager qu'on se traîne toujours cette merde de JPEG alors qu'on aurait même pas eu besoin de ces bricolages avec les Wavelets.

La compression d'image par Wavelets (ondelettes) est une méthode différente du JPEG qui existe depuis près de 20 ans. JPEG et MP3 sont basés sur les transformées de Fourier, et sont notoirement mauvais à l'encodage de hautes fréquences ponctuelles (une étoile sur un ciel sombre en JPEG, ou une percussion en MP3).  Les wavelets n'ont pas ce défaut, ce qui permet une meilleure qualité (ou donc une meilleure compression à qualité équivalente).

Mais l'avantage fantastique de la compression d'images par Wavelets est que le décodage de l'image peut se faire de manière progressive.   Je m'explique:
Pour des images responsives en JPEG, vous devez créer *plusieurs* JPEG à des résolutions différentes. Vous partez de l'image pleine résolution, et vous créez plusieurs copies à des résolutions inférieures. Le navigateur (ou votre javascript) va choisir laquelle charger en fonction du périphérique.

Avec les wavelets, plus vous décodez d'octets de l'image d'origine, plus l'image s'affine. Le navigateur peut donc décider d'arrêter le chargement de l'image s'il juge qu'il en a assez par rapport au périphérique sur lequel il l'affiche. Ainsi, vous n'avez plus à avoir plusieurs copies de votre image: Vous pouvez laisser l'image de 8 Mo sur le serveur.  Un navigateur sur un tout petit écran pourra décider de ne charger que les 16 premiers kilo-octets, ce qui lui suffira pour afficher l'image en entier.  L'internaute met son téléphone en mode paysage ?  Le navigateur peut charger 16 ou 32 ko supplémentaire pour l'afficher dans une meilleure qualité.
Vous êtes sur un écran Retina ?  Le navigateur peut afficher l'image en entier dès les premiers kilo-octets reçus, et charger - par exemple - jusqu'à 1 Mo pour avoir une image bien fine.
Aucun besoin de ré-encoder votre image à différentes résolutions/densités de pixels.

Les wavelets existent depuis plus de 20 ans, mais n'ont jamais décollé (tout le monde restant campé sur le JPEG). Toujours le problème de l’œuf et de la poule.  Le comité JPEG est arrivé très tardivement avec son JPEG-2000 (qui implémente les wavelets), mais sous forme d'un format bardé de brevets et de licences (dont personne n'a voulu, bien entendu). C'est trop tard. Nous sommes coincés avec le JPEG, tout comme nous sommes coincés avec le MP3 malgré l’existence de formats bien meilleurs (Vorbis, Opus...). Les wavelets sont une très bonne technologie de compression pour les images, mais aucun format n'a su s'imposer.

Et nous voilà à bricoler des horreurs en javascript ou dans les balises <img> parce que le JPEG ne permet pas le décodage progressif. Pouark. (Certes on a du JPEG progressif, mais ça reste un pis-aller et ne permet pas nativement de faire du multi-résolution).

Des fois, voir de superbes technologies ne pas être utilisées (wavelets, Vorbis, Opus, 7z/LZMA...) ça me dégoûte.

PS: Les wavelets peuvent également être utilisées pour compresser des modèles 3D, ce qui est bigrement intéressant pour les jeux en ligne: Les modèles 3D peuvent être progressivement envoyés au client. Quand ce dernier se rapproche de l'objet, le chargement de l'objet se poursuit (et le modèle 3D s'affine).  Cela évite également d'avoir à conserver plusieurs modèles 3D à des résolutions différentes (ce que font tous les jeux 3D).

La compression du format ZIP est effectivement inutile dans ces cas, mais une de ses autres fonctions est utile: Le contrôle d'intégrité.
Si une partie de votre MP3 ou votre JPEG est corrompue, vous ne vous en apercevez qu'en l'ouvrant.  Le fichier ZIP lui, permet de contrôler l'intégrité des fichiers dès la réception.
Il peut donc être utile de compresser en ZIP/7z malgré tout.

EDIT: http://lehollandaisvolant.net/?id=20140707162039
Oui la couche transport est censée garantir ça, mais qui n'a jamais eu un fichier téléchargé corrompu ?
Il faut aussi compter avec les supports de stockage qui deviennent défaillants.
Sinon on peut effectivement demander à ZIP de ne pas compresser du tout, mais les processeurs sont tellement rapide que cela ne fera pratiquement aucune différence avec la compression minimale.