calibrage moniteur Gamma 2.2 ou courbe L* ?

[asak]

Il serait bon de vérifier que photoshop donne bien un gris rvb à 128 et TSL a 50 avant de wspéculer 

[Benaparis]

Il serait bon de vérifier que photoshop donne bien un gris rvb à 128 et TSL a 50 avant de wspéculer  

A partir du moment où vous utilisez un espace de travail où un profil d'image qui est en L* (Prostar ou eciRGBv2 par exemple) vous pouvez être certain que ce sera le cas...Cela n'a rien à voir avec l'affichage à l'écran...à ce moment là ce n'est plus la pipette qu'il faut utiliser mais un spectromètre  

Je pense que vous faites la confusion entre les espaces travail et l'affichage du moniteur à proprement parler.

[asak]

A partir du moment où vous utilisez un espace de travail où un profil d'image qui est en L* (Prostar ou eciRGBv2 par exemple) vous pouvez être certain que ce sera le cas...Cela n'a rien à voir avec l'affichage à l'écran...à ce moment là ce n'est plus la pipette qu'il faut utiliser mais un spectromètre  

Je pense que vous faites la confusion entre les espaces travail et l'affichage du moniteur à proprement parler.

Non je ne fais pas de confusion  Je m'adresse à ceux qui calent leur écran en L et qui ne sont pas en espace L  C'est un moyen de vérifier et qui peu expliquer le pourquoi du comment de certains écarts   

[Benaparis]

Non je ne fais pas de confusion  Je m'adresse à ceux qui calent leur écran en L et qui ne sont pas en espace L  C'est un moyen de vérifier et qui peu expliquer le pourquoi du comment de certains écarts  

Au temps pour moi 😉

[Dub]

Non je ne fais pas de confusion  Je m'adresse à ceux qui calent leur écran en L et qui ne sont pas en espace L  C'est un moyen de vérifier et qui peu expliquer le pourquoi du comment de certains écarts   

Vu le niveau des intervenants , cela me semblait évident ...

Quoi que ...

 

[fred94-]

Non je ne fais pas de confusion  Je m'adresse à ceux qui calent leur écran en L et qui ne sont pas en espace L  C'est un moyen de vérifier et qui peu expliquer le pourquoi du comment de certains écarts   

Ouf alors?   

[tenmangu81]

Vous avez un ensemble hardware 30bits....etc, vous traiter un TIFF avec un joli dégradé de gris perfecto que vous visualisez de manière parfaite et vous m'envoyer ce fichier.

Moi je l'ouvre dans Photoshop avec le même espace de travail sur un écran pourri mais je l'imprime avec le même matos que vous sans rien touché, j'ai le même résultat ou pas?

