Forum Chasseur d'Images - www.chassimages.com

Bonjour à tous.

Deux articles intéressants sur la correction gamma et la courbe de transfert que je vous transmet

http://pics.idemdito.org/fr/tech/ordi/gamma.htm

http://pics.idemdito.org/fr/tech/physique/fonction.htm
On y lit que la correction gamma 0,45 est utilisée pour corriger la non linéarité des écrans. Celle ci est systématiquement appliquée lors de l'encodage jpeg et est devenue une norme. Raison pour laquelle il est nécessaire de fixer le gamma de l'écran à une valeur correcte lors de l'étalonnage. Afin que ces deux fonctions réciproques s'annulent. On y lit que cela permet de mieux coller à la perception de la vue ou à l'impression des films argentiques. Ma première question est pourquoi cela colle mieux à la perception de notre vue ?

Le second article traite de la fonction de transfert. Lors de l'encodage en 8 bits il est nécessaire d'appliquer cette fonction qui tend à comprimer les hautes et basses lumières. Et surtout de ne pas coder les tons les plus sombres qui ne contiennent que du bruit photonique.
Ma seconde question est quelle différence ou rapport entre cette fonction de transfert et la correction gamma ? Merci beaucoup pour vos explications

Pour la différence entre la fonction de transfert et la correction gamma, à mon avis c'est très proche mais la différence, c'est que la correction gamme correspond à une forme de courbe définie uniquement par son facteur gamma qui correspond à la pente au centre.

Une fonction de transfert peut elle avoir une forme différente et s'adapte à la réponse réelle du capteur. Par exemple si tu as un capteur avec une réponse non linéaire, la courbe va devoir s'adapter pour rendre sa réponse linéaire.

Pour l'adaptation aux yeux, j'ai un doute car j'ai du mal à comprendre la logique : si le capteur est linéaire et qu'on affiche sur un écran linéaire, l'image va être la même que la réalité, donc pourquoi faudrait-il une correction autre que celle induite par la réponse de l'écran ?

Merci pour ta réponse.
j'avais bien le sentiment que la courbe gamma et la courbe en s étaient utilisées pour des raisons différentes. J'ai eu le doute car on lit partout que la courbe de correction gamma et la courbe de transfert sont exactement la même chose. Il suffit de regarder leur forme pour comprendre que c'est pas vrai. Donc si je comprends bien, il y aurait deux courbes appliquées lors de l'encodage en jpeg tiff.
est-ce bien cela.

Ta remarque sur la captation linéaire et reproduction linéaire (gamma de 2.2 + gamma de 0,45) amène une réalité proche de la réalité. Comme toi je ne comprends pas en quoi la correction gamma est proche de la perception humaine. Je le lit partoit, y compris chez les grands rédacteurs comme messieurs volker et autres.

Quelqu'un aurait il une réponse aux questions que je pose.

Pour la première question peut-être faut il comprendre que sans la corection gamma (profil linéaire) l'image affichée sera trop sombre. Du coup il faut peut-être comprendre que grâce à cette correction gamma, l'image reprend une forme naturelle conforme à notre vision. Je dis peut-être....

Intéressant ce fil : je me pose exactement le même genre de questions...  ;-)

Citation de: egtegt² le Juin 25, 2018, 11:36:47
Pour la différence entre la fonction de transfert et la correction gamma, à mon avis c'est très proche mais la différence, c'est que la correction gamme correspond à une forme de courbe définie uniquement par son facteur gamma qui correspond à la pente au centre.

D'après ce que j'ai compris, la courbe de gamma est liée au moniteur (gamma = 2.2), et la courbe de transfert, qui présente le gamma inverse, est liée à l'image, de façon à linéariser le résultat final visualisé...

http://www.blog-couleur.com/?Qu-est-ce-que-le-gamma

Je crois que la réponse la plus courte consiste à dire que nos électroniques sont linéaires alors que notre oeil ne l'est pas.
Il faut donc d'un côté accorder le fichier brut linéaire à notre oeil lors de la derawtisation par une courbe avec un certain gamma et d'un autre côté il faut aussi accorder l'écran à notre  oeil par une autre courbe avec un certain gamma.

Au contraire en argentique on arrivait à faire fonctionner la chimie film de façon non linéaire avec une courbe proche de celle de notre oeil donc pas de correction à postériori ( on arrivait tout de même à contrôler le gamma au développement  noir et blanc).

A mon avis le gamma tel qu'on l'entend en électronique n'a rien à voir avec le gamma en photo argentique défini comme le rapport entre l'accroissement de densité à l'accroissement correspondant du log de l'expo dans la partie linéaire de la courbe

Citation de: Jean-Claude le Juin 25, 2018, 20:59:22
Je crois que la réponse la plus courte consiste à dire que nos électroniques sont linéaires alors que notre oeil ne l'est pas.
Il faut donc d'un côté accorder le fichier brut linéaire à notre oeil lors de la derawtisation par une courbe avec un certain gamma et d'un autre côté il faut aussi accorder l'écran à notre  oeil par une autre courbe avec un certain gamma.

Au contraire en argentique on arrivait à faire fonctionner la chimie film de façon non linéaire avec une courbe proche de celle de notre oeil donc pas de correction à postériori ( on arrivait tout de même à contrôler le gamma au développement  noir et blanc).

J'ai déjà lu cette explication, et je l'avais prise pour argent comptant ... mais si elle est vraie, alors il manque un élément. Je m'explique :

Si notre œil n'est pas linéaire, et qu'un capteur est linéaire, qu'est-ce que ça change : si je capture une image de façon linéaire et que je la restitue de façon linéaire, alors pourquoi mon œil, devrait-il la voir différemment de la réalité ?

Pour ce qui est de la correction pour l'écran, c'est simple : si je veux reproduire l'image enregistrée par le capteur, il faut que j'applique une correction parce que mon écran n'est pas linéaire. Là ça semble normal, mais du coup je me retrouve avec une image linéaire si je n'applique que la correction due à l'écran. Est-ce que cette image me semblera naturelle ou est-ce qu'il faut que j'ajoute une correction gamma pour s'adapter à mon œil ?

Comme ça, je vois plusieurs explications possibles :
- En fait la correction gamma ne sert qu'à corriger l'écran et on visualise une image linéaire,
- Notre œil a un gamma différent suivant qu'on regarde la même scène en vrai ou sur un écran, ce qui serait plausible, le niveau de luminosité étant différent et donc il faut afficher une image non linéaire pour corriger cette variation.

Pour l'instant, en recherchant sur google, j'ai trouvé des explications allant dans les deux sens donc ...

Le gamma est une forme particuliere de fonction de transfert. Ses raisons sont multiples:
1. historique: c'était plus facile au temps des tube acthodiques
2. marketing: les écrans de TV ont l'air "mieux" quand les tons moyens sont relevés
3. technique: la, l'argument est double.
3a. D'une part une variation donnée (+10) semble avoir le meme impact visuel quel que soit le degré de gris auquel elle est appliquée (meme sensation de contraste entre 45 et 55 qu'entre 215 et 225). Cet argument ne s'applique évidemment qu'aux images décodées et non pas aux JPG.
3b. D'autre part, comme le JPG est un codage destructeur, ca permet de détruire les bits qu'on voit le moins, quelle que soit leur position dans la gamme de gris. A qualité égale, un JPG passé a la moulinette du gamma sera donc plus compact qu'un JPG linéaire. Cet argument, a l'inverse du précédent, ne s'applique évidemment qu'aux fichiers JPG.

Quand on parle de la courbe gamma comme proche de la perception humaine, on fait référence au point 3a.

J'ai bien lu vos réponses.

Je suis d'accord avec le fait que la courbe de correction gamma 0,45 corrige la déformation définie aux lcd gamma 2.2. Oui en effet les profils d'écran intègrent ce gamma 2.2. Donc ces deux courbes se neutralisent. La restitution est linéaire. L'œil voit donc une image telle qu'elle existe dans la réalité.

La courbe de transfert n'a pas du tout la même vocation, je suis en contact avec l'auteur des articles cités et je reviendrai avec des éléments de réponse. D'ailleurs cette courbe n'a pas la même forme. J'ai le sentiment qu'il y a deux courbes. Une qui adapte l'image affichée sur écran (sinon c'est trop sombre) et l'autre s'adapte à la réponse du capteur et de sa conversion.

Du coup, la courbe de correction gamma étant standardisée, avec les différents capteurs et leur spécificités il est nécessaire d'avoir une autre courbe qui s'adapte au capteur et à sa conversion.

J'ai des éléments de réponses mais j'attends d'avoir des nouvelles afin de confirmer cela.

Il y a peut-être matière à confusion lorsqu'on lit courbe de correction gamma =courbe de transfert.

Je suis aussi d'accord que la courbe de transfert en argentique n'a rien à voir avec ce qui se passe en numérique. Mais il semblerai qu'en numérique justement il y ai cette même démarche.

Voici la réponse de Marc doigny, auteur des articles. J'attends d'autres précisions pour clarifier la situation

Je cite :

La courbe de gamma est une fonction standardisée, appliquée par tous les fabricants. Elle a comme avantage que chaque "pas" produit une augmentation du signal dont l'effet est perçu identiquement.
La fonction de transfert est un truc pour faire passer les 12 (...) bits d'un capteur dans les 8 bits du format jpeg. Le format jpeg a une courbe de gamma, ce qui le rend déjà plus efficace en attribuant plus de bits aux ombres (nos yeux discernent mieux les différences dans les ombres que dans les hautes lumières).
Mais en plus, on va comprimer les extrèmes, en attribuant le plus de bits au niveaux moyens, là où se trouve l'information principale. En comprimant les extrèmes (et en attribuant donc une gamme plus étendue aux tons moyens) on augmente en fait le contraste de l'image, qui devient plus plaisante, sans avoir le risque d'un écrètage.

La fonction de transfert dépend de l'appareil photo (caractéristiques du capteur et du convertisseur), mais il est également possible de jouer sur la courbe en choisissant une image plus "dure" ou plus "douce" (possible sur certains appareils, sur mon appareil cela s'appelle "picture style").
Marc Doigny"

Oh lala j'y comprends rien.

Une courbe gamma est une courbe de forme incurvée. Mais si on change l'échelle linéaire par une échelle des abscisses en logarithme du coup cette forme incurvée devient" droite ". Ah intéressant ! Du coup on joue sur le pied et l'épaule de la courbe pour lui donner une forme de S. C'est la compression des extrêmes évoqué par l'auteur.

Du coup c'est effectivement peut être la même courbe.

