calibrage moniteur Gamma 2.2 ou courbe L* ?

[olivier1010]

Petite question en passant, Olivier : j'ai quelquefois un message d'avertissement que je ne comprends pas trop (ça concerne un problème sur le jeu de couleurs actif (?)), à la fois chez moi (Nec PA241w + SpectaViewII + W7 64 Pro) et au club photo (Nec SV241w + Profiler 5 + W7 64 Pro)...

J'ai bien vérifié que le dégradé du fichier "ramp.psd" était plus lisse en 3 x 10 bits qu'en 3 x 8 bits :
http://www.chassimages.com/forum/index.php/topic,137922.msg2634914.html#msg2634914
Je viens de vérifier, suite à ton post, le thème choisi... c'est correct, n'est-ce pas (les thèmes "Aéro" sont bien ceux avec la transparence du bandeau du haut de la fenêtre ?) ?

Question subsidiaire : bien que je vois une différence à l'affichage sur le fichier ramp, j'ai du mal à voir une différence réelle sur les photos... ton avis ?

Humm je suis pas sur, il me semble que j'ai aussi de la transparence sans être en aéro.. Il faut juste choisir un thème de base.

La transparence peut se désactiver dans "couleur de la fenêtre" dans la personnalisation du bureau.

Oui sur les photos réelles on voit rarement la différence, par ce que d'une part il faut des dégradés larges et assez sombres et d'autre part le bruit numérique contenu dans les photos lisse les dégradés. C'est nettement plus visible sur des images de synthèse.

On utilise le 30 bits depuis au moins 20 ans en vidéo, c'est pas pour rien. Cela permet de contrôler les images au mieux quelque soit leur origine, Cela me semble important en production d'être certain de la qualité. En 24 bits des petits problèmes de banding par exemple peuvent passer sous silence.

Avec la généralisation du 10 et bientôt 12 bits par canal qui s'annonce (merci HDMI 2.0), il est certainement important de ne pas rester en retrait coté production pour éviter de délivrer des images où les spectateurs finaux découvriraient des problèmes

[MBe]

Donc  [at] Mbe quand tu écris qu'il n'y a de différence pour toi ok pas de problème par contre tu dis quoi pour l'écart entre les deux images u début du fil?

Peut être un problème de compatibilité du profil espace de travail et/ou du profil intégré dans l'image finalisée par le logiciel de traitement d'image avant l'impression, comme Christophe Metairie n'est pas repassé sur ce fil depuis 2 jours (environ), nous ne savons rien de la chaîne complète qui a été utilisée.
Un autre aspect, si le profil est en icc V4, certains CMM ne savent pas les gérer par exemple et les résultats ne sont pas forcément prédictifs sans une analyse détaillée de la chaine de développement.
Christophe Metairie a également une très bonne culture sur la gestion des couleurs, il a peut être trouvé la cause de l'écart?

[MBe]

Je pense qu'on est au moins deux à penser que le L* n'est pas le soucis, qu'on devrait avoir des résultats très proches au niveau affichage pour la luminance si l'application compense correctement, et qu'il y a donc un loup quelque part dans le système de Christophe, ou un problème de compatibilité, ou un profil mal interprété. Car au bas mot il y a une erreur d'environ 0.2 en gamma sur son image en L*. Ce n'est pas normal, cela devrait être compensé par l'application lors de l'application du profil écran.

Oui je suis d'accord.

Un autre aspect auquel j'ai pensé, sans conclure totalement (des essais sont à faire) : la dynamique des meilleurs papiers d'impression ( Baryté et/ou RC brillant ?) est bien plus faible que celle d'un écran, de plus quand on fait une compensation point noir, la distribution des valeurs est recalculée en fonction du point noir papier, il y a donc nécessairement une compression, est ce que cette compression annihilerait l'effet L*?

