Courbe de correction gamma

[dioptre]

Mon problème était différent.
Mes Jpg s'affichaient correctement sur l'écran du Mac mais ils étaient trop contrastés sur l'image projetée par le vidéoprojecteur connecté au Mac, d'où la nécessité de refaire un profil spécifique sur le Mac avec gamma 2.2 quand on voulait utiliser un vidéoprojecteur.

Je pense que les logiciels conçus au départ sur Mac avant 2009 peuvent très bien avoir encore aujourd'hui des routines de traitement basées sur le gamma 1.8, comme tu l'as mis en évidence pour Capture One, et juste faire une transposition finale en 2.2 avant affichage.

Tu n'avais rien à refaire. Juste cocher une case.
Voir ma petite image un peu plus haut

[Verso92]

Pareil j'ai interverti les deux exposants à la page précédente.

Il me semblait bien, aussi...  ;-)

[Verso92]

Oui, c'est transparent, mais il n'utilise pas forcement un gamma de 0,45. En fait il utilise le gamma du profil de ton moniteur.  Par ex, comme je crois que t'es en L*, il va faire une transformation du gamma du profil de sortie choisi dans CO vers le gamma de ton moniteur. ( et de la même façon, il va y avoir un changement de gamut) .

Une chose me chiffonne, quand même : si le CMS compense automatiquement le gamma de l'écran (par l'application d'un gamma inverse, à la louche), on ne devrait plus discerner de différences visibles en fin de chaine sur l'image développée entre les gammas 1.8 et 2.2, mais aussi entre les gammas 2.2 et L*, non ?

Or, il semblerait que le gamma L* soit plus performant pour l'affichage à l'écran des tons sombres, mais qu'il pose aussi des problèmes à certains lors de l'adéquation image visualisée à l'écran vs image imprimée (les tons sombres apparaitraient plus sombres, plus bouchés, que ce qu'on voit à l'écran...).

Quid ?


A ce propos, j'ai retrouvé une discussion sur Chassimages qui aborde le sujet :
https://www.chassimages.com/forum/index.php/topic,241817.msg5573577.html#msg5573577

[jenga]

Merci pour ta réponse...
Pas tout a fait... Oui si ton logiciel n'utilises pas le CMS, non sinon.

Le CMS est fait pour afficher correctement des images, presque quelque soit la façon dont elles ont été encodées.

En effet; je n'avais pas évoqué le CMS pour essayer de séparer les problèmes, mais tu as raison on ne peut pas l'omettre.

Cela dit, il me semble que la précision risque d'être médiocre si le CMS doit compenser un gros écart de gamma sur une image de sortie 8 bits, ce qui peut produire des erreurs ou des crénelages soit dans les sombres soit dans les clairs, selon le sens du gamma à rattraper.
Ne vaut-il pas mieux appliquer le gamma adéquat pendant qu'on dispose encore de toute la précision (soit lors du développement manuel, soit par le moteur jpeg de l'APN)?

[jenga]

Or, il semblerait que le gamma L* soit plus performant pour l'affichage à l'écran des tons sombres, mais qu'il pose aussi des problèmes à certains lors de l'adéquation image visualisée à l'écran vs image imprimée (les tons sombres apparaitraient plus sombres, plus bouchés, que ce qu'on voit à l'écran...).

Quid ?
A ce propos, j'ai retrouvé une discussion sur Chassimages qui aborde le sujet :
https://www.chassimages.com/forum/index.php/topic,241817.msg5573577.html#msg5573577

Le fil que tu cites évoque un éventuel problème de compensation du point noir. C'est peut-être une bonne piste, mais il faudrait connaître la manière dont les tireuses gèrent le point noir et je n'en ai aucune idée.

[Verso92]

Le fil que tu cites évoque un éventuel problème de compensation du point noir. C'est peut-être une bonne piste, mais il faudrait connaître la manière dont les tireuses gèrent le point noir et je n'en ai aucune idée.

Les retours que j'évoque sont liés, entre autre, à des tirages sur Epson R3000...


(compensation du point noir identique entre ProPhotoRVB et L*)

[Tonton-Bruno]

Tu n'avais rien à refaire. Juste cocher une case.
Voir ma petite image un peu plus haut

Il fallait effectivement cocher une case et aussi choisir le profil calculé pour le projecteur avec la sonde I-One, et en fin de projection il suffisait de faire la manip inverse.
Pas compliqué une fois qu'on le sait et qu'on a déterminé les 2 profils idoines avec la bonne sonde, mais juste un peu fastidieux.