J'attends avec impatience vos commentaires. Svp essayez d'être le plus clair possible. Merci d'avance

Citation de: lawre51 le Juin 26, 2018, 00:29:23
La fonction de transfert est un truc pour faire passer les 12 (...) bits d'un capteur dans les 8 bits du format jpeg.

Elle ne serait donc pas appliquée sur un TIFF 16 bits, par exemple ?

Citation de: lawre51 le Juin 26, 2018, 00:44:44
Oh lala j'y comprends rien.

Une courbe gamma est une courbe de forme incurvée. Mais si on change l'échelle linéaire par une échelle des abscisses en logarithme du coup cette forme incurvée devient" droite ". Ah intéressant !

C'est juste une question de représentation. Ça ne change rien à la "courbe"...

Donc si j'ai bien compris, le gamma de l'oeil n'aurait rien à voir avec tout ça et le fameux 2,2 serait le gamma standard d'un écran et pas celui de l'oeil.

Citation de: egtegt² le Juin 26, 2018, 07:53:01
Donc si j'ai bien compris, le gamma de l'oeil n'aurait rien à voir avec tout ça et le fameux 2,2 serait le gamma standard d'un écran et pas celui de l'oeil.

Le gamma 2.2 est effectivement celui de l'écran : il traduit sa non linéarité.

Et la norme varie en fonction de la définition de l'écran, pour l'UHD c'est 2.4.

Citation de: lawre51 le Juin 26, 2018, 00:24:19
Il y a peut-être matière à confusion lorsqu'on lit courbe de correction gamma =courbe de transfert.

Je suis aussi d'accord que la courbe de transfert en argentique n'a rien à voir avec ce qui se passe en numérique. Mais il semblerai qu'en numérique justement il y ai cette même démarche.

De toute façon, il ne peut pas y avoir d'équivalence, ce sont deux choses différentes :
- Une courbe de correction Gamma est une courbe d'une forme prédéterminée et caractérisée par son coefficient Gamma
- Une courbe de transfert est une courbe quelconque qui définit la façon de convertir d'un système à un autre (RAW vers JPEG, Capteur vers linéaire ...) elle peut avoir la forme d'une courbe de correction Gamma ... ou pas. Celle de RAW vers JPEG a dans les faits une courbe de correction Gamma mais c'est un choix des concepteurs du format.

Citation de: Verso92 le Juin 26, 2018, 07:21:58
Elle ne serait donc pas appliquée sur un TIFF 16 bits, par exemple ?

C'est juste une question de représentation. Ça ne change rien à la "courbe"...

Bien d'accord. Mais c'est juste cette représentation qui peut prêter à confusion.

Citation de: lawre51 le Juin 26, 2018, 11:28:35
Bien d'accord. Mais c'est juste cette représentation qui peut prêter à confusion.

Pas compris... les échelles log sont très souvent utilisées pour représenter des grandeurs physique (cf courbes de réponse audio, etc).

Citation de: Verso92 le Juin 26, 2018, 11:31:25
Pas compris... les échelles log sont très souvent utilisées pour représenter des grandeurs physique (cf courbes de réponse audio, etc).

Bien sûr que cette représentation est souvent utilisée. Je voulais juste faire remarquer que pour un novice regarder la forme de la courbe sans tenir compte de son échelle est un piège

Bon alors Marc doigny  a precisé les choses. Je vous transmet la conversation:

On 25-Jun-18 22:07, Cyril Beaudron wrote:
Merci Marc pour ces renseignements complémentaires. Si j'ai bien compris il y a deux courbes distincts (courbe gamma 0,45 et une courbe en S) est-ce bien cela ?
La première associé à la courbe de l'écran (gamma 2,2) à pour effet de linéariser le rendu affiché. Sans cette courbe de correction gamma, l'image apparaîtra trop foncé (cas du profil linéaire) c'est bien ça ?

La courbe de transfert s'applique au moment de la conversion en tiff jpeg. Toujours d'accord ?
Merci pour l'attention que vous porterez à ma demande.
Merci pour vos observations sur mes propos cités en amont.

Bonne journée Marc

Cyril BEAUDRON

réponse:
Vous ne vous êtes pas trompé, mais lors de la conversion en jpeg on utilise les deux courbes en même temps.
Le gamma, parce que c'est devenu un standard et la courbe en S pour comprimer un peu les données sans rendre l'image trop fade. La courbe en S n'est pas standard et ses paramètres dépendent de l'appareil.
Marc Doigny

Citation de: lawre51 le Juin 26, 2018, 00:44:44
Oh lala j'y comprends rien.

Une courbe gamma est une courbe de forme incurvée. Mais si on change l'échelle linéaire par une échelle des abscisses en logarithme du coup cette forme incurvée devient" droite ". Ah intéressant ! Du coup on joue sur le pied et l'épaule de la courbe pour lui donner une forme de S. C'est la compression des extrêmes évoqué par l'auteur.

Du coup c'est effectivement peut être la même courbe.

J'attends avec impatience vos commentaires. Svp essayez d'être le plus clair possible. Merci d'avance

Non, une courbe gamma n'est pas une courbe en S. C'est une courbe qui n'est incurvée que dans un sens, alors qu'une courbe en S est incurvée dans un sens puis dans l'autre. Oublie simplement le commentaire sur les échelles logarithmiques.

Une courbe de transfert est un terme générique pour décrire les transformations qu'on fait subir aux canaux selons lesquels l'image est codée (RGB en JPG, mais ca peut etre Lab, CMYK, Yuv, HSV pour les espaces les plus courants). Les courbes de transfert peuvent avoir n'importe quelle forme, de la droite, a la courbe gamma, a la courbe en S ou, plus probablement, une pente ondulée sans véritable équation qui la définit.

Les courbes de transfert interviennent a de multiples points dans la chaine de l'image. Elles peuvent etre explicitesment codées quand on les inclut dans un traitement informatique, comme c'est le cas en sortie de capteur, ou dans une conversion JPG. Mais elles peuvent etre implicite au hardware, comme l'objectif (ou elles sont compliquées car elles varient sagitallement, en d'autre termes la couleur dans les coins n'est pas toujours la meme qu'au centre) ou l'écran. Dans ce cas, on les contre par la calibration, qui introduit par software une courbe de transfert inverse a celle du hardware.

Citation de: Verso92 le Juin 26, 2018, 08:04:16
Le gamma 2.2 est effectivement celui de l'écran : il traduit sa non linéarité.

