calibrage moniteur Gamma 2.2 ou courbe L* ?

Démarré par Christophe Métairie, Septembre 13, 2015, 15:57:48

« précédent - suivant »

matopho

Bonsoir,

Merci à tous. C'est clair maintenant.

Mais le canard est toujours vivant !

Salutations
+ c loin - c net

MBe

Information:
Je crains que Christophe Metairie ne communique plus sur ce fil, ce forum (?) car il a été pris à parti sur un blog relatif "normalement" à la gestion des couleurs, comme Jean Delmas, et bien d'autres,  ou moi même, nous sommes régulièrement l'objet d'insultes diverses.
C'est une triste nouvelle, j'espère que cela ne portera pas préjudice à son activité.

Fin du hors sujet.


olivier1010

Citation de: MBe le Septembre 22, 2015, 23:51:01
Une courbe peut être décrit par une équation, par une table, la précision de la table est donnée par la quantification des données.

Dans le cas qui nous intéresse, la comparaison est réellement pertinente.

Prenons un cas très simple, l'équation d'une droite :
y = x

et la table
x, y
0, 0
1, 1
2, 2
....etc

Vous ne trouverez pas de différence en traçant les 2 courbes.


De même pour un gamma, on peut le décrire de trois façons :

- par un simple nombre, la base de la puissance employée dans la formule du gamma, par exemple 2.2

- par une courbe décrite point par point, par exemple le début d'une courbe gamma 2.2

0
0.000507259
0.002330748
0.005687169
0.010724338
0.017516636
0.026155814
0.036710742
0.049241576
0.063801905
0.080485324
0.099251324
0.120180562
0.143311034
0.168678278
0.196315705
0.226334212

- par sa formule, par exemple pour un gamma 2.4 : x = y puissance 2.4
La précision est parfaite pour les solutions 1 et 3 (même chose), elle dépend en fait de la précision utilisée dans les calculs.

Pour la solution 2, comme l'a dit Mbe, elle est limitée à 16 bits, ce qui est déjà une très bonne précision pour un système de gestion des couleurs dans une chaine graphique.
Dans les débuts du système icc (1995...), on voyait des tables 8 bits, qui je pense ont disparu en pratique. Aujourd'hui dans l'icc version 4.3, on peut utiliser des tables 32 bits en virgule flottante, en IEEE 754 simple précision, soit 23 bits pour la mantisse et 8 bits pour l'exposant.

Ces améliorations sont importantes par exemple pour l'industrie du cinéma, qui doit faire correspondre très précisément des espaces couleurs non linéaires dans le cadre des effets spéciaux.

aziber

C'est étrange : le logiciel CoPrA m'indique d'autres résultats avec une linéarité parfaite du L*. Mais comme MBe est votre caution scientifique, vous devriez envoyer vos résultats à BasICColor : support [at] basiccolor.de

olivier1010

#254
Citation de: aziber le Septembre 23, 2015, 10:01:37
C'est étrange : le logiciel CoPrA m'indique d'autres résultats avec une linéarité parfaite du L*. Mais comme MBe est votre caution scientifique, vous devriez envoyer vos résultats à BasICColor : support [at] basiccolor.de

Vous avez bien fait de faire cette vérification car je viens de découvrir une erreur dans la source des données que j'ai utilisées pour tracer la courbe L* de Basiccolor.

Comme quoi il est toujours important de recroiser les résultats.

J'ai inversé les données entre deux profils Basiccolor, l'un étant réalisé sans calibration et donc avec des courbes TRC décrivant le gamma de l'écran et non celles du L* théorique (malgré que l'interface de Basiccolor indique toujours L* dans ce cas particulier).

Donc le L* Basiccolor tracé dans les précédents messages est en fait celui du gamma d'un écran HP LP2475W, dont le contraste est réglé à 80. Au passage le gamma natif de l'écran est très différent de L* ce qui implique une correction VCGT assez forte pour ramener l'écran sur L*. Voir message suivant.

Donc on revient en arrière, la courbe L* de Basiccolor est parfaitement juste.

Voici le tracé (avec un zoom dans les bas niveaux) qui compare le L* de BAsiccolor et celui de l'espace ECIRGB. Et les bonnes données pour le L* de Basiccolor Display 5.