Je n'ai évoqué cette histoire que pour tenter d'expliquer pourquoi à mon avis certains logiciels effectuent encore une partie des traitements de l'image avec un gamma 1.8 qui autrement n'a plus cours. C'est parce que au tout début ils ont été développés sur des Mac d'avant 2009.

[thom18]

Bonjour à tous,

Je viens sur ce fil que j'ai lu avec attention pour vous soumettre un texte fait pour présenter la correction gamma dans le cadre du exposé sur la colorimétrie dans mon PhotoClub.
Merci de me dire si l'ensemble vous semble correct, même s'il est simplifié.
J'ai simplement fait une copie d'écran de mon document.

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.

Dernière remarque concernant un point de mathématique ayant engendré un petit conflit dans ce fil : une fonction f de type f(x)=x^ɣ a pour dérivée f'(x)=ɣ x^(ɣ-1). Cette dérivée vaut ɣ en x=1 et non au point médian. La tangente a donc une pente de ɣ au point d'abscisse 1.

Selon que ɣ est supérieur à 1 ou inférieur à 1, la dérivée en 0 vaut 0 ou est infinie. En général les corrections gamma appliquées sont différentes au voisinage de 0 (tons sombres) elles peuvent être linéaires et sont indiquées par la pente d'une droite qui n'a rien de la tangente à la courbe au point d'abscisse 0.

Cordialement à tous.

[Franciscus Corvinus]

Je pense que je réécriras l'article de A a Z. Désolé pour la franchise. 

Pour commencer, l'ordre des 3 premiers paragraphes est bizarre. Commence par #3, qui donne l'idée principale. Le probleme est qu'elle est fausse.

Apres, #4 est tres confus. Tu parles d'espace colorimétrique, de quantification sur 8 bits... est-ce que le lecteur, a ce point, peut jongler avec ces notions? Meme si la réponse est oui, ca n'ajoute rien (a mon avis) a l'explication sur le pourquoi du gamma.

Et c'est la le noeud du probleme. Tu as en lien plus haut dans ce fil la véritable explication. Ca n'a rien a voir avec la non-linéarité de l'oeil. C'est du au besoin de contrer la non-linéarité de la réponse des écrans cathodiques, non-linéarité qui a été reprise (volontairement ou non) par les LCD. Tu l'expliques d'ailleurs assez bien dans la derniere partie, qui a mon avis se suffit a elle-meme.

En footnote, tu parles de correction de type sortie-entrée. Il y en a d'autres? Mais de toute facon je ne suis pas sur de bien comprendre de quoi tu parles. Une courbe end gamma décrit une transformation du signal, donc forcément c'est de l'entrée vers la sortie. Comment un signal peut-il aller de la sortie vers l'entrée? Aucun lecteur ne peut comprendre ce concept!

[thom18]

Tout d'abord merci de m'avoir répondu en ces temps de farniente et de canicule. Sur le web, on trouve tout et le contraire de tout sur la correction gamma : je ferais donc partie des personnes qui ont écrit n'importe quoi  Mais peut-être que toi aussi 
Je ne suis là que pour comprendre et je n'ai que repris le point de vue du premier post d'ouverture de ce fil en m'appuyant sur ce lien (https://www.cambridgeincolour.com/tutorials/gamma-correction.htm) dont la cohérence me semblait forte (merci de le regarder soigneusement afin que nous n'ayons pas un dialogue de sourds).

Passons sur ta remarque non compréhensible comme quoi j'aurais énoncé "qu'un signal peut-il aller de la sortie vers l'entrée" alors que je n'ai écrit que l'équation des deux courbes de gamma correspondant aux étapes n°1 (gamma de 1/2,2) et n°2 (gamma de 2,2). A te relire à travers l'ensemble du fil, j'ai une question à te poser avant tout :

Pour toi, est-ce qu'une correction gamma est appliquée quand une image est quantifiée dans un espace colorimétrique ? (par exemple lors du développement d'un raw vers l'espace sRVB).

Cordialement à toi.

[Franciscus Corvinus]

Il faut bien distinguer deux messages fondamentaux:
- l'origine de la transformation gamma pour les images nous vient des tubes cathodiques
- la transformation gamma est aujourd'hui utilisée pour améliorer la qualité des JPG
Ces deux points n'ont rien a voir, en dehors du fait qu'ils utilisent la meme transformation mathématique.

