Compression avec perte ou sans perte : pourquoi les formats d'image oublient exprès

Prenez la même photo de 12 MP (4000 × 3000 pixels) et enregistrez-la deux fois. Une fois en PNG : 24 Mo. Une fois en JPEG qualité 90 : 3,4 Mo. Affichez les deux versions côte à côte : impossible de les distinguer. Zoomez à 400 % et les différences finissent par apparaître : un léger adoucissement dans les cheveux et l'herbe, de discrets halos le long des contours les plus nets.

Deux fichiers, une image, un écart de taille de 7×. Aucun des deux n'est défectueux. Ils n'ont simplement pas le même contrat. PNG s'engage à conserver chaque bit. JPEG s'engage à conserver tout ce que vous remarqueriez. Et presque tout ce qui touche aux formats d'image découle de ce choix initial.

Pourquoi la compression s'est scindée en deux camps

En 1948, Claude Shannon a publié "A Mathematical Theory of Communication" et fixé à la compression une limite infranchissable. Son théorème du codage de source dit qu'il est impossible de représenter des données sans perte en dessous de leur entropie, c'est-à-dire le contenu informationnel moyen par symbole. Une image parfaitement aléatoire ne se compresse pas du tout ; une image blanche uniforme se réduit à presque rien. Toute image réelle se situe quelque part entre les deux, et aucun algorithme sans perte ne peut descendre sous cette limite.

La compression avec perte existe grâce à une échappatoire. La limite d'entropie s'applique aux données que vous avez, pas à celles que vous conservez. Remplacez d'abord l'image par une image légèrement différente, à l'entropie plus faible, et la limite descend avec elle. Toute l'astuce est là : modifiez les données, puis compactez-les. Reste à savoir quelles modifications sont acceptables : c'est là tout le travail d'ingénierie.