BEGIN_LUT In_Out 1 1
IN OUT
 0.000   0.000
 0.392   0.043
 0.784   0.087
 1.176   0.130
 1.569   0.174
 1.961   0.217
 2.353   0.261
 2.745   0.304
 3.137   0.348
 3.529   0.391
 3.922   0.435
 4.314   0.478
 4.706   0.520
 5.098   0.565
 5.490   0.607
 5.882   0.652
 6.275   0.694
 6.667   0.739
 7.059   0.781
 7.451   0.826
 7.843   0.868
 8.235   0.912
 8.627   0.957
 9.020   1.004
 9.412   1.051
 9.804   1.100
10.196   1.152
10.588   1.204
10.980   1.259
11.373   1.314
11.765   1.372
12.157   1.430
12.549   1.491
12.941   1.553
13.333   1.617
13.725   1.683
14.118   1.750
14.510   1.819
14.902   1.891
15.294   1.964
15.686   2.039
16.078   2.115
16.471   2.193
16.863   2.274
17.255   2.356
17.647   2.440
18.039   2.527
18.431   2.615
18.824   2.705
19.216   2.799
19.608   2.893
20.000   2.989
20.392   3.088
20.784   3.189
21.176   3.291
21.569   3.397
21.961   3.505
22.353   3.615
22.745   3.726
23.137   3.841
23.529   3.957
23.922   4.076
24.314   4.198
24.706   4.321
25.098   4.446
25.490   4.576
25.882   4.707
26.275   4.840
26.667   4.976
27.059   5.115
27.451   5.255
27.843   5.399
28.235   5.545
28.627   5.695
29.020   5.846
29.412   6.000
29.804   6.157
30.196   6.316
30.588   6.477
30.980   6.644
31.373   6.812
31.765   6.981
32.157   7.155
32.549   7.330
32.941   7.510
33.333   7.692
33.725   7.877
34.118   8.064
34.510   8.255
34.902   8.449
35.294   8.646
35.686   8.846
36.078   9.049
36.471   9.255
36.863   9.464
37.255   9.676
37.647   9.891
38.039  10.111
38.431  10.332
38.824  10.556
39.216  10.785
39.608  11.017
40.000  11.250
40.392  11.489
40.784  11.730
41.176  11.975
41.569  12.222
41.961  12.474
42.353  12.729
42.745  12.988
43.137  13.249
43.529  13.515
43.922  13.783
44.314  14.057
44.706  14.333
45.098  14.612
45.490  14.896
45.882  15.181
46.275  15.473
46.667  15.767
47.059  16.065
47.451  16.365
47.843  16.672
48.235  16.980
48.627  17.293
49.020  17.610
49.412  17.931
49.804  18.254
50.196  18.584
50.588  18.915
50.980  19.252
51.373  19.593
51.765  19.936
52.157  20.284
52.549  20.636
52.941  20.992
53.333  21.352
53.725  21.717
54.118  22.086
54.510  22.458
54.902  22.835
55.294  23.217
55.686  23.601
56.078  23.990
56.471  24.384
56.863  24.782
57.255  25.185
57.647  25.591
58.039  26.003
58.431  26.418
58.824  26.838
59.216  27.262
59.608  27.691
60.000  28.124
60.392  28.560
60.784  29.003
61.176  29.450
61.569  29.902
61.961  30.356
62.353  30.817
62.745  31.283
63.137  31.752
63.529  32.226
63.922  32.705
64.314  33.188
64.706  33.678
65.098  34.171
65.490  34.668
65.882  35.172
66.275  35.680
66.667  36.193
67.059  36.710
67.451  37.232
67.843  37.760
68.235  38.293
68.627  38.830
69.020  39.371
69.412  39.919
69.804  40.472
70.196  41.028
70.588  41.592
70.980  42.159
71.373  42.731
71.765  43.310
72.157  43.893
72.549  44.482
72.941  45.075
73.333  45.673
73.725  46.278
74.118  46.888
74.510  47.503
74.902  48.122
75.294  48.748
75.686  49.378
76.078  50.014
76.471  50.657
76.863  51.304
77.255  51.957
77.647  52.615
78.039  53.278
78.431  53.948
78.824  54.623
79.216  55.303
79.608  55.990
80.000  56.681
80.392  57.379
80.784  58.082
81.176  58.791
81.569  59.506
81.961  60.226
82.353  60.952
82.745  61.685
83.137  62.422
83.529  63.166
83.922  63.915
84.314  64.671
84.706  65.432
85.098  66.200
85.490  66.973
85.882  67.752
86.275  68.537
86.667  69.329
87.059  70.126
87.451  70.930
87.843  71.740
88.235  72.555
88.627  73.378
89.020  74.206
89.412  75.041
89.804  75.880
90.196  76.727
90.588  77.581
90.980  78.441
91.373  79.306
91.765  80.179
92.157  81.056
92.549  81.941
92.941  82.832
93.333  83.731
93.725  84.634
94.118  85.545
94.510  86.462
94.902  87.387
95.294  88.316
95.686  89.253
96.078  90.198
96.471  91.147
96.863  92.103
97.255  93.068
97.647  94.037
98.039  95.015
98.431  95.998
98.824  96.988
99.216  97.986
99.608  98.990
100.000 100.000