Je ne connais pas le terme français mais le gamma est caractérisé deux coefficients :  la valeur du gamma (pente de la courbe dans sa partie linéaire) et le toe slope (traduction auto = pente de l'orteil, peut-être aménagement du pied de courbe).

Par exemple citation d'un passage d'un tutoriel dcraw :
http://guillermoluijk.com/tutorial/dcraw/index_en.htm

-g gamma slope
Applies a gamma correction to the output defined by the gamma value and the toe slope of the curve. For a pure gamma curve set slope to 0. Some typical values are:
   -g 1 1 linear 1.0 gamma (default if -4 is used)
   -g 2.2 0 pure 2.2 gamma (Adobe RGB)
   -g 1.8 0 pure 1.8 gamma (ProPhoto RGB)
   -g 2.4 12.9 sRGB gamma
   -g 2.222 4.5 BT.709 specification gamma (default if -4 is not used)

Par défaut dcraw utilise le gamma 2.4 avec seulement 4.5 en deuxième valeur ce qui donne des images faiblement contrastée. C'est mieux et plus naturel avec -g 2.4 12.9, à l'opposé si on veut conserver un maximum de hautes lumières ou d'ombre après -g 1 1 sera mieux.

Gamma 2.4 c'était pour les écrans crt, pour les LCD 2.2 est plus approprié.
L'œil, le capteur et l'écran n'ont pas le même "rendement" dans les ombres :
https://www.cambridgeincolour.com/tutorials/gamma-correction.htm

Merci à vous pour ces précisions . La compréhension est bien meilleure

Citation de: remico le Juin 26, 2018, 13:25:50
Je ne connais pas le terme français mais le gamma est caractérisé deux coefficients :  la valeur du gamma (pente de la courbe dans sa partie linéaire) et le toe slope (traduction auto = pente de l'orteil, peut-être aménagement du pied de courbe).

Par exemple citation d'un passage d'un tutoriel dcraw :
http://guillermoluijk.com/tutorial/dcraw/index_en.htm

-g gamma slope
Applies a gamma correction to the output defined by the gamma value and the toe slope of the curve. For a pure gamma curve set slope to 0. Some typical values are:
   -g 1 1 linear 1.0 gamma (default if -4 is used)
   -g 2.2 0 pure 2.2 gamma (Adobe RGB)
   -g 1.8 0 pure 1.8 gamma (ProPhoto RGB)
   -g 2.4 12.9 sRGB gamma
   -g 2.222 4.5 BT.709 specification gamma (default if -4 is not used)

Par défaut dcraw utilise le gamma 2.4 avec seulement 4.5 en deuxième valeur ce qui donne des images faiblement contrastée. C'est mieux et plus naturel avec -g 2.4 12.9, à l'opposé si on veut conserver un maximum de hautes lumières ou d'ombre après -g 1 1 sera mieux.

Gamma 2.4 c'était pour les écrans crt, pour les LCD 2.2 est plus approprié.
L'œil, le capteur et l'écran n'ont pas le même "rendement" dans les ombres :
https://www.cambridgeincolour.com/tutorials/gamma-correction.htm

Question subsidiaire : si on développe en linéaire (avec un gamma de 1, donc, à la louche), on se retrouve avec le gamma de l'écran, soit 2.2, c'est bien ça ?


(donc, avec une image plutôt sombre avec les ombres qui ont du mal à décoller...)

excuses le gamma n'est pas une fonction de  transfer particulière.

Le gamma est tout simplement une des caractéristiques de toute fonction de transfer, mathématiquement il s'agit de la dérivée au point médian de la courbe, plus communément la pente.

Après on peut comme évoqué plus haut en argentique définir des gamma de pied de courbe et d'épaule de courbe qui caractérisent le modelé des basses et hautes lumières

Cette discussion m'a donné l'idée de faire une mesure sur mon écran.
J'ai utilisé la fonction Colorimètre avec ma sonde Spyder3
(remplacée par une sonde X-rite pour mes calibrations mais c'est sans importance).
Pour diverses valeurs de gris (255, 192, 128, 64, 32, 0) sur l'écran
j'ai lu la luminance Y indiquée par la Spyder3 (114, 61, 26, 5.7, 1.65, 0.583).
J'ai normalisé à 1 en divisant la 1ère par 255, notée e
et la 2ème par 114, notée s.
J'ai tracé la courbe s = f(e) en rouge.
J'ai aussi tracé la courbe s = e^2.2 (j'aurais dû lui donner un autre nom, mais c'est le même axe vertical) en bleu.
On voit que les 2 courbes sont très voisines, ce qui confirme que l'écran est réglé suivant cette loi.
C'est juste une confirmation.

J'avoue que cette question du gamma reste, malgré les explications données ici, assez mystérieuse pour moi.
Pourquoi avoir une correction des fichiers qui annule l'effet de la correction d'écran ? Il me semble qu'il serait plus simple de ne pas mettre ces corrections.
(Je pense qu'il y a peut-être une raison historique, les écrans CRT étaient je crois très non linéaires).
L'argument de tenir compte de la non linéarité de l'oeil me semble discutable, comme l'a dit egtegt2, et de toutes façons les 2 corrections (fichier+écran) s'annulent.

Citation de: balfly le Juin 26, 2018, 22:18:35
J'avoue que cette question du gamma reste, malgré les explications données ici, assez mystérieuse pour moi.
Pourquoi avoir une correction des fichiers qui annule l'effet de la correction d'écran ? Il me semble qu'il serait plus simple de ne pas mettre ces corrections.

L'écran (CRT ou LCD) ne sait pas rendre les valeurs de façon correcte...

Citation de: Jean-Claude le Juin 26, 2018, 22:01:45
excuses le gamma n'est pas une fonction de  transfer particulière.

Le gamma est tout simplement une des caractéristiques de toute fonction de transfer, mathématiquement il s'agit de la dérivée au point médian de la courbe, plus communément la pente.

Source?

Parce que mathématiquement le terme "gamma" vient de l'exposant dans la fonction y=x^ɣ. Elle est calculée pour x variant de 0 a 1 (donc on ramene a 1 le point 2^8 ou 2^12 ou 2^16 suivant la profondeur des canaux). Au médian, la pente est ɣ*2^(1-ɣ), ce qui n'a évidemment rien a voir avec ɣ sauf quand on a une droite (ɣ=1).
https://en.wikipedia.org/wiki/Gamma_correction

source ?

bien on apprend cela à l'école en cours de maths, pour moi cela doit bientot faire 50 ans de cela, mis je ne crois pas que cela ai changé entretemps  :)

Juste qu'à l'époque les courbes de transfer ne pouvaient pas être calculées par manque de moyens, sauf par quelques énormes appareils électroniques analogiques qui coutaient le prix d'une maison.

Le gamma en photo est juste un cas particulier de la loi générique, à méditer  :)

Citation de: Jean-Claude le Juin 27, 2018, 06:54:15
source ?

bien on apprend cela à l'école en cours de maths, pour moi cela doit bientot faire 50 ans de cela, mis je ne crois pas que cela ai changé entretemps  :)

Juste qu'à l'époque les courbes de transfer ne pouvaient pas être calculées par manque de moyens, sauf par quelques énormes appareils électroniques analogiques qui coutaient le prix d'une maison.

Le gamma en photo est juste un cas particulier de la loi générique, à méditer  :)

Bizarre, je n'ai aucun souvenir de ça en math. Et puis le terme gamma en tant que tel est un terme générique en mathématique, il n'a pas de signification définie comme par exemple PI.

Pour moi, en photographie, la correction Gamma est celle qui vient de la vidéo https://fr.wikipedia.org/wiki/Correction_gamma

Citation de: Verso92 le Juin 26, 2018, 19:49:22
Question subsidiaire : si on développe en linéaire (avec un gamma de 1, donc, à la louche), on se retrouve avec le gamma de l'écran, soit 2.2, c'est bien ça ?
(donc, avec une image plutôt sombre avec les ombres qui ont du mal à décoller...)

Ce serait comme agir sur une image normale avec l'outil courbe en tirant la courbe vers le bas.
Ce serait plus simple de parler de gamma 2.2 pour un développement raw et de gamma 0,45 ( 1 / 2,2 ) pour l'écran.

Le deuxième paramètre de dcraw c'est une sorte de courbe en S, pour rattraper non plus les défauts d'affichages, mais pour avoir plus de contraste. Cela n'apparaît pas directement ou pas sous la forme d'un coefficient sur d'autres logiciels, mais il y a des réglages qui reviennent au même.

La question de Verso me semble particulièrement intéressante : Quand j'applique un profil linéaire, de quelle courbe de correction parle-t-on ? S'agit-il de la correction écran ou de la correction due au jpeg ?

En fait c'est encore un peu confus pour moi :
Si j'affiche une photo RAW sur mon écran, je pense avoir compris qu'il y avait deux corrections appliquées sur mon image :
- La correction pour s'adapter à la non linéarité de l'écran
- La correction "jpeg" qui fait rentrer les 12 ou 14 bits de ma photo dans les 8 bits de mon écran
J'ai un gros doute sur la seconde pour être honnête.

Et dans ce cadre, qu'est-ce que je fais quand dans mon logiciel de P/T je sélectionne un profil linéaire ?

Citation de: Jean-Claude le Juin 27, 2018, 06:54:15
source ?

bien on apprend cela à l'école en cours de maths, pour moi cela doit bientot faire 50 ans de cela, mis je ne crois pas que cela ai changé entretemps  :)

Juste qu'à l'époque les courbes de transfer ne pouvaient pas être calculées par manque de moyens, sauf par quelques énormes appareils électroniques analogiques qui coutaient le prix d'une maison.

Le gamma en photo est juste un cas particulier de la loi générique, à méditer  :)

Il y a des tonnes de cours de maths online. Si les maths sont les memes que dans ta jeunesse tu ne devrais pas avoir de mal a trouver quelque chose qui étaye ta mémoire.

Mais pour le moment mon conseil a quiconque lit ce que tu viens d'écrire est de prétendre n'avoir rien lu.

Citation de: remico le Juin 27, 2018, 11:39:30
Ce serait plus simple de parler de gamma 2.2 pour un développement raw et de gamma 0,45 ( 1 / 2,2 ) pour l'écran.

Pourquoi?

Citation de: egtegt² le Juin 27, 2018, 12:17:07
La question de Verso me semble particulièrement intéressante : Quand j'applique un profil linéaire, de quelle courbe de correction parle-t-on ? S'agit-il de la correction écran ou de la correction due au jpeg ?

En fait c'est encore un peu confus pour moi :
Si j'affiche une photo RAW sur mon écran, je pense avoir compris qu'il y avait deux corrections appliquées sur mon image :
- La correction pour s'adapter à la non linéarité de l'écran
- La correction "jpeg" qui fait rentrer les 12 ou 14 bits de ma photo dans les 8 bits de mon écran
J'ai un gros doute sur la seconde pour être honnête.

Et dans ce cadre, qu'est-ce que je fais quand dans mon logiciel de P/T je sélectionne un profil linéaire ?

Tu me sembles avoir des idées confuses sur la correction JPG. Cette correction n'est faite qu'au moment de la création d'un fichier JPG si j'ai biein compris les articles initiaux. Or il n'y a pas de fichier JPG entre un RAW et l'écran quand tu affiches une image dérawtisée.

Verso, ca dépend des options de colorimétrie pour l'affichage il me semble? Pour moi la courbe de transfert linéaire dont tu parles s'applique entre le RAW et l'image stockée en mémoire. Il y a une deuxieme conversion entre l'image stockée en mémoire et l'écran qui dépend de tes options colorimétriques et qui s'applique de la meme maniere que tu développes en linéaire ou pas. C'est comme ca que je comprends les choses.

Citation de: Franciscus Corvinus le Juin 27, 2018, 12:56:17
Tu me sembles avoir des idées confuses sur la correction JPG. Cette correction n'est faite qu'au moment de la création d'un fichier JPG si j'ai biein compris les articles initiaux. Or il n'y a pas de fichier JPG entre un RAW et l'écran quand tu affiches une image dérawtisée.

C'est pour ça que j'ai mis "jpeg" entre guillemets pour indiquer que je faisais référence au mécanisme qu'on utilise pour convertir un RAW en JPEG. Ma question était donc de savoir si en plus de la correction due à la non linéarité de l'écran, une courbe de correction gamma s'appliquait également pour convertir les 12 ou 14 bits du RAW en quelque chose d'affichable à l'écran.

Citation de: Franciscus Corvinus le Juin 27, 2018, 12:48:14
Pourquoi?

Pour différencier vu que les deux actions visent à se neutraliser. Utiliser deux paramètres différents pour la même fonction gamma ou bien utiliser le même paramètre mais avec deux noms de fonctions différentes, correction gamma de l'écran et compensation de la correction gamma de l'écran.

Citation de: remico le Juin 27, 2018, 13:52:52
Pour différencier vu que les deux actions visent à se neutraliser. Utiliser deux paramètres différents pour la même fonction gamma ou bien utiliser le même paramètre mais avec deux noms de fonctions différentes, correction gamma de l'écran et compensation de la correction gamma de l'écran.

En vidéo on utilise les termes OETF et EOTF et les 2 ne se neutralisent pas forcement. Il me semble que dans un environnement sombre, on doit rechercher un gamma système proche de 1.2.

Pour plus d'information, il y a le papier suivant ( en anglais ) :

http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP309.pdf

Citation de: egtegt² le Juin 27, 2018, 12:17:07
La question de Verso me semble particulièrement intéressante : Quand j'applique un profil linéaire, de quelle courbe de correction parle-t-on ?

C'est souvent un problème car on parle de linéaire dans de nombreux cas.

Il y a le linéaire du RAW ( les valeurs RGB des RAW sont proportionnelles aux luminances de la scène capturée).

Il y a le linéaire perceptuel et le pratiquement :-) linéaire perceptuel ( le sRGB est proche du perceptuellement lineaire, plus que le gamma 2.2 et encore plus que le 1.8).

Enfin certains parlent de linéaire quand la TRC d'un profil dcp est linéaire.

Certaines opérations effectuées sur les images numériques s'appliquent plus facilement dans certains cas .

Pour une balance des blancs, ou une correction d'expo, il vaut mieux travaille sur les données avec un gamma 1.0. c'est une des premières opérations du pipeline de lightroom.

Mais travailler avec un gamma 1.0 n'est pas pratique et il est plus facile d'utiliser certains outils lorsque les données sont proche du perceptuellement linéaire.

L'outil courbe de correction de tonalité de LR est appliqué après le passage dans le gamma sRGB et après l'application de la courbe de tonalité du profil dcp.