La réponse dépend de deux choses. D'abord, le contenu. La capture d'écran d'un panneau de réglages, c'est surtout de la couleur unie et des formes répétées : entropie faible, facile à prédire. Une photo de forêt, c'est du bruit de grenaille des photons et du bruit de lecture du capteur, à l'échelle du pixel : entropie forte, imprévisible. Ensuite, l'utilisateur final. Un programme qui lit le fichier exige des bits exacts. Un humain qui le regarde arrive avec une tolérance à l'erreur intégrée : acuité spatiale limitée pour la couleur, faible sensibilité aux textures fines à haute fréquence, et une perception de la luminosité qui suit des rapports plutôt que des valeurs absolues (loi de Weber, pas de luminance d'environ 1 à 2 %).

Les formats se sont donc répartis entre les deux approches. Si votre contenu est prévisible et que votre utilisateur est une machine, ou un humain qui scrute chaque pixel, choisissez le sans perte. Si votre contenu est bruité et que votre utilisateur est un humain à bout de bras, vous avez le droit d'oublier des choses.

Comment fonctionne la compression avec perte

On dit souvent des codecs avec perte qu'ils "jettent des données". C'est vrai, mais imprécis : ils jettent des données bien choisies, désignées par un modèle de la vision humaine. Voici le pipeline :

1. Convertissez le RGB en espace colorimétrique luma-chroma (YCbCr pour JPEG, séparations équivalentes ailleurs). L'œil distingue bien mieux les détails de luminosité que les détails de couleur : les canaux de chrominance peuvent donc être stockés au quart de la résolution (sous-échantillonnage 4:2:0). À elle seule, cette étape réduit les données brutes d'environ 50 %, et elle reste invisible sur la plupart des photos.

2. Transformez chaque bloc en fréquences. JPEG utilise la transformée en cosinus discrète sur des blocs de 8 × 8. JPEG 2000 utilise des ondelettes. AV1 et HEVC utilisent des transformées plus grandes, de taille variable. Le résultat a toujours la même allure : quelques gros coefficients qui décrivent les formes générales, et une multitude de petits coefficients pour la texture fine.

3. Quantifiez. Divisez chaque coefficient par un pas et arrondissez à l'entier. Les petits coefficients passent à zéro. C'est la seule étape avec perte de tout le pipeline, et le réglage de qualité de votre encodeur n'est rien d'autre qu'un multiplicateur appliqué à ces pas. Qualité 95 : petits pas, presque tout est conservé. Qualité 30 : gros pas, l'essentiel de la texture fine passe à zéro.

4. Appliquez un codage entropique à ce qui survit. Balayage en zigzag, codage par plages, Huffman ou codage arithmétique. Cette étape est sans perte : elle se contente de compacter les nombres déjà quantifiés.

Relisez cette liste. Les étapes 1, 2 et 4 ne font que réorganiser les données, de façon parfaitement réversible. C'est à l'étape 3 que l'image est réellement détruite, délibérément, une erreur d'arrondi à la fois.

Cette destruction laisse une signature reconnaissable. Poussez la qualité trop bas et vous obtenez du blocage (des bords de grille 8 × 8 visibles dans les ciels et les murs), du ringing (des halos autour du texte et des contours à fort contraste) et du banding (des dégradés lisses qui s'effondrent en marches d'escalier). Réenregistrez un fichier avec perte et tout le pipeline repasse sur des données déjà abîmées : c'est pour cela que la perte de génération s'accumule. À la dixième réécriture, un JPEG ressemble à une aquarelle de l'original.

Comment fonctionne la compression sans perte

Les codecs sans perte ne s'autorisent rien de tel. Le fichier décodé doit être identique à l'original, bit pour bit : tout ce qu'ils peuvent faire, c'est modéliser puis compacter. La recette standard compte deux étapes.

Première étape : décorréler. PNG filtre chaque ligne de balayage avant de la compresser. Pour chaque ligne, l'encodeur choisit l'un des cinq prédicteurs (None, Sub, Up, Average, Paeth) et stocke l'écart entre le pixel réel et la prédiction. Une ligne blanche uniforme devient un seul pixel blanc suivi de milliers de zéros. Un dégradé lisse devient une suite de petits résidus qui varient lentement. Dans les deux cas, les valeurs rapetissent et se regroupent autour de zéro, exactement ce qu'attend l'étape suivante.

Deuxième étape : le codage entropique. PNG utilise DEFLATE, le même algorithme que gzip et zip, assemblé à partir de deux idées des années 1970. LZ77 repère les séquences d'octets répétées et remplace chaque répétition par un pointeur (distance, longueur) vers les 32 Ko de données précédentes. Le codage de Huffman attribue ensuite des codes courts aux valeurs fréquentes et des codes longs aux valeurs rares. Aucune des deux étapes ne perd quoi que ce soit : à partir du flux compacté, on peut toujours revenir aux octets d'origine.

Voilà pourquoi PNG excelle sur les captures d'écran et s'essouffle sur les photos. Les graphismes d'interface se répètent : lignes identiques, icônes dupliquées, longues plages de couleur unie. LZ77 trouve des correspondances partout, et les filtres ramènent ce qui reste à des résidus proches de zéro. Une photographie, elle, ne répète rien. Le bruit de grenaille rend chaque pixel légèrement différent de ses voisins : les prédicteurs se trompent, les résidus restent grands et aléatoires, et LZ77 ne trouve rien vers quoi pointer. Sur une photo de 12 MP, PNG atteint péniblement 1,3:1 à 1,6:1 par rapport aux pixels bruts. JPEG, à qualité visuelle comparable, monte à 10:1.

En échange de ces fichiers plus lourds, une garantie absolue : décodez un PNG, hachez les pixels, et le hachage correspond à la source à chaque fois. Pour les captures d'écran qui passeront sous OCR, les scans qui seront réédités, les images médicales ou scientifiques susceptibles de finir dans une publication ou au tribunal, cette garantie est précisément la raison d'être du format.

Pourquoi JPEG a parié sur la compression avec perte en 1992

Le Joint Photographic Experts Group a commencé ses travaux en 1986, et les contraintes de l'époque expliquent chacune de ses décisions. Un disque dur de 20 Mo coûtait plusieurs centaines de dollars. La disquette de 1,44 Mo tenait lieu de support d'échange standard. Les modems plafonnaient à 14,4 kbps les bons jours : télécharger une seule photo VGA non compressée de 921 Ko prenait environ neuf minutes. La version avec perte à 10:1 arrive en moins d'une minute. La version sans perte à 2:1 en demande encore plus de quatre.

Les propres tests du comité montraient que le sans perte n'irait pas plus loin. Le contenu photographique, la cible affichée ("images à tons continus"), ne contient tout simplement pas assez de redondance. Face à ce constat, il a exploité la seule marge de manœuvre qui restait : le spectateur.

Ce qu'on sait moins, c'est que la norme publiée en 1992 (ISO/IEC 10918-1) contient bien un mode sans perte. Il se passe complètement de la DCT, prédit chaque pixel à partir de trois voisins au maximum, via l'un de sept prédicteurs fixes, et applique un codage entropique aux résidus : conceptuellement, la même astuce que PNG trois ans plus tard. Presque personne ne l'a implémenté. Les décodeurs l'ont ignoré, les encodeurs aussi, et lorsque l'imagerie médicale a eu réellement besoin d'un JPEG sans perte, elle a eu droit à une norme à part (JPEG-LS, ISO/IEC 14495, 1999).

Le comité a aussi dû composer avec les brevets. L'option de codage arithmétique de JPEG était empêtrée dans les brevets Q-coder d'IBM : le profil de base, libre de droits, a donc retenu le codage de Huffman, et la plupart des implémentations n'ont jamais touché à la voie arithmétique. Que des brevets dictent la conception d'un codec n'avait rien de nouveau en 1992. Et ça n'allait pas s'arranger.

Au fond, JPEG était un pari psychovisuel : le dernier facteur 5 de compression ne relève plus des mathématiques, mais de la biologie.

Pourquoi PNG a parié sur la compression sans perte en 1995

PNG n'est pas né d'un projet d'ingénierie. Il est né d'une urgence juridique.

En décembre 1994, Unisys annonce qu'elle facturera des licences aux logiciels utilisant GIF : la compression de GIF reposait sur l'algorithme LZW, couvert par un brevet de 1985 dont Unisys avait hérité. CompuServe, le créateur de GIF, a conclu un accord et refilé la facture aux développeurs. Les communautés graphiques d'Usenet étaient furieuses : GIF était gratuit depuis sept ans, et tout un pan du Web des débuts, images comme outils, tombait soudain sous le coup d'un brevet.

Quelques semaines plus tard, début janvier 1995, Thomas Boutell publiait le premier jet d'un format de remplacement. Des bénévoles ont mis la conception au point sur des listes de diffusion en quelques mois. PNG 1.0 est arrivé en octobre 1996 comme recommandation du W3C, puis comme RFC 2083 en mars 1997.

Deux exigences n'ont jamais été négociables. Chaque algorithme devait être libre de tout brevet, ce qui voulait dire DEFLATE (la combinaison LZ77 plus Huffman du PKZIP de Phil Katz, implémentée dans zlib par Jean-loup Gailly et Mark Adler). Et le format devait être sans perte, point final. La communauté remplaçait GIF : un successeur qui aurait dégradé les images aurait été mort-né. Et de toute façon, la contrainte des brevets ne laissait aucune place aux astuces perceptuelles sur lesquelles reposait JPEG.

Le contenu pesait tout autant. PNG a été conçu pour ce que GIF transportait vraiment : logos, diagrammes, dessins au trait, icônes, captures d'écran. Des contours nets et de la couleur unie, précisément le type de contenu où les artefacts de ringing de JPEG se voient le plus. Courir après les photos aurait voulu dire réinventer la DCT et affronter un JPEG libre de droits, déjà bien installé. PNG a choisi le combat qu'il pouvait gagner, et il l'a gagné sur toute la ligne. Le brevet du GIF a expiré en 2003 (2004 hors des États-Unis), mais PNG lui avait déjà ravi le poste.

Pourquoi la compression avec perte a malgré tout gagné le marché

PNG a gagné sa niche. JPEG a raflé tout le reste.

La raison tient en un mot : le volume. Les images du Web sont massivement des photographies, et pour les photographies, la compression avec perte n'est pas un compromis : c'est le bon outil. Le Web Almanac 2025 place JPEG à environ 57 % de toutes les images servies, trois décennies après sa naissance. Fils d'actualité, photos de presse, visuels de produits, annonces immobilières : que du contenu à tons continus, où un encodage avec perte en qualité 75 est visuellement indiscernable de la source sur les écrans que les gens utilisent vraiment.

L'économie pousse dans le même sens. Stockage et bande passante se facturent à l'octet, et 10:1 contre 2:1, ce n'est pas une marge : c'est un facteur 5 sur le coût de diffusion à qualité acceptable. La vitesse d'une page suit la taille des fichiers, et la taille des fichiers suit la compression. Tout appareil photo et tout téléphone sort d'usine avec la compression avec perte par défaut (JPEG ou HEIC). Tous les CMS génèrent des vignettes avec perte. Les plateformes sociales réencodent chaque envoi, en partie pour la taille, en partie pour supprimer les métadonnées et tout ce qui pourrait s'y cacher de malveillant. Un photographe peut bien envoyer un TIFF impeccable : ce que le fil d'actualité sert, c'est un JPEG qualité 85.

La compression sans perte n'a pas vraiment perdu : elle s'est repliée là où sa garantie compte. Captures d'écran et ressources d'interface, où les artefacts sautent aux yeux et où le contenu se compresse bien de toute façon. Masters dans un pipeline d'édition, où chaque génération avec perte aggrave les dégâts. Imagerie médicale, juridique et scientifique, où "assez proche" ne vaut pas preuve. Dans ces niches, PNG et TIFF règnent sans conteste. Mais ce n'est pas là que passe le trafic.

Où en sont les formats

Deux tendances se dégagent. Les nouveaux codecs ne choisissent plus leur camp : WebP, HEIC, AVIF et JPEG XL embarquent tous les deux modes, avec et sans perte, dans une seule spécification, et JPEG 2000 le faisait déjà en 2000. La question n'est plus "quel format" mais "quel mode". Et les cas limites continuent d'arriver : JPEG XL peut recompresser un JPEG existant sans perte, à environ 80 % de sa taille, une prouesse possible uniquement parce que les deux camps ont passé trente ans à s'approprier les mathématiques de l'autre.

Choisir en pratique

L'arbre de décision est court :

• Vous publiez une photo ? Avec perte. JPEG si la compatibilité prime, WebP ou AVIF si la taille prime.
• Vous enregistrez une capture d'écran, un logo, ou quoi que ce soit avec du texte et de la couleur unie ? Sans perte. PNG.
• Vous éditez ? Gardez le master sans perte, exportez des copies avec perte, et ne réenregistrez jamais un fichier avec perte dans son propre format. Chaque génération aggrave les dégâts.
• Vous convertissez ? Adaptez la sortie à l'usage, pas à l'entrée. Une capture PNG destinée à une galerie photo devrait devenir JPEG ou WebP. Un JPEG qui part dans un fichier de design devrait devenir PNG : pas parce qu'il gagnerait en qualité (c'est impossible), mais parce qu'il arrêtera d'en perdre.