==> Ce facteur de compression est lié au contenu du fichier image, et peut être donc pas systématique (?)
==> Une des premières remarque sur ce fil (de Salomé) est d'utiliser un RIP (Raster Image Processor) qui permet une maîtrise plus importante sur  la possibilité de linéariser, d'agir sur le point d'encrage (correspondant en simplifiant au gamma de l'écran), sans passer par le driver de l'imprimante en privilégiant par exemple les basses lumières ou les hautes lumières, l'exploitation d'un profil en L* demande peut être ce type d'interface pour en conserver tous les avantages dans quelques cas particuliers ?

[Verso92]

Oui sur les photos réelles on voit rarement la différence, par ce que d'une part il faut des dégradés larges et assez sombres et d'autre part le bruit numérique contenu dans les photos lisse les dégradés. C'est nettement plus visible sur des images de synthèse.

Merci pour ton retour, Olivier (quelque part, ça me rassure !).

[Miaz3]

Hi, hi... je n'ai pas un Eizo, mais un Nec. Et pas une NVidia, mais une ATi (AMD) FirePro.
Le 3 x 10 bits est bien sûr activé dans le Catalyst Pro Control Center :

hehe , j'ai du me planter avec Mbe...

[MBe]

Merci pour ton retour, Olivier (quelque part, ça me rassure !).

Le 3 * 10 bits est intéressant pour le rapport signal à bruit, car pour la vision humaine, elle n'apporte rien,  la sensibilité ( Delta de luminance / luminance) est d'environ 2%, soit environ 50 niveaux sur une échelle de 1 à 100, donc en arrondissant 2^6.
Ta perception (vision) sur une image codée sur 10 bits est donc tout à fait normale.
C'est également probablement pour cela que les applications qui gèrent du 10 bits ne sont pas nombreuses (comme les cartes vidéo).

[olivier1010]

Oui je suis d'accord.

Un autre aspect auquel j'ai pensé, sans conclure totalement (des essais sont à faire) : la dynamique des meilleurs papiers d'impression ( Baryté et/ou RC brillant ?) est bien plus faible que celle d'un écran, de plus quand on fait une compensation point noir, la distribution des valeurs est recalculée en fonction du point noir papier, il y a donc nécessairement une compression, est ce que cette compression annihilerait l'effet L*?

==> Ce facteur de compression est lié au contenu du fichier image, et peut être donc pas systématique (?)
==> Une des premières remarque sur ce fil (de Salomé) est d'utiliser un RIP (Raster Image Processor) qui permet une maîtrise plus importante sur  la possibilité de linéariser, d'agir sur le point d'encrage (correspondant en simplifiant au gamma de l'écran), sans passer par le driver de l'imprimante en privilégiant par exemple les basses lumières ou les hautes lumières, l'exploitation d'un profil en L* demande peut être ce type d'interface pour en conserver tous les avantages dans quelques cas particuliers ?

Non je ne pense pas que ce soit nécessaire même si un RIP apporte beaucoup de souplesse. Je pense qu'il y a simplement un problème de compatibilité avec un
profil dans le cas qui nous intéresse ici, ou un problème de calibration hardware de l'écran pourquoi pas (échange entre deux profils et leur calibration associée, mauvaise calibration chargée ou quelque chose dans le genre).

En ce qui concerne la compensation du point noir, elle se fait entre profile source et profile destination. Par exemple entre le fichier image et l'impression par réduction de la dynamique du fichier image pour la faire rentrer dans celle du périphérique d'impression.

Si l'affichage est en mode normal, le profil d'impression n'intervient pas pour l'affichage. On ne devrait avoir (presque) aucune différence d'affichage entre
une calibration en gamma 2.2 et une calibration en courbe tonale L* qui doivent être compensées par le profil écran. Le fichier image est connecté à
l'écran par un profil source en passant par l'espace de connexion XYZ, à destination de l'écran à travers le profil écran qui avertit l'application (ou le
CMS) qu'elle doit appliquer tel ou tel gamma ou courbe tonale pour l'affichage afin de compenser la calibration de l'écran et obtenir les mêmes niveaux de
luminance dans tous les cas, aux erreurs de quantification près dues à la faible profondeur de quantification de la liaison vidéo en 8 ou 10 bits par canal.