Citation de: Verso92 le Juin 26, 2018, 22:24:31
L'écran (CRT ou LCD) ne sait pas rendre les valeurs de façon correcte...

Est-ce qu'un écran LCD est aussi non linéaire qu'un CRT ?
Evidemment il n'est pas parfait mais j'ai tendance à croire que la correction qui pourrait le rendre linéaire est beaucoup plus faible que pour un CRT.
D'ailleurs la courbe d'étalonnage que vous avez donnée hier à 8h04 montre qu'il y a égalité entre la courbe idéale et la courbe effective, le but étant non pas d'obtenir la linéarité mais un gamma de 2.2 (2.4 d'après ma mesure sur cette courbe).
Ceci dit je ne serais pas surpris que le comportement d'un écran LCD actuel soit meilleur quand on lui applique un gamma de 2.2 plutôt qu'un gamma de 1.
Mais je pense que c'est un choix de fabrication.
Je pense que le jour où on décidera de ne plus appliquer de correction de 1/gamma aux fichiers issus du Raw (en interne ou en externe de l'appareil photo), les fabricants fourniront sans problème des écrans optimisés pour un comportement linéaire.
Ce jour n'est probablement pas près d'arriver car tous les fichiers passés et actuels ont cette correction.

Citation de: balfly le Juin 27, 2018, 22:26:47
Est-ce qu'un écran LCD est aussi non linéaire qu'un CRT ?

Aucune idée...

Citation de: balfly le Juin 27, 2018, 22:26:47
D'ailleurs la courbe d'étalonnage que vous avez donnée hier à 8h04 montre qu'il y a égalité entre la courbe idéale et la courbe effective [...]

Encore heureux : c'est la courbe après étalonnage !

Citation de: balfly le Juin 27, 2018, 22:26:47
Ceci dit je ne serais pas surpris que le comportement d'un écran LCD actuel soit meilleur quand on lui applique un gamma de 2.2 plutôt qu'un gamma de 1.
Mais je pense que c'est un choix de fabrication.

Pas compris... le gamme d'un écran LCD est ~2.2.

C'est un fait.


Si on voulait un gamma ~1, il faudrait une électronique de linéarisation incorporée...

Ce qui rendrait caduques (et inexploitables) les corrections "standards" dont sont affublées les images vidéo.

Citation de: balfly le Juin 27, 2018, 22:26:47
Je pense que le jour où on décidera de ne plus appliquer de correction de 1/gamma aux fichiers issus du Raw (en interne ou en externe de l'appareil photo), les fabricants fourniront sans problème des écrans optimisés pour un comportement linéaire.
Ce jour n'est probablement pas près d'arriver car tous les fichiers passés et actuels ont cette correction.

Pas compris (bis).

Lors de l'invention de la télévision, il aurait été facile de doter les récepteurs d'une linéarisation (comme les platines vinyles, cf courbe RIAA, par exemple).

Seulement, cela aurait déporté le coût de l'émetteur aux récepteurs : économiquement pas viable.

Citation de: Verso92 le Juin 27, 2018, 22:51:34
Pas compris... le gamme d'un écran LCD est ~2.2.

C'est un fait.
Si on voulait un gamma ~1, il faudrait une électronique de linéarisation incorporée...

Ce qui rendrait caduques (et inexploitables) les corrections "standards" dont sont affublées les images vidéo.

Est-ce que le gamma d'un pixel de LCD est 2.2 (en mettant la tension en abscisse)? Ou est-ce que les fabriquants d'écrans LCD appliquent une courbe de transfert de telle sorte que les écrans donnent l'impression d'avoir une réponse suivant un gamma 2.2?

Citation de: Franciscus Corvinus le Juin 28, 2018, 00:21:38
Est-ce que le gamma d'un pixel de LCD est 2.2 (en mettant la tension en abscisse)? Ou est-ce que les fabriquants d'écrans LCD appliquent une courbe de transfert de telle sorte que les écrans donnent l'impression d'avoir une réponse suivant un gamma 2.2?

Pour autant que j'ai bien compris, la réponse est oui. Ils appliquent un gamma pour ne pas remettre en cause tout ce qui a été fait depuis les écrans CRT. Car autant c'était coûteux à corriger sur les écrans cathodiques, autant ça pourrait se faire sans le moindre surcoût sur les écrans actuels.

Bon, effectivement, le gamma 2.2 des LCD est peut-être délibéré (pour rester cohérent avec les flux existants), et pas forcément subit...


Sinon, d'autres avis sur ma question posée un peu plus haut ?

Citation de: Verso92 le Juin 26, 2018, 19:49:22
Question subsidiaire : si on développe en linéaire (avec un gamma de 1, donc, à la louche), on se retrouve avec le gamma de l'écran, soit 2.2, c'est bien ça ?

Citation de: Verso92 le Juin 26, 2018, 19:49:22
Question subsidiaire : si on développe en linéaire (avec un gamma de 1, donc, à la louche), on se retrouve avec le gamma de l'écran, soit 2.2, c'est bien ça ?

(donc, avec une image plutôt sombre avec les ombres qui ont du mal à décoller...)

En tout cas, sur ce point, voici ce que j'ai remarqué avec DXO : Si je sélectionne un profil linéaire, l'image est effectivement sombre et peu saturée. Si je met un gamma de 2,2 sur la luminance, je retrouve une image avec une exposition proche de celle que j'avais en profil "standard".
Par contre, ce qui m'interpelle est le suivant :
Comme mon oeil n'est pas linéaire, si j'enregistre une image en linéaire (ce qui est le cas pour autant que je sache) et que je la restitue en linéaire parfait, pour moi je devrais la voir plus ou moins comme l'original (j'écris plus ou moins parce que si je photographie quelque chose de très lumineux, l'intensité lumineuse à l'écran sera moindre et il est possible que ça fasse une différence si mon oeil ne suit pas une courbe parfaitement logarithmique, ce qui est probable vu qu'il n'y connait rien en math :) )
Donc je dirais que l'image que tu affiche à l'écran doit bien être une image avec le gamma de l'écran, soit 0,45 qu'il faut corriger avec un gamma de 2,2 qui est l'inverse. (en fait, 0,45 et 2,2 sont un peu interchangeable suivant d'où on se place)

Ca semble logique car un RAW n'inclut pas le gamma de 2,2 pour corriger celui de l'écran, contrairement au jpeg.

Je te remercie de ta question, je crois bien qu'elle vient de me faire commencer à comprendre comment ça s'imbrique ;) ... jusqu'à ce qu'on me démontre que je me suis planté sur toute la ligne  ::)

Il me reste à comprendre pourquoi même si j'applique un gamma de 2,2 sur la luminance, l'image reste peu saturée. Faut-il aussi que j'applique ce même gamma sur les canaux couleurs ? Je pensais que ça s'additionnerait avec celui sur la luminance, mais visiblement j'ai encore pensé trop vite sur ce coup :) Mais il va falloir que je regarde les options possibles dans DXO car avoir un Gamma sur la luminance et un Gamma sur les canaux RVB me semble incohérent.

Citation de: egtegt² le Juin 28, 2018, 09:12:05
Donc je dirais que l'image que tu affiche à l'écran doit bien être une image avec le gamma de l'écran, soit 0,45 qu'il faut corriger avec un gamma de 2,2 qui est l'inverse. (en fait, 0,45 et 2,2 sont un peu interchangeable suivant d'où on se place)

Ca me semble un peu hasardeux de dire qu'un nombre et son inverse sont interchangeables. Si je te donnes €100, tu preferes me rendre un centieme ou cent fois plus? Moi je sais ce que je préfere! Un gamma > 1 aura un rendu a prédominance sombre. Un gamma < 1 aura un rendu a prédominance claire. Ca n'est pas interchangeable ni facile a confondre.

Citation de: egtegt² le Juin 28, 2018, 09:12:05
Il me reste à comprendre pourquoi même si j'applique un gamma de 2,2 sur la luminance, l'image reste peu saturée. Faut-il aussi que j'applique ce même gamma sur les canaux couleurs ? Je pensais que ça s'additionnerait avec celui sur la luminance, mais visiblement j'ai encore pensé trop vite sur ce coup :) Mais il va falloir que je regarde les options possibles dans DXO car avoir un Gamma sur la luminance et un Gamma sur les canaux RVB me semble incohérent.

En effet. Le gamma s'applique sur chaque canal, qui est un axe dans un modele de couleurs. Un des modeles a les trois axes RGB. Un autre a trois axes HSL (L pour luminance). Etc. Mais meme si ce sont des représentations, l'image que tu représentes reste unique. Donc si tu travalles en HSL et apres en RGB, tu fais deux transformations sur l'image. Il ne faut en faire qu'une. Et comme le gamma de l'écran est de 2.2 sur des pixels RGB, c'est uniquement dans l'espace RGB qu'il faut faire ta correction.

Le probleme est qu'il est difficile, quand on fait les corrections en RGB, de trouver un résultat plaisant facilement. Un autre probleme est que la teinte peut changer. Un des attraits du modele HSL est que pour certaines choses on arrive plus vite a un résultat plus plaisant. Le modele Lab combine un aspect intéressant de HSL (séparation couleurs et luminosité) avec d'autres de RGB et personnellement je le trouve plus pratique pour corriger les dominantes et la saturation. Mais tout cela n'a rien a voir avec le gamma et les courbes de transfert en général.

Citation de: Franciscus Corvinus le Juin 28, 2018, 11:27:11
Un gamma > 1 aura un rendu a prédominance sombre. Un gamma < 1 aura un rendu a prédominance claire.

C'est ce qui me semble aussi, bien qu'on lise le contraire dans l'article de Claude Tauleigne (RP N°313, P136).

Citation de: Franciscus Corvinus le Juin 28, 2018, 11:27:11
Ca me semble un peu hasardeux de dire qu'un nombre et son inverse sont interchangeables. Si je te donnes €100, tu preferes me rendre un centieme ou cent fois plus? Moi je sais ce que je préfere! Un gamma > 1 aura un rendu a prédominance sombre. Un gamma < 1 aura un rendu a prédominance claire. Ca n'est pas interchangeable ni facile a confondre.

Ce que je voulais dire, c'est que selon qu'on parle de la correction qu'on y applique ou de l'image à laquelle on l'applique, les valeurs sont inversées.

Un écran à une courbe de rendu Gamma de 0,45 et donc on applique une correction de 2,2. Et dans les différents articles que j'ai lu sur le sujet ces derniers jours, certains font référence au rendu, d'autres à la correction a y appliquer.

J'ai écrit ça parce que Verso a écrit :