C'est sur ce dernier point que les photos iPhone en trompent plus d'un. HEIC, c'est déjà de la compression HEVC avec perte. Convertir du HEIC en PNG ne restaure rien : cela fige l'état actuel et garantit qu'on ne perdra rien de plus, ce qui reste utile si vous comptez éditer. Pour partager, la conversion directe en JPEG est la solution la plus simple et la plus propre. Nos convertisseurs HEIC vers JPG, HEIC vers PNG et HEIC vers WebP tournent localement dans votre navigateur : le fichier ne quitte jamais votre appareil.

La même logique couvre le reste de la matrice. Passer un JPEG dans un workflow d'édition sans perte : JPG vers PNG. Alléger une capture PNG pour le Web : PNG vers JPG, ou PNG vers WebP si vous voulez des fichiers plus petits sans sacrifier la transparence. Dans l'autre sens, WebP vers PNG et WebP vers JPG restaurent la compatibilité avec les logiciels plus anciens. Si vous êtes coincé avec des scans BMP non compressés, BMP vers JPG, BMP vers PNG et BMP vers WebP vous offrent le même choix avec ou sans perte en une étape. Même l'export de documents mène à la même bifurcation : transformer une page PDF en image, c'est choisir entre PDF vers JPG pour les pages photographiques et PDF vers PNG quand le texte doit rester net.

Trente ans plus tard, les formats qui ont survécu sont ceux qui ont su, avec précision, quelles informations leurs utilisateurs accepteraient de perdre, et lesquelles étaient intouchables.