En mode aperçu d'épreuve, l'écran n'est plus connecté directement au fichier image. Le fichier image converti ses données par son profil source vers l'espace de connexion XYZ puis vers l'imprimante à travers la table de correspondance couleur du profil d'impression en appliquant la compensation du point noir. Puis la table de correspondance couleur inverse du profil d'impression est utilisée pour faire correspondre les couleurs imprimées avec l'écran, en repassant par l'espace de connexion XYZ, pour ressortir par le profil écran. On parle alors non pas de compensation de point noir dans ce sens là (celle-ci est déjà réalisée entre le fichier image et l'impression) mais de simulation d'encre et de teinte de papier qui est une fonction qui s'active séparément.

Dans le mode aperçu d'épreuve on repasse donc par l'espace de connexion XYZ après avoir appliqué la simulation encre / papier (réduction de dynamique, modification de point blanc) et on sort par le profil écran. Je pense que la simulation encre / papier se fait avant d'entrer dans l'espace XYZ. Il n'y a donc pas plus de raison que l'affichage soit différent entre une calibration gamma 2.2 et une calibration L* puisque la simulation est réalisée bien avant d'entrer dans le profil écran, ce dernier devant ensuite faire assurer la conversion vers la bonne cible de calibration écran, gamma 2.2 ou L*. D'autant plus que si la dynamique est réduite par la simulation d'encre, le niveau de noir mini affiché sera plus élevé, et donc on se retrouvera au delà des premiers niveaux de noir qui est la zone la plus affectée par les erreurs de quantification qui différencient gamma 2.2 et L*.

Il me semble donc peu probable que la compensation de point noir ainsi que la simulation d'encre / papier ait une influence sur le problème de différence
de niveau de luminance remarqué entre une calibration gamma 2.2 et L*.

Les différences notées sur les deux images sont quand même élevées (de l'ordre de 5 en luminance sur l'eau en bas à gauche).

Une modification de gamma de 0.15 fait correspondre les deux images. C'est bien plus que des erreurs de quantification 8 ou 10 bits imputables à la liaison vidéo.

Je pense qu'il s'agit peut être d'une simple confusion du CMS ou de l'application entre une calibration gamma 2.2 et une calibration L*. Je me demande si une application qui ne saurait pas lire les tags de courbe tonale TRC ne se rabattrait pas sur un gamma 2.2 par défaut.
C'est peut être pour cette raison que le logiciel i1 profiler conseille de générer des profils écran en matrice de tags gamma plutôt que des profils en courbe tonale TRC.

Il faudrait essayer d'appliquer une modification de gamma de 0.15 à la partie basse de la courbe L* et voir si on retombe approximativement sur la courbe gamma 2.2. Cela étaierait la thèse de la confusion.

Attendons des informations en retour de la part de Christophe qui a peut être du nouveau.

[Salomé_B]

ColorNavigator

[Salomé_B]

BasICColor Display (même configuration que précédemment, mais pas le même résultat ...)

[olivier1010]

BasICColor Display (même configuration que précédemment, mais pas le même résultat ...)

Interessant. Basiccolor ajoute des tables de correspondance couleur directes et inverses A2B et B2A en rendu perception et relatif ainsi que la valeur XYZ du point noir. Par contre il ne met pas non plus les tags gamma, à l'identique de Colornavigator lorsqu'on demande un profil avec courbes tonales TRC.

il serait intéressant dans le setup de Christophe de générer un profil L* sans les tables A2B / B2A, puis sans le XYZ point noir, et voir si le problème persiste.

[Salomé_B]

Intéressant : c'est la raison de mon upload.

Vous devriez tester, pour la forme, 'bICC Display', c'est gratuit, afin de vous mettre dans les mêmes conditions d'expérience.

[olivier1010]

Intéressant : c'est la raison de mon upload.

Vous devriez tester, pour la forme, 'bICC Display', c'est gratuit, afin de vous mettre dans les mêmes conditions d'expérience.

J'ai déjà lu le manuel. Mais je n'ai pas trop envie de l'installer sur ma station graphique. Je l'ai déjà testé il y a une paire d'années. Et finalement pour mes écrans bas de gamme j'ai utilisé pendant longtemps DispCalGui avec ArgyllCMS qui me semble suffisant et surtout gratuit. Maintenant sur ces écrans j'utilise I1 profiler qui est plus rapide et moins complexe à utiliser et toujours aussi gratuit.

