La courbe de gamma (et par extension, la valeur de gamme), c’est quoi exactement ? Il s’agit d’une correction effectuée sur les images pour prendre en compte deux choses. La première vient de la réponse de l’oeil humain, qui n’est pas linéaire. La seconde vient des écrans cathodiques, qui ne l’étaient pas non plus. Sous macOS, c’est un sujet intéressant car Apple a changé la valeur il y a quelques années, et l’arrivée du HDR complexifie les choses.
Je ne suis pas spécialiste du sujet, donc je vais essayer de vulgariser un peu pour expliquer les deux causes de l’utilisation de la courbe. Commençons par l’oeil humain. Globalement, l’oeil est beaucoup plus sensible aux variations de luminosité quand l’environnement est sombre que quand il est lumineux. Une bougie allumée dans une pièce sombre sera perçue comme amenant beaucoup de lumières, alors que la même bougie dans une pièce éclairée sera pratiquement invisible. Pour les écrans cathodiques, le problème vient du rapport entre la tension appliquée et la luminosité obtenue. Si on obtient une luminosité x avec une tension y, une tension y/2 ne donne pas une luminosité x/2 mais plutôt une luminosité x/5. Pour obtenir un résultat qui semble linéaire, une correction est donc appliquée avec une valeur de gamma. La forum reste simple : y = x^gamma.
Ce qui est intéressant, c’est que la valeur de gamma varie en fonction des cas. A une époque, les écrans cathodiques utilisaient une valeur de 2,5, mais actuellement la norme est de 2,2. Dans les ordinateurs, les modèles d’Apple utilisaient jusqu’en 2009 une correction avec une valeur de 1,8, alors que les stations SGI travaillaient à 1,7. Typiquement, une image affichée avec un gamma de 1,8 semble plus claire qu’avec un gamma de 2,2 (la norme actuellement). La correction de gamma joue surtout sur la perception des gris, étant donné que le blanc et le noir ne varient pas. Apple avait choisi à la base une valeur de 1,8 en fonction de certaines caractéristiques de QuickDraw et des imprimantes de l’époque, le Mac étant très populaire dans le monde de la PAO. Le passage à 2,2 avec Snow Leopard a simplifié le passage entre le monde PC et le monde Mac, avec une correction identique dans les deux cas.
Ce passage est visible dans les fonds d’écrans de Snow Leopard et Leopard, spécialement avec Abstract 1. Comme Apple a essayé d’obtenir une perception identique, le fond d’écran de Snow Leopard est plus clair que celui de Leopard, étant donné que le gamma de 2,2 de Snow Leopard assombrit l’image. En modifiant rapidement le gamma avec Pixelmator en fonction des valeurs, on voit bien que les différences s’estompent. Dans la majorité des fonds d’écran présents dans les deux OS, le changement est clairement visible quand on ouvre le fichier avec le mauvais OS.
La version Leopard (prévue pour un gamma 1,8)
La version Leopard modifiée pour un gamma 2,2
La version Snow Leopard, prévue pour un gamma 2,2
La version Snow Leopard, modifiée pour un gamma 1,8
A noter que la courbe de gamma peut être modifiée (et l’est) par certains appareils, étant donné qu’elle a été pensée pour les écrans cathodiques mais que ces derniers n’existent pratiquement plus. Les fabricants d’écrans (mais aussi ceux de capteurs) utilisent donc des courbes plus adaptées au matériel que la simple courbe gamma. Enfin, quel rapport avec le HDR ? La gestion des hautes luminosités pose des soucis avec la courbe de gamma classique. Les solutions récentes consistent à utiliser des courbes logarithmiques adaptées aux hautes lumières, avec un codage sur 10 ou 12 bits pour les couleurs. Les solutions se basent soit sur une courbe qui suit celle de gamma sur les basses lumières et une courbe logarithmique sur les hautes lumières (Hybrid Log-Gamma), soit sur des courbes qui contiennent les données pour les écrans classiques et pour les écrans HDR, sous la forme de métonnées ou d’un flux secondaire. Vu que macOS Sierra et les iMac 5K supportent a priori le HDR, j’imagine qu’Apple a planifié un passage sur ce type de courbes.
Une chose importante, quand vous utilisez un appareil photo numérique, le profil ICC de la photo est stocké dans l’image. Grace à ce profil, l’image sera affiché identiquement sur un écran à Gamma 1.8 et 2.2.
Donc le Gamma, n’a pas d’importance pour le développement photo (tant que le profil est sauvegardé, ce qui est le cas des logiciels de gestion d’image).
Maintenant, il me semble que les navigateurs gèrent le profil, ce qui n’était pas le cas avant.
Si le sujet t’intéresse y a eu une longue discussion (en anglais) sur le bug tracker de mpv y a quelques temps, c’est complet et technique :
https://github.com/mpv-player/mpv/issues/534
https://github.com/mpv-player/mpv/issues/2815
Matthieu : oui, c’est assez récent, mais Safari (au moins) gère ça proprement, notamment le Wide Gammut.
Nyx0uf : je regarde ça, merci
Petite side-note sur la fin quand tu parles des courbes HDR. Il se trouve que j’ai étudié la question récemment donc je vais essayer de restituer ce que j’en ai compris.
Le standard ITU BT-2100 a figé les deux seules courbes qui vont être amenées à être utilisées pour le HDR, à savoir la courbe Hybrid-Log Gamma et la courbe Perceptual Quantizer (PQ).
La courbe HLG est, comme tu la décris, une courbe ou on utilise le Gamma sur environ 70% de la courbe, et une courbe logarithmique sur les hautes lumières.
Il faut cependant comprendre que cette courbe est un compromis. Elle est en théorie « rétro-compatible » puisque l’utilisation du gamma sur les basses lumières évites l’effet délavé typique qu’on retrouve avec la courbe PQ lorsqu’on projette l’image sur un écran non compatible.
Cependant, cette méthode est sous optimale puisque le fait de ne modifier que le haut de la courbe limite la luminance maximale que l’on peut coder à environ 1000 nits (1000 cd/m²) en 10 bits (pour éviter de faire apparaître du moiré qui serait lié à un échantillonnage trop imprécis). De plus, le rendu en mode « rétrocompatibilité SDR » peut (en fonction des programmes et de la marge de l’ingénieur vision/l’étalonneur) être parfois assez étrange dans les hautes lumières (c’est assez difficile à décrire mais notamment avec des lumières de face, on a une impression étrange que les hautes lumières ne sont pas naturelles).
La courbe PQ est une approche plus moderne et plus élégante de la question, mais qui est techniquement plus difficile à appréhender pour les fabricants et les diffuseurs, notamment parce qu’elle n’est pas rétro-compatible.
Il s’agit d’une courbe entièrement « nouvelle » basée sur les travaux récents de recherche autour du modèle SVH (système visuel humain). Contrairement à la courbe Gamma, elle a été définie directement d’après les travaux récents sur le psycho-visuel (la courbe de Barten notamment qui décrit comment l’oeil humain perçoit le contraste par rapport à la luminosité).
Il faut aussi comprendre que contrairement au Gamma, la courbe PQ est une courbe qui utilise des valeurs absolues. La courbe représente des valeurs de 0 à 10000 nits. Quel que soit l’écran/le système de diffusion, une valeur prise sur la courbe PQ correspond toujours à la même luminance cible.
La difficulté avec cette courbe est qu’elle est un peu « overkill » à l’heure actuelle puis qu’aucun écran ne permet d’afficher ne serait-ce que sur quelques pixels une luminosité au delà de 5000 nits (et encore, la on parle de quelques écrans prototypes de chez Dolby, loués au compte-goutte pour la production cinéma) et que les meilleurs écrans grand public HDR peinent à atteindre 700 nits.
Ainsi, en PQ, dans la plupart des cas les écrans vont recevoir « trop » d’informations (valeurs de luminance élevées qu’ils sont incapables d’afficher). C’est là que rentrent en comptent les metadata de ce qu’on appelle le « HDR10 » utilisé dans le Blu-Ray.
Les écrans sont en effet incapables de non seulement afficher certaines nuances (valeurs supérieures à leur luminance crête) mais sont surtout incapables de tenir la luminance crête sur l’ensemble de la dalle pour des questions de consommation électrique et de surchauffe (un écran qui possède une luminance crête spécifiée de 1000 cd/m² comme le moniteur professionnel Sony BVM-X300 ne peut pas maintenir cette intensité sur plus de 10 à 20% des pixels de la dalle, un indicateur spécifique est prévu pour alerter l’opérateur quand l’écran se met en sécurité).
Des metadata sont donc incluses dans les flux AVC/HEVC HDR (puis véhiculés dans le signal HDMI 2.0A) qui stipulent la valeur crête maximale présente dans le contenu (MaxCLL) et la valeur maximale de la luminance moyenne sur une image (MaxFALL). C’est ensuite de la responsabilité du fabricant de l’écran d’appliquer une correction adaptée au contenu et dans ses limites de consommation d’après ces metadata.
Je passe rapidement sur le Dolby Vision, qui est entièrement propriétaire, et qui consiste en gros à utiliser une courbe PQ, mais à transmettre les metadata MaxFALL et MaxCLL (+ quelques autres) pour chaque scène (voire pour chaque image) au lieu d’une fois pour tout le programme.
Concernant la rétro-compatibilité, la courbe PQ n’est nativement pas rétrocompatible. Une image PQ affichée sur un écran SDR sans traitement sera toute délavée et n’aura aucun contraste.
Une solution pour régler le problème est d’utiliser des algorithmes de « tone mapping » qui vont créer des matrices de transfert permettant de « traduire » la courbe PQ vers une courbe Gamma, mais la problématique est complexe puisqu’il n’existe aucune matrice « universelle ». En fonction de la nature du contenu (CG, sport, série, interface utilisateur ,…), le rendu doit être calculé différemment (exemple : sur une interface utilisateur on préfèrera maximiser le contraste quitte à supprimer des nuances dans les hautes lumières afin que les boutons/textes ressortent bien, mais un tel traitement sur une image avec un visage humain risque de transformer vos photos de vacances en musée des horreurs).
A l’heure actuelle, plusieurs solutions de tone mapping propriétaires existent et sont implémentées par certains fabricants (Philips/Technicolor notamment), mais il n’y a pas encore de standard défini, ce qui complique un peu les choses, notamment en termes de production/diffusion TV (comment être sur que mon contenu produit avec la courbe X ne va pas être totalement dénaturé chez un client dont le matériel non compatible applique incorrectement la courbe Y). Ajoutons-y les problématiques de conversion d’espace colorimétrique (les contenus HDR sont quasi-exclusivement produits en espace Rec.2020, alors que les écrans SDR sont en espace Rec.709 ou sRGB) et la problématique devient encore plus complexe.
Heureusement, pour les PC/MAC, le standard HDMI 2.0A (et sans doute les dernières versions du DisplayPort mais je les connais moins) permet à l’écran et au diffuseur d’échanger des informations quand à leur capacités (courbes supportées, MaxFALL, MaxCLL, espaces colorimétriques supportés, …) au moment de la négociation.