Et bien, sur mon écran, oui, je vois la différence 
, malgré le fait que tu nous as montré que les écarts étaient très faibles, et suffisamment pour être indiscernables.
Je n'utilise pas Color Navigator (j'ai un NEC 
), mais Spectraview II, en calibration hardware, donc.
Vous voyez une différence de luminosité dans les ombres ?
Afin de savoir si c'est réellement un bénéfice de L*, ou une calibration qui produit un résultat d'affichage légèrement différent, ou une réaction spécifique du logiciel de graphisme, il est nécessaire de procéder à une validation avec un nombre de patchs noir / gris foncés assez important pour pouvoir tracer une courbe de réponse précise dans les tons foncés. Basiccolor s'arrête au niveau L* = 13.9 lors de la validation.
C'est ce que j'ai fait dans mes tests, en utilisant un fichier de mesure pour la validation contenant 200 patchs en niveaux de gris. Cela donne une bonne définition dans la zone critique des 10 premiers % de clarté L*.
Ensuite, et même en utilisant un logiciel de validation indépendant, comme PatchTool, ou une solution de calibration vidéo haut de gamme, plus professionnelle que ce qu'on peut trouver dans le domaine de la calibration pour la chaine graphique (et aussi beaucoup plus cher), rien ne dit que le logiciel de graphisme réagira ou utilisera le CMS exactement de la même façon, surtout en ce qui concerne la compensation du point noir, qui est mal décrite en icc V2, et mal ou pas du tout supportée par les logiciels pour icc V4.
Ce problème de standardisation de la compensation du point noir en V2 pour l'écran explique certainement d'ailleurs pourquoi Eizo fournit l'option RBL (reflect black level in tone curve). Option qu'il faudrait théoriquement désactiver lorsque le profil propose un tag spécifique (MediaBlackPointTag) pour le niveau de noir. Le profil écran V2 ou V4 généré par ColorNavigator ne contient pas ce Tag.
On peut lire ceci dans un document icc :
Proposer: William Li (Kodak)
Date: November 2, 2007
1. Introduction
The mediaBlackPointTag is an optional tag which is intended to be used to specify the
media black point. In practice, this tag has not been implemented (either for profile
generators or consumers) well or at all. In addition, there is more than a single useful
method to calculate the media black point, hence a single tag such as this is insufficient
anyways. There are no known CMMs which make use of the mediaBlackPointTag.
It is desired to delete the mediaBlackPointTag from the ICC profile specification in order
to simplify the specification’s use. Going forward, the mediaBlackPointTag will be
treated as a private tag.
Basiccolor écrit ce tag, que ce soit en version 2 ou version 4.
Comme quoi les choses ne sont pas si simples dans le monde de la gestion de la couleur par icc.
Pour être absolument certain de ce qu'il se passe avec l'application graphique utilisée, la solution consisterait à générer des patchs sous forme d'images, ouvrir ces images une par une dans le logiciel graphique, et mesurer chaque image (chaque patch donc) avec un utilitaire de mesure qui pourrait être par exemple Display-read de PatchTool.
Le problème dans cette approche est qu'il faut avoir un sacré niveau dans la compréhension du système icc pour comprendre ce qu'on fait.
En pratique je pense qu'il n'est pas nécessaire d'aller jusque là, quoique le problème de Christophe Métairie laisse entendre un dysfonctionnement quelque part dans la chaine de gestion des couleurs spécifique certainement à la configuration qu'il a utilisé. Dans ces cas particuliers évidemment il est toujours intéressant d'investiguer pour trouver la cause exacte du problème si possible.
La difficulté provient également du fait que les éditeurs de logiciels documentent très peu le fonctionnement de leurs applications en ce qui concerne la gestion de la couleur. Ils ont peut être eux aussi d'ailleurs parfois du mal à s'y retrouver dans le tumulte des versions icc, et préfèrent peut être ne pas prendre de risques en diffusant des informations trop précises qui pourraient entraîner des débats houleux au vu de la complexité des systèmes CMS et de leurs diverses implémentations pas toujours entièrement compatibles.
Lorsqu'on regarde le manuel Basiccolor par exemple, il n'y a absolument aucune description des méthodes utilisées pour la calibration et surtout pour la validation des profils. Ce n'est pas mieux pour ColorNavigator, qui ne donne pas de détails par exemple concernant l'utilisation de l'option RBL (reflect black level in tone curve).
On peut lire ça dans le manuel ColorNavigator pour l'option RBL, rien de plus :
- Reflect black level in tone curve
When this check box is checked, the black level value is reflected to the tone curve for the profile.
Sinon, les écarts devraient être assez minimes tout de même si la calibration et la profilage sont réalisés correctement, même si une application ne respecte pas exactement la méthode idéale ou parfaitement rigoureuse pour afficher à l'écran. Ils risquent de se manifester le plus dans la zone des noirs, parce que d'une part c'est la zone la plus difficile à calibrer (principalement pour des raisons de précision des sondes et de non linéarité causée par le gamma de l'écran, surtout en calibration software) mais aussi parce que la compensation du point noir peut affecter plus particulièrement cette zone.
Cela n'empêche pas d'être méfiant, et de vérifier si quelque chose semble suspect.