olivier1010


La correction appliquée par la carte vidéo (en 8 bits donc) pour ramener un écran HP LP2475W sur une courbe tonale L*.

On remarque que la correction est assez forte dans le bas de la courbe (bas niveaux) avec pour conséquence une légère détérioration de la résolution tonale car cette correction est appliquée en 8 bits.

Pour cette raison je pense qu'il est préférable d'utiliser L* sur des moniteurs à calibration hardware.


fred94-

piouuuuu  tu nous a fait peur ^^

en tout cas merci encore pour les test.

bonne journée

aziber


asak


MBe

Citation de: olivier1010 le Septembre 23, 2015, 11:44:21
Vous avez bien fait de faire cette vérification car je viens de découvrir une erreur dans la source des données que j'ai utilisées pour tracer la courbe L* de Basiccolor.

Comme quoi il est toujours important de recroiser les résultats.

J'ai inversé les données entre deux profils Basiccolor, l'un étant réalisé sans calibration et donc avec des courbes TRC décrivant le gamma de l'écran et non celles du L* théorique (malgré que l'interface de Basiccolor indique toujours L* dans ce cas particulier).

Donc le L* Basiccolor tracé dans les précédents messages est en fait celui du gamma d'un écran HP LP2475W, dont le contraste est réglé à 80. Au passage le gamma natif de l'écran est très différent de L* ce qui implique une correction VCGT assez forte pour ramener l'écran sur L*. Voir message suivant.

Donc on revient en arrière, la courbe L* de Basiccolor est parfaitement juste.

[...]

L'erreur est humaine et le principal est d'avoir trouvé une explication logique au défaut suspecté. Cela confirme également le sérieux de BasiCColor sur la qualité de ces produits.
Comme je restais interrogatif sur les résultats d'hier soir j'ai poursuivi assez tardivement mes recherches sur le sujet, ré-ouvert quelques bons livres...
Les courbes de TRC  sont comprises entre  racine carré de 2 et racine cubique pour la sensibilité et la perception de la vision humaine. j'ai retracé ces courbes sur la courbe "BasiCColor"  et par itération successives je concluais que la courbe tracée était très proche d'un gamma2,2. Le HP LP2475W a donc un comportement natif normal, qui en effet, si il était souhaité de le corriger en Lstar serait torturé par les données mémorisées dans la carte graphique et donnerait un gamut bien plus défavorable qui si il est calibré en 2,2.

Pour les écrans avec une calibration logicielle, une mesure de gamma natif est conseillée pour vérifier qu'il est compatible avec le Lstar, sinon une calibration avec un TRC de 2,2 reste une excellente solution.
Pour les écrans avec une calibration hardware, le choix est possible entre Lstar (pour les esthètes  ;) ) ou 2,2.

MBe

Citation de: aziber le Septembre 23, 2015, 13:15:52
CN vs bICC

Les courbes vcgt ne sont pas des droites pour BlCC, cela correspond pas à une calibration hardware ? c'est bien ça?

aziber

 [at]  MBe

