Courbe de correction gamma

[thom18]

<Parenthese>
Il faut corriger un abus de langage que j'ai également joyeusement commis. C'est lié a la gestion des couleurs. Une image jpeg n'est pas délinéarisée avec un gamma particulier (cf mon post précédent). L'image linéaire est transformée en utilisant les informations du profil avec lequel on veut enregistrer le JPG (sRGB par défaut). Si on utilise un profil totalement linéaire, le jpeg sera enregistré sans transformation. Les ombres seront tres postérisées alors que les hautes lumieres garderont du détail, d'ou une impression de moins bonne qualité qu'un jpeg en sRGB, a taux de compression égal. D'ou l'amalgame entre jpeg et conversion gamma.
</Parenthese>

Ok ! C'est ce que j'avais dit, c'est l'espace colorimétrique qui impose son gamma, pas la norme jpeg.

Non, je ne pense pas. Les systemes actuels sont bien différents de ce que décrivait Poynton (je n'ai pas acces au deuxieme lien). Tout ce que tu envoies a ton écran est ajusté par la gestion de couleur de ton OS, c'est maintenant quasi universel. Elle va utiliser le profil de ton écran, qui peut avoir un gamma, ou plus probablement une LUT non caractérisable par un gamma, pour délinéariser les valeurs RGB de ton image de sorte que les intensités lumineuses que ton oeil recoit soient elles linéaires.

Je doute fortement que L'OS se pose la question de savoir si un fichier est enregistré avec un gamma (ou plus généralement une transformation) qui se trouvera etre l'exact opposé du gamma (ou de la transformation) requis(e) par le profil de l'écran dans le simple but de s'économiser quelques calculs.

C'est sur ce point que je ne suis pas d'accord. Comprends moi bien, jusqu'à vouloir faire un exposé sur la colorimétrie, je ne m'étais pas du tout branché plus sur le gamma que "c'est une correction envoyée à l'écran".

C'est au moment où j'ai vu que chaque espace colorimétrique avait son gamma (et en général 2,2) puis lu à de multiples reprises que "pour compenser le gamma de 2.2 (en fait 2.5) des écrans cathodiques, on avait préféré enregistrer  les données avec un gamma de 1/2.2 tout d'abord en vidéo puis par extension en imagerie numérique pour que la linéarité soit atteinte sans circuit spécialisé intégré à l'écran" que je me suis posé beaucoup de questions car en notant F la réciproque de f, F suivie de f cela me va mais [F suivie de f suivie de f] ou [F suivie de f suivie de F] cela ne me va plus ! Autrement dit deux corrections gamma réciproques l'une de l'autre cela me va mais le rajout d'une troisième identique à une des deux autres non !

L'explication fournie par :

• CIC (https://www.cambridgeincolour.com/tutorials/gamma-correction.htm)
  
• par le lien que tu n'as pas pu lire (http://www.profil-couleur.com/tp/216-correction-gamma.php) dont je fais une copie partielle du contenu ici
  Dès la création de la télévision, les ingénieurs ont compris qu'il serait très compliqué d'installer un dispositif de compensation dans les téléviseurs pour corriger ce problème de gamma car leur nombre allait augmenter de façon exponentielle dans les années futures et leur prix s'en serait ressenti. Le plus simple à ,l'époque était de traité le problème à la source, c'est à dire à l'intérieur même de la camera vidéo. Pour corriger les atténuations de luminance que produit le moniteur, il suffit d'appliquer une sur-amplification sur les niveaux de gris au sein même de la caméra. On appelle ce dispositif la correction du gamma ou compression du gamma ou bien encore la courbe de transfert. La correction du gamma des images dès la source est donc devenu le flux standard en vidéo et par extension, il s'est propagé dans le domaine de l'informatique puis de la photographie numérique. Le gamma standard qu'on applique dans cette courbe de transfert est un gamma de 2,2 car il correspond à la norme sRGB.
  Dans la chaine numérique, on va donc considérer comme normale la restitution non linéaire du moniteur, on ne va pas tenter de corriger matériellement cet état de fait, mais simplement corriger en amont tous les fichiers-image pour qu'un gris moyen s'affiche correctement. On applique aux image un traitement automatique qui correspond à une courbe inverse de celle du gamma.
  

• et par Arnault Frich dans un résumé visuel en tout début de son article (https://www.guide-gestion-des-couleurs.com/le-gamma.html) car ensuite il s'égare en liant cela à la vision humaine de manière marquée.

Pour résumé, je suis d'accord pour dire que même s'il y a dans la correction gamma de 1/2.2 une ressemblance avec la vision par l'oeil humain, ce n'est pas l'explication du gamma et que celle-ci tient sans doute dans le défaut initial des écrans cathodiques.
Ensuite l'histoire a sans doute un peu pataugé mais toujours est-il qu'il semble bien qu'on a décidé de corriger le gamma des moniteurs simplement par un gamma inverse à l'enregistrement des images. La mise en place normalisée des profils colorimétriques a formalisé le tout essentiellement d'abord sur sRVB avec un gamma de 1/2.2 et des moniteurs à gamma 2.2 (même Apple s'y est conformé). Ensuite que les mécanismes actuels de CMS permettent des affinements et des contrôles plus sophistiqués je n'en toute pas mais il me semble que le principe de correction du gamma affecté à l'écran LCD par l'enregistrement d'une image au gamma sensiblement inverse reste fondamental.

Je peux me tromper, dans ce cas je ne serais pas le seul. Nous avons utilement discuté de ce point et j'aurais espéré des contributions constructives par les spécialistes des profils écrans qui se sont manifestés sur d'autres fils. La seule contribution que nous avons eu jusque là ne me semble pas pertinente, que viennent faire les IL ici ?

Cordialement.

[egtegt²]

Un petit lien qui n'a rien à voir mais est basé sur le même principe : 

http://www.yfolire.net/humr/humeur18.htm

[Franciscus Corvinus]

Pour résumé, je suis d'accord pour dire que même s'il y a dans la correction gamma de 1/2.2 une ressemblance avec la vision par l'oeil humain, ce n'est pas l'explication du gamma et que celle-ci tient sans doute dans le défaut initial des écrans cathodiques.
Ensuite l'histoire a sans doute un peu pataugé mais toujours est-il qu'il semble bien qu'on a décidé de corriger le gamma des moniteurs simplement par un gamma inverse à l'enregistrement des images. La mise en place normalisée des profils colorimétriques a formalisé le tout essentiellement d'abord sur sRVB avec un gamma de 1/2.2 et des moniteurs à gamma 2.2 (même Apple s'y est conformé). Ensuite que les mécanismes actuels de CMS permettent des affinements et des contrôles plus sophistiqués je n'en toute pas mais il me semble que le principe de correction du gamma affecté à l'écran LCD par l'enregistrement d'une image au gamma sensiblement inverse reste fondamental.

D'accord avec tout ca sauf le bout en gras.

Je ne suis absolument pas sur que les profils d'écran actuels utilisent un quelconque gamma, et donc que la notion de gamma soit toujours fondamentale. Je soupconne qu'ils utilisent une LUT plus alambiquée---et pas juste une variation sur le theme du gamma. Car la réponse des sous-pixels est trop différente de celle d'un canon a électron (cf. doc de Fujistsu) pour etre facilement représentable par une courbe en gamma. Mais j'atteinds la les limites de mon expérience directe.

Ce qui laisserait pour seul role moderne a la fonction gamma de "limiter la casse" en imitant la vision humaine quand une faible profondeur d'échantillonage force la perte d'information. En clair, un JPG, en sRGB.

[asak]

Si vous le trouvez correct, une simple question se pose à moi : une image enregistrée sous un profil ProPhoto a un gamma de 1,8 mais le moniteur lui a un gamma de 2,2 et la jolie explication de mon document rencontre un petit problème à moins qu'il ne faille complètement délaisser ProPhoto au profil d'espaces au gamma de 2,2.
Pour ton exemple l espace profoto est prévu pour un gamma 1.8 ; mais il n embarque pas le gamma 1.8.  L image est développée avec le gamma 2.2 ; donc les primaires et gris etc sont décalées par rapport au profoto 1.8 mais ça n a aucune importance puisque en enregistrant tu valides le codage des couleurs de ton image.
Le prostar est un profoto avec des primaires recalculée pour s adapter à la courbe L*   l avantage est que les mode rvb tsl et cmyn sont aligné sur les gris
Je penses que la notion de delta E est à introduire notamment le 2000
Sur un écran il n y a pas que le gamma ; il y a aussi le point noir le taux de contraste  le v2 ou v4 les luts l'émulation etc... tous les ecrans ne sont pas égaux et ont des systèmes de fonctionnements différent depuis les systèmes rétroéclairage  led

[jenga]

Non, je ne pense pas. Les systemes actuels sont bien différents de ce que décrivait Poynton (je n'ai pas acces au deuxieme lien). Tout ce que tu envoies a ton écran est ajusté par la gestion de couleur de ton OS, c'est maintenant quasi universel. Elle va utiliser le profil de ton écran, qui peut avoir un gamma, ou plus probablement une LUT non caractérisable par un gamma, pour délinéariser les valeurs RGB de ton image de sorte que les intensités lumineuses que ton oeil recoit soient elles linéaires.

J'ai lu avec grand intérêt les explications données dans ce fil, merci! J'ai une interrogation sur la gestion des couleurs.
D'après ce que j'ai compris, la transformation entre les valeurs RGB à afficher et ce qui est effectivement envoyé à l'écran comporte deux étapes:

-une transformation matérielle: dans la carte graphique, des LUTs transforment les valeurs RGB émises par l'application pour compenser en partie l'écart entre la réponse de l'écran et la réponse souhaitée.
Le contenu des LUTs est défini lors de l'étalonnage, qui commence par le réglage physique de l'écran pour l'approcher du point de fonctionnement souhaité. Puis, le logiciel de calibration détermine, avec une sonde, les données à charger dans les LUT pour améliorer l'approche (ces données sont stockées dans le profil icc, sous la rubrique « vcgt ») ;

-une transformation logicielle; la caractérisation, effectuée également par le logiciel de calibration, consiste à mesurer l'écart entre le rendu voulu et le rendu obtenu après étalonnage, et à en déduire les données de correction (stockées également dans le profil icc, rubrique « TRC »);
Ces données sont utilisées par les applications qui gèrent les couleurs pour qu'elles corrigent en conséquence les valeurs transmises à la carte graphique.

Ainsi, tout affichage à l'écran bénéficie de la correction matérielle par les LUT de la carte graphique, mais seules les applications gérant la couleur exploitent les données de caractérisation pour une correction plus complète des écarts..
J'ai fait quelques expériences avec des profils volontairement très faux, produisant des écarts de couleurs qui sautent aux yeux, pour mettre en évidence ces deux aspects, et il me semble que ça fonctionne bien comme cela (sous Ubuntu, en tout cas).

Cette description est-elle correcte?

[egtegt²]

Tu as oublié un élément : la quantification sur 8 bits.
Si on travaille en linéaire sur 8 bits, on a 256 valeurs, de 0 à 255. Mais comme la photographie fonctionne sur un principe logarithmique, c'est à dire qu'augmenter d'un cran revient à multiplier par deux, on attribue 1 au premier cran, le second à 2, le troisième 4 et ainsi de suite jusqu'à 128 puis 256.

On voit bien qu'entre 1 et 2, on n'a pas de valeur intermédiaire, et entre 2 et 4 juste une. Donc dans ce cas, les 3 premiers IL auront 4 valeurs différentes possibles, alors que les 3 derniers auront de 64 à 256 soit 192 valeurs possibles. 

Le résultat, c'est que tu auras du banding dès que tu auras un aplat dans des zones sombres car tu ne disposeras pas d'assez de valeurs différentes pour différentier les teintes.

Pour palier à ça, les concepteurs du JPEG ont décidé de permettre d'appliquer un gamma qui fait qu'on va à l'enregistrement augmenter la valeur des zones sombres et diminuer celle des zones claires. Ca permet d'augmenter les valeurs dans les zones sombres et donc les nuances disponibles. Et quand on affiche, on rétablit les bonnes valeurs en appliquant le gamma inverse.

Dans les faits, si on est en 8 bits sur toute la gamme, ça ne change que si on retravaille la photo, à cause des erreurs d'arrondi, mais si on affiche sur une carte graphique 10 bits par exemple, le gamma appliqué à l'affichage peut être appliqué sur 10 bits donc en récupérant à nouveau des nuances sur les tons sombres.

[thom18]

Comme suggéré par Franciscus Corvinus, j'ai refait mon document après avoir consulté de nombreuses autres sources d'information fiables. Je n'ai effectivement pas souhaité reprendre l'analogie avec la vision humaine qui ne me semble pas de nature explicative par la correction gamma. Le gamma de 2,2 des écrans et celui de 1/2,2 des espaces colorimétriques ont été traités à part et je laisse à chacun son opinion sur cette coïncidence.
Voici en deux images le document final qui devait ne faire qu'une seule page.

Cordialement et merci  tous.

[egtegt²]

En tout cas, c'est bien plus clair que la précédente version ! Et du peu que je connais, ça me semble correct et cohérent.

[Franciscus Corvinus]

Ca m'a l'air beaucoup mieux. C'est plus "tight", focalisé sur la problématique. Les exemples fonctionnent bien. Le "flux" des idées s'enchaine bien. Le langage reste simple et direct, facile a comprendre.

La seule chose qui manque, c'est le "so what", c-a-d, pourquoi doit-on en tenir compte en tant que photographe? Répondre a cette question est beaucoup plus difficile. Mais c'est peut-etre le sujet d'une autre page...

[Tonton-Bruno]

Bravo, c'est clair et concis, mais comme le dit Francis dans son sabir "et alors?"

La suite au prochain numéro ?

[thom18]

Ce paragraphe est une partie d'un document de présentation de la colorimétrie pour le photographe destiné aux membres de mon PhotoClub. La question "Qu'est ce que le gamma ?" s'est déjà posée lors d'un calibrage d'écran et voilà donc maintenant un document concis et précis pour y répondre.
Cordialement à tous.

[B_M]

Merci messieurs - thom18 et Franciscus Corvinus notamment - pour cette discussion. Une clarification que j'attendais depuis longtemps.

[Verso92]

Comme suggéré par Franciscus Corvinus, j'ai refait mon document après avoir consulté de nombreuses autres sources d'information fiables. Je n'ai effectivement pas souhaité reprendre l'analogie avec la vision humaine qui ne me semble pas de nature explicative par la correction gamma. Le gamma de 2,2 des écrans et celui de 1/2,2 des espaces colorimétriques ont été traités à part et je laisse à chacun son opinion sur cette coïncidence.
Voici en deux images le document final qui devait ne faire qu'une seule page.

Il y a toujours un truc qui m'échappe un peu : tu écris que le capteur a un comportement linéaire face à la luminance, et qu'on doit procéder à une correction gamma pour garder des détails dans les tons sombres... soit.

Mais la conjugaison du gamma "en 1/x" appliqué au fichier et du gamma "en x" de l'écran aboutit à une restitution linéaire à l'écran, au bout du compte... quid des détails dans les tons sombres ?

[B_M]

idem Verso. Le ciel s'éclaircit mais n'est pas encore parfaitement bleu. 
Je vois les choses ainsi : première courbe pour une question de précision de la quantification dans les ombres. Deuxième pour retour mais avec des ombres bien codées cette fois

[Franciscus Corvinus]

Il y a toujours un truc qui m'échappe un peu : tu écris que le capteur a un comportement linéaire face à la luminance, et qu'on doit procéder à une correction gamma pour garder des détails dans les tons sombres... soit.

Mais la conjugaison du gamma "en 1/x" appliqué au fichier et du gamma "en x" de l'écran aboutit à une restitution linéaire à l'écran, au bout du compte... quid des détails dans les tons sombres ?

L'étape qu'il te manque, c'est la troncation des bits 9-16, qui intervient entre les deux gammas. Cette troncation, si elle se faisait sur un fichier codé en linéaire, produirait une forte *perception* de perte de détails dans les ombres par rapport aux hautes lumieres.

[Verso92]

L'étape qu'il te manque, c'est la troncation des bits 9-16, qui intervient entre les deux gammas. Cette troncation, si elle se faisait sur un fichier codé en linéaire, produirait une forte *perception* de perte de détails dans les ombres par rapport aux hautes lumieres.

Pas vraiment compris où tu voulais en venir... et puis, pourquoi y aurait-il une troncature ?

[asak]

Finalement la carte graphique et ses tables ne servent  à rien si c est l 'écran qui corrige applique le gamma. Je penses qu'il faut bien faire la différence moniteur / téléviseur; bien que les écrans hardware..
Quand aux 9/16 bits il serait bon de faire un synoptique pour bien comprendre le cheminement analogique numérique.

[Franciscus Corvinus]

Pas vraiment compris où tu voulais en venir... et puis, pourquoi y aurait-il une troncature ?

Pour deux raisons. D'une part notre ami parle de fichiers JPG comme intermédiaires. D'autre part les écrans ne prennent que 8 bits (sauf modeles récents haut de gamme).

[Verso92]

Pour deux raisons. D'une part notre ami parle de fichiers JPG comme intermédiaires. D'autre part les écrans ne prennent que 8 bits (sauf modeles récents haut de gamme).

Ben oui... mais le Jpeg n'est qu'un cas parmi d'autres (que beaucoup ici n'utiliseront pas comme fichier de base).

Sinon, je ne vois pas trop le rapport avec le gamma de l'écran... il est codé dans un espace beaucoup plus large que 8 bits, non ?


(le fait qu'il ne restitue que 8 (ou 10) bits au final n'est pas la question... d'ailleurs, les LUT intégrées aux écran à étalonnage hardware sont sur 14 bits, par exemple)

[Franciscus Corvinus]

Ben oui... mais le Jpeg n'est qu'un cas parmi d'autres (que beaucoup ici n'utiliseront pas comme fichier de base).

On est d'accord, mais l'OP a choisi de ne s'intéresser qu'a ce cas. Ce qu'il dit n'est pas techniquement faux, mais il faudrait expliquer en clair que ca n'est pas extrapolable a d'autres formats ou a des images stockées dans un espace couleur qui utilise des gammas différents (voire pas de gamma du tout).

Sinon, je ne vois pas trop le rapport avec le gamma de l'écran...

Comme l'OP le dit, le gamma de sRGB est de 2.2 et celui des écrans 1/2.2 (gross modo). L'absence d'information concluante ne permet pas de savoir s'il s'agit d'une coincidence ou pas. C'est a chacun de se faire son avis. Pour ma part, l'ubiquité de la gestion des couleurs rend ce rapport caduque: il me semble avoir lu (je n'arrive pas a retrouver ou), que certains écrans maintenant se dispensent d'émuler des espaces traditionnels et leurs gammas 1/2.2. Donc le gamut de l'écran décrit directement la réponse des sub-pixels.

il est codé dans un espace beaucoup plus large que 8 bits, non ?

Pas clair pour moi. Qui est "il"? Le gamut (pas le gamma) de l'écran? Mais il y a une différence entre la précision du gamut et celle de l'image.

(le fait qu'il ne restitue que 8 (ou 10) bits au final n'est pas la question... d'ailleurs, les LUT intégrées aux écran à étalonnage hardware sont sur 14 bits, par exemple)

Restituer sur 8 bits est un probleme suivant ou dans la chaine de l'image tu le fais. Si tu tronques sur 8 bits un signal linéaire, l'oeil percevra de la postérisation dans les ombres. Donc il faut etre clair sur les points de la chaine de l'image ou de telles troncatures ont lieu. Il faut tenir compte du fait que l'interface physique ordi-écran peut restreindre l'image a 8 bits par canal (DisplayPort dans certaines configurations par exemple, ce qui est une limitation surprenante de la part d'un standard "moderne"). Donc tu as intéret a appliquer un gamma avant et son inverse apres (idéalement 1.45), quelle que soit la capacité de l'écran a restituer beaucoup de bits.

[thom18]

Bonsoir à tous, je rentre de vacances et je vais prendre soin de répondre aux questions qui directement ou indirectement me sont posées. Réponses accompagnées dans la mesure du possible par des liens qui les confortent.

Il y a toujours un truc qui m'échappe un peu : tu écris que le capteur a un comportement linéaire face à la luminance, et qu'on doit procéder à une correction gamma pour garder des détails dans les tons sombres... soit.
Mais la conjugaison du gamma "en 1/x" appliqué au fichier et du gamma "en x" de l'écran aboutit à une restitution linéaire à l'écran, au bout du compte... quid des détails dans les tons sombres ?

Avoir une restitution linéaire au final est le but du jeu depuis le début : les écrans de télévision avaient une distorsion gamma d'environ 2,5 qu'on a pas cherché à corriger mais on a appliqué une correction gamma inverse aux images vidéo.
Ensuite, comme le dit avec humour le texte cité par egtegt² (http://www.yfolire.net/humr/humeur18.htm), la norme perdure et se développe en informatique, photographie numérique et télévision HD numérique ...

Par contre, hasard ou pas, on a réussi a utiliser l'application d'une fonction de transfert en 1/gamma aux images au plus tôt dans le codage pour améliorer le rendu des ombres par ce même codage. Cette application d'une fonction de transfert ne s'occupe pas de savoir si c'est du jpeg ou du TIFF, c'est l'espace colorimétrique qui l'impose : elle peut être 1/gamma avec gamma=1,8 pour ProPhoto (16 bits), avec gamma =2,2 pour Adobe RVB (https://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf) ou en L* pour ProStar (16 bits) et sensiblement un gamma de 1/2,2 sauf au voisinage de 0 pour sRVB.
cf http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html

Ensuite, du côté moniteur, on va trouver des moniteurs simples avec un gamma imposé que l'on espère être 2,2 uniformément sur la totalité du spectre jusqu'à des moniteurs ou la fonction de transfert peut être choisie entre des gammas 1 -> 3, L* (surement l'inverse du L* des images en toute logique) et même injectée dans les LUT.
Cf par exemple un Eizo où le mode d'emploi précise :
Le réglage par défaut de chaque mode AdobeRGB(CX240 uniquement))/sRGB est réglé sur «Standard», qui correspond au gamma de chaque standard. La courbe du gamma peut être réglée à L* à l'aide de ColorNavigator.

Je n'ai pas souhaité expliqué le gamma par la vision de l'oeil même si c'est souvent fait et que j'avais commencé ainsi dans mon premier document. A bien y réfléchir, c'est à la fois une réécriture de l'histoire et un masquage de compréhension de  la réalité puisque avant tout on a voulu annuler le méchant gamma des moniteurs CRT par un gamma inverse des images pour avoir en fin de compte un rendu linéaire.

idem Verso. Le ciel s'éclaircit mais n'est pas encore parfaitement bleu. 
Je vois les choses ainsi : première courbe pour une question de précision de la quantification dans les ombres. Deuxième pour retour mais avec des ombres bien codées cette fois

Je pense que tu avais parfaitement compris.
Je redonne ici le lien vers un document partie d'un cours universitaire qui me semble explicite. http://www.claudegabriel.be/B2%20Lumi%C3%A8re%20et%20image,%20chapitre%209.pdf

Finalement la carte graphique et ses tables ne servent  à rien si c est l 'écran qui corrige applique le gamma. Je penses qu'il faut bien faire la différence moniteur / téléviseur; bien que les écrans hardware..
Quand aux 9/16 bits il serait bon de faire un synoptique pour bien comprendre le cheminement analogique numérique.

Mais le gamma n'est qu'une partie de la correction colorimétrique, comme dit plus haut dans certaines configurations haut de gamme on peut régler son gamma moniteur aux petits oignons en utilisant les LUT, l'objectif n'étant plus d'avoir parfaitement la fonction réciproque de celle appliquée au codage des images mais un mieux qu'on espère sensible. Là où tout se complique c'est quand en plus, on change de fonction de transfert dans les images en choisissant des espaces colorimétriques divers et variés ...

D'autre part, les profils ICC d'un écran peuvent selon le type d'écran être chargés dans les LUT si l'écran autorise la correction hardware et elles ont alors un rôle de correction des couleurs par tables autre que la correction gamma.

En ce qui concerne l'éventuelle conversion 16 bits vers 8 bits évoquée par Corvinus Franciscus, je lui laisse le soin d'être plus précis mais ce que j'ai à dire c'est qu'une conversion 16 bits vers 8 bits ne peut se faire par troncature que dans le cas d'un type de codage très spécifique pour le 16 bits dont je ne sais même pas s'il est utilisé. Je ne suis pas un spécialiste de la conversion 16 bits /8bits et je ne pense pas qu'elle éclaircisse la notion de gamma tant est que la norme des espaces colorimétriques ne distinguent pas si le codage est en 8 bits ou en 16 pour appliquer une fonction de transfert inverse gamma ou L*. C'est certes peut être inutile en 16 bits mais on traine l'histoire egtegt² dirait le "cul d'un cheval romain". Peut-être qu'un jour ....

Cordialement à tous.

[thom18]

Finalement la carte graphique et ses tables ne servent  à rien si c est l 'écran qui corrige applique le gamma. Je penses qu'il faut bien faire la différence moniteur / téléviseur; bien que les écrans hardware..
Quand aux 9/16 bits il serait bon de faire un synoptique pour bien comprendre le cheminement analogique numérique.

Je voudrais reprendre ma réponse à cette remarque faite par asak car il se trouve qu'hier j'ai avec une nouvelle sonde et le logiciel DisplayCal fait un nouvel étalonnage de mon moniteur qui est équipé d'une dalle IPS 16x10 d'entrée de gamme simplement. Ma réponse précédente omet totalement le fait que le gamma des moniteurs n'est pas forcément parfaitement uniforme surtout sans doute pour des modèles de début de gamme.
Les courbes de corrections suivantes ont été chargées dans la carte graphique. Le gamma du moniteur est réglé à 2,2 ; la consigne donnée au logiciel d'étalonnage est gamma=2,2. Selon ma compréhension, (après lecture de la documentation DisplayCal) ces courbes sont les correctifs nécessaires afin que le gamma de 2,2 soit uniformément appliqué sur toutes les valeurs d'entrée. On voit que sur les deux tiers gauche un simple correctif de gamma=1,1 environ sur les trois canaux R G B est nécessaire pour atteindre la cible mais que sur la partie droite des hautes luminosités l'écran nécessite une correction plus forte pour que la cible gamma=2,2 soit uniformément atteinte.
Cordialement à tous.

[asak]

Il faut oublier ce que tu as écrit  sur le gamma; issu des écrans cathodique qui n'ont plus cours. La seul vrai linéarisation qui est utilisée est software ... adobe..c1..et tous les autres. La référence de base est http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1886-0-201103-I!!PDF-F.pdf          qui n'a peut être plus vraiment cours. Le gamma de base est 2.21 mais il subit quelques arrangement d'usine de conception pour avoir le plus grand gamut avec un DE dans les normes ? ( les primaires de l'espace couleurs défini ).
Tu dois assurer aussi l'échelle de gris défini de 0 à 100ire; la luminosité le contraste.
Quand les correcteurs de luminosité et de contraste.. bougent respectivement la courbe de luminance  (les noirs) et en haut (les blancs). Celui du gamma permet, en bougeant l'ensemble de la courbe, de modifier la luminosité globale de l'image sans altérer l'équilibre entre chaque palier de l'échelle de gris. On peut en écrire quelques pages toutes différentes en fonction de la technologie ( financier ) employée et de la calibration usine ou etalonnage et calibration personnalisée.
Voilà une calibration d'usine en gamma 2.2. Naturellement ont peut inventer différentes courbes ou utiliser les nombreuses qui existes

[thom18]

Bonjour,
Me répondre avec les normes établies en 2011 puis 2015 (https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-F.pdf) pour la production de programmes télévisés en HD puis prochainement en HDR (https://imagingscience.com/2017/06/08/goodbye-gamma-hello-e-o-t-f/) me parait quelque peu en avance pour gommer tout ce que j'ai écrit sur le gamma d'autant que la fabrication mathématique des nouvelles fonctions de transfert n'est pas très éloignée de celles du gamma basique (ou plutôt sRVB) et que la notion de correction à la source puis à la visualisation demeure.
En ce qui me concerne, et je pense que c'est le cas de nombreux autres photographes amateurs, je n'utilise pour l'instant au développement avec C1 que sRGB ou Adobe RGB donc un gamma 2,2 ou sensiblement tel et à la reproduction un écran que j'ai étalonné pour avoir un gamma de 2,2.

Cordialement.

[asak]

quelque peu en avance pour gommer tout ce que j'ai écrit sur le gamma
La réponse gamma d'un écran Led ressemble plus à une fonction affine; on utilise un correction Log pour une histoire de rendu (2.2 ou 2.4 en rec 709 par exemple ) La fonction Log inverse pour linéariser n'existe plus; elle est juste utilisée dans les soft pour les profils linéaires.