Je vais peut être l'installer à nouveau sur une machine de test par curiosité. Peut être que si le prix baissait encore un peu... Pour l'instant il est encore au prix d'un écran d'occasion ou d'un Lightroom

[olivier1010]

BasICColor Display (même configuration que précédemment, mais pas le même résultat ...)

Concernant les tables A2B et B2A du profil écran, je pense qu'elles ne sont pas utilisées par les applications mais je peux me tromper. Si quelqu'un a des informations là dessus cela m'intéresse.

Basiccolor introduit un tag avec la définition de la valeur de noir minimum de l'écran. Cela pourrait avoir une influence.

Des infos intéressantes lorsque les tables A2B et B2A sont utilisés lors de la combinaison de plusieurs profils :

en provenance de :

http://argyllcms.com/doc/iccgamutmapping.html

Comme quoi les choses ne sont pas si simples dans les systèmes de gestion de la couleur 

ICC Version 4 behaviour
(Note that Argyll does not currently support ICC V4)

By default, ICC Version 4 profile operates similarly to the ICC V2 profile in regard to gamut mapping, with the exception that a minimally specified reference medium and reference viewing conditions are introduced for perceptual (and presumably saturation) tables, allowing at least the luminance range to have a well defined behavior when mixing and matching the perceptual A2B and B2A tables of different profiles.

A slight adjustment was made to the permitted tag contents, to allow things like Display profiles to contain the full range of AtoB and BtoA tables, so that they could also be gamut mapped. An optional part of ICCV4, introduces a more comprehensively specified Profile Reference Medium Gamut (PRMG) as an intermediate gamut boundary between the source colorspace, and the destination colorspace. If this option is used, then an additional tag in the ICCV4 profile indicates that this is the case. This then solves the problem of the gamut mapping having to know the source and destination gamuts to operate. Instead, the gamut mapping is split into two parts, the first where the source gamut to RMG is done by the AtoB tables, and then the RMG to destination gamut is done by the BtoA tables. Profiles can therefore be mix and matches, while retaining true gamut mapping.

This approach has a number of drawbacks though. One is that the colors get gamut mapped twice. Gamut mapping is sometimes not very precise, and the geometry of the transforms may not cancel out, especially since different profile vendors may choose different algorithms in their gamut mapping. By "cancel out", I mean that even if you were linking the same source colorspace to the same destination colorspace, the gamut may be expanded (say) in the process of mapping to the PRMG, and then compressed again in mapping from the RMG to the device space, and these expansions and compressions may not quite match. Given that the PRMG is a relatively large gamut, larger than many real devices actual behavior, this sort of expansion and re-compression will be the normal thing.

The chief drawback, is that only one (non colorimetric) intent can really be supported, that of saturation.

The typically expected behavior of perceptual intent gamut mapping, is to compress any areas of the source gamut that lie outside the destination gamut, but for areas that fall within the destination gamut, change them as little as possible, consistent with keeping smooth and proportional with respect to the compressed colors. This preserves the source "look" as much as possible, while ensuring that out of gamut colors are smoothly brought within the destination gamut.

Typical behavior of a saturation intent, is (at least), to not only compress out of gamut source colors to fit within the destination, but to expand any source boundary that falls within the destination gamut outwards match the destination gamut. Some practical saturation gamut mappings may go further than this, and expand a little beyond the destination gamut to ensure fully saturated boundary colors, and also enhance the saturation of all colors mapped through it.

By mapping the source gamut to the RMG in the A2B, all information about what areas of the source gamut are inside or outside of the destination gamut are lost, so the destination gamut mapping can not known which colors may be left unchanged, and which really need compressing. All it can do is map the RMG to match the destination gamut, thereby effecting a saturation style intent.

Once again, this is a fundamental limitation of using pre-computed gamut mappings. The only effective way of overcoming such limitations is to move to a more active color management architecture, in which gamut mappings are computed at link time, to accommodate the actual source and destination gamuts.