Tout est en hard sur le dernier CG27 de la marque. C'est réalisé sous ColorNavigator en hard et sous bICC display le dernier en hard, après reset de la PRAM du mac et aussi de la configuration de l'écran eizo. Le logiciel est CoPrA pour la réalisation des courbes.

MBe

#262
Citation de: aziber le Septembre 23, 2015, 20:05:28
[at]  MBe

Tout est en hard sur le dernier CG27 de la marque. C'est réalisé sous ColorNavigator en hard et sous bICC display le dernier en hard, après reset de la PRAM du mac et aussi de la configuration de l'écran eizo. Le logiciel est CoPrA pour la réalisation des courbes.

Donc en théorie les courbes vcgt devraient être des droites (comme avec ColorNavigator), car les corrections sont chargées dans la mémoire de l'écran (16bits), pas dans la mémoire de la carte graphique (8bits).

aziber

Citation de: MBe le Septembre 23, 2015, 20:15:39
Donc en théorie les courbes vcgt devraient être des droites (comme avec ColorNavigator), car les corrections sont chargées dans la mémoire de l'écran (16bits), pas dans la mémoire de la carte graphique (8bits).

Si tu le dis, surtout n'hésite pas à le signaler au support d'EIZO (c'est pour le CG277) et les féliciter de la justesse de ColorNavigator, (fait le à la façon de Nelson Monfort version caution scientifique, cela te va si bien) ; envoi un rapport à BasICColor, ainsi qu'à ColorLogic pour leur signaler qu'ils déconnent grave dans leurs calculs.

Je passe la main, également ...

olivier1010

Citation de: MBe le Septembre 23, 2015, 20:15:39
Donc en théorie les courbes vcgt devraient être des droites (comme avec ColorNavigator), car les corrections sont chargées dans la mémoire de l'écran (16bits), pas dans la mémoire de la carte graphique (8bits).

En théorie oui.

Si l'écran est vraiment calibré en hardware on peut imaginer que ces courbes soient lues par le gamma loader de Basiccolor pour les envoyer dans la table de calibration hardware de l'écran.

Lequel gamma loader s'assurerait de mettre à zéro les LUT de la carte vidéo.

Après tout ces tags VCGT ne sont pas standardisés...


olivier1010

Citation de: fred94- le Septembre 23, 2015, 12:08:42
piouuuuu  tu nous a fait peur ^^

en tout cas merci encore pour les test.

bonne journée
Au vu de la forte correction qu'il est nécessaire d'appliquer par la carte vidéo pour ramener un écran classique sur une courbe L*, je me suis dit qu'il serait intéressant de réaliser un test dans le cadre de ce fil afin de montrer la différence entre une calibration L* réalisée en software (par la carte vidéo en 8 bits) ou en hardware (par les courbes LUT de l'écran en 12 ou 14 bits). Le but étant de montrer que la précision des niveaux de luminance affichés par l'écran est affectée par le type de calibration.
Pour réaliser ce test dans de bonnes conditions, je n'ai pas voulu utiliser un écran bureautique comme le HP LP2475w car sa stabilité même sur une courte période (quelques minutes) est trop mauvaise. en effet sur ce type d'écran la luminance peut varier de  quelques % sur quelques minutes voir sur quelques dizaines de secondes, ce qui donne des résultats de mesure peu objectifs.

J'utiliserai donc un Eizo CG277, dont la stabilité sur des périodes courtes est bien inférieure à 0.1 Delta L* selon ce que j'ai pu observer lors de mes récentes mesures.
La procédure consiste à réaliser deux mesures d'un même fichier de 200 patchs en niveau de gris, en valeurs L*a*b* étagées avec un pas de 0.5 L* :
- une première mesure réalisée avec une calibration hardware de l'écran en L*.

Cette mesure montrera la précision de la luminance pour une calibration en L* à travers les tables LUT internes de l'écran qui sont en 14 bits.
L'affichage des patchs sera réalisé en 8 bits par canal, comme pour la mesure suivante afin de bien mettre en évidence l'influence de la calibration, hardware ou software, et non pas l'influence de la profondeur de quantification de la liaison vidéo.
- une seconde mesure réalisée avec une calibration hardware de l'écran en gamma 2.2, plus une calibration software vers L* à travers la correction gamma de la carte vidéo.

