Sous-échantillonnage de chroma

Le sous-échantillonnage de chroma est une technique de compression qui stocke la couleur (chroma) à une résolution inférieure à la luminosité (luma). Il exploite une particularité bien documentée de la vision humaine : nous sommes bien plus sensibles au contraste de luminosité qu’au contraste de couleur à petite échelle.

La notation ressemble à 4:2:0, 4:2:2 ou 4:4:4. Les trois nombres décrivent un bloc de référence de 4 pixels de large : combien d’échantillons de luma (toujours 4), combien d’échantillons de chroma dans la première rangée, combien dans la deuxième rangée.

• 4:4:4 — pas de sous-échantillonnage. Résolution de couleur complète. Utilisé pour les graphiques, les captures d’écran, partout où les bords et le texte comptent.
• 4:2:2 — chroma à demi résolution horizontale. Utilisé dans l’édition vidéo professionnelle.
• 4:2:0 — chroma au quart de la résolution (moitié horizontale, moitié verticale). Utilisé par JPG, MPEG, H.264, H.265, la plupart des vidéos grand public. Économise ~50 % des données chroma avec une perte de qualité perçue presque nulle pour les photographies.

Où le 4:2:0 échoue : les bords de couleur nets, en particulier le texte. Du texte rouge saturé sur un fond bleu saturé devient visiblement flou. C’est pourquoi les captures d’écran doivent être en PNG (pas de sous-échantillonnage) et les photographies peuvent être en JPG (4:2:0 invisible).

Exemple de calcul

Une image RGB de 1920×1080 stocke 1920 × 1080 × 3 octets = 6 220 800 octets (~6 Mo brut). Convertir en YCbCr 4:4:4 et la taille est identique — 3 canaux à pleine résolution. Convertir en 4:2:2 et les canaux chroma (Cb et Cr) tombent à 960×1080 chacun : total octets = 1920·1080 (Y) + 960·1080·2 (Cb+Cr) = 2 073 600 + 2 073 600 = 4 147 200, une réduction de 33 % des données brutes de plan. Convertir en 4:2:0 et les plans chroma tombent à 960×540 chacun : total = 2 073 600 + 1 036 800 = 3 110 400, exactement 50 % de l’original. JPG, H.264, H.265, AVIF et WebP utilisent tous le 4:2:0 par défaut, c’est pourquoi un JPG “économise 50 %” avant même que la compression DCT ne s’exécute — le sous-échantillonnage de chroma fournit cette base gratuitement.

Les encodeurs modernes adaptent parfois le sous-échantillonnage par région : AVIF et JPEG XL peuvent encoder certaines régions d’image en 4:4:4 et d’autres en 4:2:0 dans un seul fichier, troquant une petite surcharge contre du texte net sur des fonds photographiques. Cette flexibilité par tuile est l’une des améliorations structurelles par rapport à la contrainte de format unique par fichier de JPEG.

Quand et pourquoi c’est important

Le sous-échantillonnage compte chaque fois qu’un flux de travail inclut des bords de couleur nets que le 4:2:0 ne peut pas représenter — captures d’écran de code ou de terminal, art vectoriel avec couleurs saturées, logos avec rouge pur sur bleu pur, exports vectoriels rastérisés pour archive, et toute image où la couleur précise au pixel au niveau des bords est non négociable. La correction est de choisir un format qui utilise par défaut (ou supporte) le 4:4:4 : PNG (pas de sous-échantillonnage du tout), AVIF avec l’encodeur forcé en mode 4:4:4 (--yuv=444 dans libavifenc), JPEG XL, ou WebP lossless moderne. L’erreur inverse — utiliser PNG pour une photographie de 12 mégapixels parce que “PNG est de meilleure qualité” — gaspille 80 %+ de la taille du fichier sur des informations de chroma que le spectateur ne peut pas percevoir. La règle de base professionnelle : photographies → JPG/WebP/AVIF 4:2:0 ; captures d’écran d’interface → PNG ou AVIF 4:4:4 ; contenu mixte → testez les deux et inspectez le résultat à 200 % de zoom autour de tout texte. Référence : Sous-échantillonnage de chroma — formats et notation.

Pourquoi la vision humaine nous permet de s’en sortir ainsi : la rétine possède environ 120 millions de cellules bâtonnets (sensibles à la luminosité, sans information de couleur) et seulement 6 millions de cellules cônes (responsables de la couleur). Le rapport de 20 pour 1 est la raison biologique pour laquelle le sous-échantillonnage de chroma fonctionne — perdre un échantillon de chroma sur deux est invisible pour la plupart des spectateurs, tandis que perdre un échantillon de luma sur deux produit une postérisation évidente. Le même principe sous-tend l’espace colorimétrique YCbCr utilisé par JPG et chaque codec vidéo : séparer le canal qui compte le plus (Y, luma) des deux qui comptent moins (Cb, Cr, chroma) afin que chacun puisse être échantillonné différemment.

Le contre-exemple du terminal-écran : les programmeurs visionnant des screencasts H.264 4:2:0 de code se plaignent régulièrement que le texte semble flou. La correction est soit de passer à un codec compatible 4:4:4 (FFV1, HuffYUV sans perte, ou H.264 en mode 4:4:4 — supporté par Chrome et OBS mais pas par le transcodage standard de YouTube), soit d’enregistrer à une résolution plus élevée pour que la mise à l’échelle à la lecture cache les artefacts chroma. Pour le contenu non textuel (gameplay, vidéo de tête parlante, animation), le 4:2:0 est universellement acceptable. Voir aussi : sRGB, gamma, WebP. Référence : UIT-T T.871 — Format d’échange de fichiers JPEG (JFIF).