Regressive JPEGs : quand un développeur retourne l'algorithme pour créer des images qui régressent

Un bidouilleur publie une exploration inversée du codec JPEG : générer des images qui, au décodage, produisent des artefacts délibérés en jouant sur la quantification DCT. Curieux, instructif, et un excellent exercice pour comprendre le format.

Le projet

Sur la home page de Hacker News cette semaine, un article intitulé « Regressive JPEGs » (maurycyz.com/projects/bad_jpeg/) a attiré notre attention. Son auteur documente une exploration inversée du codec JPEG : au lieu d'optimiser une image pour la taille et la qualité, il génère des JPEG délibérément dégradés en manipulant les tables de quantification et les blocs DCT (Discrete Cosine Transform).

Ce n'est pas un outil de production, mais un excellent prétexte pour comprendre comment JPEG fonctionne sous le capot - un format que la plupart des devs utilisent sans jamais lire la spec.

Rappel : comment JPEG encode

JPEG (Joint Photographic Experts Group, standard ISO/IEC 10918-1 de 1992) suit un pipeline classique :

1. Conversion RGB → YCbCr - sépare luminance et chrominance
2. Sous-échantillonnage de la chrominance (souvent 4:2:0)
3. Découpage en blocs 8×8
4. DCT - transforme chaque bloc du domaine spatial au domaine fréquentiel
5. Quantification - divise les coefficients DCT par une table de quantification (le vrai levier de compression)
6. Zig-zag scan + Huffman - encode les coefficients en flux binaire

La qualité perçue dépend surtout de l'étape 5 : plus la table de quantification est agressive, plus on perd de détail dans les hautes fréquences.

Ce que fait « Regressive JPEGs »

L'auteur détourne ce mécanisme. En construisant des tables de quantification exotiques (valeurs très élevées sur certaines fréquences, valeurs anormalement basses ailleurs), il produit des JPEG qui, quand un décodeur standard les lit, exhibent :

• Des blocs 8×8 visibles (blocking artifacts extrêmes)
• Des motifs de ringing (oscillations autour des contours)
• Des couleurs qui « bavent » à cause du sous-échantillonnage chroma poussé
• Voire des images totalement méconnaissables au décodage

L'intérêt pédagogique est réel : on voit à l'œil nu ce que chaque paramètre du codec contribue à préserver.

Applications sérieuses ?

Au-delà du plaisir de la curiosité, il y a quelques usages légitimes :

1. Tests de robustesse de décodeurs - un vrai décodeur JPEG doit gérer les fichiers malformés sans crash. Générer volontairement des JPEG bizarres est un fuzz-test artisanal.
2. Watermarking / stéganographie - comprendre finement la quantification aide à cacher de l'information dans les coefficients DCT (technique utilisée par F5, OutGuess).
3. Compréhension des artefacts en ML - les modèles de super-résolution entraînés sur JPEG doivent apprendre à distinguer contenu et artefact. Un dataset de « bad JPEGs » est utile.

Sur le fond, ce que ce genre de projet montre, c'est qu'un format qu'on croit boîte noire cache toujours des leviers exploitables - pour le meilleur ou pour la curiosité pure.

Pour aller plus loin

La spécification JPEG originale (ITU T.81 / ISO 10918-1) est verbeuse mais lisible - et c'est le meilleur point d'entrée pour comprendre ce qu'un décodeur voit réellement. Côté outillage, libjpeg-turbo (Darrell Commander) permet d'inspecter les tables de quantification d'un fichier via djpeg -verbose : un excellent moyen de vérifier ce que le codec a stocké dans un JPEG concret.

À retenir : les formats de fichier ne sont pas des boîtes noires. Lire un peu de spec (JPEG, PNG, WebP) transforme n'importe quel dev en meilleur utilisateur des outils d'imagerie qu'il utilise tous les jours.