[fred94-]

Salut,

J'ai un peu mal au crâne car je n'y comprend pas grand chose aux tables....machin...truc.
Mais je me souviens d'un article sur les notions de conversions d'un profil vers un autre et...
Je me pose la question suivante:

Le soucis de M.Metairie n'est il pas d'avoir un profil d'écran basé sur une matrice plutôt que les tableaux a2b...truc muche?  

http://goo.gl/UE2DpQ
Je sais certain vont venir baver un peu mais c'est pas grave.

Même si suivant ce que tu donne comme info et comme pour les cassures sur mon écran cela ne devrait rien changé.

En fait nous tournons en rond car pas de nouvelles de M.Metairie.

Pourtant olivier1010 tu passe du temps pour nous éclairer. Sympa
Ps: eh chasseur d'images c'est quoi ton problème avec les liens internet?  Ah les liens Adobe pas de soucis mais les autres.....

[MBe]

Non je ne pense pas que ce soit nécessaire même si un RIP apporte beaucoup de souplesse. Je pense qu'il y a simplement un problème de compatibilité avec un
profil dans le cas qui nous intéresse ici, ou un problème de calibration hardware de l'écran pourquoi pas (échange entre deux profils et leur calibration associée, mauvaise calibration chargée ou quelque chose dans le genre).

En ce qui concerne la compensation du point noir, elle se fait entre profile source et profile destination. Par exemple entre le fichier image et l'impression par réduction de la dynamique du fichier image pour la faire rentrer dans celle du périphérique d'impression.

Si l'affichage est en mode normal, le profil d'impression n'intervient pas pour l'affichage. On ne devrait avoir (presque) aucune différence d'affichage entre
une calibration en gamma 2.2 et une calibration en courbe tonale L* qui doivent être compensées par le profil écran. Le fichier image est connecté à
l'écran par un profil source en passant par l'espace de connexion XYZ, à destination de l'écran à travers le profil écran qui avertit l'application (ou le
CMS) qu'elle doit appliquer tel ou tel gamma ou courbe tonale pour l'affichage afin de compenser la calibration de l'écran et obtenir les mêmes niveaux de
luminance dans tous les cas, aux erreurs de quantification près dues à la faible profondeur de quantification de la liaison vidéo en 8 ou 10 bits par canal.

En mode aperçu d'épreuve, l'écran n'est plus connecté directement au fichier image. Le fichier image converti ses données par son profil source vers l'espace de connexion XYZ puis vers l'imprimante à travers la table de correspondance couleur du profil d'impression en appliquant la compensation du point noir. Puis la table de correspondance couleur inverse du profil d'impression est utilisée pour faire correspondre les couleurs imprimées avec l'écran, en repassant par l'espace de connexion XYZ, pour ressortir par le profil écran. On parle alors non pas de compensation de point noir dans ce sens là (celle-ci est déjà réalisée entre le fichier image et l'impression) mais de simulation d'encre et de teinte de papier qui est une fonction qui s'active séparément.

Dans le mode aperçu d'épreuve on repasse donc par l'espace de connexion XYZ après avoir appliqué la simulation encre / papier (réduction de dynamique, modification de point blanc) et on sort par le profil écran. Je pense que la simulation encre / papier se fait avant d'entrer dans l'espace XYZ. Il n'y a donc pas plus de raison que l'affichage soit différent entre une calibration gamma 2.2 et une calibration L* puisque la simulation est réalisée bien avant d'entrer dans le profil écran, ce dernier devant ensuite faire assurer la conversion vers la bonne cible de calibration écran, gamma 2.2 ou L*. D'autant plus que si la dynamique est réduite par la simulation d'encre, le niveau de noir mini affiché sera plus élevé, et donc on se retrouvera au delà des premiers niveaux de noir qui est la zone la plus affectée par les erreurs de quantification qui différencient gamma 2.2 et L*.

Je suis d'accord sur ta description de l'utilisation des profils par le PCS.

