exposition et filmique

[aurelienpierre]

Comme ça n'est pas possible, je fais une compression gamma à la sortie de filmique pour remettre le gris à 18 %, de façon à ce que le gamma de sortie le replace à 45 %. 

Et quand on utilise des profils de sortie dont la TRC n'est pas un gamma, que se passe t-il ?

Je parle ici d'un encodage gamma, pas d'une TRC. La TRC, c'est la fonction dont l'inverse permet de linéariser les défauts de l'écran. L'encodage gamma permet d'éviter la postérisation due aux erreurs d'arrondis dans les fichiers encodés en entiers, en redistribuant la plage dynamique de façon plus homogène entre les bits d'encodage. Cet encodage est inversé dans le convertisseur numérique/analogique de l'écran, car les écrans LED/LCD sont à présent à peu près linéaires (en émission lumineuse), donc il est neutre sur le plan mathématique.

Il y a toujours un encodage gamma dans les espaces de sortie, car ce sont des formats encodés en entiers 8/16 bits (TIFF/JPEG/PNG) ou 8/10 bits (sortie vidéo -> écran).

L'enfer du monde ICC, c'est que tu exportes ton pipe couleur vers un fichier dont l'espace RGB est encodé en gamma (genre sRGB). La carte graphique prend l'espace RGB du fichier, inverse le gamma sRGB (donc linéarise), applique la TRC inverse de l'écran (si étalonné), ré-encode avec le gamma de l'écran (2.2, si tu as étalonné, sRGB sinon), puis l'électronique interne de l'écran décode à nouveau le signal vidéo (donc relinéarise) pour finir avec un truc linéaire.

Dans l'histoire, le standard ICC ne fait rien pour s'assurer de la concordance entre les couleurs d'origine (telles que capturées par l'appareil) et les couleurs de destination (écran, imprimante) mais s'assure seulement que ce que tu vois sur ton écran va être identique à ce que verra le voisin sur son écran ou son imprimante. C'est radicalement différent. ICC fait correspondre les sorties entre elles, pas l'entrée et la sortie.

Ça implique que les conversions de profil à profil ICC (d'espace à espace RGB) autorisent des virages de teintes (notamment comme effet secondaire des ajustements de gamut), et donc risquent de flinguer ton travail sur la couleur de façon subtile et tordue. Par exemple, imagine que tu pousses la saturation du cyan dans ta retouche, mais que la conversion vers l'espace écran dégrade le cyan vers le vert : non seulement, ton réglage n'a plus l'effet escompté intuitivement, mais en plus il faut rajouter une seconde étape de correction de la teinte. Et c'est un cas qui se produit fréquemment, sur les écrans moyen-bas de gamme, qui ont souvent des soucis de cassure du gamut dans les couleurs secondaires.

Pour éviter ça, il faudrait court-circuiter toute la chaîne ICC pour contrôler directement les valeurs utilisées par l'écran, et passer par des options de preservation de la chrominance, c'est à dire que l'énergie lumineuse du pixel soit corrigée en fonction de la réponse de l'écran, mais que le spectre lumineux soit conservé identique entre l'entrée et la sortie. Mais ça n'est pas possible sur les OS actuels, qui intègrent la chaîne ICC par défaut (s'ils sont gérés en couleur), donc il faut user d'artifices mathématiques pour simuler la déviation dûe aux conversions, et la pré-corriger en amont, avec les hypothèses sales et les approximations/erreurs/compromis que ça suppose.

C'est ici, en fait, que ne pas étalonner son écran est presque mieux : certes, on perd la cohérence d'un écran à l'autre (ou de l'écran au tirage), mais la retouche est d'avantage What You See Is What You Get. Si tu satures le cyan, tu voies le cyan se saturer, pas virer vers le vert. Par contre, ça risque de ne pas être le même cyan que sur l'écran du voisin.

Et c'est entre autres une des raisons pour lesquels l'industrie du cinéma n'utilise pas ICC mais OpenColorIO. Sauf que le petit monde de la photo est tellement occupé à se demander ce que ferait Adobe qu'il a en oublié de se tourner vers l'avenir.