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.
