Affichage 10 bits - précision en luminance : 16 bits L* vers écran gamma 2.2

olivier1010 · Septembre 28, 2015, 02:16:30

Le but de ce test est de mesurer la précision en luminance dans des conditions réelles d'utilisation afin de valider l'affichage 10 bits par canal depuis une application graphique gérant les couleurs par CMS.

Au lieu d'utiliser un utilitaire de validation d'écran, qui ne réagit pas forcément à l'identique par rapport à la gestion des couleurs d'une application graphique, l'idée est d'utiliser directement Photoshop pour l'affichage des patchs de test. Il permettra en outre d'afficher en mode 10 bits par couleur. Il est en effet pour l'instant une des rares applications graphique capable d'afficher dans ce mode avec Zoner photo Studio.

Une autre solution eut été d'utiliser un logiciel de calibration très haut de gamme, capable d'afficher des patchs en 10 (et même 12 bits par canal), mais d'une part le prix est dissuasif, et d'autre part cela n'aurait pas permis une mise en situation réelle, le but étant de valider l'affichage au sein d'une application graphique.
Afin de minimiser les erreurs la configuration est la suivante :

- Un écran Eizo CG277 calibré hardware en gamma 2.2. Luminance mini à 0.12 cd/m², maxi à 100 cd/m², D50.

- une carte vidéo compatible 10 bits par canal (Ati Firepro)

- Une sonde de mesure i1 Display pro

- Le logiciel PatchTool et son utilitaire Display-read, pour mesurer les niveaux de gris d'une image RVB 16 bits affichée en 10 bits à travers Photoshop CS6.

- une image 16 bits RGB dans l'espace ECIRGB 2.0 version ICC v4, contenant uniquement un fond noir.
Le fichier 16 bits ramp.psd est utilisé en premier pour vérifier que l'affichage fonctionne bien en mode 30 bits.
Une image 16 bits RVB est crée dans Photoshop en mode 16 bits, dans l'espace ECIRGB v2.0. L'image est entièrement noire, R=B=V=0. Avec l'outil niveaux en mode aperçu, je vais progressivement remonter le niveaux de sortie de 1 en 1 jusqu'à à 255, afin d'obtenir 256 niveaux de gris, du noir 0,0,0 au blanc 255,255,255.

A chaque niveau, je mesure avec PatchTool et la sonde Display pro afin de créer un fichier avec les 256 mesures de niveau de gris affiché à l'écran. C'est la valeur L* qui sera retenue pour la suite afin de caractériser la précision d'affichage en luminance (ou clarté plus exactement).

Ce fichier est ensuite importé dans Excel, pour calculer en premier lieu une compensation de point noir sur les mesures L* obtenue, le but étant de ramener le point noir de l'écran à L* = 0, au lieu du L* du point noir correspondant à 0.12 cd/m².

Puis à partir de ce L* corrigé, la série de donnée obtenue est comparée à la courbe L* théorique, afin d'obtenir l'erreur L* finale.
Cette erreur caractérise la précision d'affichage en luminance qu'on obtient depuis une image 16 bits dans un espace RGB L*, ouverte dans Photoshop, et affichée en mode 10 bits par canal sur un écran stable compensé en température et dont la calibration a été réalisée en hardware sur une cible en gamma 2.2.

Il y a un léger accident que je ne m'explique pas trop dans les bas niveaux jusqu'à L* = 10, qui n'est je pense ni causé par l'écran, ni par sa calibration hardware, ni par la sonde de mesure. En effet de précédentes mesures réalisées pour un autre test ont montré qu'une calibration hardware sur cet écran était capable de maintenir une courbe pratiquement droite jusqu'au noir.

Voir ici :

http://www.chassimages.com/forum/index.php/topic,241228.msg5571597.html#msg5571597
Il est probable que cet accident soit causé soit par un problème dans la gestion de l'affichage 10 bits, soit par le moteur de gestion des couleurs, soit par le mode aperçu de l'outil niveau. A prendre avec des pincettes car c'est le premier test de ce type que je réalise, d'où un manque de recul.
En conclusion provisoire, on peut dire que l'affichage en mode 10 bits par canal ne pose pas de problème particulier, malgré la conversion d'un espace couleur L* vers un écran calibré en gamma 2.2.

J'ai en projet de refaire ce test en calibrant cette fois l'écran en L*. Ce qui permettra de valider la prise en charge correcte par Photoshop d'un affichage 10 bits avec une calibration en cible L*.

MBe · Septembre 28, 2015, 22:36:17

Bonsoir Olivier,