Une mauvaise visualisation sur écran (soft proofing ou profil d'épreuve) n'a aucune incidence sur l'impression à condition que ce soit le même fichier et qu'on l'envoie sur la même imprimante avec le même profil.

[olivier1010]

Il me vient une idée permettant à coup sur de déterminer si Photoshop prend correctement en compte la courbe tonale L* à l'affichage : créer un leurre, un profil écran incluant pour chaque canal RVB :

- les valeurs gamma 1.0, 1.0, 1.0

- trois courbes LUT L*
Si Photoshop sait lire les courbes LUT du profil, il affichera correctement l'image. Sinon il affichera une image complétement délavée croyant que l'écran est en gamma 1.0. Valeur qu'il aura été chercher dans la matrice de base du profil au lieu de lire les courbes LUT.

Faire cet essai en générant un profil V2 et un V4, les deux formats prenant en charge les LUT (le V4 permet aussi de prendre en charge une description de courbe tonale par équation paramétrique).

Evidement il faudra bricoler à la main dans le profil car je doute qu'il soit possible de générer un tel profil avec une application de gestion de profil. Cela dit modifier les trois valeurs de gamma doit être simple avec un éditeur hexa, si tant est qu'il ne faille pas recréer une clé de hachage pour le fichier. Ce qui ne semble pas être le cas après vérification rapide dans le standard icc v4.

En regardant dans la spécification icc V4 en page 27, je m'aperçois comme je le pensais qu'un profil peut contenir optionnellement un tag gamutTag lorsqu'il contient déjà des courbes LUT pour décrire les courbes tonales.

http://www.color.org/specification/ICC1v43_2010-12.pdf

Je m'aperçois également de cela :

In addition to the tags listed in 8.2 an N-component LUT-based Input profile shall contain the following tags:  
⎯  AToB0Tag (see 9.2.1);
⎯  BToA0Tag (see 9.2.6).

Le profil devrait donc contenir en plus du gamma et des courbes LUT non seulement une table de transformation couleur de A vers B en rendu perception, mais aussi de B vers A dont je ne vois pas trop l'utilité pour un profil écran. Elle doit être là parce qu'un profil écran peut être utilisé pour autre chose qu'un écran puisque c'est un profil RGB standard.

Si l'application prend en charge uniquement cette table de transformation pour corriger la luminance de l'affichage, et si cette table ne contient pas assez de patchs dans les bas niveaux, ce qui me semble être le cas dans les réglages standards des logiciels de calibration écran où l'on a généralement environ 50 patchs, alors on peut raisonnablement penser que le rendu ne sera très précis en terme de luminance. Cela pourrait expliquer ces différences de rendu en luminance entre L* et gamma 2.2.
Pour vérifier cette hypothèse, il suffirait de générer un profil écran avec 30 ou 40 patchs en niveaux de gris en plus des patchs couleurs, pour être sur que la correspondance par rapport à la courbe tonale théorique serait bien respectée. Dans le cas d'une application qui ne s'aiderait pas des courbes LUT pour établir une correspondance exacte en terme de luminance, mais se baserait uniquement sur la table de correspondance couleur AToB0Tag.

Ces tables de correspondance couleurs peuvent d'ailleurs être codées au choix  en 8 ou 16 bits, ce qui peut influer sur la précision du résultat final, mais il me semble que tout est passé en 16 bits dans les logiciels de génération de profil depuis longtemps. Egalement les différences qu'on voit sur l'exemple de Christophe, facilement visibles, sont certainement supérieures aux différences qu'on pourrait avoir en passant de tables LUT 8 bits à des tables 16 bits. Il faudrait vérifier dans les profils générés mais je suis presque sur que toutes les LUT sont aujourd'hui en 16 bits.

[olivier1010]

Deux choses à prendre en compte si vous tentez de réaliser ce type de profil écran très précis avec 30 ou 40 patchs en niveaux de gris : il faut absolument utiliser du matériel haut de gamme pour éviter de mettre en évidence des défauts qui seraient induits par le hardware :

- écran stable à calibration hardware et compensation en température

- liaison avec l'écran en 10 bits par canal (utilisation du Display Port obligatoire pour les ecrans Eizo, carte vidéo supportant ce mode, mode 30 bits activé dans le driver de la carte vidéo)

- logiciel de profilage prenant en charge la liaison vidéo en 10 bits par canal pour afficher les patchs (oui on ne pense pas forcément à vérifier ça !)

- générer des tables LUT en 16 bits dans le profil écran (ce qui doit être toujours le cas je pense car ce réglage n'est même plus disponible dans les logiciels de création de profil écran)

- et enfin utiliser un colorimètre écran haut de gamme corrigé en température, surtout pas un spectro qui a une mauvaise précision dans les noirs et produirait un résultat pouvant aller jusqu'au désastreux dans l'affichage des noirs et des tons sombres. Le i1 Display Pro ou peut être mieux le Discus me semblent les plus appropriés pour faire ces expérimentations.

Attention également aux anciens spectro comme le i1 pro, qui en plus d'une mauvaise précision dans les noirs, souffrent d'une très forte dépendance à l'orientation des sources polarisées, ce qui est la cas sur un écran LCD. Toujours les placer parfaitement verticalement sur l'écran sinon les différences sur les valeurs mesurées sont colossales d'une sessions de mesure à une autre.

[olivier1010]

Pour info quelques explications très intéressantes données dans un autre fil par Jean Delmas. Explications qui confirment comme je le pensais que les courbes tonales de l'écran qu'elles soient gamma 2.2, L* ou sRGB ne devrait pas beaucoup changer la perception à partir du moment ou l'on est en 10 bits par canal pour la liaison écran.

"Berns rappelle en outre que la recherche d’un « gamma optimal » n’a de sens que si la résolution tonale n’est que de 8 bits."

Donc à mon avis, les causes des différences visibles entre gamma 2.2 et L* qu'a remarqué Christophe sont à rechercher dans une mauvaise gestion du profil écran par l'application, ou bien dans un profil écran dont la table conversion couleur ne contiendrait pas assez de patchs N/B pour assurer une représentation précise des niveaux de luminance, si l'application utilise seulement cette table et non les LUT de courbes tonales du profil pour assurer le codage de la luminance.

Pour ces questions de quantification, mais aussi pour celles, bien plus graves, qui concernent les écrêtages de gamut, vous pouvez consulter la récente étude (2014) de Roy S. Berns, dont MBe a rappelé ici le lien il y a qq semaines : https://www.google.fr/search?q=camera+encoding+evaluation&ie=utf-8&oe=utf-8&rls={moz:distributionID}:{moz:locale}:{moz:official}&gws_rd=cr&ei=7RRaVfT6C6aAywOPsoCoBw

Cette étude aborde un domaine photographique exigeant en matière de colorimétrie, celui de la reproduction des œuvres d’art et des autres objets patrimoniaux. Dans sa partie consacrée aux erreurs de quantification, Berns conclut qu’avec une résolution tonale de 16 bits, les différences obtenues entre gamma=1,8 et gamma=2,2 ou L* sont négligeables. Berns rappelle en outre que la recherche d’un « gamma optimal » n’a de sens que si la résolution tonale n’est que de 8 bits. Et il conclut finalement que le « Studio for Scientific Imaging and Archiving of Cultural Heritage » continuera de définir ses images dans ProPhoto RGB… Bon, cette décision péremptoire n’est peut-être que provisoire et pourrait changer s’il parcourre ce fil.

3 - Perte de niveaux à l’affichage par erreur de quantification

Pour en terminer avec les mauvais tours que nous jouent les erreurs de quantification, examinons ce qui se passe chez un photographe possédant un écran dont le comportement natif est la courbe gamma 2,2 (ce qui n’est pas rare) et qui, séduit par les austérités de la Très Sainte Clarté L*, décide de le calibrer sur la courbe L*. Supposons qu’il fasse cette opération en chargeant les données correctives dans la LUT de sa carte graphique. Eh bien, si la carte graphique fait ses calculs sur 8 bits (ce qui n’est pas rare non plus), son affichage perdra 8,59% des niveaux d’entrée (8,35% si la carte graphique travaille sur 12 bits).

Tabernacle ! Un raisonnement basé sur la « cohérence » des courbes tonales militerait donc ici pour la conservation du comportement natif de l’écran à la place de la courbe L* ?  Rassurez vous, adopter L* pour l’affichage reste un bon choix et présente un avantage qualitatif (*) marginal mais incontestable pour les écrans qui le permettent. Et les inconvénients ci-dessus dus à la quantification ne pèsent pas bien lourd vis-à-vis de cet avantage.

De même qu’avec une résolution tonale de 16 bits, « l’inconvénient de cohérence » présenté par ProPhoto RGB et sa courbe gamme 1,8 compte pour du ghee (beurre clarifié à la clarté L*) à coté des écrêtages de gamut provoqués par un espace comme eciRGB_v2 qui présente l’avantage de L* mais aussi et surtout les inconvénients sévères d’un gamut trop petit pour les impressions à jet d’encre modernes. Et quid de ProStar RGB alors ? Eh bien le gaillard possède tous les avantages, celui du gamut de ProPhoto RGB et ceux de la courbe de réponse L*. C’est donc un choix optimal, mais ne rêvons pas, il n’apporte probablement aucun progrès visible à l’affichage de ceux qui, comme Berns, utilisent aujourd’hui déjà ProPhoto RGB.

Les photographes qui trouvent que leur noirs affichés sont moins bouchés avec un écran réglé sur L* sont des artisans attentifs et bien équipés d’un écran pour arts graphique soigneusement étalonné. En revanche, je ne vois pas par quel prodige de la Très Sainte Clarté leur affichage (et même leurs impressions !) pourraient être améliorés  en 16 bits par une définition des images dans un espace RGB ayant L* comme courbe tonale…

Quant à la bonne idée consistant à créer un espace de travail RGB avec L* comme courbe de réponse tonale, merci Salomé de lever les doutes de votre ami blogueur taquin et sceptique. Je confirme que c’est par un mail du sympathique Bruce Lindbloom daté du 20 septembre 2007 (c’était un jeudi) qu’il m’a annoncé que c’était probablement lui qui en avait eu le premier l’idée dans une conférence donnée en 1989 au SIGGRAPH dont il m’a envoyé un exemplaire en PJ que j’ai conservé depuis sous mon oreiller.

(*) A quoi devons nous cet avantage ? Mais à la sempiternelle racine cubique ! Je rappelle que la courbe L* est un bon modèle de notre perception des luminances parce que, la clarté L* variant linéairement avec la racine cubique de la luminance, elle se conforme au fait que, quand on multiplie une luminance par 2x2x2, notre perception ne ressent qu’un doublement de la luminosité (2 est la racine cubique de 2x2x2). Voila pourquoi la courbe L* est vraiment intéressante et non parce qu’elle donne une clarté de 50% (127 sur l’échelle 0-255) pour le gris moyen de luminance relative=18%, car la courbe gamma=2,47 et bien d’autres encore possèdent la même agréable propriété.

[fred94-]

salut

Donc si je résume en gros car je ne comprends que les courbes et les couleurs "avec mon ptit cerveau":

Peut importe le choix pour calibrer son écran entre L* ou 2.2 car l'essentiel est de choisir un "espace de travail en L*".

[asak]

C est peut etre normal si on utilise un espace de travail gamma avec une visu L..
Espace de tra ail gamma visu gamma. Espace de travail L visu L.
 

Deuxieme reponse du fil de 4 pages 

[olivier1010]

salut

Donc si je résume en gros car je ne comprends que les courbes et les couleurs "avec mon ptit cerveau":

Peut importe le choix pour calibrer son écran entre L* ou 2.2 car l'essentiel est de choisir un "espace de travail en L*".

Non, l'essentiel est d'avoir un système qui marche correctement pour le travail qu'on a à réaliser. Dans le cas de la question du début de ce fil, il y a un problème avec L* sur les niveaux de luminance produits par le profil écran et j'ai proposé quelques pistes pour essayer de déterminer d’où il vient. Il est suffisamment prononcé pour être facilement visible et donc gênant dans un processus de tirage qualité expo.

L'harmonisation des courbes tonales entre espaces est un autre débat. Berns montre par exemple qu'à une résolution de 16 bits le choix de la courbe tonale de l'espace n'a que peu d'influence sur le résultat des conversions entre espaces. 16 bits est la norme depuis longtemps pour les tables de correspondance dans les profils même s'il est toujours possible de créer des profils avec des tables 8 bits ce qui n'a plus de sens aujourd'hui vu la puissance des machines.

Ensuite il y a l'influence des courbes tonales sur la linéarité perceptuelle d'un espace, et cela peut avoir une influence sur les traitements qu'on applique dans l'image selon les algorithmes utilisés. Encore ici il faut faire attention à ce qu'on dit, par exemple certains logiciels dont Lightroom utilisent des espaces internes différents pour la visualisation et le traitement. La visualisation en gamma 1.8 pour Lightroom avec Melissa, et un espace avec les mêmes primaires mais en gamma 1.0 pour les traitements internes.

Je pense qu'on ne peut pas tirer des règles définitives en ce qui concerne le bienfait de tel ou tel espace ou courbe tonale. Il y a tellement de paramètres qui entrent en ligne de compte, depuis les besoins de l'utilisateur du CMS jusqu'aux performances possibles voir les bugs des logiciels employées, qui ne savent pas toujours gérer correctement tel ou tel aspect des conversions icc. En passant par la profondeur de quantification ou de calcul de chaque logiciel, fichier image et de chaque périphérique, sans parler de la précision des sondes de mesure, de l'influence de la couleur des papiers et de la présence ou non de produits azurants, de l'influence de l'éclairage pour la visualisation des tirages (conditions de visualisation). Lorsqu'on veut aller au bout des choses il faut prendre le problème dans son ensemble et avoir une bonne compréhension de la colorimétrie, sinon on risque d'être fortement déçu par ce que peut apporter le CMS qui ne traite qu'une partie du problème de la transmission des couleurs de leur source vers leur destination.

Le mieux je pense est de rester dans la limite de ce qu'on comprend et de ce qui fonctionne pour le travail qu'on a besoin de réaliser. Plutôt que de jouer aux apprentis sorcier pour se rendre compte au final qu'on perd sont temps à essayer d'améliorer quelque chose qui marche déjà bien avec les paramètres par défaut qui sont souvent mieux pris en compte dans les matériels et les logiciels.

Si on ne comprend pas, ce qui n'est pas condamnable au vu de la complexité de la gestion des couleurs, ou parce que on a trop petit cerveau ce qui peut arriver , soit on essai d'apprendre pour aller jusqu'au bout des choses, soit on fait avec des méthodes standards qui marchent bien dans la plupart des situations.

Il y a tant de choses à améliorer avant de se prendre la tête avec les systèmes CMS, comme par exemple l'éclairage de la pièce et la qualité de son écran , la qualité de son imprimante, de ses sondes, ses connaissances globales en gestion des couleurs... Des choses qui apporteront certainement plus que changer les profils CMS dans tous les sens.

[Benaparis]

Non, l'essentiel est d'avoir un système qui marche correctement pour le travail qu'on a à réaliser. Dans le cas de la question du début de ce fil, il y a un problème avec L* sur les niveaux de luminance produits par le profil écran et j'ai proposé quelques pistes pour essayer de déterminer d’où il vient. Il est suffisamment prononcé pour être facilement visible et donc gênant dans un processus de tirage qualité expo.

L'harmonisation des courbes tonales entre espaces est un autre débat. Berns montre par exemple qu'à une résolution de 16 bits le choix de la courbe tonale de l'espace n'a que peu d'influence sur le résultat des conversions entre espaces. 16 bits est la norme depuis longtemps pour les tables de correspondance dans les profils même s'il est toujours possible de créer des profils avec des tables 8 bits ce qui n'a plus de sens aujourd'hui vu la puissance des machines.

Ensuite il y a l'influence des courbes tonales sur la linéarité perceptuelle d'un espace, et cela peut avoir une influence sur les traitements qu'on applique dans l'image selon les algorithmes utilisés. Encore ici il faut faire attention à ce qu'on dit, par exemple certains logiciels dont Lightroom utilisent des espaces internes différents pour la visualisation et le traitement. La visualisation en gamma 1.8 pour Lightroom avec Melissa, et un espace avec les mêmes primaires mais en gamma 1.0 pour les traitements internes.

Je pense qu'on ne peut pas tirer des règles définitives en ce qui concerne le bienfait de tel ou tel espace ou courbe tonale. Il y a tellement de paramètres qui entrent en ligne de compte, depuis les besoins de l'utilisateur du CMS jusqu'aux performances possibles voir les bugs des logiciels employées, qui ne savent pas toujours gérer correctement tel ou tel aspect des conversions icc. En passant par la profondeur de quantification ou de calcul de chaque logiciel, fichier image et de chaque périphérique, sans parler de la précision des sondes de mesure, de l'influence de la couleur des papiers et de la présence ou non de produits azurants, de l'influence de l'éclairage pour la visualisation des tirages (conditions de visualisation). Lorsqu'on veut aller au bout des choses il faut prendre le problème dans son ensemble et avoir une bonne compréhension de la colorimétrie, sinon on risque d'être fortement déçu par ce que peut apporter le CMS qui ne traite qu'une partie du problème de la transmission des couleurs de leur source vers leur destination.

Le mieux je pense est de rester dans la limite de ce qu'on comprend et de ce qui fonctionne pour le travail qu'on a besoin de réaliser. Plutôt que de jouer aux apprentis sorcier pour se rendre compte au final qu'on perd sont temps à essayer d'améliorer quelque chose qui marche déjà bien avec les paramètres par défaut qui sont souvent mieux pris en compte dans les matériels et les logiciels.

Si on ne comprend pas, ce qui n'est pas condamnable au vu de la complexité de la gestion des couleurs, ou parce que on a trop petit cerveau ce qui peut arriver , soit on essai d'apprendre pour aller jusqu'au bout des choses, soit on fait avec des méthodes standards qui marchent bien dans la plupart des situations.

Il y a tant de choses à améliorer avant de se prendre la tête avec les systèmes CMS, comme par exemple l'éclairage de la pièce et la qualité de son écran , la qualité de son imprimante, de ses sondes, ses connaissances globales en gestion des couleurs... Des choses qui apporteront certainement plus que changer les profils CMS dans tous les sens.

+1000 😊

Savoir rester pragmatique dans ce domaine m'apparaît en effet essentiel.

[Nikojorj]

- Avec un profil d'affichage en L*, il est préférable de travailler dans espace de travail avec un TRC  L* ou de finaliser dans tiff avec un profil L* afin de garder la cohérence.

Ah? Tant qu'on est pas limité par la quantification (et on ne va pas se remettre à bosser en 8bits comme il y a 20 ans hein?), quel intérêt de mettre le L* dans l'espace de travail?

[Nikojorj]

Il me semble en tout cas que pour profiter du L*, un écran avec calibration hardware est nécessaire.

Mon gravier à l'édifice : en essayant L* sur un moniteur bas de gamme, les pbs de linéarité étaient plus gênants que le gain de détails dans les BL... et je trouvais, mais c'est peut-être surtout une question d'environnement, que les BL étaient un poil trop éclaircies à mon goût.
Je retiens que la courbe sRGB pourrait faire un juste milieu.

Peut importe le choix pour calibrer son écran entre L* ou 2.2 car l'essentiel est de choisir un "espace de travail en L*".

C'est l'inverse, non? On peut se faire un espace de travail tarabiscoté OSEF, et par contre entre L* et 2.2 à l'écran l'affichage n'est pas le même.

[olivier1010]

Mon gravier à l'édifice : en essayant L* sur un moniteur bas de gamme, les pbs de linéarité étaient plus gênants que le gain de détails dans les BL... et je trouvais, mais c'est peut-être surtout une question d'environnement, que les BL étaient un poil trop éclaircies à mon goût.
Je retiens que la courbe sRGB pourrait faire un juste milieu.

C'est l'inverse, non? On peut se faire un espace de travail tarabiscoté OSEF, et par contre entre L* et 2.2 à l'écran l'affichage n'est pas le même.

Je pense que L* ou 2.2 n'a plus tellement d'importance aujourd'hui puisqu'on peut attaquer l'écran en 10 bits par canal. Les deux courbes sont suffisamment proches je pense pour qu'en 10 bits on ne voit plus trop de différence entre l'une ou l'autre, à condition évidement que l'application corrige l'affichage correction en fonction de ces deux différentes courbes.

Par contre je viens de lire dans l'étude "A New Encoding System for Image Archiving of Cultural Heritage :ETRGB"   que L* est plus proche de gamma 2.4. Je pensais initialement que L* est était plus proche de gamma 2.2.

Fort de ce constat, j'ai repris les images de Christophe et quand j'ajoute 0.2 à l'image de Christophe en gamma 2.2, ce qui fait un gamma de 2.4,  je retombe approximativement sur l'image de gauche en L*.

J'en déduit qu'il y a effectivement un problème avec Photoshop sur la gestion du profil écran en L*. Je pense qu'il considère que l'écran est en gamma 2.2, ce qui explique que l'image apparaisse trop claire avec une calibration L* qui s'approche donc de gamma 2.4.

C'est une supposition, il faudrait vérifier en modifiant le profil L* comme je l'ai proposé plus haut : modifier les tags gamma en par exemple en 1.0 pour voir si Photoshop tient compte de ce ces tags, ou s'il tient réellement compte des courbes tonales L* du profil.

Il faudrait aussi tout simplement regarder comment est construit le profil L* de Christophe. Il y a peut être un problème à ce niveau, il pourrait contenir des tags gamma 2.2 au lieu de 2.4 ou pas de tags gamma du tout.

[Miaz3]

je réitère :
Le delta c'est bien le end-to-end gamma ? (je viens de la video, hein) donc pour un gamma de 2.2 il faudrait qu'il soit entre 1.1 et 1.2, non ?
et pour le print vers 1.4 ?

Sachant qu'il y ai bien trois gamma. (moniteur, correction, endtoend)

[MBe]

Ah? Tant qu'on est pas limité par la quantification (et on ne va pas se remettre à bosser en 8bits comme il y a 20 ans hein?), quel intérêt de mettre le L* dans l'espace de travail?

les CMM qui utilisent les espaces de travail qui réalisent les calculs sur des quantifications bien supérieure à 8 bits, la TRC L* définie une courbe, pas la quantification.

[fred94-]

Salut,

Suivant l avis d olivier1010 et l étude ETRGB donc c'est logique la différence entre les deux images de M.Metairie. Mais il faudrait savoir comment a été traité cette image, développement seul ou développement+retouche dans Topshop?

"Un autre avantage de L * est son terme explicite de pente pour des couleurs presque noir. Bien que cela a été développé pour éviter des valeurs L * négatives, il sert également comme un terme linéaire pour éviter une pente infinie à 0. Ainsi, la fonction de L * a été sélectionné."
Pi être il y a confusion avec les espaces de travail en L*?

[MBe]

Pour info quelques explications très intéressantes données dans un autre fil par Jean Delmas. Explications qui confirment comme je le pensais que les courbes tonales de l'écran qu'elles soient gamma 2.2, L* ou sRGB ne devrait pas beaucoup changer la perception à partir du moment ou l'on est en 10 bits par canal pour la liaison écran.

"Berns rappelle en outre que la recherche d’un « gamma optimal » n’a de sens que si la résolution tonale n’est que de 8 bits."

Donc à mon avis, les causes des différences visibles entre gamma 2.2 et L* qu'a remarqué Christophe sont à rechercher dans une mauvaise gestion du profil écran par l'application, ou bien dans un profil écran dont la table conversion couleur ne contiendrait pas assez de patchs N/B pour assurer une représentation précise des niveaux de luminance, si l'application utilise seulement cette table et non les LUT de courbes tonales du profil pour assurer le codage de la luminance.

Olivier1010, tu as bien fait de remonter l'analyse de Jean Delmas   et je suis globalement d'accord avec tes analyses.

J'ai quelques questions pour toi :

- Est ce que tu sais comment il a calculé les erreurs de quantification entre TRC 2,2 et L*?

Pour en revenir au profil calculé par ColorNavigator (Eizo) :

- La balise vcgt est bien une droite, j'ai vérifié (donc en effet tout est normal et conforme à tes explications détaillées).
-La TRC  L* et 2, 2 ont chacune un offset, ce qui fait que la courbe ne se superpose pas dans les basses lumières, est ce que tu peux regarder sur tes profils?
Pour un profil L* j'ai :

0 64
1 93
2 121
3 149
4 177
[...]
pour un profil en 2,2  je relève :
0 259
1 259
2 260
3 262
4 266
[...]
==> c'est codé de 0 à 255 en entrée et de 0 à 65535 en sortie

Merci.

[Miaz3]

Oups, désolé : j'ai fait une confusion malencontreuse entre les deux termes (la fatigue ?)... merci de m'avoir remis dans le droit chemin !

;-)

Votre lexique est un brin faussé, et c'est lu en diagonale.
Exemple avec le GAIN, le gain est une opération de multiplication, alors que le contraste est de l'ordre de la puissance.
Donc il ne peut en aucun cas : permet de régler (en %) l'intensité de l'augmentation du contraste des zones de transition.
La CHROMINANCE, attention car il y a plusieurs termes...la CHROMINANCE (générale) est plutôt de l'ordre d'une information de couleurs -YCBCR- (et sous-échantillonnage) et non d'artefacts colorés dans l'image
Si vous parlez de BRUIT il faut une partie dédiée au GRAIN aussi.
INTERPOLATION : très mal traduit de l'anglais "subsampling" qui lui même est lié à l'aliasing.
Si vous parlez de QUANTIFICATION il faut expliquer l'échantillonnage aussi et non de SHANNON
...
bref, la fatigue surement.

[olivier1010]

je réitère :
Le delta c'est bien le end-to-end gamma ? (je viens de la video, hein) donc pour un gamma de 2.2 il faudrait qu'il soit entre 1.1 et 1.2, non ?
et pour le print vers 1.4 ?

Sachant qu'il y ai bien trois gamma. (moniteur, correction, endtoend)

Dans un système CMS (color management system) les courbes tonales (qui peuvent être gamma ou non) n'ont pas vraiment d'importance puisque le CMS réalise les conversions entre périphériques afin que le résultat soit identique quelque soit la cible. On entend encore parler de gamma surtout pour l'écran, car il peut se calibrer sur diverses courbes tonales, dont gamma généralement entre 1.8 et 2.4, ou courbe tonale sRGB ou L* ou tout autre courbe tonale spécifique comme celle du système DICOM pour l'imagerie médicale. Cette possibilité de réglage est principalement liée à l'histoire des écrans qui ont évolué et ont du surtout s'adapter à divers périphériques d'impression à l'époque ou les CMS n'existaient pas. Aujourd'hui la courbe tonale de l'écran a tendance à se standardiser, et ce sera encore plus vrai avec le nouvel espace REC 2020.

Dans un système CMS, on calibrera généralement l'écran sur une courbe non linéaire proche de la sensibilité de l’œil, afin de profiter au mieux de la liaison vidéo qui est en 8 ou 10 bits par canal seulement. Soit sRGB ou L* de préférence, mais pas obligatoirement. Gamma 2.2 ou 2.4 sont également suffisamment proches pour donner de bons résultats. Dans tous les cas ce réglage ne devrait pas influencer les niveaux de luminance affichés puisqu'il y aura une compensation du coté de l'application pour afficher les bons niveaux. Selon la courbe choisie et à cause de la liaison vidéo en faible profondeur de quantification (surtout si elle est en 8 bits), il y aura effectivement des légères différences de rendu dans les bas niveaux et un peu de banding, à cause des écarts en luminance (mais aussi en chrominance) induits par cette liaison de faible profondeur de quantification. Ces écarts sont quand même minimes si l'écran est calibré hardware.

Idem pour l'impression connaître le gamma de l'imprimante n'a plus de sens aujourd'hui, elle est décrite bien plus précisément dans son profil couleur avec des tables de couleurs composées parfois de plusieurs milliers de correspondances. Ce qui est nettement plus précis qu'un simple système de courbe tonale. Et le système Icc V4 propose même une table de correspondance inverse dans les profils d'impressions, afin de faire concorder au mieux les couleurs écran.

Pour ceux qui sont débutants dans les systèmes CMS, je leur conseil le livre de Jean Delmas : "La gestion des couleurs". Sinon c'est impossible de suivre ce genre de fil.

[Miaz3]

Dans un système CMS (color management system) les courbes tonales (qui peuvent être gamma ou non) n'ont pas vraiment d'importance puisque le CMS réalise les conversions entre périphériques afin que le résultat soit identique quelque soit la cible. On entend encore parler de gamma uniquement pour l'écran, car il peut se calibrer sur diverses courbes tonales, dont gamma généralement entre 1.8 et 2.4, ou courbe tonale sRGB ou L* ou tout autre courbe tonale spécifique comme celle du système DICOM pour l'imagerie médicale.

Dans un système CMS, on calibrera généralement l'écran sur une courbe non linéaire proche de la sensibilité de l’œil, afin de profiter au mieux de la liaison vidéo qui est en 8 ou 10 bits par canal seulement. Soit sRGB ou L* de préférence, mais pas obligatoirement. Gamma 2.2 ou 2.4 sont également suffisamment proches pour donner de bons résultats. Dans tous les cas ce réglage ne devrait pas influencer les niveaux de luminance affichés puisqu'il y aura une compensation du coté de l'application pour afficher les bons niveaux. Selon la courbe choisie et à cause de la liaison vidéo en faible profondeur de quantification (surtout si elle est en 8 bits), il y aura effectivement des légères différences de rendu dans les bas niveaux et un peu de banding, à cause des écarts en luminance (mais aussi en chrominance) induits par cette liaison de faible profondeur de quantification. Ces écarts sont quand même minimes si l'écran est calibré hardware.

Idem pour l'impression connaître le gamma de l'imprimante n'a plus de sens aujourd'hui, elle est décrite bien plus précisément dans son profil couleur avec des tables de couleurs composées parfois de plusieurs milliers de correspondances. Ce qui est nettement plus précis qu'un simple système de courbe tonale. Et le système Icc V4 propose même une table de correspondance inverse dans les profils d'impressions, afin de faire concorder au mieux les couleurs écran.

Pour ceux qui sont débutants dans les systèmes CMS, je leur conseil le livre de Jean Delmas : "La gestion des couleurs". Sinon c'est impossible de suivre ce genre de fil.

Bien sur, mais cela ne répond toujours pas à ma question ?!

[MBe]

je réitère :
Le delta c'est bien le end-to-end gamma ? (je viens de la video, hein) donc pour un gamma de 2.2 il faudrait qu'il soit entre 1.1 et 1.2, non ?
et pour le print vers 1.4 ?

Sachant qu'il y ai bien trois gamma. (moniteur, correction, endtoend)

Je comprends pas bien ta question...

Si ta question correspond à : (mais j'ai un doute)

Si plusieurs appareils se succèdent dans une chaîne avec g1,g2, g3, la résultante sera :

sortie = entrèe^g1*g2*g3