Gamma

Le gamma est la relation non linéaire entre les valeurs de pixels stockées dans un fichier image et l’intensité lumineuse réelle qu’un écran émet. Mathématiquement : intensité_sortie = valeur_entréeγ, où γ ≈ 2,2 pour le standard sRGB.

Pourquoi ce n’est pas simplement linéaire : l’œil humain est bien plus sensible aux différences dans les tons sombres que dans les tons clairs. Un encodage linéaire gaspillerait la majorité des 256 valeurs d’un canal 8 bits sur des détails de hautes lumières que personne ne peut voir, tout en écrasant les tons sombres en quelques valeurs à peine distinguables. L’application du gamma alloue davantage de l’encodage aux valeurs sombres là où l’œil compte vraiment.

Concret : une valeur de pixel 8 bits de 128 (à mi-chemin entre 0 et 255) ne signifie pas la moitié de l’intensité lumineuse. Elle signifie environ 22 % de l’intensité maximale, car 128/255 = 0,502, et 0,502² (gamma 2,2 est bien approximé par le carré) ≈ 0,252. L’intuition : les valeurs de gris moyen sont en réalité assez sombres en lumière linéaire.

Implications pratiques : mélanger deux couleurs dans un espace sRGB « normal » produit des résultats qui semblent trop sombres — la moyenne du noir et du blanc en sRGB semble beaucoup plus sombre que le point médian optique. Les logiciels comme Photoshop et Figma offrent des options de « mélange linéaire » qui convertissent en lumière linéaire, calculent la moyenne là, puis ré-encodent. Le color-mix(in oklab, ...) de CSS fait cela automatiquement. Les outils tenant compte du gamut gèrent cela de façon transparente ; les calculs hex manuels généralement non.

Exemple concret

Prenez le rouge pur sRGB #FF0000 (255, 0, 0) et le vert pur #00FF00 (0, 255, 0). Moyenne naïve dans l’espace sRGB : ((255+0)/2, (0+255)/2, 0) = (127, 127, 0), un olive boueux. Convertissez d’abord chaque composant en lumière linéaire (élevez à 2,2) : R→1,0, G→1,0 chacun. Moyenne en linéaire : (0,5, 0,5, 0). Reconvertissez en sRGB (élevez à 1/2,2) : (188, 188, 0) — un jaune beaucoup plus vif, plus crédible. La différence entre (127, 127, 0) et (188, 188, 0) sur un écran calibré est la différence entre « pourquoi mon dégradé semble-t-il boueux ? » et « ah, ça semble correct. » Chaque outil d’édition d’images avec une case « mélange linéaire » propose exactement cet échange. CSS prend maintenant en charge color-mix(in oklab, red, green) qui effectue la conversion automatiquement.

Quand et pourquoi cela importe

Le gamma importe chaque fois que des couleurs sont combinées, mises à l’échelle ou lissées — ce qui se passe dans pratiquement chaque pipeline de rendu. La raison pour laquelle les moteurs 3D produisent une sortie délavée, à faible contraste, sauf s’ils sont explicitement conçus pour faire du rendu correct en gamma : les intensités lumineuses s’additionnent linéairement en physique, mais les valeurs de pixels sont encodées en gamma. Les moteurs de jeu modernes (Unreal, Unity) effectuent tout l’éclairage dans l’espace linéaire et convertissent en sRGB à l’écriture finale du framebuffer. Le conseil pratique pour les web designers : utilisez oklab ou oklch pour tout dégradé qui traverse des teintes, et évitez le gris moyen (50 % de luminosité) comme mélange pur à 50 % — le point médian optique entre le noir et le blanc est plus proche de L*=50 en CIELAB, soit RGB 188, pas RGB 128. Référence : W3C — Espace de couleur sRGB.

Gamma d’affichage vs gamma d’encodage vs gamma système : l’image sRGB encodée utilise une fonction de transfert proche d’une puissance 1/2,2 (la courbe sRGB formelle est linéaire par morceaux pour les valeurs les plus sombres et un exposant de 2,4 au-dessus), l’écran applique un gamma inverse d’environ 2,2 pour convertir la valeur en lumière, et le produit — le « gamma système » que le spectateur perçoit réellement — est légèrement supérieur à 1,0. macOS avant 10.6 (2009) utilisait un gamma système de 1,8 hérité des premières imprimantes Apple LaserWriter, c’est pourquoi les images créées sur Mac semblent souvent délavées sur les moniteurs PC ; macOS moderne utilise 2,2 comme tout le monde.

HDR brise entièrement ce modèle : les formats HDR (Rec. 2100 PQ, HLG) utilisent des courbes de quantification perceptuelle conçues pour des écrans pouvant atteindre 1 000 à 10 000 nits, pas les ~80 nits de CRT pour lesquels sRGB a été conçu. Mélanger du contenu sRGB avec du contenu HDR nécessite un mappage de tons explicite — un sujet que les compositeurs d’OS gèrent maintenant mais que les applications géraient mal historiquement. Voir sRGB, Display P3, et profils ICC pour la manière dont les espaces de couleur gèrent les mêmes valeurs de pixels différemment. Référence : Spécification sRGB IEC 61966-2-1.