Tout d'abord merci de m'avoir répondu en ces temps de farniente et de canicule. Sur le web, on trouve tout et le contraire de tout sur la correction gamma : je ferais donc partie des personnes qui ont écrit n'importe quoi  Mais peut-être que toi aussi 
Je ne suis là que pour comprendre et je n'ai que repris le point de vue du premier post d'ouverture de ce fil en m'appuyant sur ce lien (https://www.cambridgeincolour.com/tutorials/gamma-correction.htm) dont la cohérence me semblait forte (merci de le regarder soigneusement afin que nous n'ayons pas un dialogue de sourds).

Je vois en effet que ton article colle beaucoup a la structure de celui de CiC, qui est une source réputée. Mais la facon dont ils, et par conséquent toi, présentent les choses embrouille plutot que clarifie. Je trouve que l'article cité par l'OP est considérablement plus clair:

La raison [de la correction gamma] est que le tube cathodique n'a pas un rendu linéaire de la lumière, son gamma est de 2.5 environ. Mais au lieu d'effectuer la correction dans le téléviseur même (ce qui à l'époque aurait nécessité un circuit complexe dans chaque téléviseur), on a préféré faire la correction unique dans l'émetteur. Le signal émis reçoit ainsi une correction à priori pour corriger le fonctionnement non-linéaire du tube de télévision.

Cependant, comme l'article de CiC, l'article de l'OP parle aussi de la non-linéarité de l'oeil. Je trouve que c'est un peu mieux présenté que dans l'article que CiC, mais ca n'est pas encore tres clair car ils ne commencent pas par la conclusion, ni par expliquer qu'ils ont changé de contexte et d'objectif. Voici comment je présenterais le choses.

Le contexte: exit les écrans; maintenant, il s'agit de coder une image dans un fichier JPG.
L'objectif: il faut que l'image ait le moins de perte de quailté possible
Le probleme: si on code linéairement, il faut beaucoup plus que les 8 bits par couleur permis par la norme JPG pour éviter la postérisation dans les ombres. Ou, pour dire les choses différemment, en codage linéaire la perte de qualité n'est pas homogene entre les hautes lumieres et les ombres, ce qui conduit a une sous-optimisation de la compression (le revers de la sous-optimisation étant la perte de qualité locale, contraire a notre objectif)
La raison: notre oeil a une réponse non-linéaire [note que la raison est accessoire, ce qui compte, c'est le probleme et la solution, mais les liens la mettent en exergue, ce qui est a mon avis une erreur].
La solution: on applique une courbe en gamma pour réduire les détails dans les hautes lumieres au bénéfice de ceux dans les basses lumieres.

Mais franchement, qui a besoin de savoir que le codage JPG inclut un courbe gamma? Qu'est-ce que ca va changer dans la facon de procéder du photographe? Pour moi, rien, vu que le JPG est un état transitoire entre le TIF et l'imprimeur. Une fois que j'ai ma photo sur papier, le JPG c'est de l'histoire ancienne. Seul m'intéresse le TIF, pour archivage. N'ayant pas besoin de savoir ca, on n'a pas besoin de s'occuper de la non-linéarité de l'oeil.

J'espere que ca éclaire un peu mon commentaire plus haut.

Passons sur ta remarque non compréhensible comme quoi j'aurais énoncé "qu'un signal peut-il aller de la sortie vers l'entrée" alors que je n'ai écrit que l'équation des deux courbes de gamma correspondant aux étapes n°1 (gamma de 1/2,2) et n°2 (gamma de 2,2).

Tu dis "(...) la correction appliquée est sensiblement du type sortie-entrée". Ca veut dire quoi exactement? Parce que pour moi ca ne veut rien dire. Je ne dis pas que c'est faux, mais qu'il me manque le meme jeu de clé que toi pour comprendre.

A te relire à travers l'ensemble du fil, j'ai une question à te poser avant tout :

Pour toi, est-ce qu'une correction gamma est appliquée quand une image est quantifiée dans un espace colorimétrique ? (par exemple lors du développement d'un raw vers l'espace sRVB).

Je fais un détour avant de répondre a ta question.

Un raw est une image quantifiée dans un espace colorimétrique. Je sais que certains vont hurler en lisant ca, mais c'est comme ca. Explication de texte:
- quantifiée: l'image est indéniablement codée en nombres de pixels finis sur un nombre finis de bits dans un nombre finis de composantes
- dans un espace colorimétrique: chaque valeur RGB d'un raw correspond a une couleur unique suivant la synthese additive RGB. Le raw est donc codé dans un espace othonormé par les axes RGB. Les positions maximales sur ces axes définissent l'enveloppe, i.e., le gamut. Le décalage de luminosité entre chaque incrément sur chaque axe est connu. Ca permet d'appliquer la définition d'un espace colorimétrique: "une représentation des couleurs dans un système de synthèse des couleurs". Ou, pour dire les choses de facon plus détaillée:

A color space is a specific organization of colors.(...) A color model is an abstract mathematical model describing the way colors can be represented as tuples of numbers (e.g. triples in RGB or quadruples in CMYK); (...). Adding a specific mapping function between a color model and a reference color space establishes within the reference color space a definite "footprint", known as a gamut, and for a given color model this defines a color space.

Tout ca pour dire que ta question devient: "applique-t-on une courbe gamma quand on passe d'un espace colorimétrique a un autre?". Je ne peux te donner qu'une réponse: ca dépend des tuples d'espaces. Entre deux modeles RGB, pas forcément. Mais entre des modeles RGB et ceux basés sur XYZ, oui:
https://www.mathworks.com/help/vision/ref/colorspaceconversion.html

[Verso92]

Un raw est une image quantifiée dans un espace colorimétrique. Je sais que certains vont hurler en lisant ca [...]

Oui, il y a de quoi.

[thom18]

Bonsoir,

J'ai ouvert la boite de Pandore sur ce sujet mais le dialogue a pris une tournure bien plus constructive.
Je vais réfléchir à tout ce que tu as dit et à tes liens indiqués.

Par contre
Citation de: Franciscus Corvinus le Aujourd'hui à 17:45:39
Tu dis "(...) la correction appliquée est sensiblement du type sortie-entrée". Ca veut dire quoi exactement? Parce que pour moi ca ne veut rien dire. Je ne dis pas que c'est faux, mais qu'il me manque le meme jeu de clé que toi pour comprendre.
Serais-je trahi par ma copie d'écran, pour moi, sur mon PC non ! Alors peut être as-tu lu sur un écran moins défini ? Si tu grossis l'image, tu devrais voir que j'ai écrit :
Dans l'étape n°1, la correction gamma appliquée est sensiblement du type sortie = entrée ^(1/2,2) qui correspond à la courbe du schéma. En fait, pour la norme sRVB, cette correction est un peu plus sophistiquée.
Dans l'étape n°2, la correction gamma appliquée est du type  sortie = entrée^2,2 qui correspond à la courbe du schéma et qui est la fonction réciproque de la précédente.

Cordialement.
PS : j'avale assez mal le coup de l'espace colorimétrique dans le raw ... 

[thom18]

Passons à la suite.

D'abord, mathématiquement parlant pour le raw et l'espace colorimétrique tu as raison mais pour le photographe l'espace colorimétrique se choisit parmi les standards au moment du développement.

Personnellement, je préfère l'article de CiC à l'article de l'OP. Revenir aux tubes cathodiques pour comprendre le gamma me semble actuellement inutile.
Cette correction gamma parait souvent curieuse à beaucoup quand on lit les forums où on en parle, en effet faire une fonction (correction gamma 1/2,2) suivie ensuite de sa réciproque (correction gamma 2,2) est souvent analysé comme une complication inutile mais c'est oublier l'apport qu'à la première correction à une meilleure quantification des ombres sur 8 bits tout au moins. Qu'en serait-il si on passait majoritairement à des images codées sur 16 bits ?

Maintenant la correction gamma de 2,2 appliquée au moment de la visualisation sur le moniteur ne me semble plus qu'avoir une seule justification : annuler la correction gamma de 1/2,2 appliquée sur l'image avant la quantification ! Surprenant non 

Il y a un point sur lequel il faut être clair : ce n'est pas le codage JPEG qui impose une correction gamma mais pour reprendre tes termes le passage de l'espace colorimétrique dans lequel est développé le raw (ça c'est tout un problème ... comme dirait Capture One c'est un très grand espace  ) vers l'espace standard dans lequel est créée l'image que ce soit sRVB, Adobe 1998 ou tout autre espace plus rare avec souvent un gamma de 2,2 (éventuellement 1,8 ou L*). Cf http://www.brucelindbloom.com/index.html

Cordialement.

[Franciscus Corvinus]

Par contre
Citation de: Franciscus Corvinus le Aujourd'hui à 17:45:39
Tu dis "(...) la correction appliquée est sensiblement du type sortie-entrée". Ca veut dire quoi exactement? Parce que pour moi ca ne veut rien dire. Je ne dis pas que c'est faux, mais qu'il me manque le meme jeu de clé que toi pour comprendre.
Serais-je trahi par ma copie d'écran, pour moi, sur mon PC non ! Alors peut être as-tu lu sur un écran moins défini ? Si tu grossis l'image, tu devrais voir que j'ai écrit :
Dans l'étape n°1, la correction gamma appliquée est sensiblement du type sortie = entrée ^(1/2,2) qui correspond à la courbe du schéma. En fait, pour la norme sRVB, cette correction est un peu plus sophistiquée.

Merci, j'avais mal vu en rouge que c'était une équation. Je comprends maintenant, et je suis d'accord.

La phrase en vert est ambigue. Je pense qu'il faut préciser "pour les conversions vers l'espace sRGB, cette correction...". Ca évite de créer l'impression qu'une transformation est inhérente a un espace, alors qu'il faut toujours avoir a l'esprit qu'il y a un espace de départ et un espace d'arrivée.

PS : j'avale assez mal le coup de l'espace colorimétrique dans le raw ... 

Je veux bien changer d'avis, mais il faut me donner des billes. Spécifiquement, quels sont les éléments qui montrent que la définition ne s'applique pas?

[egtegt²]

[...]

Maintenant la correction gamma de 2,2 appliquée au moment de la visualisation sur le moniteur ne me semble plus qu'avoir une seule justification : annuler la correction gamma de 1/2,2 appliquée sur l'image avant la quantification ! Surprenant non 
[...]

J'ai un petit doute sur ce point pour deux raisons :
- Il me semble que le gamma de 2,2 du jpeg étant intrinsèque au format, la conversion est implicite tant lors de l'écriture que de la lecture, c'est à dire que les fonctions de lecture de Jpeg vont directement appliquer cette correction pour restituer une image linéaire.
- Il me semble également que les moniteurs actuels ont conservé un gamma de 2,2 pour des raisons assez évidente de compatibilité avec les anciens moniteurs.

Pour ce qui est du RAW, il me semble que Franciscus oublie un point : un raw n'est pas constitué de pixels avec 3 valeurs RGB, il est constitué d'1/4 de pixels rouges, 1/4 de pixels bleus et le reste de pixels verts. Pour obtenir une image RGB, il faut d'abord passer par une phase d'interprétation des pixels du RAW, phase plus complexe qu'une simple moyenne de pixels adjacents. Donc même si un RAW a bien une plage de valeurs limitées, il est vraiment délicat de parler d'espace colorimétrique alors que les couleurs ne sont pas déterminées de façon définitives dans ce RAW.

[Franciscus Corvinus]

J'ai un petit doute sur ce point pour deux raisons :
- Il me semble que le gamma de 2,2 du jpeg étant intrinsèque au format, la conversion est implicite tant lors de l'écriture que de la lecture, c'est à dire que les fonctions de lecture de Jpeg vont directement appliquer cette correction pour restituer une image linéaire.
- Il me semble également que les moniteurs actuels ont conservé un gamma de 2,2 pour des raisons assez évidente de compatibilité avec les anciens moniteurs.

C'est également ce qu'il me semble. Je suis en train de rechercher dans quel document je l'ai lu. Heureusement que mon browser garde un historique...

Pour ce qui est du RAW, il me semble que Franciscus oublie un point : un raw n'est pas constitué de pixels avec 3 valeurs RGB, il est constitué d'1/4 de pixels rouges, 1/4 de pixels bleus et le reste de pixels verts. Pour obtenir une image RGB, il faut d'abord passer par une phase d'interprétation des pixels du RAW, phase plus complexe qu'une simple moyenne de pixels adjacents. Donc même si un RAW a bien une plage de valeurs limitées, il est vraiment délicat de parler d'espace colorimétrique alors que les couleurs ne sont pas déterminées de façon définitives dans ce RAW.

Non, je suis bien conscient du fait que chaque point n'a qu'une valeur dans un canal. Mais c'est accessoire. Chaque canal a une valeur 0 et une valeur maxi (suivant le nombre de bits utilisés) qui correspond a une couleur unique. Il ne peut en etre autrement.

Déplacer ces couleurs par un changement de BdB ne contredit en aucune facon le fait que le raw a son espace colorimétrique. Par exemple je peux sauvegarder une image quelconque en Lab. Puis j'ouvre le Lab sous Photoshop pour changer la BdB en déplacant les courbes a et b. Est-ce que ca veut dire que mon image en Lab n'était pas dans un espace colorimétrique? Non bien sur, puisque Lab en est un.

C'est meme plus simple que ca: si le raw n'est pas quantifié dans un espace colorimétrique parfaitement défini, comment savoir de quoi auront l'air les couleurs en mettant la BdB a une valeur donnée (par exemple 6500K)? Si l'espace de départ n'était pas défini, cette valeur de 6500K (ou toute autre) ne serait ancrée sur rien. Mais ca n'est pas mon expérience: je trouve que cette échelle est assez cohérente d'un logiciel a l'autre meme si, chacun appliquant sa sauce a l'image, on ne retrouve pas une correspondance exacte.

Dans la copie 'écran ci-dessous on a (clockwise from top left): Affinity, Capture NX, Capture One et ACDsee. Les curseurs de BdB sont a la meme TC. L'axe "teint" doit etre ignoré car il n'a pas la meme échelle entre les éditeurs (je l'ai ajusté pour faciliter la comparaison sur l'axe de TC). Comme on peut le voir, les images different, mais tres peu et dans l'ensemble la TC reste homogene entre les 4. Si les résultats sont les memes, et la transformation (l'applicaiton de la TC) est la meme, c'est que le point de départ (le raw) est le meme. Il n'y a qu'une seule facon pour quatre éditeurs indépendants d'interpréter un raw de maniere aussi constante: c'est de définir l'espace colormétrique qu'il utilise.

[Franciscus Corvinus]

D'abord, (1) mathématiquement parlant pour le raw et l'espace colorimétrique tu as raison (2) mais pour le photographe l'espace colorimétrique se choisit parmi les standards au moment du développement.

1) Ouf!
2) On choisit parmi les standards... ou pas: on peut faire sa fonction de transfert custom. Et ca n'est pas qu'au moment du développement; c'est aussi pour la sauvegarde dans un fichier. En effet rare sont les dérawtiseurs qui publient leur espace de dévelopopement, donc il y a une transformation a la sauvegarde. Cela dit, Quelle est la différence entre passer de l'espace de développement a celui du fichier de sauvegarde, et, par exemple, passer sous Photoshop de ProPhoto RGB en Lab pour faire la BdB, passer en sRGB pour faire des masques, et finir en CMYK pou imprimer?

Personnellement, je préfère l'article de CiC à l'article de l'OP. Revenir aux tubes cathodiques pour comprendre le gamma me semble actuellement inutile.
Cette correction gamma parait souvent curieuse à beaucoup quand on lit les forums où on en parle, en effet faire une fonction (correction gamma 1/2,2) suivie ensuite de sa réciproque (correction gamma 2,2) est souvent analysé comme une complication inutile mais c'est oublier l'apport qu'à la première correction à une meilleure quantification des ombres sur 8 bits tout au moins. Qu'en serait-il si on passait majoritairement à des images codées sur 16 bits ?

Tu as raison de poser la question: la correction gamma est inutile avec 16 bit par canal.

There seems to be a persistent rumor going around that 16-bit images suffer from posterization in linear gamma color spaces, but I have not found that to be true, even when editing in the super-sized Identity color space. Also, the VFX [effets spéciaux] industry uses linear gamma 16-bit floating point data ("half" floating point precision), and 16-bit integer is more precise than 16-bit floating point. So contrary to rumor, you really can edit linear gamma 16-bit integer images without fearing posterization.

C'est pourquoi j'ai précisé que le cadre de cette discussion était le codage JPG, qui est défini sur 8 bits.

Mais revenir aux écrans cathodiques n'est a mon avis pas inutile: les écrans actuels sont construits pour avoir la meme réponse qu'un écran cathodique, ce qui est d'ailleurs un exercice difficile, comme le note l'article de CiC: "ensuring an overall display gamma of 2.2 often requires substantial corrections, and they are also much less consistent than CRT's. LCDs therefore require something called a look-up table (LUT) in order to ensure that input values are depicted using the intended display gamma (amongst other things)."

Je crois vraiment que les deux idées---la réponse non-linéaire des CRT, et le besoin de limiter la postérisation dans les ombres quand on n'a que 8 bits---sont deux choses qui n'ont rien a voir. Il se trouve que les gammas dans les deux cas sont presque inverses l'un de l'autre. En fait, il y a quand meme un petit ajustement. Toujours chez CiC: "Values from a gamma-encoded file could therefore be sent straight to the [CRT] screen and they would automatically be corrected and appear nearly OK. However, a small gamma correction of ~1/1.1 needs to be applied to achieve an overall display gamma of 2.2". Il ne faut donc pas croire que le but du gamma de l'écran est de contrer celui de la conversion en sRGB. C'est une coincidence, rien de plus.

[thom18]

Je crois vraiment que les deux idées---la réponse non-linéaire des CRT, et le besoin de limiter la postérisation dans les ombres quand on n'a que 8 bits---sont deux choses qui n'ont rien a voir. Il se trouve que les gammas dans les deux cas sont presque inverses l'un de l'autre. En fait, il y a quand meme un petit ajustement. Toujours chez CiC: "Values from a gamma-encoded file could therefore be sent straight to the [CRT] screen and they would automatically be corrected and appear nearly OK. However, a small gamma correction of ~1/1.1 needs to be applied to achieve an overall display gamma of 2.2". Il ne faut donc pas croire que le but du gamma de l'écran est de contrer celui de la conversion en sRGB. C'est une coincidence, rien de plus.

Je m'attache ce soir à ne traiter que de ce sujet.
Pour illustrer mon propos, deux articles :
http://poynton.ca/PDFs/Rehabilitation_of_gamma.pdf
http://www.profil-couleur.com/tp/216-correction-gamma.php

Le premier est très technique et ancien ; justement c'est son intérêt même s'il est difficile à lire (très long et anglais). Je retiendrai le schéma de la page n°17 très instructif (voir pj).
On voit qu'à l'époque (environ 1990 sans doute), selon les systèmes un fichier jpeg déjà passé à la correction gamma de 1/2.2 pouvait subir sur PC une correction gamma presque inverse et sur Mac une première correction par la LUT et une seconde par le fait du moniteur (pour les autres systèmes, je vous laisse voir). C'était donc l'anarchie pour la reproduction d'image mais surtout cela m'éclaire peut-être le point le plus important. Actuellement comment cela se passe-t-il ?

L'hypothèse de départ est que les moniteurs actuels ont un gamma de 2.2 qui est une caractéristique (obtenue sans doute artificiellement).
Une image jpeg est à afficher, puisqu'elle est corrigée par un gamma de 1/2.2 elle doit donc arriver à l'écran sans aucune autre correction.
Ai-je raison ?

Est-ce que le 1/2.2 et le 2.2 sont une coïncidence comme le dit le premier article à propos de l'équivalent en vidéo. Peut-être initialement mais ensuite cela me parait surprenant de soutenir la coïncidence et encore plus l'indépendance, il suffit de lire le second article. Pour étayer encore plus la relation entre les deux gamma, il suffit de voir que les espaces colorimétriques sont en 2.2 ; 1.8 ou L* et que, si je ne me trompe, les sondes de calibrages proposent ces trois gamma. A ce propose, que font-elles de cette info ?

Déjà quand on sera clair la dessus ... pour le reste, on verra plus tard.

Merci.

[Franciscus Corvinus]

Je suis en train de lire le premier article. Pour le moment je me contente de noter cet extrait page 7:

The fact that a CRT's transfer function is very nearly the inverse of the lightness sensitivity of vision is an amazing, and fortunate, coincidence!

[philooo]

Juste une contribution sur la partie "maths", niveau Terminale :

Dernière remarque concernant un point de mathématique ayant engendré un petit conflit dans ce fil : une fonction f de type f(x)=x^ɣ a pour dérivée f'(x)=ɣ x^(ɣ-1). Cette dérivée vaut ɣ en x=1 et non au point médian. La tangente a donc une pente de ɣ au point d'abscisse 1.

Selon que ɣ est supérieur à 1 ou inférieur à 1, la dérivée en 0 vaut 0 ou est infinie. En général les corrections gamma appliquées sont différentes au voisinage de 0 (tons sombres) elles peuvent être linéaires et sont indiquées par la pente d'une droite qui n'a rien de la tangente à la courbe au point d'abscisse 0.

Se rappeler que tout est "logarithmisé" :  f(x)=x^ɣ devient log(f(x))=ɣ log(x), autrement dit Y=ɣX, représentée par une droite. La dérivée est alors, en chaque point, la pente ɣ de la droite (la tangente à une droite, c'est la droite elle-même...).

Avec une fonction de transfert quelconque (pas forcément une fonction puissance parfaite, en particulier aux extrémités), la courbe logarithmisée n'est plus une droite, mais on convient que ɣ est la dérivée (la pente de la tangente) au point médian.

[thom18]

/quote]
Diable, mais où as-tu vu cette information ?
Cordialement.

[philooo]

La courbe de transfert traduit une correspondance entre indices de lumination (IL), pas entre luminations - dont les IL sont les logarithmes en base 2. C'est ce que je veux dire par "tout est logarithmisé".

La relation entre luminations y=x^ɣ devient une relation linéaire Y=ɣX entre indices de lumination. En pratique, seule une partie de la courbe est (à peu près) linéaire, c'est le ɣ de cette partie qu'on considère.

[Franciscus Corvinus]

Le premier est très technique et ancien ; justement c'est son intérêt même s'il est difficile à lire (très long et anglais). Je retiendrai le schéma de la page n°17 très instructif (voir pj).
On voit qu'à l'époque (environ 1990 sans doute), selon les systèmes un fichier jpeg déjà passé à la correction gamma de 1/2.2 pouvait subir sur PC une correction gamma presque inverse et sur Mac une première correction par la LUT et une seconde par le fait du moniteur (pour les autres systèmes, je vous laisse voir). C'était donc l'anarchie pour la reproduction d'image mais surtout cela m'éclaire peut-être le point le plus important. Actuellement comment cela se passe-t-il ?

Oui pour la partie en gras. Quelques corrections de détail:

In practice, an image is encoded into JPEG using the encoding transfer function that is in effect for the platform that it is encoded on. A decoded JPEG image is displayed using the transfer function in effect on the platform upon which it is decoded. Figure 19 overleaf sketches the gamma situation for JPEG on the web. It's chaos!

Il dit qu'un JPG n'est pas forcément codé avec un gamma de 2.2. Il peut etre codé avec n'importe quoi. En tout cas, a l'époque (1998). Actuellement, on a la gestion de profils a toutes les étapes de la génération/reproduction. Donc on n'a pas besoin de s'occuper du gamma. Si tu enregistres un JPG en sRGB, c'est le pseudo-gamma du sRGB qui sera utilisé, a la fois pour le codage et (son inverse) pour le décodage. Si tu l'enregistres en ProPhoto RGB, c'est le gamma de ce modele qui sera utilisé, pour le codage et pour le décodage. C'est donc un peu moins l'anarchie.

[Franciscus Corvinus]

L'hypothèse de départ est que les moniteurs actuels ont un gamma de 2.2 qui est une caractéristique (obtenue sans doute artificiellement).
Une image jpeg est à afficher, puisqu'elle est corrigée par un gamma de 1/2.2 elle doit donc arriver à l'écran sans aucune autre correction.
Ai-je raison ?

<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>

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.

Est-ce que le 1/2.2 et le 2.2 sont une coïncidence comme le dit le premier article à propos de l'équivalent en vidéo. Peut-être initialement mais ensuite cela me parait surprenant de soutenir la coïncidence et encore plus l'indépendance, il suffit de lire le second article. Pour étayer encore plus la relation entre les deux gamma, il suffit de voir que les espaces colorimétriques sont en 2.2 ; 1.8 ou L* et que, si je ne me trompe, les sondes de calibrages proposent ces trois gamma. (...)

La réponse des LCD est complexe et n'est pas naturellement modélisable par un gamma.
http://www.orientdisplay.com/LCD-basics.html
http://www.fujitsu.com/downloads/MICRO/fma/pdf/LCD_Backgrounder.pdf (page 6)
L'implication est la suivante: tant que les dalles ne sont pas capables de travailler avec plus de 8 bits (6 pour certaines), il leur faudra artificiellement émuler un gamma proche de 2.2 pour postériser de maniere homogene sur toute la gamme de gris. L'apparition du standard HDR (lien) pour les écrans pourrait éliminer ce besoin completement (en supposant que 10 bits soient suffisants; ca m'étonnerait car le meme article donne 1:10000 comme contraste statique pour l'oeil, ce qui requiert 14 bits; cependant il ne parle pas de la discrimination de l'oeil).

Mais je suis persuadé que l'émulation d'un gamma de 2.2 n'est pas la pour des raisons physiologiques mais simplement pour des raisons historico-technico-économiques, avec accent sur l'économique. Pendant les années formatives des LCD, Windows était le systeme d'exploitation dominant (95% du marché).

Il supposait un gamma de 2.2 et ne proposait pas de gestion des couleurs. Qu'allaient faire les fabriquants si ce n'est s'aligner sur un standard de facto?