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.

Je suis en train de faire du ménage sur disque, et j'en profite pour recompresser des archives de log en 7z.  Ce format de compression est juste fantastique. Le gain de place par rapport à gzip ou la bouse de .zip est extraordinaire. Mes 1,5 Go de logs qui prenaient 157 Mo en .gz ne prennent plus que 57 Mo en 7z. J'ai gagné 100 Mo sur un fichier de 157 Mo.
Pour ceux qui ne connaissent pas encore les avantages de ce formidable format, voir: http://sebsauvage.net/rhaa/index.php?2010/06/23/18/07/54-la-superiorite-du-format-7z-7-zip-

Et oui.... Le OGG Vorbis est supérieur au MP3.  Tout comme les wavelets et le WebP sont supérieurs au JPEG.  Tout comme 7Zip est supérieur à Zip. Mais on est coincés par le phénomène de l’œuf et de la poule.  :-/

Actuellement, le format vidéo webm utilise le codec VP8. VP9 est prêt d'être finalisé. Ce qui veut dire: une meilleure qualité vidéo à compression équivalente (ou une plus petite taille à qualité équivalente).

+1
Non seulement 7z est meilleur en taux de compression, mais en prime c'est un logiciel libre et gratuit (WinRAR est à sources fermés et payant).

Un format ouvert, une meilleure compression que le JPEG. Good.
(Opera l'utilise déjà quand vous utilisez le mode "Turbo" dans OperaMobile, ou quand vous utilisez OperaMini.)

Google ouvre les sources d'un algo de compression maison plus puissant que zlib, mais plus lent à compresser.
J'aimerais bien savoir comment ça se compare à l'excellent LZMA.
https://code.google.com/p/zopfli/

EDIT: Ah c'est juste un algo de compression compatible zlib (deflate). Ce qui veut dire que zlib peut décompresser ce qu'a compressé zopfli. Le truc est qu'il prend 100 FOIS PLUS DE TEMPS pour un gain de 5% par rapport à zlib. Bof.  LZMA a des gains plus importants pour des temps de compression bien moindres.

Par contre, il pourrait être intéressant d'intégrer zopfli dans les libs de compression zip, png, tiff et PDF. Cela permettrait d'obtenir des fichiers plus petits (Ces derniers utilisant la compression zlib. Cf. http://sebsauvage.net/rhaa/index.php?2010/03/03/12/17/13)

Wouhou !... le codec vidéo propriétaire et payant H265 (annoncé comme écrasant les performances du H264) va enfin voir de la concurrence avec Daala, un projet commun des fondations Xiph et Mozilla dont le but est de faire *mieux* que le H265, le tout dans un codec libre. On doit déjà à Xiph (et d'autres participants) les excellents codecs Vorbis, Speex, FLAC, Theora et Opus.

Xiph, Mozilla, je vous aime.

Je souhaite la réussite à ce projet.

Opus est un nouveau codec audio qui écrase complètement tous les autres, y compris AAC, AC3 et Vorbis.

Ecoute en aveugle de musique compressée par les lecteurs de CodingHorror. Le résultat est clair: A part le 128 kb/sec., les lecteurs ne différencient pas les débits plus élevés avec le format non compressé.

OGG Vorbis, FLAC ?  Il n'y a pas déjà d'excellents formats de compression meilleurs que le MP3 ? Et qu'est-ce qu'il y connaît à la compression audio, Neil Young ?

:-)
Franchement le JPEG-XR c'est de la crotte à côté de WebP. Vraiment pas mal.

Contrairement à ce que pensait le développeur de x264, les gars de ffmpeg sont parvenus à optimiser le décodeur VP8: il est bien plus rapide que le décodeur de chez Google (libvpx)

atools est simple et bien pratique.

Un petit freeware de (dé)compression à tester... Les autres freeware du même éditeur on l'air bien aussi.

Test de fou avec tous les programmes de compression et tous les types de fichiers (texte, image, excécutables...)