Cette mesure simulera un écran plus bas de gamme sans calibration hardware, dont le gamma natif serait proche de gamma 2.2 et qui serait calibré software L* par une application de calibration.

Elle permettra de montrer qu'elle est l'influence d'une calibration en précision 8 bits par la carte vidéo, lorsqu'on veut forcer un écran de gamma natif 2.2 vers une courbe tonale L*.
Pour se mettre dans les conditions d'un écran moins haut de gamme, le mode d'affichage 30 bits sera désactivé dans le driver de la carte vidéo, afin que celle-ci réalise une correction gamma en 8 bits et non 10 bits par canal.
Enfin, les mesures sont réalisées par un logiciel indépendant, PatchTool 4.7, à partir de valeurs en L*a*b* converties vers le profil écran pour affichage et mesure par une sonde i1 Display Pro.
Voici le graphique qui montre les erreurs Delta L* pour une calibration L* software sur un écran calibré hardware en gamma 2.2 et relié au PC par une liaison vidéo 8 bits.
On remarque que des erreurs assez importantes commencent à apparaître en dessous d'une luminance écran L* de 13 % environ. Limite qu'a choisi Basiccolor Display pour positionner son dernier patch gris foncé dans la procédure de validation.

Dans le message suivant vous trouverez un tracé des courbes VCGT (correction gamma par la carte vidéo), utilisées par Basiccolor pour ramener l'écran d'un gamma 2.2 vers une courbe tonale L*.

On remarque que ces corrections ont été minorées certainement volontairement dans la zone des noirs, pour éviter une cassure trop importante dans le bas de la courbe. Ce qui implique une plongé des luminances d'environ 2.5 en Delta L*.

olivier1010


Le tracé des courbes VCGT (correction gamma par la carte vidéo), utilisées par Basiccolor pour ramener l'écran d'un gamma 2.2 vers une courbe tonale L*.

On remarque que ces corrections ont été minorées certainement volontairement dans la zone des noirs, pour éviter une cassure trop importante dans le bas de la courbe. Ce qui implique une légère plongée des luminances d'environ 2.5 en Delta L* dans les très bas niveaux (voir graphique dans le message précédent).


MBe

Citation de: olivier1010 le Septembre 23, 2015, 21:28:17
En théorie oui.

Si l'écran est vraiment calibré en hardware on peut imaginer que ces courbes soient lues par le gamma loader de Basiccolor pour les envoyer dans la table de calibration hardware de l'écran.
Lequel gamma loader s'assurerait de mettre à zéro les LUT de la carte vidéo.


Pas vraiment les datas dans la LUT (RAM) de la carte graphique sont chargés à chaque démarrage système, elles sont en 8 bits... donc pas adaptées à un écran avec une LUT 3D 16bits

Plutôt une solution logicielle, par le gestionnaire de profils écran,  qui indique de ne pas tenir compte de la balise vcgt, de ne pas les charger dans la carte graphique (ou les remplacer par une droite), par exemple lorsque l'écran avec une LUT interne est détectée.

Citation de: olivier1010 le Septembre 23, 2015, 21:28:17

Après tout ces tags VCGT ne sont pas standardisés...

Oui, tout à fait.


olivier1010


Enfin le graphique qui montre les erreurs Delta L* pour une calibration L* hardware et également relié au PC par une liaison vidéo 8 bits.

On remarque une courbe plus lisse, ainsi que l'absence de défaut de luminance dans la zone des noirs, contrairement à la calibration software.

olivier1010

Citation de: MBe le Septembre 23, 2015, 22:50:15
Pas vraiment les datas dans la LUT (RAM) de la carte graphique sont chargés à chaque démarrage système, elles sont en 8 bits... donc pas adaptées à un écran avec une LUT 3D 16bits

Plutôt une solution logicielle, par le gestionnaire de profils écran,  qui indique de ne pas tenir compte de la balise vcgt, de ne pas les charger dans la carte graphique (ou les remplacer par une droite), par exemple lorsque l'écran avec une LUT interne est détectée.

Oui, tout à fait.