Il me semble donc peu probable que la compensation de point noir ainsi que la simulation d'encre / papier ait une influence sur le problème de différence
de niveau de luminance remarqué entre une calibration gamma 2.2 et L*.

Christophe Metairie parle de différence entre l'image de l'écran avec un profil L* et l'impression avec une compensation du point noir, mais on ne sait pas si en softproofing l'écart est visible (?).
Pour moi cela reste une hypothèse à explorer, mais j'ai pas de certitude.

[...]

Attendons des informations en retour de la part de Christophe qui a peut être du nouveau.

Oui, car avec les informations actuelles, il n'est guère possible d'aller plus loin, seulement des hypothèses.

[MBe]

Concernant les tables A2B et B2A du profil écran, je pense qu'elles ne sont pas utilisées par les applications mais je peux me tromper. Si quelqu'un a des informations là dessus cela m'intéresse.

Basiccolor introduit un tag avec la définition de la valeur de noir minimum de l'écran. Cela pourrait avoir une influence.

Des infos intéressantes lorsque les tables A2B et B2A sont utilisés lors de la combinaison de plusieurs profils :

en provenance de :

http://argyllcms.com/doc/iccgamutmapping.html

Comme quoi les choses ne sont pas si simples dans les systèmes de gestion de la couleur 

La copie d'écran de la stucture du profil réalise avec BasiCColor Display me semble être en version 4 de l'icc, en V2 il n' y a qu'une table A2B et B2A alors que dans l'exemple montré il y a les table A2B0 (perception) et A2B1 (relatif) (et idem pour les tables B2A).

Par un CMM qui gère l'icc V4, Lcms par exemple, ces tables sont utilisées pour l'affichage vers l'écran ou le softproofing, mais c'est le CMM qui choisit d'utiliser ces stables (en théorie plus précises) ou les matrices. En Icc V4 ces stables peuvent être plus plus complexes.

Remarque : en Icc V4, il faut que l'utilisateur n'oublie pas d'indiquer au CMM le mode perception ou saturation pour l'affichage de son image sur son écran et qu'il vérifie l'origine du CMM utilisé par son logiciel photo et sa compatibilité avec les profils icc V4.

Olivier, est ce que tu as essayé d'utiliser des icc V4? en mode perception avec la notion de "Perceptual Reference Media Gamut (PRMG)", tu en penses quoi?

[fred94-]

La copie d'écran de la stucture du profil réalise avec BasiCColor Display me semble être en version 4 de l'icc, en V2 il n' y a qu'une table A2B et B2A alors que dans l'exemple montré il y a les table A2B0 (perception) et A2B1 (relatif) (et idem pour les tables B2A).

salut,

j'ai la même chose en v2

[MBe]

salut,

j'ai la même chose en v2

Possible, j'ai lu dernièrement qu'il y avait des profils V2, des V2 compatibles V4 et les V4, la gestion des couleurs c'est pas simple...