Ton essai est très intéressant, hormis l'accident dans les basses lumières, une conversion d'un espace avec une TRC en Lstar vers un écran avec TRC en 2,2 donne d'excellents résultats, les erreurs de calculs sont négligeables, en tous cas ces résultats ne confortent pas les militants d'espaces avec une TRC homogène (je n'en suis pas surpris). Je suis intéressé par la suite.

Quelques idées :
cette erreur dans les basses lumières n'est très n'est pas trop critique car la vision humaine à une sensibilité moindre dans les basses lumières que les hautes lumières, il n'empêche qu'il est toujours intéressant de comprendre et d'avoir une explication rationnelle.

La forme de la courbe un peu surprenante dans les basses lumières, un problème de quantification des courbes TRC? (dans un profil en V4, la courbe TRC est tracée à partir d'un gamma et de 3 coefficients dans une fonction paramétrique, mais avec quelle quantification? peut être pas en float?)

Est ce que tu pourrais te mettre dans un espace L*a*b* à la place de l'espace RGB? (cela permettrait de s"affranchir du codage de l'espace RGB)

Le même essai avec une liaison 8bits vers l'écran? (à titre de comparaison)

Dans tous les cas , merci.

olivier1010 · Septembre 29, 2015, 00:45:14

Citation de: MBe le Septembre 28, 2015, 22:36:17
Bonsoir Olivier,

Ton essai est très intéressant, hormis l'accident dans les basses lumières, une conversion d'un espace avec une TRC en Lstar vers un écran avec TRC en 2,2 donne d'excellents résultats, les erreurs de calculs sont négligeables, en tous cas ces résultats ne confortent pas les militants d'espaces avec une TRC homogène (je n'en suis pas surpris). Je suis intéressé par la suite.

Quelques idées :
cette erreur dans les basses lumières n'est très n'est pas trop critique car la vision humaine à une sensibilité moindre dans les basses lumières que les hautes lumières, il n'empêche qu'il est toujours intéressant de comprendre et d'avoir une explication rationnelle.

La forme de la courbe un peu surprenante dans les basses lumières, un problème de quantification des courbes TRC? (dans un profil en V4, la courbe TRC est tracée à partir d'un gamma et de 3 coefficients dans une fonction paramétrique, mais avec quelle quantification? peut être pas en float?)

Est ce que tu pourrais te mettre dans un espace L*a*b* à la place de l'espace RGB? (cela permettrait de s"affranchir du codage de l'espace RGB)

Le même essai avec une liaison 8bits vers l'écran? (à titre de comparaison)

Dans tous les cas , merci.

Oui effectivement cette erreur n'est pas très critique, tout du moins au niveau perception. Ma sonde étant bien plus précise que cette erreur relevée, je pense qu'il y a quand même un petit souci bien réel quelque part dans la prise en compte du profil écran. Je dois faire des tests complémentaire pour essayer d'en trouver l'origine. Cela ressemble mathématiquement à un manque de résolution dans les bas niveaux lors des conversions.

Ce qui est curieux, c'est que si j'utilise l'utilitaire Display-check de PatchTool, qui utilise le CMS LCMS, je ne retrouve pas cette bizarrerie dans les bas niveaux. D'un autre coté, Display-check affiche en 8 bits seulement. Difficile donc de faire des déductions.
Je peux essayer en Lab, cela implique quand même deux conversions : Lab vers XYZ et XYZ vers RGB écran. Au cas ou le problème disparaitrait, on pourrait en déduire un soucis avec la conversion RGB vers XYZ.

Un essai en 8 bits serait intéressant effectivement.

A ce sujet, je remarque que visuellement, sur un écran bureautique calibré software, la perception du banding sur un dégradé de gris en 8 bits ne se fait pas seulement à travers les erreurs Delta L*, mais aussi pour une bonne partie à travers les erreurs de chroma (Delta C) qui facilitent la perception de ce banding. Sur un écran calibré hardware, les gris sont plus neutres, la perception du banding se fait plus sur les erreurs de luminance seules.

Cela dépend également de la priorité donnée à la crête des gris lors de la génération du profil, priorité au contraste (meilleur respect des valeurs de luminance), priorité à la neutralité, ou équilibre entre ces deux aspects.

Ce qui est sur, c'est que ce banding disparait totalement en 10 bits.

tenmangu81 · Septembre 29, 2015, 10:50:40

Citation de: olivier1010 le Septembre 28, 2015, 02:16:30

En conclusion provisoire, on peut dire que l'affichage en mode 10 bits par canal ne pose pas de problème particulier, malgré la conversion d'un espace couleur L* vers un écran calibré en gamma 2.2.

Merci Olivier. Intéressant. Et en 8 bits (je n'ai pas de CG ad hoc

), ça donnerait quoi à ton avis ?

olivier1010 · Septembre 29, 2015, 19:48:00

Citation de: tenmangu81 le Septembre 29, 2015, 10:50:40
Merci Olivier. Intéressant. Et en 8 bits (je n'ai pas de CG ad hoc ), ça donnerait quoi à ton avis ?

Je vous dis ça dès que j'aurai fait les tests. Je termine déjà les tests en 10 bits.

Ci-dessous un test en 10 bits, toujours avec l'écran calibré hardware en gamma 2.2, mais cette fois avec une image source en Lab 16 bits.
L'accident dans les bas niveaux a disparu, par contre on a une irrégularité en marches d'escalier de hauteur 0.4 Delta L* qui apparait.

A part l'accident du début qui a disparu, et même si l'erreur moyenne Delta L* de 0.18 est meilleure par rapport au test précédent qui était à 0.33, on a quand même ces marches d'escalier qui proviennent peut être d'un manque de précision dans les conversions entre Lab et XYZ.

La hauteur de ces marches laisse penser qu'elles peuvent peut être produire du banding visible à l'affichage sur des images critiques.

Je pensais obtenir un meilleur résultat que celui-ci en Lab. Je commence à comprendre pourquoi Icc V4 implémente des tables en virgule flottante

MBe · Septembre 29, 2015, 20:33:50

Olivier, le résultat est pour moi très bon, l'écart crête à crête est +/- 0,5 L* sur une plage de 0 à 100 L*, avec une une fluctuation Basse fréquence, déjà constatée dans l'espace RVB.

Ces écarts de clarté mesurés ont probablement plusieurs origines :
- la précision de la commande en L* du patch
- les fluctuations du rétroéclairage du moniteurs ( l'alimentation, notamment pour la fluctuation en en basse fréquence)
- les fluctuation sur la dalle (horloges...)
- la précision / résolution de la sonde de mesure
- les erreurs de conversions d'un espace vers un autre, mais elles me semblent presque négligeables vis à vis des causes énoncées ci dessus

==> l'œil (la vision humaine) à un pouvoir intégrateur, il ne peut pas voir ces petites variations, en l'absence d'un référentiel, hormis pour le banding sur un signal continu, avec des défauts sur la quantification, qui crée des "marches d'escalier".

Pour l'espace RVB , Eci RGB V2 en icc V4, j'ai cherché hier au soir dans la spécification icc V4, la quantification du codage des équations TRC, je n'ai pas trouvé si c'était sur un mot de 16, 32 bits ou plus, sur un entier ou un flottant, est ce que tu connais cette information? (la spécif de l'icc n'est pas facile à lire...)

A voir et à suivre sur une caractérisation /calibrations en Lstar pour l'écran et sur une liaison 8 bits. Tes mesures sont très intéressantes.

MBe · Septembre 29, 2015, 23:38:00

Olivier, tu fais bien ces mesures dans le noir?, car si ce n'est pas le cas, il n'est pas à exclure des réflexions internes (de sources externes au rétroéclairage de l'écran) dans la dalle qui peuvent perturber la mesure.

olivier1010 · Septembre 29, 2015, 23:42:50

Citation de: MBe le Septembre 29, 2015, 20:33:50
Olivier, le résultat est pour moi très bon, l'écart crête à crête est +/- 0,5 L* sur une plage de 0 à 100 L*, avec une une fluctuation Basse fréquence, déjà constatée dans l'espace RVB.

Ces écarts de clarté mesurés ont probablement plusieurs origines :
- la précision de la commande en L* du patch
- les fluctuations du rétroéclairage du moniteurs ( l'alimentation, notamment pour la fluctuation en en basse fréquence)
- les fluctuation sur la dalle (horloges...)
- la précision / résolution de la sonde de mesure
- les erreurs de conversions d'un espace vers un autre, mais elles me semblent presque négligeables vis à vis des causes énoncées ci dessus

==> l'œil (la vision humaine) à un pouvoir intégrateur, il ne peut pas voir ces petites variations, en l'absence d'un référentiel, hormis pour le banding sur un signal continu, avec des défauts sur la quantification, qui crée des "marches d'escalier".

Pour l'espace RVB , Eci RGB V2 en icc V4, j'ai cherché hier au soir dans la spécification icc V4, la quantification du codage des équations TRC, je n'ai pas trouvé si c'était sur un mot de 16, 32 bits ou plus, sur un entier ou un flottant, est ce que tu connais cette information? (la spécif de l'icc n'est pas facile à lire...)

A voir et à suivre sur une caractérisation /calibrations en Lstar pour l'écran et sur une liaison 8 bits. Tes mesures sont très intéressantes.

Oui c'est très bon pour la photographie. Mais jugé insuffisant par exemple en cinéma digital. D'où la nouvelle norme icc V4 qui introduit la précision IEE754 (23 bits virgule flottante).

https://en.wikipedia.org/wiki/IEEE_floating_point

CitationCes écarts de clarté mesurés ont probablement plusieurs origines :
- la précision de la commande en L* du patch

Le patch s'affiche en 10 bits, soit environ +/- 0.005 Delta L* au niveau de la précision d'affichage en sortie de carte graphique (100 / 1024 / 2) , sachant que cette erreur est approximativement linéaire car l'écran est calibré sur un gamma proche de L*.

Cette précision est maintenu dans l'écran au niveau mathématique, moteur de calcul en 16 bits et tables LUT en 14 bits.

Citation- les fluctuations du rétroéclairage du moniteurs ( l'alimentation, notamment pour la fluctuation en en basse fréquence)
- les fluctuation sur la dalle (horloges...)

Je n'ai pas vu de variations mesurables à ce niveau sur le court terme.

Citation- la précision / résolution de la sonde de mesure

La sonde est très stable sur le court terme, sa référence est prise sur le point blanc écran juste avant les mesures. La valeur minimum de mesure recommandée est 0.1 cd/m². Et même à cette luminosité sa répétabilité est d'environ 0.01 L*, il suffit de faire plusieurs mesures d'un même patch pour se rendre compte que les mesures sont souvent les mêmes à 0.01 L*. La linéarité sur toute la gamme de luminance est plus difficilement mesurable, en tout cas le point milieu est presque parfaitement centré à L* = 50

Citation- les erreurs de conversions d'un espace vers un autre, mais elles me semblent presque négligeables vis à vis des causes énoncées ci dessus

Non ce sont ces erreurs de conversion qui semblent produire le plus de déviations. Elles sont je pense induite par les profils eux mêmes, qui sont en 16 bits, mais surtout par le moteur CMS. Icc V4 peut améliorer la situation, avec des profils en précision IEEE754, à condition que le CMS sache en tirer parti.

De plus le test Lab 16 bits vers écran gamma 2.2 a montré que l'erreur était totalement différente dans les bas niveaux. Cela prouve que la calibration de l'écran et la sonde ne sont pas en cause dans l'accident qu'on peut voir dans le test ECIRGB vers gamma 2.2.

Le test espace L* vers écran L* apportera peut être un éclairage à ce niveau, on devrait théoriquement avoir des erreurs de conversion plus faible puisque les courbes tonales source et destination seront identiques.

A ma connaissance les applications de calibration d'écran n'utilisent pas les équations paramétriques pour le moment. Juste des tables LUT 16 bits pour décrire les courbes tonales TRC de L*. ColorNavigator sait écrire les équations paramétriques, mais seulement pour un gamma, pas un L*.
Ci-dessous un test toujours en 10 bits, depuis une image dans l'espace ECIRGB v2 ( L* ), vers l'écran en gamma 2.2 calibré hardware, mais cette fois avec le moteur CMS Microsoft.

L'erreur est plus réduite dans les premiers niveaux jusque L* = 10 par rapport au test avec le moteur CMS Adobe.

olivier1010 · Septembre 29, 2015, 23:48:12

Citation de: MBe le Septembre 29, 2015, 23:38:00
Olivier, tu fais bien ces mesures dans le noir?, car si ce n'est pas le cas, il n'est pas à exclure des réflexions internes (de sources externes au rétroéclairage de l'écran) dans la dalle qui peuvent perturber la mesure.

J'ai environ 60 lux au niveau du poste de travail. Cela ne perturbe aucunement la mesure. Je viens d'essayer sur un patch noir, le plus sensible, aucune différence par rapport au noir total.

Ces histoires de chiffons nécessaires autour de la sonde c'est une légende. En tout cas avec une i1 display pro et à partir du moment ou un éclairage ISO est respecté (32 à 64 lux en éclairage diffus sans reflets dans l'écran )

olivier1010 · Septembre 30, 2015, 01:01:37

Voici un test attendu :
- image source en ECIRGB v2 (iccv4) 16 bits, donc en courbe tonale L*

- écran avec liaison vidéo 10 bits, calibré en L* hardware
Ci-dessous le graphe de l'erreur Delta L*. C'est le meilleur résultat obtenu, l'erreur moyenne est de 0.21 Delta L*, mais surtout, la courbe est bien plus lisse qu'avec une source en Lab, et les accidents dans les premiers niveaux de noir ont aussi disparu.

Il y a juste un petit problème de linéarité, avec une erreur d'environ 0.5 Delta L* sur toute la gamme. Elle s'explique peut être en partie par le choix du type de priorité pour l'axe des gris lors de la calibration de l'écran.

Il est probable que si j'avais choisi la priorité "contraste", la courbe Delta L* aurait été plus plate au détriment de la neutralité des gris en chrominance.

On a ici la preuve que la précision d'un moteur CMS d'ancienne génération n'est pas optimale pour convertir au mieux d'un espace source en L* vers un écran en gamma 2.2. (voir les tests précédents qui permettent d'arriver à cette déduction).

Non optimale, mais suffisante pour les applications en photographie, tirage, impression offset, etc....

Pour le cinéma digital par exemple, les erreurs dont on parle ici peuvent poser problème, pas tellement à l'affichage, mais plus lorsqu'il s'agit d'intégrer des effets spéciaux dans des scènes déjà existantes, où la concordance des couleurs doit être parfaite pour satisfaire aux exigences d'affichage dans la norme DCI (jusqu'à 12 bits par composante en gamut large).

Il sera intéressant de compléter par quelques autres tests, par exemple en 8 bits par canal pour la liaison écran, et de pousser les analyses statistiques, en particulier faire une analyse harmonique des déviations pour tenter de caractériser l'influence des erreurs Delta L* sur la perception du banding dans chaque cas. Les basses fréquences (déviations amples de la courbe d'erreur) ne causent pas de banding visible, mais les moyennes ou hautes fréquences le peuvent car l'œil est plus sensible aux fluctuations de niveaux proches l'une de l'autre. C'est là je pense qu'on verra des différences significatives entre 8 et 10 bits par canal.

olivier1010 · Septembre 30, 2015, 01:28:15

Je voudrais faire une remarque à ce niveau, il ne faut pas à ce stade faire une généralité du comportement de Photoshop.

En effet, lors de mes premiers tests réalisés avec l'utilitaire Display-check du logiciel PatchTool, qui utilise le CMS LCMS, je n'ai pas retrouvé ce comportement chaotique dans les bas niveaux jusque L* = 10 qu'on peut voir dans Photoshop lorsque le profil source est en L* et le profil écran en gamma 2.2.

Dans ce cadre, il serait intéressant de faire d'autres tests, en utilisant divers CMS et diverses applications, de recouper et compléter les résultats, afin de pointer du doigt des défauts commun ou spécifiques à une application, les choses qui marchent bien, les écueils à éviter.

Cela inciterait sans doute aussi les éditeurs de logiciels à modifier leurs moteurs CMS pour implémenter réellement icc V4 et ses améliorations en terme de précision de conversion.

A vous de jouer ! Vous avez la méthode pour réaliser ces tests vous même (voir en début de ce fil).

olivier1010 · Octobre 05, 2015, 13:00:23

Une petite correction ci-dessous.

La formule que j'ai utilisée initialement concernant la correction du point noir pour l'affichage de la courbe d'erreur Delta L* n'est pas valide car elle applique une compensation linéaire sur des données L* qui ne sont pas linéaires.

Suite à une suggestion de l'éditeur du logiciel PatchTool, que je remercie au passage pour son support très professionnel, j'ai appliqué la formule de compensation non pas sur les données L*, mais sur les données de luminance Y de l'espace XYZ, qui sont linéaires. Puis j'ai ensuite converti Y vers L*.

Ci-dessous le graphique avec l'ancienne et la nouvelle courbe. La courbe verte est la nouvelle méthode.

La différence est significative. L'erreur moyenne Delta L* descend à 0.13 Delta L* au lieu de 0.21 précédemment.

Cela dit, j'ai essayé d'appliquer cette nouvelle méthode de compensation au test ECIRGB vers écran en gamma 2.2, cela ne supprime en rien l'accident dans les bas niveaux.
Donc cela ne change rien aux conclusions qu'on peut déduire des tests précédents : le choix de la courbe tonale pour la calibration de l'écran a globalement une faible influence sur les erreurs de luminance, surtout si l'écran est un modèle à calibration hardware et si le CMS sait convertir avec une bonne précision dans les bas niveaux. Que ce soit sRGB, L* ou gamma 2.2 on reste quand même dans des courbes assez proches.

On remarque également que le logiciel graphique utilisé, à travers ses méthodes de calcul et son système de management des couleurs influe significativement sur le résultat. LCMS au sein de PatchTool semble fournir des meilleurs résultats que Photoshop, en ce qui concerne la précision des conversions dans les bas niveaux. Il est capable de convertir entre L* et gamma 2.2 sans accident dans les bas niveaux.
Évidemment comme on pouvait s'y attendre, les meilleurs résultats sont obtenus lorsque les courbes tonales des espaces couleurs sources et destinations sont identiques. Les espaces couleurs source Lab et ECIRGB utilisés avec un écran calibré hardware en L* donnent des résultats pratiquement parfaits indépendamment du CMS. Avec une réserve pour le mode Lab, dont la courbe d'erreur delta L* en marche d'escalier trahi une conversion qui manque de précision. Donc mon conseil serait d'utiliser l'espace Lab uniquement si absolument nécessaire. Pour la plupart des applications courantes, les espaces RGB sont certainement plus adaptés et plus intuitifs.
Enfin, pour éviter tout problème et obtenir les meilleurs résultats quelque soit le logiciel graphique utilisé, il est sans doute préférable d'éviter l'utilisation des courbes gamma classiques pour la calibration d'écran à cause de la pente infinie dans les très bas niveaux qui peut causer des erreurs de conversion. Il est probable d'ailleurs que l'option "reflect black level in tone curve" de ColorNavigator (X-rite fait de même) ait un effet bénéfique en éloignant les courbes TRC du zéro. Ce qui mitige cet argument en défaveur du gamma 2.2.

A ce titre L* semble plus appropriée, tout comme sRGB qui possèdent toutes deux une zone linéaire dans les très bas niveaux pour éviter ces problèmes de précision de conversion.

Il serait donc intéressant de réaliser un test avec une calibration écran hardware en sRGB sous Photoshop, afin de voir si les accidents dans les bas niveaux visibles avec un gamma 2.2 disparaissent comme avec L*.

J'ai réalisé un fichier de courbe tonale sRGB pour ColorNavigator, qui devrait me permettre de faire un test sRGB et donc comparer les résultats avec gamma 2.2 et L*.

Si ce test écran sRGB s'avérait très positif sous Photoshop avec un espace source en L*, le choix d'une calibration hardware en courbe tonale sRGB serait peut être la plus intéressante en terme de polyvalence, sachant en outre que LightRoom utilise un espace d'affichage en sRGB (Melissa RGB).

Ensuite, rien n'empêche d'utiliser une calibration d'écran différente en fonction des logiciels ou espaces utilisés, mais une seule calibration a l'avantage de nécessiter moins de temps de calibration.

olivier1010 · Octobre 06, 2015, 01:52:02

Voici le test avec une image source 16 bits en ECIRGB (courbe tonale L*), vers l'écran calibré hardware en courbe tonale sRGB. Le tout toujours mesuré dans Photoshop avec une liaison vidéo 10 bits.

L'accident dans les bas niveaux est inexistant tout comme avec une calibration L*. L'erreur moyenne est très faible également avec un Delta L* moyen de 0.11. La courbe est assez régulière comme pour le test ECIRGB vers écran en calibration L*.

C'est peut être la courbe tonale à recommander pour un usage polyvalent tout en gardant une bonne performance.

Elle s'adapte bien à une source en L*, les tout premiers niveaux de noir ne sont pas gaspillés comme c'est un peu le cas en gamma 2.2, elle permet d'afficher correctement avec des logiciels non géré CMS, les accidents de luminance dans les premiers niveaux sont inexistants.

Lightroom également avec son espace couleur de visualisation en courbe tonale sRGB (Melissa) devrait s'en accommoder au mieux, surtout qu'il ne dispose pas du mode d'affichage 30 bits. Lorsque la liaison vidéo est en 24 bits (8 bits par couleur), il est logiquement intéressant d'avoir un espace d'affichage dont la courbe tonale est identique à celle de la source afin de minimiser les erreurs de quantification.

tenmangu81 · Octobre 06, 2015, 12:10:35

Citation de: olivier1010 le Octobre 06, 2015, 01:52:02
Lightroom également avec son espace couleur de visualisation en courbe tonale sRGB (Melissa) devrait s'en accommoder au mieux, surtout qu'il ne dispose pas du mode d'affichage 30 bits. Lorsque la liaison vidéo est en 24 bits (8 bits par couleur), il est logiquement intéressant d'avoir un espace d'affichage dont la courbe tonale est identique à celle de la source afin de minimiser les erreurs de quantification.

Cela va sans dire, mais ça va mieux en le disant.
Tu vois qu'il y en a qui suivent ?

olivier1010 · Octobre 06, 2015, 14:11:21

Citation de: tenmangu81 le Octobre 06, 2015, 12:10:35
Cela va sans dire, mais ça va mieux en le disant.
Tu vois qu'il y en a qui suivent ?

Je n'en doutais pas

Une remarque concernant la courbe tonale sRGB : elle est certainement (à tord) beaucoup moins sexy que L*, parce que souvent associée à l'espace couleur sRGB, lui aussi peu sexy à cause de son gamut un peu restreint et malgré ses qualités.

Mais une calibration en sRGB ne veut pas dire que le gamut de l'écran sera restreint à sRGB. Il sera égal soit au gamut natif de l'écran, soit même à un autre gamut en fonction du paramétrage choisi.

En conséquence, une calibration en courbe tonale sRGB peut très bien être un choix très intéressant, si l'on recherche un maximum de compatibilité tout en évitant de prendre des risques avec L* lorsqu'on ne maîtrise pas la procédure de validation d'écran au sein des logiciels graphiques utilisés.

MBe · Octobre 07, 2015, 22:45:48

Merci Olivier pour la publication de ces résultats que je regarde avec assiduité.
De mon côté j'ai fait 2 profils ( L* et 2,2) avec Colornavigator en version 4.2.
Les résultats Delta E 2000 (Iso 1246) en max et average, sont légèrement meilleurs en 2,2 qu'en L*, mais je doute que la vision humaine détecte de si petits écarts. J'ai refait quelques essais sur des images appropriées en commutant L* ou 2,2, pour ces images choisies volontairement avec des zones d'ombre, le L* avec un écran wide gamut apporte du confort pour le réglage des niveaux.

Je n'ai pas encore trouvé le temps pour valider ces résultats avec Display check de PatchTool.

En L*, la comparaison entre les versions V2 et V4.2, avec les mêmes valeurs cibles, donne V4.2 légèrement meilleur, mais est ce que la comparaison à un sens avec un seul essai?

En regardant les rapports de calibration générés par ColoNavigator sur un peu plus d'un an, les variations sont faibles, tant pour les profils L* et 2,2, je considère donc que ces 2 solutions sont fiables. j'ai également prévu de refaire quelques essais en faisant des impressions sur des photos traitées en L* et en 2,2.

EN ce qui concerne les CMM et la version icc V4, l'exploitation complète des possibilités des profils donnent provisoirement les résultats suivants :

Argylcms : compatible, mais n'exploite pas les ressources de iccV4
Littlecms (Lcms) : exploite les ressources de l'iccV4, toutes?
Qcms (Mozilla -Firefox) : exploite les ressources de l'iccV4, toutes?
ACE (Adobe) ; compatible, mais ? (ce n'est pas très clair)
Microsoft ICM2/WCS : compatible, mais ? (ce n'est pas très clair)?

olivier1010 · Octobre 08, 2015, 23:11:20

Citation de: MBe le Octobre 07, 2015, 22:45:48
Merci Olivier pour la publication de ces résultats que je regarde avec assiduité.
De mon côté j'ai fait 2 profils ( L* et 2,2) avec Colornavigator en version 4.2.
Les résultats Delta E 2000 (Iso 1246) en max et average, sont légèrement meilleurs en 2,2 qu'en L*, mais je doute que la vision humaine détecte de si petits écarts. J'ai refait quelques essais sur des images appropriées en commutant L* ou 2,2, pour ces images choisies volontairement avec des zones d'ombre, le L* avec un écran wide gamut apporte du confort pour le réglage des niveaux.

Je n'ai pas encore trouvé le temps pour valider ces résultats avec Display check de PatchTool.

En L*, la comparaison entre les versions V2 et V4.2, avec les mêmes valeurs cibles, donne V4.2 légèrement meilleur, mais est ce que la comparaison à un sens avec un seul essai?

En regardant les rapports de calibration générés par ColoNavigator sur un peu plus d'un an, les variations sont faibles, tant pour les profils L* et 2,2, je considère donc que ces 2 solutions sont fiables. j'ai également prévu de refaire quelques essais en faisant des impressions sur des photos traitées en L* et en 2,2.

EN ce qui concerne les CMM et la version icc V4, l'exploitation complète des possibilités des profils donnent provisoirement les résultats suivants :

Argylcms : compatible, mais n'exploite pas les ressources de iccV4
Littlecms (Lcms) : exploite les ressources de l'iccV4, toutes?
Qcms (Mozilla -Firefox) : exploite les ressources de l'iccV4, toutes?
ACE (Adobe) ; compatible, mais ? (ce n'est pas très clair)
Microsoft ICM2/WCS : compatible, mais ? (ce n'est pas très clair)?

Citationpour ces images choisies volontairement avec des zones d'ombre, le L* avec un écran wide gamut apporte du confort pour le réglage des niveaux.

Oui mais si vous étiez en affichage 10 bits par canal je pense que vous verriez nettement moins de différences entre gamma 2.2 et L*.

Attention, la vision humaine peut détecter des écarts de luminance et de couleur très faibles, puisqu'elle détecte du banding en 8 bits, soit une résolution de 1/256*100 = 0.39 Delta L*. En 10 bits, on doit être vers 0.1 Delta L*, et là on ne perçoit plus du tout le banding dans les dégradés.

A condition que les échantillons soient cote à cote. Sinon, si vous observez une couleur dans un lieu, puis la comparez à une couleur similaire dans un autre lieu, il sera bien difficile de différencier avec une précision meilleure que Delta E = 6, sauf peut être pour des chromistes qui ont une mémoire visuelle très affutée et pourront descendre un peu plus bas.

Ci-dessous une tonecurve sRGB que j'ai réalisé pour mes tests et que vous devriez pouvoir importer dans ColorNavigator si vous voulez la tester. Il suffit normalement de recopier les valeurs dans un fichier texte et d'importer ce fichier dans Colornavigator en temps que courbe tonale.

Comme L*, sRGB débouche plus rapidement les noirs, pas tout à fait autant que L* mais sensiblement plus que gamma 2.2. Ce qui est utile certainement en liaison vidéo 8 bits, à condition d'avoir un écran en sRGB natif ou à calibration hardware afin de ne pas introduire trop d'erreurs de quantification par l'utilisation des tables gamma de la carte vidéo.
Concernant les CMM, il y a certainement des disparités effectivement importantes dans le support des fonctions icc V4.2 et je pense un retard certain dans l'implémentation des tables en précision IEEE754.

Lorsque les CMM auront intégrés ces améliorations et que l'on pourra de façon fiable générer et exploiter des profils icc V4.3, on ne devrait plus trop voir de différences de précision entre les divers CMM.
Pour l'instant, pour des applications critiques, il est certainement prudent de tester sérieusement chaque cas de figure avant de faire confiance aveuglément.

Pour le moment, selon les tests que j'ai réalisé et qui gagneront à être validé par d'autres personnes, il existe des différences notables, concernant l'affichage écran, entre Adobe, Microsoft et LCMS qui sont les trois CMM que j'ai testé. La différence que j'ai noté étant surtout la précision de conversion dans les premiers niveaux de noir. Adobe et Microsoft ont du mal apparemment à s'en sortir avec précision lorsque le profil écran destination est en gamma 2.2, avec un accident en forme de sinusoïde d'une amplitude de l'ordre de 1 Delta L* dans la courbe d'erreur Delta L* jusque environ L*=10.

Je pense que cet accident est peut être causé par un algorithme de régression du CMS, destiné à lisser les courbes TRC présentes dans le profil, au cas ou celles-ci ne comporteraient pas assez de points. La pente infini d'une courbe gamma 2.2 pour les valeurs proches du zéro est peut être la source de ce rebond dans la régression qui se stabiliserait ensuite vers L*=10.

Pour mémoire ci-dessous la courbe où l'on voit cet accident. Conditions de mesure : Photoshop utilisant Adobe CMM, liaison écran 10 bits par canal, image source en ECIRGB (donc TRC L*), écran CG277 calibré hardware en gamma 2.2, sonde Eye one display pro, PatchTool 4.7 (Display-Read en mode slow).

Il est probable d'ailleurs que les concepteurs de sRGB avaient conscience de ce problème dans les CMM, et qu'ils aient choisi de linéariser le début de la courbe sRGB pour éviter de perturber ce supposé algorithme.

En tout cas, sRGB et L* corrigent bien le problème. Et même s'il est présent avec certains CMS en gamma 2.2, l'erreur introduite reste faible, mais néanmoins possiblement visible sur certaines images critiques car au dessus de seuil de perception du banding.
Chose amusante, en regardant dans les spécifications DirectX, je me suis aperçu que Microsoft prévoyait un mode 16 bits float par canal (mode A16B16G16R16F), soit 64 bits en tout avec le canal alpha, et même un mode 128 bits float

A32B32G32R32F.

De quoi ne pas être pris au dépourvu

https://msdn.microsoft.com/en-us/library/windows/desktop/bb153349%28v=vs.85%29.aspx

Voici la table sRGB :

0, 0
0.01010101, 0.000781812
0.02020202, 0.001563624
0.03030303, 0.002345436
0.04040404, 0.003127248
0.050505051, 0.003981529
0.060606061, 0.004958468
0.070707071, 0.006062579
0.080808081, 0.007298197
0.090909091, 0.008669454
0.101010101, 0.010180301
0.111111111, 0.011834528
0.121212121, 0.013635779
0.131313131, 0.01558757
0.141414141, 0.017693294
0.151515152, 0.019956239
0.161616162, 0.022379591
0.171717172, 0.024966444
0.181818182, 0.027719807
0.191919192, 0.030642608
0.202020202, 0.033737704
0.212121212, 0.037007879
0.222222222, 0.040455856
0.232323232, 0.044084293
0.242424242, 0.047895793
0.252525253, 0.051892904
0.262626263, 0.056078123
0.272727273, 0.060453897
0.282828283, 0.065022627
0.292929293, 0.069786671
0.303030303, 0.074748345
0.313131313, 0.079909925
0.323232323, 0.085273646
0.333333333, 0.090841711
0.343434343, 0.096616285
0.353535354, 0.1025995
0.363636364, 0.108793457
0.373737374, 0.115200223
0.383838384, 0.12182184
0.393939394, 0.128660316
0.404040404, 0.135717637
0.414141414, 0.142995757
0.424242424, 0.150496608
0.434343434, 0.158222096
0.444444444, 0.166174104
0.454545455, 0.174354489
0.464646465, 0.182765089
0.474747475, 0.191407718
0.484848485, 0.20028417
0.494949495, 0.209396219
0.505050505, 0.218745617
0.515151515, 0.2283341
0.525252525, 0.238163383
0.535353535, 0.248235163
0.545454545, 0.258551121
0.555555556, 0.269112919
0.565656566, 0.279922202
0.575757576, 0.290980602
0.585858586, 0.302289731
0.595959596, 0.313851188
0.606060606, 0.325666557
0.616161616, 0.337737406
0.626262626, 0.35006529
0.636363636, 0.362651749
0.646464646, 0.37549831
0.656565657, 0.388606487
0.666666667, 0.40197778
0.676767677, 0.415613676
0.686868687, 0.429515652
0.696969697, 0.443685169
0.707070707, 0.45812368
0.717171717, 0.472832624
0.727272727, 0.487813429
0.737373737, 0.503067512
0.747474747, 0.518596279
0.757575758, 0.534401126
0.767676768, 0.550483437
0.777777778, 0.566844587
0.787878788, 0.58348594
0.797979798, 0.600408851
0.808080808, 0.617614665
0.818181818, 0.635104717
0.828282828, 0.652880334
0.838383838, 0.670942831
0.848484848, 0.689293517
0.858585859, 0.707933691
0.868686869, 0.726864643
0.878787879, 0.746087655
0.888888889, 0.765604
0.898989899, 0.785414944
0.909090909, 0.805521743
0.919191919, 0.825925646
0.929292929, 0.846627895
0.939393939, 0.867629724
0.949494949, 0.888932357
0.95959596, 0.910537015
0.96969697, 0.932444907
0.97979798, 0.954657239
0.98989899, 0.977175207
1, 1

olivier1010 · Octobre 08, 2015, 23:13:48

Et l'accident qui a disparu avec une calibration sRGB :

olivier1010 · Octobre 08, 2015, 23:21:12

Disparu également en calibration L*, toujours avec une image source en ECIRGBv2. (ECIRGBv2 est un espace couleur en courbe tonale L*).

gibus · Octobre 09, 2015, 20:11:27

Bonjour,
Voila un fil de très haut niveau qui dépasse de loin mes modestes connaissances.
J'ai toutefois essayé de charger par curiosité la table sRGB ci-dessus (il s'agit bien d'une table LUT ?) dans ColorNavigator.
Elle n'est pas acceptée car ColorNavigator réclame 256 lignes (il n'y en a "que" 100).

olivier1010 · Octobre 09, 2015, 20:31:25

Désolé j'ai fait une confusion. Voici le bon format, j'avais moi même rencontré ce problème, le bon fichier se trouvait dans un autre dossier

Voici donc la courbe tonale sRGB pour ColorNavigator. A copier dans un fichier texte, nommé par exemple sRGB-TRC.csv

0   0
0.000303527   0.003921569
0.000607054   0.007843137
0.000910581   0.011764706
0.001214108   0.015686275
0.001517635   0.019607843
0.001821162   0.023529412
0.002124689   0.02745098
0.002428216   0.031372549
0.002731743   0.035294118
0.00303527   0.039215686
0.003346536   0.043137255
0.003676507   0.047058824
0.004024717   0.050980392
0.004391442   0.054901961
0.004776953   0.058823529
0.005181517   0.062745098
0.005605392   0.066666667
0.006048833   0.070588235
0.006512091   0.074509804
0.00699541   0.078431373
0.007499032   0.082352941
0.008023193   0.08627451
0.008568126   0.090196078
0.009134059   0.094117647
0.009721217   0.098039216
0.010329823   0.101960784
0.010960094   0.105882353
0.011612245   0.109803922
0.012286488   0.11372549
0.012983032   0.117647059
0.013702083   0.121568627
0.014443844   0.125490196
0.015208514   0.129411765
0.015996293   0.133333333
0.016807376   0.137254902
0.017641954   0.141176471
0.01850022   0.145098039
0.019382361   0.149019608
0.020288563   0.152941176
0.02121901   0.156862745
0.022173885   0.160784314
0.023153366   0.164705882
0.024157632   0.168627451
0.02518686   0.17254902
0.026241222   0.176470588
0.027320892   0.180392157
0.02842604   0.184313725
0.029556834   0.188235294
0.030713444   0.192156863
0.031896033   0.196078431
0.033104767   0.2
0.034339807   0.203921569
0.035601315   0.207843137
0.03688945   0.211764706
0.038204372   0.215686275
0.039546235   0.219607843
0.040915197   0.223529412
0.042311411   0.22745098
0.043735029   0.231372549
0.045186204   0.235294118
0.046665086   0.239215686
0.048171824   0.243137255
0.049706566   0.247058824
0.051269458   0.250980392
0.052860647   0.254901961
0.054480276   0.258823529
0.05612849   0.262745098
0.05780543   0.266666667
0.059511238   0.270588235
0.061246054   0.274509804
0.063010018   0.278431373
0.064803267   0.282352941
0.066625939   0.28627451
0.06847817   0.290196078
0.070360096   0.294117647
0.072271851   0.298039216
0.074213568   0.301960784
0.076185381   0.305882353
0.078187422   0.309803922
0.08021982   0.31372549
0.082282707   0.317647059
0.084376212   0.321568627
0.086500462   0.325490196
0.088655586   0.329411765
0.090841711   0.333333333
0.093058963   0.337254902
0.095307467   0.341176471
0.097587347   0.345098039
0.099898728   0.349019608
0.102241733   0.352941176
0.104616484   0.356862745
0.107023103   0.360784314
0.109461711   0.364705882
0.111932428   0.368627451
0.114435374   0.37254902
0.116970668   0.376470588
0.119538428   0.380392157
0.122138772   0.384313725
0.124771818   0.388235294
0.12743768   0.392156863
0.130136477   0.396078431
0.132868322   0.4
0.13563333   0.403921569
0.138431615   0.407843137
0.141263291   0.411764706
0.144128471   0.415686275
0.147027266   0.419607843
0.14995979   0.423529412
0.152926152   0.42745098
0.155926464   0.431372549
0.158960835   0.435294118
0.162029376   0.439215686
0.165132195   0.443137255
0.1682694   0.447058824
0.171441101   0.450980392
0.174647404   0.454901961
0.177888416   0.458823529
0.181164244   0.462745098
0.184474995   0.466666667
0.187820772   0.470588235
0.191201683   0.474509804
0.19461783   0.478431373
0.19806932   0.482352941
0.201556254   0.48627451
0.205078736   0.490196078
0.20863687   0.494117647
0.212230757   0.498039216
0.2158605   0.501960784
0.2195262   0.505882353
0.223227957   0.509803922
0.226965874   0.51372549
0.230740049   0.517647059
0.234550582   0.521568627
0.238397574   0.525490196
0.242281122   0.529411765
0.246201327   0.533333333
0.250158285   0.537254902
0.254152094   0.541176471
0.258182853   0.545098039
0.262250658   0.549019608
0.266355605   0.552941176
0.270497791   0.556862745
0.274677312   0.560784314
0.278894263   0.564705882
0.28314874   0.568627451
0.287440838   0.57254902
0.29177065   0.576470588
0.296138271   0.580392157
0.300543794   0.584313725
0.304987314   0.588235294
0.309468923   0.592156863
0.313988713   0.596078431
0.318546778   0.6
0.323143209   0.603921569
0.327778098   0.607843137
0.332451536   0.611764706
0.337163615   0.615686275
0.341914425   0.619607843
0.346704056   0.623529412
0.3515326   0.62745098
0.356400144   0.631372549
0.36130678   0.635294118
0.366252596   0.639215686
0.37123768   0.643137255
0.376262123   0.647058824
0.381326011   0.650980392
0.386429434   0.654901961
0.391572478   0.658823529
0.396755231   0.662745098
0.40197778   0.666666667
0.407240212   0.670588235
0.412542613   0.674509804
0.417885071   0.678431373
0.42326767   0.682352941
0.428690497   0.68627451
0.434153636   0.690196078
0.439657174   0.694117647
0.445201195   0.698039216
0.450785783   0.701960784
0.456411023   0.705882353
0.462077   0.709803922
0.467783796   0.71372549
0.473531496   0.717647059
0.479320183   0.721568627
0.48514994   0.725490196
0.49102085   0.729411765
0.496932995   0.733333333
0.502886458   0.737254902
0.508881321   0.741176471
0.514917665   0.745098039
0.520995573   0.749019608
0.527115126   0.752941176
0.533276404   0.756862745
0.539479489   0.760784314
0.545724461   0.764705882
0.552011402   0.768627451
0.55834039   0.77254902
0.564711506   0.776470588
0.571124829   0.780392157
0.57758044   0.784313725
0.584078418   0.788235294
0.590618841   0.792156863
0.597201788   0.796078431
0.603827339   0.8
0.610495571   0.803921569
0.617206562   0.807843137
0.623960392   0.811764706
0.630757136   0.815686275
0.637596874   0.819607843
0.644479682   0.823529412
0.651405637   0.82745098
0.658374817   0.831372549
0.665387298   0.835294118
0.672443157   0.839215686
0.67954247   0.843137255
0.686685312   0.847058824
0.693871761   0.850980392
0.701101892   0.854901961
0.70837578   0.858823529
0.715693501   0.862745098
0.723055129   0.866666667
0.73046074   0.870588235
0.737910409   0.874509804
0.74540421   0.878431373
0.752942217   0.882352941
0.760524505   0.88627451
0.768151147   0.890196078
0.775822218   0.894117647
0.783537792   0.898039216
0.79129794   0.901960784
0.799102738   0.905882353
0.806952258   0.909803922
0.814846572   0.91372549
0.822785754   0.917647059
0.830769877   0.921568627
0.838799012   0.925490196
0.846873232   0.929411765
0.854992608   0.933333333
0.863157213   0.937254902
0.871367119   0.941176471
0.879622397   0.945098039
0.887923118   0.949019608
0.896269353   0.952941176
0.904661174   0.956862745
0.913098652   0.960784314
0.921581856   0.964705882
0.930110858   0.968627451
0.938685728   0.97254902
0.947306537   0.976470588
0.955973353   0.980392157
0.964686248   0.984313725
0.97344529   0.988235294
0.98225055   0.992156863
0.991102097   0.996078431
1   1

gibus · Octobre 09, 2015, 21:05:54

Merci cette fois c'est OK pour le chargement de la table.

olivier1010 · Octobre 09, 2015, 21:36:27

Citation de: gibus le Octobre 09, 2015, 21:05:54
Merci cette fois c'est OK pour le chargement de la table.

De rien.

En cherchant la définition de la courbe TRC DICOM, j'ai trouvé un document très intéressant, qui discute de l'influence de la profondeur de quantification sur la précision du respect des courbes tonales.

On y découvre une comparaison très intéressante des diverses topologies couramment à disposition dans les écrans actuels : 8/8 , 8/10 , 8/12, 10/10.

On a aussi du 10/12 et 10/14 dans les écrans graphiques, mais la comparaison de ce document permet déjà de se faire une bonne idée de l'influence de la profondeur de quantification.
www.barco.com/barcoview/downloads/GrayscaleResolution.pdf
J'ai en projet de comparer les courbes tonales L* et DICOM, sachant que ces deux courbes sont de conception perceptuellement linéaires, je pense qu'il est intéressant de voir de combien elles différent afin de comparer ces deux approches différentes qui devraient en théorie donner un résultat proche.

La définition de la courbe DICOM, en page 35 du document 14 :

http://dicom.nema.org/standard.html

La méthodologie de test pour la validation est également très intéressante, à partir de la page 47, notamment en ce qui concerne la prise en compte de la lumière ambiante.
"As stated in the normative section, the effect of ambient light on the apparent Characteristic Curve must always be included when
configuring a Display System to conform with the Grayscale Standard Display Function.
If a handheld photometer that does not cast a shadow on the display screen is used to measure the Characteristic Curve, then the
Luminance produced by the display plus the effect of ambient light may be measured simultaneously.
When a suction cup photometer is used to take the Luminance measurements or when a handheld photometer casts a shadow on
the display screen, all ambient lighting should be turned off while measuring the Characteristic Curve. The effect of ambient light is
determined separately: The Display System is turned off, the ambient light is turned on, and the Luminance produced by scattering
of ambient light at the display screen is measured by placing the photometer at a distance from the display screen so that its acceptance
angle includes a major portion of the screen and that the measurement is not affected by direct illumination from areas outside the
display screen. The Luminance related to ambient light is added to the previously measured Luminance levels produced by the Display
System to determine the effective Characteristic Curve of the system.
Note
Changes in ambient lighting conditions may require recalibration of the display subsystem in order to maintain conformance
to this standard."

Pour les arts graphiques, la prise en compte de la lumière ambiante est moins bien définie, voir ici :

http://www.colourstandards.com.au/monitor_display.html

Pour ceux qui ne connaissent pas DICOM, c'est un standard pour l'imagerie médical. En ce qui concerne les écrans, souvent en niveaux de gris en médecine, ils sont depuis longtemps en précision 10 bits, et bien avant l'arrivée du Display Port, en utilisant un système propriétaire de bit packing sur le port DVI.

olivier1010 · Octobre 11, 2015, 15:24:53

Je vais ouvrir un autre fil pour parler de DICOM, le sujet étant à la fois intéressant mais aussi un peu complexe.

olivier1010 · Octobre 14, 2015, 01:03:20

Voici une comparaison des pentes dans les bas niveaux pour les courbes tonales Gamma 2.2, sRGB, L* et DICOM à 120 cd/m².
On remarque la pente qui tend vers des valeurs très forte autour de zéro pour gamma 2.2. C'est la source certainement des accidents qu'on peut voir sur la courbe d'erreur de luminance Delta L*, avec certains CMS, pour cette cible de calibration.

Toutes les autres courbes tonales disposent d'une pente raisonnable autour de zéro.

tenmangu81 · Octobre 14, 2015, 11:19:32

Citation de: olivier1010 le Octobre 14, 2015, 01:03:20

Voici une comparaison des pentes dans les bas niveaux pour les courbes tonales Gamma 2.2, sRGB, L* et DICOM à 120 cd/m².
On remarque la pente qui tend vers des valeurs très forte autour de zéro pour gamma 2.2. C'est la source certainement des accidents qu'on peut voir sur la courbe d'erreur de luminance Delta L*, avec certains CMS, pour cette cible de calibration.

Toutes les autres courbes tonales disposent d'une pente raisonnable autour de zéro.

Ca me semble normal, non ? Les courbes en gamma (dont la 2.2) sont basées sur une fonction analytique en exposant. Donc la pente tend vers l'infini lorsqu'on va vers zéro. Les autres sont linéaires au voisinage de zéro (pour DICOM, je ne sais pas trop, mais pour L* et sRGB, oui).

Edit : oups, pas vu que sur l'autre fil tu faisais le même commentaire

olivier1010 · Octobre 14, 2015, 11:58:30

Citation de: tenmangu81 le Octobre 14, 2015, 11:19:32
Ca me semble normal, non ? Les courbes en gamma (dont la 2.2) sont basées sur une fonction analytique en exposant. Donc la pente tend vers l'infini lorsqu'on va vers zéro. Les autres sont linéaires au voisinage de zéro (pour DICOM, je ne sais pas trop, mais pour L* et sRGB, oui).

Edit : oups, pas vu que sur l'autre fil tu faisais le même commentaire

Je voulais montrer également les chiffres de pente qu'on a pas l'habitude de voir sur un même tableau pour les principales courbes tonales.

Oui bien sur c'est normal mais néanmoins un peu gênant.

D'une part numériquement parlant, cela induit une réaction quelque peu chaotique des conversions de certains CMS autour du zéro, et d'autre part cela ne colle certainement pas avec la sensibilité perceptuelle de l'œil. Voir la courbe DICOM, qui comme L* et sRGB n'ont pas une pente si forte dans les bas niveaux.

Si on ajoute à cela l'influence d'un éclairage ambiant un peu trop fort qui viendrait polluer d'autant plus un gamma 2.2 qu'un sRGB, L* ou DICOM, on peut alors raisonnablement dire que gamma 2.2 n'est pas la meilleure solution, en terme de restitution des premiers niveaux de luminance.

Suite à ces tests j'ai d'ailleurs décidé de passer sur d'autres courbes tonales que gamma 2.2 pour mon écran photo, sRGB pour Lightroom, et peut être DICOM lorsque j'aurai un peu de temps pour faire des essais.

C'est surtout l'étude de DICOM qui m'a influencé, ses caractéristiques confirmant la validité des courbes sRGB et L* dans les bas niveaux de luminances.

Pour ceux qui n'ont pas accès aux courbes avancées comme L* et DICOM, il est certainement judicieux d'utiliser un étalonnage en courbe tonale sRGB qui possède le double avantage d'être à la fois facile à exploiter pour les moteurs CMS et proche de gamma 2.2. Ce qui est un avantage pour les applications non gérées par CMS (en existe t'il encore ?) et plus généralement pour la compatibilité. sRGB est un standard de fait, supporté sur la plupart des périphériques. C'est sans doute le choix qui réservera le moins de surprises pour les non experts tout en fournissant un pied de courbe proche de la sensibilité perceptuelle de l'œil, et donc moins de gaspillage des touts premiers niveaux numériques, qui sont quand même précieux sur une liaison 8 bits par couleur.

Voir la comparaison des pieds de courbe dans le fil :

http://www.chassimages.com/forum/index.php/topic,242717.0.html

Et aussi d'autres infos intéressantes que vous trouverez dans ce fil je pense pour mieux appréhender l'étalonnage écran.

olivier1010 · Octobre 18, 2015, 15:47:20

Un outil très intéressant pour calculer la perte de précision lors des conversions entre courbes tonales en fonction de la profondeur de quantification en entrée et en sortie.

http://www.brucelindbloom.com/index.html?LevelsCalculator.html

(Si le tableau de calcul n'apparait pas, ajouter "http://www.brucelindbloom.com" dans la liste des sites autorisé, panneau de configuration, Java).
Par exemple, on peut trouver le nombre de bits nécessaire au niveau de la Lut du moniteur, pour convertir depuis L* (avec une entrée vidéo en 10 bits par canal) vers la luminance Y (situation lorsque le moniteur est étalonné hardware en L*) :

- Choisir L* pour l'entrée, 10 bits

- Choisir Y pour la sortie et augmenter le nombre de bits progressivement jusque le nombre de niveaux de sortie soit égal à 1024.
On trouve dans ce cas 14 bits, ce qui correspond à la profondeur de quantification des tables LUT sur des écrans graphiques haut de gamme.

Pour une entrée en 8 bits, on trouve une sortie en 12 bits pour conserver 256 niveaux, ce qui correspond à la profondeur des tables LUT sur des écrans graphiques un peu moins haut de gamme ou un peu plus anciens (lorsque le mode vidéo 10 bits par canal n'existait pas ou était encore très peu utilisé pour l'épreuvage écran).
Autre exemple, on veut calibrer un moniteur bureautique (gamma natif proche de sRGB, soit approximativement gamma 2.2) sur une courbe tonale L*. La liaison vidéo est donc en 8 bits tout comme la table LUT de la carte vidéo qui est utilisée pour opérer l'adaptation tonale puisque l'écran ne dispose pas de table interne pour une calibration hardware.
- Choisir L* pour l'entrée, 8 bits

- Choisir Gamma 2.2 pour la sortie, 8 bits

Le nombre de niveaux de sortie disponibles pour l'affichage est de 234. On a donc perdu 22 niveaux dans l'opération (dans le meilleur des cas si l'adaptation n'est pas trop difficile), d'où mon conseil livré dans un autre fil de ne pas utiliser L* avec un moniteur bureautique non calibré hardware.
Ce calculateur permet donc de trouver les profondeurs de quantification nécessaires pour éviter la perte de niveaux lors des conversions. Ce qui est un critère important vers l'obtention de la meilleure précision possible dans l'affichage des niveaux de luminance.

L'autre critère aussi important est le choix de la courbe tonale pour l'affichage écran, qui devra si possible s'approcher au mieux de la perception visuelle humaine afin d'exploiter correctement le nombre de niveaux de quantification physiquement disponibles sur la liaison vidéo.

Sachant que l'œil est capable de discerner environ 450 niveaux de luminance sur un écran (voir par exemple le standard DICOM ou tout cela est expliqué en détail), il apparait clairement qu'indépendamment du choix de la courbe tonale une liaison vidéo 8 bits n'est pas suffisante. Il faudra au moins 9 bits, en pratique 10 bits, le format 9 bits n'ayant jamais existé.

Ensuite, pour convertir ces 10 bits en entrée, vers une luminance sur la dalle suivant une courbe tonale "perceptuelle" comme L* ou DICOM, il faudra une LUT 14 bits dans le moniteur. Avec Gamma 2.2, dont la pente est très forte vers le zéro, il faudrait une LUT de plus de 16 bits.

Conclusion : pour obtenir la meilleure précision possible sur un affichage écran, mathématiquement et perceptuellement parlant il faut :

- une liaison vidéo 10 bits par canal

- une LUT 14 bits dans le moniteur pour la conversion vers les niveaux de luminance

- une courbe tonale "perceptuelle" chargée dans cette LUT. sRGB, L* ou DICOM sont préférables à une courbe gamma dont le tassement très important vers le zéro impliquerait une LUT de plus de 16 bits pour obtenir la même précision dans les faibles niveaux.
Enfin pour obtenir la meilleure précision d'affichage, au delà de l'étalonnage et des caractéristiques de l'écran, il est très important que l'éclairage de la pièce soit être adapté au niveau de luminance mini de l'écran. Voir mon fil sur la pollution par l'éclairage ambiant.
http://www.chassimages.com/forum/index.php/topic,242949.0.html