CitationQuestion subsidiaire : si on développe en linéaire (avec un gamma de 1, donc, à la louche), on se retrouve avec le gamma de l'écran, soit 2.2, c'est bien ça ?

Et en fait, l'écran a un gamma de 0,45 qu'on corrige avec un facteur de 2,2. Donc parler de Gamma 0,45 ou de Gamma 2,2 pour un écran signifie en fin de compte la même chose, on se place simplement suivant deux perspectives différentes.

Citation de: Verso92 le Juin 28, 2018, 08:40:21
Sinon, d'autres avis sur ma question posée un peu plus haut ?

Citation de: Verso92 le Juin 26, 2018, 19:49:22
Question subsidiaire : si on développe en linéaire (avec un gamma de 1, donc, à la louche), on se retrouve avec le gamma de l'écran, soit 2.2, c'est bien ça ?

Pas simple ta question car comment tu fais pour développer (un raw ???) en linéaire avec un gamma de 1 sur tout le process de développement...

Sur lightroom ça ne me semble pas possible et sur capture one non plus ( mais bon, je suis en train d'analyser un peu CO et mes idées ne sont pas encore bien arrêtées, j'ai encore pas mal de tests a faire  :-)  )...

Enfin, ça veut dire quoi se retrouver avec le gamma de l'écran ?

Citation de: frmfrm le Juin 28, 2018, 15:47:58
Enfin, ça veut dire quoi se retrouver avec le gamma de l'écran ?

L'écran "distord" la luminosité; donc, si on n'applique pas au préalable un "distorsion" inverse, on obtient une image écran non fidèle à la scène initiale, ce qui est l'objectif technique de la chaîne scène - capteur - traitement - image numérique - écran
(je parle bien d'objectif technique, les courbes en S pour rehausser le contraste ou les remontées d'ombres de 3IL pour faire du HDR style smartphone sont une autre histoire)

Voici ce que j'ai compris de la chaîne (vous me corrigerez au besoin):

-mathématiquement, le gamma est une fonction exponentielle: gamma écran 2.2 signifie que la luminosité d'un pixel est égale à la valeur numérique en entrée élevée à la puissance 2.2 (je laisse tomber les facteurs multiplicatifs correspondant aux changements d'unités, ils n'interviennent pas ici)

-appliquer deux exponentielles successivement (par exemple un gamma de 0.45 puis un gamma de 2.2) revient à appliquer l'exponentielle dont le coefficient est le produit des coefficients de chacune.
Donc un gamma 2.2 appliqué à une image déjà affectée d'un gamma de 0.45 revient à appliquer un gamma global de 0.45x2.2 = 0.99, soit un gamma de 1, c'est-à-dire globalement pas de transformation.

-l'objectif technique est d'avoir une visualisation aussi proche que possible de la scène captée (les éventuels traitements artistiques constituent un autre aspect)
-peu importe que la sensibilité de l'œil soit linéaire ou logarithmique ou n'importe quoi d'autre: si on lui montre à l'écran la même chose que la scène d'origine, c'est bon (du point de vue technique, toujours).

-pour des raisons technico-économiques, les écrans cathodiques ont un gamma de l'ordre de 2.2; pour des raisons de compatibilité entre toutes les images existantes et à venir et tous les dispositifs de visualisation (dont l'immense majorité n'est pas calibrable), les écrans actuels ont également un gamma de 2.2

-pour que la visualisation soit autant que possible identique à la scène de départ, il faut que l'image numérique pré-compense le gamma de l'écran; il faut donc introduire un gamma de 0.45 entre la scène captée et l'image numérique, pour que le gamma global soit égal à 1

(l'écran a le gamma de 2.2 -c'est-à-dire une réponse en forme de branche droite d'un U- et non 0.45, c'est pour cela que le développement linéaire donne des images "sombres": les tons moyens sont tirés vers le bas par l'écran; si l'écran avait un gamma de 0.45 ce serait l'inverse.
Peut-être qu'appliquer un gamma 2.2 dans DXO, que je ne connais pas, signifie "appliquer un gamma pour un écran à 2.2"; on trouve souvent ce type de formulation dans les logiciels, par exemple pour les températures de couleur dans Gimp...)

-les valeurs RVB après dématriçage sont proportionnelles à la luminosité de la scène captée (car le capteur est linéaire, je laisse de côté les facteurs multiplicatifs et un éventuel écrêtage)

-par conséquent le gamma 0.45 doit être appliqué quelque part entre le dématriçage et la production du fichier visualisable (typiquement jpg). Si on l'omet, la chaîne applique globalement un gamma 2.2, donnant des images "sombres".

Est-ce correct? Si oui, ce fil m'aura bien aidé, merci à tous!

Je ne sais pas si c'est correct, mais j'ai compris la même chose :)

Merci pour ta réponse...

Citation de: jenga le Juin 28, 2018, 16:16:48
-par conséquent le gamma 0.45 doit être appliqué quelque part entre le dématriçage et la production du fichier visualisable (typiquement jpg). Si on l'omet, la chaîne applique globalement un gamma 2.2, donnant des images "sombres".

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.

On ne code pas forcement les jpg avec un gamma de 2.2 . Verso utilie parfois le L* , mais on a aussi le prophoto et l'adobeRGB qui n'ont pas non plus un gamma de 2.2. C'est au logiciel qui va afficher les images d'adapter l'image codée au gamma de l'écran pour qu'elle soit affichée correctement..

Si tu ouvres dans photoshop une image avec un gamma 1.0, soit tu utilises le CMS et elle s'affiche correctement, soit tu indiques de ne pas utiliser la gestion des couleurs et elle sera très sombre.

Citation de: frmfrm le Juin 28, 2018, 15:47:58
Sur lightroom ça ne me semble pas possible et sur capture one non plus ( mais bon, je suis en train d'analyser un peu CO et mes idées ne sont pas encore bien arrêtées, j'ai encore pas mal de tests a faire  :-)  )...

Je me quote moi même car je viens de faire quelques tests de CO et en première impression je pense qu'une partie du dev se passe avec un gamma de 1.8.

Ci-dessous, le dev d'un raw d'une bande de test où toutes les bandes sont équidistantes.

Pour le dev, j'ai choisi en entrée un profil avec un gamma de 1.8 et en sortie un profil avec un gamma de 1.0.

L'histo du haut représente l'histo du fichier final. On voit bien que les raies sont équidistantes, preuve qu'on a bien un gamma de 1.0 pour le développement.

Par contre sur l'histo des niveaux, on voit un gamma proche de 1.8 ce qui me semble être le gamma de travail pour cette étape du dev.

Maintenant, l'image du dessous représente le même dev, mais en utilisant cette fois ci un profil d'entrée avec un gamma de 1.0

Là, l'histo du haut est identique à l'histo des niveaux. Me semble que le gamma du profil d'entré est utilise pour compenser le gamma de travail...

J'ai regardé 2 ou 3 profils d'apn fournis avec CO et ils ont tous une gamma du profil d'entré proche de 1.8. Si quelqu'un à le courage de le faire pour tous les autres profils ;-)

Citation de: egtegt² le Juin 28, 2018, 12:50:16
Ce que je voulais dire, c'est que selon qu'on parle de la correction qu'on y applique ou de l'image à laquelle on l'applique, les valeurs sont inversées.

Un écran à une courbe de rendu Gamma de 0,45 et donc on applique une correction de 2,2. Et dans les différents articles que j'ai lu sur le sujet ces derniers jours, certains font référence au rendu, d'autres à la correction a y appliquer.

J'ai écrit ça parce que Verso a écrit :
Et en fait, l'écran a un gamma de 0,45 qu'on corrige avec un facteur de 2,2. Donc parler de Gamma 0,45 ou de Gamma 2,2 pour un écran signifie en fin de compte la même chose, on se place simplement suivant deux perspectives différentes.

N'oublie pas qu'un gamma est un cas particulier de courbe (fonction) de transfert. Ca n'est donc pas inhérent a une image. C'est inhérent a un périphérique seulement dans le sens ou celui-ci a une entrée (une valeur RGB) et donne une sortie (des lumens). Le "gamma" ne fait que décrire la correspondance entre l'entrée et la sortie.

A Verso92
Finalement j'ai fait des tests en imposant un calibrage écran avec un gamma de 1. La correction affichée dans les courbes de calibration devient importante ce qui montre que l'écran a par défaut un gamma proche de 2.2 puisque la correction est faible dans ce dernier cas.
J'avais mal interprété les courbes affichées après un calibrage. Cette discussion m'a permis de progresser dans la compréhension du calibrage de mon écran.
Donc les écrans actuels ne sont pas du tout linéaires, vous avez raison.

Je reviens sur la question que je me posais relative à la linéarité naturelle des LCD. A y réfléchir je pense finalement que, basés sur des effets de polarisation, il ne sont probablement pas naturellement linéaires.
Je présume que les écrans Amoled, qui devraient se répandre dans les années à venir, sont eux beaucoup plus proches de la linéarité.