A priori en V2 compatible V4, les tables A2B0 et 1* seraient identiques (j'ai pas été vérifié), de plus en V4 il y a la possibilité de paramètres et tables plus élaborés. Ce qui  est assez "flou", c'est la gestion de ces versions de profils par les CMM, et je ne connais pas actuellement de soft qui permet de paramétrer en fonction des versions des profils, du CMM utilisé, les différentes options que l'ICC V4 offre. Je précise également que Icc V4 apporte des nombreux progrès par rapport à l'Icc V2, mais peu ou pas de soft exploite en toute transparence vers l'utilisateur ces possibilités.

0 = perception
1 = relatif
2 = saturation (peu ou pas utilisé en traitement photo)

[olivier1010]

Je viens de refaire deux validations d'écran. L'une pour une calibration en cible gamma 2.2 et l'autre pour une cible L*.

Les autres réglages :

Point blanc en D50, noir à 0.2 cd/m², blanc à 100 cd/m², priorité standard.

Pour rappel c'est un écran Eizo CG277. C'est un écran à calibration hardware interne 14 bits par canal.

La calibration est réalisée avec ColorNavigator et la sonde interne de l'écran selon les paramètres décrits ci-dessus.

La validation est réalisée avec un colorimètre Eyeone Display pro.
Étant donné que les procédures de validation des logiciels de calibration ne sont pas documentées, j'ai préféré utilisé un logiciel spécialisé, PatchTool, pour lequel cette procédure est bien documentée dans le manuel.

J'ai choisi une validation simulant le passage à travers un CMS pour être au plus proche de la réalité :

A partir d'un ensemble de 100 patchs de niveaux de gris en valeurs Lab de 1 à 100. (D50 observateur 2°), conversion dans l'espace du profil écran pour affichage avec rendu colorimétrie relative et compensation du point noir.

Ces valeurs de gris en Lab sont donc converties en RGB vers l'espace couleur de l'écran, en utilisant donc les courbes TRC du profil écran et la valeur de luminance du point blanc pour la compensation du point noir. D'autre part il n'y a pas d'adaptation chromatique puisque espaces source et destination sont dans le même illuminant D50.

Je pense que dans le cas de Patchtool, l'affichage des patchs se fait en 8 bits, cela reste à confirmer par l'éditeur du logiciel à qui je vais poser la question.

Voici les résultats qui montre la distribution statistique de l'erreur en luminance, le Delta L*.

Les barres oranges montrent combien de patchs ont quelle erreur. Par exemple pour Gamma 2.2, 9 patchs ont une erreur de 0.075 Delta L*.

On a la valeur moyenne de Delta L* (soit 0.09), la moyenne des 90 % de meilleurs patchs (0.08 Delta L*),  la moyenne des 10 % de moins bons patchs (0.17 Delta L*).

La courbe violette représente l'erreur en fonction du percentile, par exemple si l'on prend 95 % de percentile, on a une erreur de 0.17 Delta L*, c'est à dire que 95 % des patchs ont une erreur de 0.17 Delta L* ou moins.

Je passe sur la signification du sigma que les matheux comprendront.

Une première conclusion : la différence entre une calibration L* et Gamma 2.2 est vraiment très faible en ce qui concerne les niveaux de luminance affichés, après égalisation par le profil écran et malgré une liaison vidéo certainement limitée à 8 bits par PatchTool.

Dans le message suivant, je joindrai un graphe montrant l'erreur de luminance elle même en fonction du niveau de noir affiché.

[olivier1010]

Ci-dessous l'évolution de l'erreur de luminance (erreur de clarté faudrait il dire )  Delta L* en fonction du niveau de gris, pour les deux cibles de calibration gamma 2.2 et L*, après compensation par le profil écran correspondant à chaque cible.

Les conditions de ce test sont légèrement différentes. Je n'ai pas pu profiter d'un espace couleur indépendant pour les données source des patchs, la source est donc en sRGB et il n'y a que 33 patchs au lieu de 100. Cela dit je pense que cela n'a qu'une faible influence sur le résultat et que cela permet déjà de se faire une idée de la situation.

En conclusion on peut dire que l'influence d'une cible de calibration en gamma 2.2 ou L* sur la luminance affichée après compensation à travers le profil écran est vraiment très faible. L'erreur se chiffre en dixièmes d'unité L*, avec une erreur moyenne d'environ 0.1 L* et une erreur maxi d'environ 0.2 L*, dont une bonne partie est certainement causée par la sonde de mesure qui en toute logique doit présenter une erreur de mesure d'environ 0.1 L* (les matheux en statistiques pourront valider ou invalider cela).

L'erreur réelle doit donc se situer à environ 0.1 Delta L* au niveau de l'affichage, et la cible de calibration, gamma 2.2 ou L* ne change pas grand chose à ce résultat.

Il sera néanmoins intéressant de refaire ce test avec un nombre plus important de patchs et si possible à partir d'un espace source L*a*b*, afin d'augmenter la précision des résultats dans les très bas niveaux de noir qui sont les plus touchés par le passage de gamma 2.2 à L*.

Je referai donc le test si possible avec 100 patchs en valeurs Lab comme le précédent, si l'éditeur du logiciel peux me donner une solution pour rendre compatible le rapport présenté ci-dessous avec ces paramètres.

[olivier1010]

Et voilà finalement la différence de luminance (clarté plus exactement) mesurée sur mon système, entre une calibration L* et gamma 2.2, après compensation par le profil écran correspondant, à partir de données en sRGB.

Il y a 33 patchs en niveaux de gris comme ci-dessus. Ce graphique a été réalisé à partir de deux exports des données Display Data de PatchTool. L'un en calibration gamma 2.2, l'autre en calibration L*.

Il représente simplement la différence entre les valeurs Delta L* de chaque test, en tenant compte du signe de chaque erreur (simple soustraction).

On voit bien que l'utilisation de deux cibles de calibration différentes, en l'occurrence ici gamma 2.2 ou L*, n'a pas une influence significative sur la précision des niveaux de luminance reproduits. Si tant est que l'application graphique utilisée sache correctement utiliser le profil écran pour compenser les calibrations.

On est en tout cas en dessous de la limite de discernement de l'œil avec des valeurs d'erreurs qui oscillent entre -0.15 et +0.15 Delta L*, tolérance de la sonde de mesure incluse.

[MBe]

Merci Olivier pour la publication de ces résultats de mesure. Ton écran, aussi bien avec un profil L* ou 2,2 donne des erreurs de Delta L* qui sont très très faibles, certainement pas visibles par l'œil.
Comme les 33 patchs sont répartis de 0 à 100, même avec les 100 patchs et une analyse directe dans l'espace L*a*b*, la tendance serait la même comme le montre les stats de PatchTool.

Je suis également d'accord, c'est dans la zone des basses lumières qu'il peut y a avoir éventuellement une différence un peu plus marquée entre un profil L* et 2,2.  

Ps : je n'avais pas vu ton dernier graphe donnant l'écart entre les résultats en L* et 2,2 (il ne change pas les conclusions), j'étais en train de regarder si PacthTool proposait un fichier avec des valeurs L* de 0.2  ...

[tenmangu81]

Joli travail, Olivier !! Et conclusion significative et claire.
Merci !!

[MBe]

suite du 1er message :

Merci Olivier pour la publication de ces résultats de mesure. Ton écran, aussi bien avec un profil L* ou 2,2 donne des erreurs de Delta L* qui sont très très faibles, certainement pas visibles par l'œil.
Comme les 33 patchs sont répartis de 0 à 100, même avec les 100 patchs et une analyse directe dans l'espace L*a*b*, la tendance serait la même comme le montre les stats de PatchTool.

Je suis également d'accord, c'est dans la zone des basses lumières qu'il peut y a avoir éventuellement une différence un peu plus marquée entre un profil L* et 2,2.  

Ps : je n'avais pas vu ton dernier graphe donnant l'écart entre les résultats en L* et 2,2 (il ne change pas les conclusions) au moment ou j'ai posté mon message, j'étais en train de regarder si PacthTool proposait un fichier avec des valeurs L* de 0.2  ...

[olivier1010]

Merci Olivier pour la publication de ces résultats de mesure. Ton écran, aussi bien avec un profil L* ou 2,2 donne des erreurs de Delta L* qui sont très très faibles, certainement pas visibles par l'œil.
Comme les 33 patchs sont répartis de 0 à 100, même avec les 100 patchs et une analyse directe dans l'espace L*a*b*, la tendance serait la même comme le montre les stats de PatchTool.

Je suis également d'accord, c'est dans la zone des basses lumières qu'il peut y a avoir éventuellement une différence un peu plus marquée entre un profil L* et 2,2.  

Ps : je n'avais pas vu ton dernier graphe donnant l'écart entre les résultats en L* et 2,2 (il ne change pas les conclusions), j'étais en train de regarder si PacthTool proposait un fichier avec des valeurs L* de 0.2  ...

On peut générer soit même une cible de test avec l'utilitaire Gamut, mais le pas minimum en Lab est de 2 sur la luminance.

Il y a aussi des fichiers de test avec 100 patch en Lab.

Mais les données Display Data ne sont disponibles qu'avec les tests "Quick test", donc jusqu'à 33 patchs maxi en sRGB.