Oui c'est peut être comme ça que cela fonctionne, mais pour information les tables VCGT du profil sont en 16 bits et donc pourraient être envoyées dans la mémoire de l'écran après mise en forme.

D'ailleurs, 10 de ces 16 bits sont certainement exploités par la carte vidéo lorsque le mode d'affichage est en 30 bits.


olivier1010



Autre rapport intéressant, celui de Basiccolor après la calibration software en L*, ou l'on remarque que le trou dans les noirs à -2.5 Delta L* n'apparait pas parce qu'il n'y a pas de patch gris foncé en dessous de la valeur de luminance 13.9 %, limite en dessous de laquelle la calibration software commence à poser problème sur la précision des niveaux de luminance.

olivier1010

#271
Enfin, les données de mesure pour la calibration software L*, toujours à partir de l'écran calibré hardware en gamma 2.2, pour vous montrer le détail des mesures dans les bas niveaux de luminance, ce que ne montre pas Basiccolor dans son rapport.

La différence entre la valeur Lab d'origine des patchs noirs et la valeur Lab corrigée s'explique par la compensation du point noir utilisée pour s'adapter au profil écran.


olivier1010

Pour ceux qui voudraient comparer avec les données de mesure L* en calibration hardware, toujours dans les bas niveaux.

On voit que le Delta L reste très stable, seul le Delta E bouge un peu dans les noirs les plus profonds, mais c'est certainement du en grande partie à la précision de mesure en chroma de la sonde qui s'écroule un peu dans cette zone.


aziber

Un truc ENORME :

MacBook Pro (Intel HD Graphics 4000) + EIZO CG277 et EIZO CX241
MBP + CG277 :

Mono-écran en CG277 : VCGT => parfaitement droit sur le profil bICC pour le CG277

Bi-écran MBP + CG277 : VCGT => courbes de rattrapage sur les 2 profils bICC (MBP et CG277)

MBP + CX241

Mono-écran CX241 : VCGT => courbes de rattrapage sur le profil bICC pour le CX241

Bi-écran MBP + CX241 : VCGT => courbes de rattrapage sur les 2 profils bICC (MBP et CX241)
. Y a t'il un rapport avec la carte graphique HD4000 ? incapable de gérer ?
. Le CX241 est il incapable de gérer la configuration HARDWARE sous bICC ? (fonctionne sous ColorNavigator)
. Vos CG / CX / CS ont t'ils des droites ou des courbes sur le VCGT sous bICC ?
chez moi : CG droites, CX courbes

olivier1010

Citation de: aziber le Septembre 24, 2015, 09:59:46
Un truc ENORME :

MacBook Pro (Intel HD Graphics 4000) + EIZO CG277 et EIZO CX241
MBP + CG277 :

Mono-écran en CG277 : VCGT => parfaitement droit sur le profil bICC pour le CG277

Bi-écran MBP + CG277 : VCGT => courbes de rattrapage sur les 2 profils bICC (MBP et CG277)

MBP + CX241

Mono-écran CX241 : VCGT => courbes de rattrapage sur le profil bICC pour le CX241

Bi-écran MBP + CX241 : VCGT => courbes de rattrapage sur les 2 profils bICC (MBP et CX241)
. Y a t'il un rapport avec la carte graphique HD4000 ? incapable de gérer ?
. Le CX241 est il incapable de gérer la configuration HARDWARE sous bICC ? (fonctionne sous ColorNavigator)
. Vos CG / CX / CS ont t'ils des droites ou des courbes sur le VCGT sous bICC ?
chez moi : CG droites, CX courbes


La liste des écrans compatibles pour la version 5.6 :

Eizo CG 210
- Eizo CE 210W
- Eizo CG 211
- Eizo CG 220
- Eizo CG 221
- Eizo CG 222W
- Eizo CG 223W
- Eizo CG 232W
- Eizo CE 240W
- Eizo CG 241W
- Eizo CG 242W
- Eizo CG 243W
- Eizo CG 245W
- Eizo CG 246
- Eizo CG 247
- Eizo CG 275W
- Eizo CG 276
- Eizo CG 277
- Eizo CG 301W
- Eizo CG 303W

Pour la version 5.7 je n'arrive pas à retrouver la liste que j'ai pourtant vu quelque part il me semble.