Pour continuer dans une direction voisine, j'ai analysé avec une sonde d'imprimante une charte de gris que j'ai imprimée sur du papier glossy, j'ai trouvé (sauf pour le noir) une loi du type s = e^-0.9 = 1 en 1ère approximation, alors que la même comparaison faite avec mon écran me donnait s = e^2.2 (e est l'entrée qui varie de 1, correspondant à 255, à 0 ; s est la sortie).
Ceci conduit à dire que la correction de gamma (0.45) lors de la sortie du Raw sert à compenser le gamma de l'écran, alors qu'elle sert directement à l'impression.
Ceci reste à interpréter.

Citation de: egtegt² le Juin 28, 2018, 12:50:16
Et en fait, l'écran a un gamma de 0,45 qu'on corrige avec un facteur de 2,2.

Là, pas compris...

L'écran a un gamma de 2.2 : si tu as une entrée à 50%, tu obtiens 0,5^2,2 = 0,22 en sortie...

C'est la compensation avec un gamma = 1/2,2 (soit 0,45) qui remet les choses en ordre.

Citation de: frmfrm le Juin 28, 2018, 15:47:58
Pas simple ta question car comment tu fais pour développer (un raw ???) en linéaire avec un gamma de 1 sur tout le process de développement...

En développant en linéaire avec Capture One, par exemple ?

Une expliquation claire de http://www.profil-couleur.com/tp/216-correction-gamma.php
Le gamma est une caractéristique des moniteurs vidéo à reproduire les images plus contrastése et plus sombles que celles qu'on leur soumet en entrée. Cette reproduction tonale particulière provient du fait que la luminosité émise par les luminophores d'un tube cathodique n'est pas proportionnelle à la tension électrique appliquée dans le tube. En d'autres termes, si une tension de 1 volt donne le blanc, c'est à dire la luminance maximum de 100 %, une tension moyenne de 0,5 volt ne donnera pas une luminance de 50 % comme on pourrait l'esperait mais plutôt une luminance bien plus faible de 20 % seulement. Et cet écart s'amplifir de plus en plus en s'approchant des valeurs proches du noir.
Le gamma du moniteur n'est pas un propriété décidée par les constructeurs ou une réponse à un standard, c'est une contrainte incontournable liée aux lois naturelles de la physique. Bien que les écrans à tube cathodique ne soient pratiquement plus utilisés aujourd'hui, c'est dans ce système que la fonction mathématique appelée gamma est décrite.
Fig. 2. La déformation trop sombre par un moniteur est définie par une courbe mathématique non-linéaire (parabolique) qui porte le nom de courbe gamma
Prise en compte du gamma à la source
Dès la création de la télévion, 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 leut 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 réstitution 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.
Fig. 3. la correction du gamma est appliqué dès l'appareil photo numérique ou la caméra vidéo sous forme d'une courbe de transfert qui est l'inverse de celle du gamma
Etalonnage du gamma de l'écran
Puisque la courbe de transfert est appliquée de façon automatique sur l'ensemble des images dès la source, l'utilisateur de base n'a pas à se préocuper de cette correction gamma sur ses images. Par contre, il devra vérifier que son écran propose bien un gamma standard de 2,2. Bien que la plupart des écran LCD aient un gamma naturel de 2,2, il peut y avoir une petite dérive qu'il est facile de corriger lors de l'étalonnage de l'écran. Les écrans cathodiques quant à eux ont un gamma naturel de 2,5, il est donc indispensable d'étalonner leur gamma vers 2,2.

et la figure 3

Citation de: dioptre le Juin 28, 2018, 21:15:29
Une expliquation claire de http://www.profil-couleur.com/tp/216-correction-gamma.php
Le gamma est une caractéristique des moniteurs vidéo à reproduire les images plus contrastése et plus sombles que celles qu'on leur soumet en entrée. Cette reproduction tonale particulière provient du fait que la luminosité émise par les luminophores d'un tube cathodique n'est pas proportionnelle à la tension électrique appliquée dans le tube. En d'autres termes, si une tension de 1 volt donne le blanc, c'est à dire la luminance maximum de 100 %, une tension moyenne de 0,5 volt ne donnera pas une luminance de 50 % comme on pourrait l'esperait mais plutôt une luminance bien plus faible de 20 % seulement. Et cet écart s'amplifir de plus en plus en s'approchant des valeurs proches du noir.
Le gamma du moniteur n'est pas un propriété décidée par les constructeurs ou une réponse à un standard, c'est une contrainte incontournable liée aux lois naturelles de la physique. Bien que les écrans à tube cathodique ne soient pratiquement plus utilisés aujourd'hui, c'est dans ce système que la fonction mathématique appelée gamma est décrite.
Fig. 2. La déformation trop sombre par un moniteur est définie par une courbe mathématique non-linéaire (parabolique) qui porte le nom de courbe gamma
Prise en compte du gamma à la source
Dès la création de la télévion, 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 leut 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 réstitution 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.
Fig. 3. la correction du gamma est appliqué dès l'appareil photo numérique ou la caméra vidéo sous forme d'une courbe de transfert qui est l'inverse de celle du gamma
Etalonnage du gamma de l'écran
Puisque la courbe de transfert est appliquée de façon automatique sur l'ensemble des images dès la source, l'utilisateur de base n'a pas à se préocuper de cette correction gamma sur ses images. Par contre, il devra vérifier que son écran propose bien un gamma standard de 2,2. Bien que la plupart des écran LCD aient un gamma naturel de 2,2, il peut y avoir une petite dérive qu'il est facile de corriger lors de l'étalonnage de l'écran. Les écrans cathodiques quant à eux ont un gamma naturel de 2,5, il est donc indispensable d'étalonner leur gamma vers 2,2.

Oui, mais... tout cela est très clair, et assimilé par la plupart des intervenants, j'imagine.


La question est ailleurs...

Citation de: Verso92 le Juin 28, 2018, 22:07:43
Oui, mais... tout cela est très clair, et assimilé par la plupart des intervenants, j'imagine.

....

Pas si sur
Je ne suis pas si imaginatif

Heu ... quelle est la question ?

Citation de: dioptre le Juin 28, 2018, 21:15:29
Fig. 3. la correction du gamma est appliqué dès l'appareil photo numérique ou la caméra vidéo sous forme d'une courbe de transfert qui est l'inverse de celle du gamma
Etalonnage du gamma de l'écran
Puisque la courbe de transfert est appliquée de façon automatique sur l'ensemble des images dès la source, l'utilisateur de base n'a pas à se préocuper de cette correction gamma sur ses images.

Je vais reformuler ma question, alors : cette correction gamma (0,45 à la louche, pour faire court) est-elle appliquée sur les données du format RAW ?


Comprendre : est-elle appliquée quand on développe en linéaire avec Capture One, par exemple ?

Citation de: Verso92 le Juin 28, 2018, 20:34:14
Là, pas compris...

L'écran a un gamma de 2.2 : si tu as une entrée à 50%, tu obtiens 0,5^2,2 = 0,22 en sortie...

C'est la compensation avec un gamma = 1/2,2 (soit 0,45) qui remet les choses en ordre.

Oups ! c'est moi qui suis idiot, j'ai oublié qu'on parle de valeurs inférieures à 1. Donc 0,5^2,2 donne bien une valeur inférieure à 0,5, ce qui fait que j'ai inversé les chiffres. Ca ne change pas grand chose à mon raisonnement d'ailleurs, mais il faut inverser les chiffres que j'ai donnés.
Désolé  :-[

J'ai aussi été trompé par le fait que dans DXO, quand tu donnes un gamma de 2,5,  il affiche la courbe pointillée et pas la rouge, ce qui est un peu bizarre d'ailleurs.
(https://www.chassimages.com/forum/index.php?action=dlattach;topic=286152.0;attach=1041218;image)

Citation de: Verso92 le Juin 28, 2018, 22:26:00
Je vais reformuler ma question, alors : cette correction gamma (0,45 à la louche, pour faire court) est-elle appliquée sur les données du format RAW ?

En principe non, les données raw sont lineaires cad proportionnelles aux luminances de la scène capturée. ( Il me semble cependant qu'il y a un mode de raw spécial chez nikon).

Citation de: Verso92 le Juin 28, 2018, 22:26:00
Comprendre : est-elle appliquée quand on développe en linéaire avec Capture One, par exemple ?

Oui :-)

Tu as plusieurs étapes lors du développement. Il n'est peut être pas facile de lire comprendre les 2 dernières images que j'ai postées, mais on y trouve pas mal d'infos...

La première étape du développement s'effectue avec un gamma 1.

La seconde étape semble s'effectuer avec un gamma 1.8. ( car ce n'est pas facile de travailler avec l'outil courbe dans un gamma  1 )

Il y a aussi l'étape où on applique la trc du traitement  ( Courbe std ou courbe lineaire) C'est ce que certains appellent la courbe en S ou de contraste, mais elle ne fait pas qu'ajouter du contraste, elle remonte aussi les tons moyens et c'est pour ça que tu observes un assombrissement dans le cas d'une trc linéaire.

Enfin on applique le gamma du profil de sortie.

Maintenant si tu travailles comme dans mon exemple n° 1, l'exportation va te générer une image avec un gamma 1.0, mais comme CO utilise le CMS pour l'afficher lors du développement, elle s'affiche correctement et n'est pas trop sombre.

Citation de: frmfrm le Juin 29, 2018, 00:07:40
En principe non, les données raw sont lineaires cad proportionnelles aux luminances de la scène capturée. ( Il me semble cependant qu'il y a un mode de raw spécial chez nikon).

Oui :-)

Tu as plusieurs étapes lors du développement. Il n'est peut être pas facile de lire comprendre les 2 dernières images que j'ai postées, mais on y trouve pas mal d'infos...

La première étape du développement s'effectue avec un gamma 1.

La seconde étape semble s'effectuer avec un gamma 1.8. ( car ce n'est pas facile de travailler avec l'outil courbe dans un gamma  1 )

Il y a aussi l'étape où on applique la trc du traitement  ( Courbe std ou courbe lineaire) C'est ce que certains appellent la courbe en S ou de contraste, mais elle ne fait pas qu'ajouter du contraste, elle remonte aussi les tons moyens et c'est pour ça que tu observes un assombrissement dans le cas d'une trc linéaire.

Enfin on applique le gamma du profil de sortie.

Maintenant si tu travailles comme dans mon exemple n° 1, l'exportation va te générer une image avec un gamma 1.0, mais comme CO utilise le CMS pour l'afficher lors du développement, elle s'affiche correctement et n'est pas trop sombre.

Donc, si j'ai bien compris, la compensation du gamma de l'écran (2,2) est faite automatiquement par le CMS (un gamma de 0,45 ?), sans que l'on ait à s'en occuper en quelque sorte... c'est donc transparent pour l'utilisateur.

Citation de: frmfrm le Juin 29, 2018, 00:07:40
La première étape du développement s'effectue avec un gamma 1.

La seconde étape semble s'effectuer avec un gamma 1.8. ( car ce n'est pas facile de travailler avec l'outil courbe dans un gamma  1 )

Ce gamma de 1,8, il est imposé par le logiciel de développement, j'imagine ?


Par ailleurs, je ne suis pas sûr d'avoir bien compris les significations des deux histogrammes (ce qu'ils représentent exactement)...

Citation de: frmfrm le Juin 29, 2018, 00:07:40
La seconde étape semble s'effectuer avec un gamma 1.8. ( car ce n'est pas facile de travailler avec l'outil courbe dans un gamma  1 )

Il me semble que le gamma de 1.8 était celui choisi par Apple pour ses moniteurs il y a une dizaine d'années.

Comme à l'époque j'utilisais tantôt un PC tantôt un MacBook pour projeter mes photos avec un vidéoprojecteur, lorsque j'utilisais le MacBook, il fallait que je change au préalable son profil de calibration, puis que je revienne au gamma 1.8 après projection pour pouvoir utiliser le Macbook sans vidéoprojecteur.

Si tes copies d'écran viennent d'un Mac, cela expliquerait peut-être l'origine de cette étape avec gamma 1.8, ou alors c'est que la première version de Capture One aurait été développée sous Mac.

C'est juste une suggestion d'hypothèse, bien sûr.

Citation de: Tonton-Bruno le Juin 29, 2018, 09:09:37
Il me semble que le gamma de 1.8 était celui choisi par Apple pour ses moniteurs il y a une dizaine d'années.

Comme à l'époque j'utilisais tantôt un PC tantôt un MacBook pour projeter mes photos avec un vidéoprojecteur, lorsque j'utilisais le MacBook, il fallait que je change au préalable son profil de calibration, puis que je revienne au gamma 1.8 après projection pour pouvoir utiliser le Macbook sans vidéoprojecteur.

Si tes copies d'écran viennent d'un Mac, cela expliquerait peut-être l'origine de cette étape avec gamma 1.8, ou alors c'est que la première version de Capture One aurait été développée sous Mac.

C'est juste une suggestion d'hypothèse, bien sûr.

Je dirais même plus : il était vrai que ... mais cela remonte à 2009, et c'est totalement abandonné

Ce qu'on disait en 2009 :

Avec Snow Leopard, Apple a changé le gamma par défaut des Macs de 1.8 vers le gamma standard 2.2 (pour mémoire et en résumé, le gamma est le facteur de contraste de votre écran, l'écart entre le noir le plus profond et le blanc le plus lumineux).

Lars Borg, un des principaux spécialistes de la gestion de la couleur chez Adobe, revient sur cette décision sur le blog de John Nack.

Il rappelle ainsi que si le gamma des Macs était fixé à 1.8, c'était d'abord pour des raisons historiques. Quand Apple a sorti le Macintosh en 1984, il fallait faire correspondre son rendu colorimétrique avec les systèmes d'impression de l'époque, dont les imprimantes laser Apple... à gamma 1.8. Au début des années 1990, l'industrie télévisuelle a adopté un gamma de 2 pour son standard HDTV, et le standard sRGB de rendu colorimétrique des écrans CRT, adopté en 1996, a choisi un gamma à 2.2, qui est dès lors devenu la règle du côté PC. Apple a conservé son gamma historique d'1.8 sans autre réelle raison apparente que des raisons d'habitude.

Jusque là, un designer sur Mac, s'il voulait s'assurer du rendu colorimétrique de ses projets sur PC, soit sur 90% des ordinateurs du marché, devait passer au gamma 2.2. Celui-ci est "plus sombre" que le gamma à 1.8, ce qui le rend particulièrement adapté au Web et au rendu sur écran en général, mais parfois moins fidèle pour une impression sur papier, notamment pour les photographies en noir-et-blanc. En passant le gamma par défaut de Snow Leopard à 2.2, Apple simplifie la tâche des créatifs, notamment pour le Web, mais permet aussi un rendu des couleurs plus flatteur sur les écrans à diodes, pour le grand public.

Citation de: Verso92 le Juin 29, 2018, 07:32:46
Donc, si j'ai bien compris, la compensation du gamma de l'écran (2,2) est faite automatiquement par le CMS (un gamma de 0,45 ?), sans que l'on ait à s'en occuper en quelque sorte... c'est donc transparent pour l'utilisateur.

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

Citation de: Verso92 le Juin 29, 2018, 07:32:46
Ce gamma de 1,8, il est imposé par le logiciel de développement, j'imagine ?

Je le pense.

Lightroom lui utilise une réponse tonale de type sRGB. Il me semble avoir lu que l'on parlait de l'espace Melissa ( primaires du prophoto et réponse tonale du sRGB ). C'est les infos RGB du dév dans cet espace qui sont utilisées pour afficher l'histo de LR.
Mais pour ne pas polluer ce fils, je vais peut être ouvrir nouveau fil dans la rubrique Capture One pour avoir d'autres avis...

Citation de: Tonton-Bruno le Juin 29, 2018, 09:09:37
Il me semble que le gamma de 1.8 était celui choisi par Apple pour ses moniteurs il y a une dizaine d'années.

Je crois avoir lu que c'était plus compliqué que cela. ( il me semble que c'est dans la gamma faq de Charles Poynton ).

En fait 1.8 était le gamma de travail, mais les luts des cartes graphiques des Apple ramenaient le gamma système ( gamma 1.8 + gamma Luts ) à la bonne valeur.

Le problème, c'est que les luts des systèmes windows n'avaient pas cette compensation et on avait une différence entre ce que voyaient dans leurs navigateurs les utilisateurs de mac et les utilisateurs de pc  ( navigateurs qui  à l'époquen'avaient pas de CMS ).

Citation de: frmfrm le Juin 29, 2018, 13:25:02
Je crois avoir lu que c'était plus compliqué que cela. ( il me semble que c'est dans la gamma faq de Charles Poynton ).

En fait 1.8 était le gamma de travail, mais les luts des cartes graphiques des Apple ramenaient le gamma système ( gamma 1.8 + gamma Luts ) à la bonne valeur.

Le problème, c'est que les luts des systèmes windows n'avaient pas cette compensation et on avait une différence entre ce que voyaient dans leurs navigateurs les utilisateurs de mac et les utilisateurs de pc  ( navigateurs qui  à l'époquen'avaient pas de CMS ).

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.

Citation de: egtegt² le Juin 29, 2018, 00:01:39
Oups ! c'est moi qui suis idiot, j'ai oublié qu'on parle de valeurs inférieures à 1. Donc 0,5^2,2 donne bien une valeur inférieure à 0,5, ce qui fait que j'ai inversé les chiffres. Ca ne change pas grand chose à mon raisonnement d'ailleurs, mais il faut inverser les chiffres que j'ai donnés.
Désolé  :-[

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

Citation de: Tonton-Bruno le Juin 29, 2018, 15:17:59
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

Citation de: remico le Juin 29, 2018, 17:05:29
Pareil j'ai interverti les deux exposants à la page précédente.

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

Citation de: frmfrm le Juin 29, 2018, 13:14:09
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

Citation de: frmfrm le Juin 28, 2018, 16:49:58
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)?

Citation de: Verso92 le Juin 29, 2018, 19:40:07
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.

Citation de: jenga le Juin 29, 2018, 21:50:09
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*)

Citation de: dioptre le Juin 29, 2018, 18:25:00
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.

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.

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!

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  ;D
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 (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.

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.

Citation de: thom18 le Août 05, 2018, 07:59:10
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  ;D
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 (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:

Citation de: http://pics.idemdito.org/fr/tech/ordi/gamma.htm
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.

Citation de: thom18 le Août 05, 2018, 07:59:10
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.

Citation de: thom18 le Août 05, 2018, 07:59:10
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:

Citation de: https://en.wikipedia.org/wiki/Color_spaceA 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

Citation de: Franciscus Corvinus le Août 05, 2018, 17:45:39
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.

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 ...  :o

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  ;D) 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 (http://www.brucelindbloom.com/index.html)

Cordialement.

Citation de: thom18 le Août 05, 2018, 19:38:16
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.

Citation de: thom18 le Août 05, 2018, 19:38:16
PS : j'avale assez mal le coup de l'espace colorimétrique dans le raw ...  :o

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?

Citation de: thom18 le Août 05, 2018, 20:23:35
[...]

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.

Citation de: egtegt² le Août 06, 2018, 00:46:41
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... :-[

Citation de: egtegt² le Août 06, 2018, 00:46:41
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.

Citation de: thom18 le Août 05, 2018, 20:23:35
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! ;D
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?

Citation de: thom18 le Août 05, 2018, 20:23:35
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.

Citation de: https://ninedegreesbelow.com/photography/xyz-rgb.html
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.

Citation de: Franciscus Corvinus le Août 06, 2018, 03:21:46
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://poynton.ca/PDFs/Rehabilitation_of_gamma.pdf)
http://www.profil-couleur.com/tp/216-correction-gamma.php (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.

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

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

;)

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

Citation de: thom18 le Août 04, 2018, 12:33:30Derniè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.

Citation de: philooo link=topic=286152.msg6861131#msg6861131 date=1533618835
Se rappeler que tout est "logarithmisé".
/quote]
Diable, mais où as-tu vu cette information ?
Cordialement.

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.

Citation de: thom18 le Août 06, 2018, 22:25:09
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:

Citation de: Charles Pyonton, The rehabilitation of gamma
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.

Citation de: thom18 le Août 06, 2018, 22:25:09L'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.

Citation de: thom18 le Août 06, 2018, 22:25:09
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 (http://www.tftcentral.co.uk/article/hdr.htm#monitor_hdr)) 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é).
(http://zdnet2.cbsistatic.com/hub/i/r/2014/10/05/2b45a912-4ca1-11e4-b6a0-d4ae52e95e57/resize/770xauto/589156ad7443ee82d280dd9fe1b178c9/meeker620-620x466.jpg)
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?

Citation de: Franciscus Corvinus le Août 07, 2018, 17:36:33
<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.

Citation de: Franciscus Corvinus le Août 07, 2018, 17:36:33
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 (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 (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 (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.

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

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

Citation de: thom18 le Août 07, 2018, 22:09:52
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.

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

Citation de: Franciscus Corvinus le Août 07, 2018, 17:36:33
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?

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.

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.

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.

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... ;)

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

La suite au prochain numéro ?

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.

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

Citation de: thom18 le Août 16, 2018, 22:38:50
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 ?

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

Citation de: Verso92 le Août 18, 2018, 11:34:37
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.

Citation de: Franciscus Corvinus le Août 18, 2018, 19:59:57
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 ?

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.

Citation de: Verso92 le Août 18, 2018, 20:43:03
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).

Citation de: Franciscus Corvinus le Août 19, 2018, 11:10:45
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)

Citation de: Verso92 le Août 19, 2018, 11:13:59
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).

Citation de: Verso92 le Août 19, 2018, 11:13:59
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.

Citation de: Verso92 le Août 19, 2018, 11:13:59il 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.

Citation de: Verso92 le Août 19, 2018, 11:13:59
(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.

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.

Citation de: Verso92 le Août 18, 2018, 11:34:37
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 (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 (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.

Citation de: B_M le Août 18, 2018, 12:04:57
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 (http://www.claudegabriel.be/B2%20Lumi%C3%A8re%20et%20image,%20chapitre%209.pdf)

Citation de: asak le Août 19, 2018, 03:19:00
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.

Citation de: asak le Août 19, 2018, 03:19:00
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.

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           (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
(https://goo.gl/de7zhU)

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 (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/ (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.

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.

asak, il est en train de s'installer un dialogue de sourds entre nous deux que je clôturerai ici. Je te laisse l'entière responsabilité de tes affirmations mais, en tant que mathématicien, je voudrais te faire remarquer que dans tout ce fil et dans tous les documents indiqués en lien, il n'a jamais été question de fonctions logarithmes ou de leur réciproque (exponentielles). Ce ne sont que des fonctions puissances qui interviennent dans ces corrections.
Amicalement.

C'est quoi la différence entre une fonction puissance et une fonction exponentielle ?

Citation de: egtegt² le Août 28, 2018, 09:25:14
C'est quoi la différence entre une fonction puissance et une fonction exponentielle ?

Voici la réponse  ;)

Citation de: thom18 le Août 28, 2018, 09:10:53
asak, il est en train de s'installer un dialogue de sourds entre nous deux que je clôturerai ici...

Pas forcement simple de s'entendre car les choses sont plus complexes, enfin à mon avis.

Lorsqu' asak parle de trc logarithmique, il n'a pas forcement tord car il me semble que la sortie d'un jpeg par un appareil numérique peut être assez proche d'une fonction log, au moins dans les tons moyens. Ci-dessous, les trc d'un raw purement linéaire avec DPP4 dans 3 espaces différents. ( le contraste du dév a été fixé à -3 pour faciliter la lecture).

Enfin, 2 remarques sur ton papier/page web :

La TRC d'encodage n'est pas forcement l'inverse de la réponse du moniteur. Dans le cas de l'observation en faible lumière, le gamma système recherché n'est pas 1.0, mais plus élevé ( et il me semble avoir lu qu'on est plus proche d'un gamma système de 1.2).

Le travail sur une image linéaire n'est pas toujours facile et la mise en oeuvre de certains outils ( comme l'outil courbe de tonalité) est plus aisée lorsque l'image est proche du perceptuellement linéaire. Proche car on n'utilise pas forcément le Lstar. Par ex. capture one effectue cette opération après passage dans son espace de travail ( qui me semble proche de 1.8). LR lui l'effectue après le passage dans son espace de travail qui a un gamma sRGB. ( Mais là aussi les choses sont peut-être plus compliquées :-) )

Citation de: thom18 le Août 28, 2018, 09:10:53
asak, il est en train de s'installer un dialogue de sourds entre nous deux que je clôturerai ici.

Il faut peut-etre recadrer le dialogue en expliquant pourquoi tu veux parler du gamma. Comme déja dit je pense que c'est ca qui manque. Pour ton texte, je pense qu'asak peut convenir que ca n'est pas techniquement faux.

Franciscus Corvinus, j'ai déjà répondu à ta question : le document que je vous ai présenté est un paragraphe d'un document de 15 pages présentant la colorimétrie moderne aux membres de mon PhotoClub.

Lorsque j'ai préparé ce document, je n'avais qu'une vague connaissance du gamma, c'est la raison qui m'a conduit à présenter le premier jet du paragraphe sur le gamma dans ce fil du forum de Chasseur d'images. J'en ai retiré la conviction qu'il était préférable que contrairement à beaucoup d'auteurs (cf. PS2 et PS3 en bas de page) je n'associe pas le gamma à la vision humaine mais à l'évolution historique de la visualisation d'images sur écran CRT puis LCD ou LED. Ma présentation finale simple, résultant tout de même d'une synthèse de beaucoup de documents sérieux sur le web a paru séduire certains d'entre vous mais a suscité des remarques diverses que je ne comprenais de moins en moins.

Mon monde photographique est celui, je pense de beaucoup d'autres photographes modestes :

-- un moniteur avec un gamma réglé à 2,2 suivi d'un étalonnage qui assure entre autre, la régularité de ce gamma pour les trois canaux R,V, B.
-- un logiciel de traitement des raws qui me permet de créer des jpeg ou des Tiff dans l'espace colorimétrique Adobe RGB ou l'espace colorimétrique sRGB.

- Quand je crée un jpeg dans l'espace colorimétrique Adobe RGB, conformément à la norme Adobe RGB 1998, il y a, à partir du raw développé, d'abord application d'un gamma de 1/2,2 (fonction sortie=entrée^1/2,2) puis application de l'algorithme de compression jpeg, codage puis écriture du fichier.

- Quand je crée un Tiff dans l'espace colorimétrique Adobe RGB, conformément à la norme Adobe RGB 1998, il y a, à partir du raw développé, d'abord application d'un gamma de 1/2,2 (fonction sortie=entrée^1/2,2) puis codage et écriture du fichier.

- Si l'espace choisi est sRGB, alors la formule du gamma est un peu plus complexe, elle est écrite dans l'image jointe copiée sur Wikipédia.

- Quand je visualise sur mon écran une telle image, les opérations inverses sont effectuées, notamment l'application d'un gamma de 2,2 puisque c'est ainsi que j'ai étalonné mon écran.

Il semble que ce monde ne soit pas ou plus celui de certains intervenants mais c'est encore le mien, du moins c'est ainsi que je comprends les normes citées.

Cordialement

PS1 : Quand le process est fait directement dans l'appareil photo pour produire un jpeg, c'est évidemment le même algorithme qu'à partir d'un raw via un "dérawtiseur". Aucune fonction logarithme à l'horizon.

PS2 : Le simple gamma 2,2 a pour but d'annuler le gamma 1/2,2 des images sRGB ou Adobe RGB : le gamma total résultant étant de 1. Certains préconisent plutôt pour être plus flatteur à l'oeil de cibler un gamma total résultant de 1,1.

PS3 : La réponse de l'oeil à la luminance d'une source a été quantifiée entre autre par la fonction L* de CIE Lab. C'est peut-être ce qui conduit certains à préférer un étalonnage écran en L* au lieu d'un simple gamma 2,2. Là encore des fonctions puissances 1/3 dans L* mais aucun logarithme.

De toute façon, tu ne feras jamais l'unanimité. Soit tu fais un document exhaustif et on te dira qu'il est trop compliqué, soit tu simplifies et on te dira que tu as trop simplifié ;)
Sans compter ceux qui de toute façon te diront que tu te trompes dans le seul et unique but d'étaler leurs connaissances  ::)

Pour ce qui me concerne, tu as fait un bon document de vulgarisation, et comme tout document de vulgarisation, il y a des approximations indispensables pour le rendre compréhensible. Et il est à mon avis largement suffisant pour comprendre ce qui est nécessaire du gamma dans la vie de tous les jours pour un photographe.

J'aimerais bien voir le reste de ton document, mais je comprends parfaitement que tu puisse souhaiter le conserver à usage interne de ton club ;)

Citation de: egtegt² le Septembre 04, 2018, 09:57:23
J'aimerais bien voir le reste de ton document, mais je comprends parfaitement que tu puisse souhaiter le conserver à usage interne de ton club ;)

La raison fondamentale qui fait que je ne saurais rendre public un tel document est surtout que bien que je sois l'auteur du texte de ce document et de l'articulation des explications qu'il contient, il est illustré par de nombreux graphiques bruts ou adaptés puisés sur de nombreux sites sur le web. Tous ces sites sont cités et leurs auteurs formellement remerciés dans la préface, mais je n'ai pas effectivement les autorisations pour utiliser ces graphiques qu'il est difficile et quelquefois impossible de refaire aussi je me contente d'une diffusion privée restreinte.

Dommage, mais c'est ainsi.
Cordialement.
PS : j'ai fait une petite entorse à ce respect du droit en publiant tout de même le paragraphe sur le gamma, mais les sites sources ont été cités lors de la présentation initiale du texte.

Citation de: thom18 le Septembre 04, 2018, 08:36:19
Franciscus Corvinus, j'ai déjà répondu à ta question : le document que je vous ai présenté est un paragraphe d'un document de 15 pages présentant la colorimétrie moderne aux membres de mon PhotoClub.

Merci, désolé d'avoir oublié le contexte.

je commence à avoir certaines difficultés à vous suivre
A l'ouverture d'un raw qui est flat; il y a une précorrection gamma  et un profil caméra qui s'installent  ... l'écran en crée une copie image et établie une Lut de correspondance pour coller au gamma attribué à l'écran; en faisant remarquer que un LCD n'a pas une réponse gamma mais utilise une correction gamma.

Cette LUT  interne  n'a rien a voir avec une caractérisation écran; le système étant en boucle ouverte. On ferme temporairement la boucle avec une sonde pour établir une correction au niveau de la carte graphique.

La mise en évidence de la précorrection se fait sur écran gamma 1;  L'image  s'affiche correctement et tout ce qui est soft apparaît pâle.

La mise en évidence de la LUT écran ce fait sur un JPG par exemple après trois phase d'ouverture et d'enregistrement on peut constater de l'effet cumulatif , avec la disparition progressive des valeurs moyennes un tassement des valeurs sombres, on se dirige progressivement vers un effet de seuil.

On pourrait aussi discuter de l'assombrissement périphérique ... Quel influence sur le Gamma ?

On peut s'affranchir de la précorrection; mais là il faut utiliser un soft qui ne l'utilise pas et enregistrer en tif pour l'ouvrir dans adobe par exemple. On peut appliquer cette méthode pour établir des profil ou utiliser des Log ou ETTR ?
Pourquoi Lstar ?
(https://goo.gl/Z9FM9g)

C'est sans doute correct dans ta tete, mais je n'y comprends rien.

Juste pour exemple: "il y a" décrit un état, et utilise ca pour expliquer des transformations (actions). Sémantiquement, ca ne tient pas debout.

Autre exemple: "précorrection (...) et profil (..) qui s'installent". Non un profil ne s'installe pas. Un programme (lequel?) utilise un profil. Ou un programme transforme une image d'un profil vers un autre.

Dernier exemple: "L'image  s'affiche correctement et tout ce qui est soft apparaît pâle.". "soft", c'est défini comment? Parce que suivant ce a quoi ca fait référence, apparaitre "pale" pourrait etre une défaut, auquel cas l'image ne s'affiche pas correctement.

etc.

Encore une fois, je ne juge pas la véracité de ce que tu dis. Juste la clarté d'expression.

On prendra pour référence adobe
A la prise de vue et enregistrement le fichier raw est à l état brut  son rendu est pâle sans contraste
A l ouverture de ce fichier par acr  le dematricage le corrige avec une "courbe gamma" puis avec le profil caméra canon nikon... c est juste cette partie que l on peut transformer en linéaire..
Concernant le soft qui est codé uniquement rvb il est tributaire du gamma pour son echelle de gris
Concernant le L* je compléte ma réponse.... le gris L*  correspont au gris infographique 128 le 2.2 a 117 et le 1.8 de sulement 98 pour le gamma simple 2.47 il correspond aussi a 128.