Forum Chasseur d'Images - www.chassimages.com

une petit sondage ou retour utilisateurs du calibrage de vos moniteurs:

Certains logiciels de calibrage écran propose au choix une courbe tonale en gamma 2.2 ou une courbe en L*. Pas mal de mes clients ( et moi même ) ont remarqués que lorsqu'on sélectionne une courbe L* pour le réglage du moniteur le rendu des très basses lumières est affecté à l'affichage ( très basses lumières plus sombres en L* qu'en gamma 2.2 ).
Le problème se pose alors à l'impression avec un rendu de ces très basses lumières et de leur détail très différent du rendu écran, avec des ombres plus lumineuses qu'a l'écran ( courbe L* ) alors que si le moniteur est calibré en gamma 2.2 le problème semble ne pas se poser.

Avez vous pu voir se problème sur votre système ?

C Métairie

correction:  ... CE problème ...   ;)

Bonjour, jamais utilisé ce réglage. À quoi correspond cette courbe? Le "L" est pour dire quoi, "Log" comme en cinéma à moins que ce soit "Linéaire" auquel cas ça voudrait dire qu'il n'y a pas de gamma appliqué? A ton une représentation graphique pour la comparer à la courbe d'un gamma 2.2 ou 2.4 par exemple. Je vais suivre ce fil la calib m'intéresse toujours.  ;)

C est peut etre normal si on utilise un espace de travail gamma avec une visu L..
Espace de tra ail gamma visu gamma. Espace de travail L visu L.
;)

la courbe L* correspond a une courbe "perceptuelle" qui est théoriquement meilleure qu'un simple gamma 2.2 pour le visionnage à l'écran.

C Métairie

Il me semble que les écrans Nec Spectraview du club photo, étalonnés avec Nec Spectraview Profiler 5, le sont en L* (proposition par défaut).

Le mien, un Nec PA241w, est étalonné avec Spectraview II, qui ne propose pas ce réglage (juste des valeurs de gamma, 2.2 en ce qui me concerne).
Dans un cas comme dans l'autre, je n'ai pas noté de problème de rendu dans les ombres, ou alors, un peu inverse de celui évoqué par Christophe (si j'ai bien compris) : à savoir que, quelquefois, les ombres les plus denses sont un peu enterrées sur le tirage, par rapport à l'écran (mais j'ai mis ça sur le dos du rendu différent d'un écran et d'un papier. Précision : sur papier baryté).
Après, j'ai fait réaliser des profils chez CMP (;-) pour le club photo : il faudra que je vois si ça change les choses par rapport au profil générique du fabricant de ce point de vue...

Sur mon Eizo, j'ai pu me faire 2 profils et passer de l'un à l'autre à la vollée  dans Colornavigator6.
Avec des tirages issus de mon labo en ligne tirés en sRVB, le gamma 2.2 est celui qui va mieux. Le gamma en L* donne des tons moins contrastés/saturés me semble il, mais c'est subtil.
J'ai gardé le 2.2 qui me va mieux, mais il faut bien rappeler que l'illuminant sous lequel on expose ses tirages est très important, j'utilise une ampoule Philips lumière du jour.

j'utilise BasICColor display 5 (meme logiciel que spectraview profiler ) et les 2 choix sont proposés ( parmi d'autres ), c'est après avoir fait des premiers profils écrans en L* que j'ai vu une différence avec les tirages, d'où un essai de calibrage écran en gamma 2.2 qui donne une meilleure correspondance écran/tirage.
il est intéressant d'avoir votre retour pour essayer de dégager une "ligne directrice"  ;)

C Métairie

C'est pas bien compliqué (faut juste les compétences) : C1 + RIP dédié

Au revoir à tous car je fais ma rentrée

Salomé

Citation de: Salomé_B le Septembre 13, 2015, 20:25:02
C'est pas bien compliqué (faut juste les compétences) : C1 + RIP dédié

Au revoir à tous car je fais ma rentrée

Salomé

Merci pour tout et bonne rentrée Salomé

Citation de: PascalDespeaux le Septembre 13, 2015, 18:57:11
Bonjour, jamais utilisé ce réglage. À quoi correspond cette courbe? Le "L" est pour dire quoi, "Log" comme en cinéma à moins que ce soit "Linéaire" auquel cas ça voudrait dire qu'il n'y a pas de gamma appliqué? A ton une représentation graphique pour la comparer à la courbe d'un gamma 2.2 ou 2.4 par exemple. Je vais suivre ce fil la calib m'intéresse toujours.  ;)

La courbe L* correspond au L* de L*a*b*, espace ou les distances entre 2 couleurs correspondent presque à la perception visuelle. Entre un TRC de 2,2 ("gamma) ou le gris à 18% correspond à environ 47, avec un TRC L*, le gris à 18% correspond à 50 pour une échelle de la "clarté de 0 à 100.

Citation de: MBe le Septembre 13, 2015, 20:52:45
La courbe L* correspond au L* de L*a*b*, espace ou les distances entre 2 couleurs correspondent presque à la perception visuelle. Entre un TRC de 2,2 ("gamma) ou le gris à 18% correspond à environ 47, avec un TRC L*, le gris à 18% correspond à 50 pour une échelle de la "clarté de 0 à 100.

Tupperware à 47 ou 50?
Dsl 😁

Citation de: fred94- le Septembre 13, 2015, 21:14:32
Tupperware à 47 ou 50?
Dsl 😁

Aucun tupperware, que quelques équations traduites en courbes, mais je comprends l'allusion  ;)

Citation de: Christophe Métairie le Septembre 13, 2015, 15:57:48
une petit sondage ou retour utilisateurs du calibrage de vos moniteurs:

Certains logiciels de calibrage écran propose au choix une courbe tonale en gamma 2.2 ou une courbe en L*. Pas mal de mes clients ( et moi même ) ont remarqués que lorsqu'on sélectionne une courbe L* pour le réglage du moniteur le rendu des très basses lumières est affecté à l'affichage ( très basses lumières plus sombres en L* qu'en gamma 2.2 ).
Le problème se pose alors à l'impression avec un rendu de ces très basses lumières et de leur détail très différent du rendu écran, avec des ombres plus lumineuses qu'a l'écran ( courbe L* ) alors que si le moniteur est calibré en gamma 2.2 le problème semble ne pas se poser.

Avez vous pu voir se problème sur votre système ?

C Métairie

J'ai fait pas mal d'essais sur les espaces L* et la calibration/caractérisation  de mon écran avec du L* et du 2,2. La courbe TRC en L* a l'avantage d'avoir une meilleur linéarité dans les basses lumières, je le vois très bien sur la courbe, ainsi que sur mon écran (j'utilise ColorNavigator avec une calibration matérielle). Il est fort probable que le backlight des écrans LCD , l'électronique de commande du backlight,  les courbes chargés dans les cartes graphiques pour ce L*,  ne soient pas très bien adaptés et peut être éloignés de la courbe de réponse naturelle de tous les écrans. il faut faire des essais pour le vérifier avec son équipement. (je n'ai pas essayé sur l'écran de mon portable et je ne crois pas qu'il y ait un intérêt à le faire  :D)

Un autre aspect, le ratio de contraste (dynamique) que je demande à mon écran est raisonnable,  j'utilise une valeur très proche de l'ISO 12646, 2008 qui préconise 287,9, cette valeur a été établie en relation avec la dynamique d'un tirage papier, c'est peut être également pour cela que je n'ai pas constaté de problème entre écran et tirage (?), à noter, je ne fais pas de tirage N&B. En fait, il faut attacher autant d'importance au point noir qu'au point blanc, mais ce n'est qu'un avis personnel.
Pour le RIP, je ne sais pas, mais un excellent profil icc pour imprimante, comme vous le faites, devrait pouvoir traduire ce dégradé dans les basses lumières.

Citation de: Verso92 le Septembre 13, 2015, 19:12:32

Le mien, un Nec PA241w, est étalonné avec Spectraview II, qui ne propose pas ce réglage (juste des valeurs de gamma, 2.2 en ce qui me concerne).

Sur mon PA242, Spectraview II me propose un réglage en L*  ???

ma question portait plus sur la correspondance écran / tirage, les profils ICC d'impression étant normalisés, c'est le calibrage écran et la courbe choisie qui détermine la bonne correspondance entre les 2.

C Métairie

Citation de: tenmangu81 le Septembre 13, 2015, 22:28:40
Sur mon PA242, Spectraview II me propose un réglage en L*  ???

Il faudrait peut-être que j'installe la dernière version ?
(j'avais vu qu'elle apportait des améliorations pour la prise en compte du PA242w, et je n'avais pas jugé utile de mettre à jour...)

Citation de: fred94- le Septembre 13, 2015, 21:14:32
Tupperware à 47 ou 50?
Dsl 😁

Hi, hi !

;-)

Il me semble en tout cas que pour profiter du L*, un écran avec calibration hardware est nécessaire. Car à ce niveau de précision, il me semble illusoire de penser qu'on pourra obtenir mieux que la courbe gamma 2.2 en utilisant un écran classique dont la calibration se fait en 8 bits avec la carte vidéo.

En cas de calibration par la carte vidéo, les résultats risquent bien d'être moins bons en L* qu'en gamma 2.2 à cause des sauts de quantification induits par le 8 bits, l'écran étant certainement nativement plûtot réglé en usine sur un gamma proche de 2.2. Donc tenter de changer ses courbes gamma natives par une calibration externe en 8 bits risque de causer plus de dégâts qu'autre chose car il faudra triturer les courbes natives par des coefficients externes 8 bits.

D'ailleurs les logiciels récents évitent de toucher à la partie basse de la courbe de calibration lorsqu'ils opèrent une calibration par la carte vidéo. Car toucher à cette partie de la courbe introduit le plus souvent des sérieux problèmes, surtout que c'est la zone où la précision des spectros et colorimètres est la plus mauvaise. Je l'ai souvent remarqué en calibrant des écrans avec d'anciens logiciels, la zone des bas niveaux de la calibration était souvent désastreuse.

Sachant qu'une liaison vidéo 8 bits est déjà insuffisante pour représenter correctement un dégradé de gris sans banding, je vous laisse imaginer ce qu'il se passe lorsqu'on triture en plus les courbes gamma en 8 bits par calibration externe, par rapport à un écran plutôt calibré en usine sur un gamma 2.2.

Donc Eizo ou Nec obligatoire avec table de calibration 14 bits pour voir des différences qui correspondent à une vrai réalité physique au niveau calibration en L*, et non des artifacts liés à des sauts de quantifications provenant d'une calibration par carte vidéo en 8 bits.

J'ajouterais même que pour travailler sur certaines images une liaison 30 bits avec l'écran est avantageuse. Sinon banding possible sur certains dégradés monochromes. Dans la pratique ce type d'image est quand même rare. Mais le 30 bits deviendra de plus en plus important à mesure qu'on utilisera des espaces couleurs plus grands, à l'écran comme à l'impression. En 4K, avec le nouvel espace couleur REC 2020, le 30 bits est prévu dans les normes, même pour l'utilisation en fin de chaine par l'utilisateur final.

Sur mon Eizo j'utilise du gamma 2.2, j'avais un temps regardé quelques discussions sur le L*, pour me dire que finalement le L* n'était pas quelque chose de primordial et pouvant même causer plus de problèmes que d'améliorations, sachant que tout tourne autour du gamma 2.2 aujourd'hui.

Il est certainement beaucoup plus important de porter un soin particulier aux éclairages de la pièce plutôt que de se prendre la tête avec le L*. Et bien sur un bon écran stable qui ne bouge pas trop entre les calibrations.

L'intensité de l'éclairage pièce (32 à 64 lux au niveau de l'écran), la température de couleur, l'indice CRI, l'homogénéité et la stabilité sont importants. Dans le but d'éviter des réflexions dans l'écran et pour avoir une dalle bien éclairée de façon homogène. Cela évitera une perception différente des niveaux de noir selon les zones de la dalle. Mais aussi une bonne perception des couleurs écran (à condition aussi d'avoir un environnement homogène en terme de couleurs, du gris moyen neutre de préférence autour du plan de travail).

Idem pour la lightbooth qui doit fournir la bonne température de couleur et la bonne intensité pour pouvoir contrôler les tirages avec une bonne concordance écran. Un modèle réglable est préférable bien sur. Le logiciel Eizo Colornavigator est d'ailleurs capable de régler la lightbooth pour l'adapter à la calibration écran.

Donc du bon matériel, des bons logiciels récents, et un minimum de bon sens pour des bons résultats. Il y a beaucoup de croyances et de choses qui marchent pas en gestion de la couleur, y compris du coté des développeurs qui ne comprennent pas toujours les tenants et les aboutissants tellement la couleur est quelque chose de complexe.

On le voit bien dans l'évolution des logiciels de calibration. aucun ne donne des résultats identiques en utilisant pourtant le même spectro. Et même des spectros / colorimètres haut de gamme donnent des différences DeltaE importantes selon le fabricant du matériel et sa date de fabrication :)

Ca progresse, lentement mais surement...

Citation de: olivier1010 le Septembre 14, 2015, 10:57:25
Il me semble en tout cas que pour profiter du L*, un écran avec calibration hardware est nécessaire. Car à ce niveau de précision, il me semble illusoire de penser qu'on pourra obtenir mieux que la courbe gamma 2.2 en utilisant un écran classique dont la calibration se fait en 8 bits avec la carte vidéo.

En cas de calibration par la carte vidéo, les résultats risquent bien d'être moins bons en L* qu'en gamma 2.2 à cause des sauts de quantification induits par le 8 bits, l'écran étant certainement nativement plûtot réglé en usine sur un gamma proche de 2.2. Donc tenter de changer ses courbes gamma natives par une calibration externe en 8 bits risque de causer plus de dégâts qu'autre chose car il faudra triturer les courbes natives par des coefficients externes 8 bits.

D'ailleurs les logiciels récents évitent de toucher à la partie basse de la courbe de calibration lorsqu'ils opèrent une calibration par la carte vidéo. Car toucher à cette partie de la courbe introduit le plus souvent des sérieux problèmes, surtout que c'est la zone où la précision des spectros et colorimètres est la plus mauvaise. Je l'ai souvent remarqué en calibrant des écrans avec d'anciens logiciels, la zone des bas niveaux de la calibration était souvent désastreuse.

Sachant qu'une liaison vidéo 8 bits est déjà insuffisante pour représenter correctement un dégradé de gris sans banding, je vous laisse imaginer ce qu'il se passe lorsqu'on triture en plus les courbes gamma en 8 bits par calibration externe, par rapport à un écran plutôt calibré en usine sur un gamma 2.2.

Donc Eizo ou Nec obligatoire avec table de calibration 14 bits pour voir des différences qui correspondent à une vrai réalité physique au niveau calibration en L*, et non des artifacts liés à des sauts de quantifications provenant d'une calibration par carte vidéo en 8 bits.

J'ajouterais même que pour travailler sur certaines images une liaison 30 bits avec l'écran est avantageuse. Sinon banding possible sur certains dégradés monochromes. Dans la pratique ce type d'image est quand même rare. Mais le 30 bits deviendra de plus en plus important à mesure qu'on utilisera des espaces couleurs plus grands, à l'écran comme à l'impression. En 4K, avec le nouvel espace couleur REC 2020, le 30 bits est prévu dans les normes, même pour l'utilisation en fin de chaine par l'utilisateur final.

Sur mon Eizo j'utilise du gamma 2.2, j'avais un temps regardé quelques discussions sur le L*, pour me dire que finalement le L* n'était pas quelque chose de primordial et pouvant même causer plus de problèmes que d'améliorations, sachant que tout tourne autour du gamma 2.2 aujourd'hui.

Il est certainement beaucoup plus important de porter un soin particulier aux éclairages de la pièce plutôt que de se prendre la tête avec le L*. Et bien sur un bon écran stable qui ne bouge pas trop entre les calibrations.

L'intensité de l'éclairage pièce (32 à 64 lux au niveau de l'écran), la température de couleur, l'indice CRI, l'homogénéité et la stabilité sont importants. Dans le but d'éviter des réflexions dans l'écran et pour avoir une dalle bien éclairée de façon homogène. Cela évitera une perception différente des niveaux de noir selon les zones de la dalle. Mais aussi une bonne perception des couleurs écran (à condition aussi d'avoir un environnement homogène en terme de couleurs, du gris moyen neutre de préférence autour du plan de travail).

Idem pour la lightbooth qui doit fournir la bonne température de couleur et la bonne intensité pour pouvoir contrôler les tirages avec une bonne concordance écran. Un modèle réglable est préférable bien sur. Le logiciel Eizo Colornavigator est d'ailleurs capable de régler la lightbooth pour l'adapter à la calibration écran.

Donc du bon matériel, des bons logiciels récents, et un minimum de bon sens pour des bons résultats. Il y a beaucoup de croyances et de choses qui marchent pas en gestion de la couleur, y compris du coté des développeurs qui ne comprennent pas toujours les tenants et les aboutissants tellement la couleur est quelque chose de complexe.

On le voit bien dans l'évolution des logiciels de calibration. aucun ne donne des résultats identiques en utilisant pourtant le même spectro. Et même des spectros / colorimètres haut de gamme donnent des différences DeltaE importantes selon le fabricant du matériel et sa date de fabrication :)

Ca progresse, lentement mais surement...

Je suis bien d'accord avec ce point de vue, mais il est toutefois intéressant de faire des essais si le matériel le permet.

Citation de: Christophe Métairie le Septembre 13, 2015, 19:06:53
la courbe L* correspond a une courbe "perceptuelle" qui est théoriquement meilleure qu'un simple gamma 2.2 pour le visionnage à l'écran.

C Métairie

Merci pour cette réponse cela ne me dit pas exactement ce à quoi ça correspond ce «L» , et comme je n'ai jamais essayé c'est intéressant, merci quand même.  ;)

Si c'est pour s'approcher d'une perception humaine, le "L" ne peut pas être pour le L  de Lab, la luminance va en effet de 0 à 100, mais elle est linéaire, il n'y a pas de gamma en luminance.

Par contre en vidéo, que ce soit amateur ou professionnel, l'espace couleur n'est pas défini en RVB il est défini en Y+Cb+Cr, le Y pour la luminance, mais pour notre œil il est appliqué un gamma ce qui devient : Luninance + Gamma = Luma
Le gamma utilisé en vidéo est 2.35, mais sur les écrans on applique un gamma de 2.4 généralement.
Donc si tu trouves des noirs plus plombés et des blancs plus ouverts... Est ce que le "L" ne serait pas pour Luma donc une luminance plus un gamma appliqué?
Attention je ne dis pas que c'est ça, hein..     ;)    Je n'ai jamais essayé encore de tirer un profil "L" pour la calib écran.

Personnellement, j'utilise depuis 1999 un point blanc à 6500K pour un gamma 2.2, avant cette date 5500K pour un gamma 1.8

Pour l'étalonnage vidéo point blanc à 6500K et gamma 2.4 sur un moniteur broadcast, attention sauf pour la vidéo sur internet ou nous nous retrouvons forcément en 2.2 en gamma.

Et à titre d'information lorsque je parle de vidéo, je ne parle pas de cinéma, là c'est un Gamma de 2.6 qui est utilisé. Et on est défini en RVB comme en photo puisque nous partons, non pas d'une image colorimétriquement sous-échantillonnée (4.2.0/4.2.2), mais de RAW cinema.

Et avec une calibration à 6500K et gamma 2.2, je n'ai pas de problème entre la visualisation à l'écran et les tirages faits en utilisant des profils tirés avec ProfilMaker. Avec un choix de rendu en Chroma Plus pour les photos et pour les reproductions de tableaux je reste sur un Profil tiré en Logo Classique pour ne pas booster la saturation.

Le L* correspondrait à la courbe de sensibilité physiologique de l'oeil en luminance. L est la luminance dans un espace douleur L*a*b* déduit de l'espace colorimétrique XYZ lui même calculé statistiquement à partir d'une procédure de mesure de la sensibilité de l'œil à des stimulus R V et B sur un échantillon d'observateurs. La moyenne de ces échantillonnages à travers cette procédure est alors appelée l'observateur standard. Cela à été réalisé en 1931.
Donc en théorie, si on envoie une progression linéaire en valeur RVB sur un moniteur calibré L*, on doit obtenir physiologiquement une impression de linéarité dans la luminance perçue. C'est à dire que si on double les valeurs RVB on doit percevoir un blanc deux fois plus lumineux.

Le gamma 2.2 est aussi une approximation de la sensibilité de l'œil à la perception de la luminance et des couleurs, avec en théorie une moins bonne corrélation avec la réalité.

Les spécialistes valideront, j'essaie de simplifier.

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

https://fr.wikipedia.org/wiki/CIE_L*a*b*
En pratique on ne devrait pas trop voir de différence sur un écran piloté en 30 bits et un logiciel qui gère les couleurs en 16 bits ou plus, puisqu'il y a derrière des profils couleurs qui doivent uniformiser les espaces et assurer les correspondances.

L'attrait du L* se voit surtout à mon avis sur des écrans pilotés en 24 bits. à vérifier...

Citation de: MBe le Septembre 14, 2015, 11:32:47
Je suis bien d'accord avec ce point de vue, mais il est toutefois intéressant de faire des essais si le matériel le permet.

Oui c'est vrai c'est important, ne serait ce que pour essayer de comprendre ce qu'il se passe.

D'un autre coté, ayant suivi les progrès en colorimétrie depuis une vingtaine d'années, je remarque que les progrès se réalisent surtout sur les logiciels et sur le matériel. Sans eux on ne peut pas faire grand chose même s'il est possible d'optimiser quelque peu soit même certains aspects grâce aux systèmes de calibration / profilage colorimétrique.

Par exemple aujourd'hui une bonne imprimante Laser délivre des images assez bonnes en terme de qualité colorimétrique sans aucune calibration / profilage externe. Prenez une imprimante un peu ancienne, et essayez de la profiler même avec du matériel haut de gamme, et vous n'arriverez à pas grand chose de bon. Ce type d'imprimante n'est tout simplement pas adapté à un profilage, car elle est incapable d'accepter des courbes tonales de pré-linéarisation. Le résultat après profilage est souvent moins bon... aussi (mais pas seulement) parce que la liaison entre PC et imprimante se fait en 24 bits, format qui n'est pas adapté à une calibration externe.

Conclusion le profilage et la calibration colorimétrique ne résout pas (encore) tous les problèmes, même si peu à peu avec les années qui passent, il améliore dans le bon sens la qualité et la constance des résultats. Le système Icc permet aussi de faire avancer les choses dans le sens ou il vulgarise et facilite la compréhension de la chaine des couleurs.

Citation de: Christophe Métairie le Septembre 13, 2015, 23:42:27
ma question portait plus sur la correspondance écran / tirage, les profils ICC d'impression étant normalisés, c'est le calibrage écran et la courbe choisie qui détermine la bonne correspondance entre les 2.

C Métairie

Oui j'ai bien compris cela également, mon message avait pour but de vous inciter à remettre en cause vos cibles de calibration, personnellement je n'ai pas réussi au premier essai à obtenir la bonne correspondance, le processus est itératif.

Bon, comme j'avais envie de savoir j'ai appelé la personne que je considère comme le plus fort en calibration d'écran.. 
Il a travaillé longtemps pour la distribution de Monaco en France et d'ailleurs a fait à l'époque la traduction du soft pour la version Française, et bosse maintenant pour la société la plus connue en France pour les produits art graphique.
Donc après information. Pour revenir sur le "L star" c'est un profil créé par les Allemands il y a déjà longtemps puisqu'il était déjà présent à l'époque de Mac Os 9.... Ptain, je n'en avais jamais entendu parlé...  :o  Il a un gamma de 2.4, comme je l'avais imaginé, mais bon c'était juste une supposition puisque je ne le connais pas. Il est bien tiré de la luminance + un gamma appliqué, forcément puisqu'il ne peut y avoir de gamma sur la luminance. Donc comme en vidéo. Par contre il n'a pas pu me dire s'il avait appelé cet espace "L star" pour le "L" comme dans "Luma"?? Il m'a aussi conseillé d'essayer pour voir, mais pour lui, il reste comme tout le monde sur un gamma 2.2 pour les calib écrans appliqués aux chaines de production.

PS : Si vous voulez voir ce que donne un rendu en linéaire, donc sans gamma, il vous suffit dans C1 de mettre dans les courbes : Linear response, et vous verrez ce que cela donne..   :-\ Par contre ce type de rendu sert en étalonnage cinéma lorsque par exemple in applique une Lut sur les images que l'on développe avant donc en linéaire.

De mémoire et sauf erreur le L* n'est plus à conseiller avec des écrans 30 bits : si le L* en tant qu'espace de calcul dépasse tous les gamuts usuels y compris  le Prophoto, son implémentation logicielle et HW la plus fréquente n'est faite qu'en valeur entières et bornées : L de 0 à 100 donc précision 1% et idem pour les axes  a et b .  Autrement dit adieu l'intérêt des Luts 3d 30 bits. De plus ces limites ne sont pas forcément telles que noir = 0 il peut donc y avoir selon l'éditeur du logiciel des décalages/offset pour compenser des spectros un peu nuls dans les basses lum d'où des basses valeurs souvent trop claires.

Pour un parc de clients ayant forcément des écrans très hétérogènes et pas forcément des cadors de la chaîne de retouche et de repro , le gamma 2.2 reste statistiquement l'approche la plus recommandable.

Citation de: restoc le Septembre 14, 2015, 21:24:24
Pour un parc de clients ayant forcément des écrans très hétérogènes et pas forcément des cadors de la chaîne de retouche et de repro , le gamma 2.2 reste statistiquement l'approche la plus recommandable.

Amen,
Pour avoir fait quelques studio; le 2.2 est à 99,9% utilisé. Et encore des fois c'est à l'aveugle, CàD sélection du sRGB dans les préréglage du moniteur et point. (sisi !) bon après c'est pour du rec709.
... Seul les etalo tournent sur des tables spécifiques et avec la matériel adéquat.

Bonjour,
N'ayant pas de sonde d'étalonnage, je ne peux pas faire le test, mais en théorie, ce choix ne doit pas affecter la luminosité finale de l'image. La luminosité relative est définie dans le fichier de l'image à afficher grâce aux valeurs RVB, et l'espace de couleurs associé au fichier indique ce que le triplet RVB doit représenter en réalité.
Une fois l'écran étalonné, il doit restituer à l'utilisateur exactement ce qui est indiqué dans le fichier.

Le choix entre 2.2 ou L* ne devrait avoir d'effet que sur la pré-linéarisation du canal d'affichage principal de l'OS (appelé "bureau" dans Windows), et au travers duquel les logiciels graphiques vont afficher les images. Autrement dit sur les icônes et les bordures des fenêtres ! Les logiciels vont ensuite appliquer la conversion de l'espace de travail de l'image vers l'espace défini par le fichier de calibration de l'écran, et cette conversion DOIT annuler le choix du gamma pour afficher au final la luminosité réelle de l'image.

Par contre, en termes de nuances de couleurs disponibles, cela change tout. Comme il a été déjà bien expliqué, si on fait tenir 20 nuances de gris dans 5 niveaux de sortie, pour ensuite ré-amplifier ces 5 niveaux vers une valeur de luminosité réelle, on va y perdre en qualité.

Citation de: PascalDespeaux le Septembre 14, 2015, 20:08:15

PS : Si vous voulez voir ce que donne un rendu en linéaire, donc sans gamma, il vous suffit dans C1 de mettre dans les courbes : Linear response, et vous verrez ce que cela donne..   :-\ Par contre ce type de rendu sert en étalonnage cinéma lorsque par exemple in applique une Lut sur les images que l'on développe avant donc en linéaire.

Bonsoir,

Oullllaaaa faites gaffe d'après certains c'est pas un vrai linéaire.....

Citation de: PascalDespeaux le Septembre 14, 2015, 20:08:15
Bon, comme j'avais envie de savoir j'ai appelé la personne que je considère comme le plus fort en calibration d'écran.. 
Il a travaillé longtemps pour la distribution de Monaco en France et d'ailleurs a fait à l'époque la traduction du soft pour la version Française, et bosse maintenant pour la société la plus connue en France pour les produits art graphique.
Donc après information. Pour revenir sur le "L star" c'est un profil créé par les Allemands il y a déjà longtemps puisqu'il était déjà présent à l'époque de Mac Os 9.... Ptain, je n'en avais jamais entendu parlé...  :o  Il a un gamma de 2.4, comme je l'avais imaginé, mais bon c'était juste une supposition puisque je ne le connais pas. Il est bien tiré de la luminance + un gamma appliqué, forcément puisqu'il ne peut y avoir de gamma sur la luminance. Donc comme en vidéo. Par contre il n'a pas pu me dire s'il avait appelé cet espace "L star" pour le "L" comme dans "Luma"?? Il m'a aussi conseillé d'essayer pour voir, mais pour lui, il reste comme tout le monde sur un gamma 2.2 pour les calib écrans appliqués aux chaines de production.

PS : Si vous voulez voir ce que donne un rendu en linéaire, donc sans gamma, il vous suffit dans C1 de mettre dans les courbes : Linear response, et vous verrez ce que cela donne..   :-\ Par contre ce type de rendu sert en étalonnage cinéma lorsque par exemple in applique une Lut sur les images que l'on développe avant donc en linéaire.

Le L* ou Lstar a pour origine la CIE avec une dénomination CIELAB en 1976 par F. W. Billmeyer, dans le bouquin de Roy S. Bern, Principles of Color Technologiy, il y a une célèbre photo qui le montre en train de présenter la genèse du CIELAB au tableau noir.
Les "Allemands" ont du s'inspirer du principe d'espace perceptuel en reprenant l'équation de L* (la clarté).

Pour les équations : https://fr.wikipedia.org/wiki/CIE_L*a*b* (https://fr.wikipedia.org/wiki/CIE_L*a*b*) ou ce site qui a ma préférence : http://www.brucelindbloom.com/index.html?LabGamutDisplay.html (http://www.brucelindbloom.com/index.html?LabGamutDisplay.html)

Citation de: restoc le Septembre 14, 2015, 21:24:24
De mémoire et sauf erreur le L* n'est plus à conseiller avec des écrans 30 bits : si le L* en tant qu'espace de calcul dépasse tous les gamuts usuels y compris  le Prophoto, son implémentation logicielle et HW la plus fréquente n'est faite qu'en valeur entières et bornées : L de 0 à 100 donc précision 1% et idem pour les axes  a et b .  Autrement dit adieu l'intérêt des Luts 3d 30 bits. De plus ces limites ne sont pas forcément telles que noir = 0 il peut donc y avoir selon l'éditeur du logiciel des décalages/offset pour compenser des spectros un peu nuls dans les basses lum d'où des basses valeurs souvent trop claires.

Pour un parc de clients ayant forcément des écrans très hétérogènes et pas forcément des cadors de la chaîne de retouche et de repro , le gamma 2.2 reste statistiquement l'approche la plus recommandable.

je viens de vérifier sur les profils de mon écran réalisés avec ColorNavigator , les TRC 2, 2 ou  L* sont codés avec 256 niveaux, donc pas de différence. Il n'est pas impossible que le soft de l'écran réalise une interpolation (?).

Pour info, un ProStar RGB (qui est en L* avec un gamut Prophoto), vanté comme le "up to date" est codé avec 700 niveaux, alors que mon sRGB est codé avec 4096 points, mon Prophoto est codé à l'ancienne avec une équation linéaire... (TRC = 1.796875)
Pour en revenir au L*, il faut l'essayer et le tester, personnellement, je vois une différence uniquement dans les basses lumières et sur quelques photos, ce n'est donc pas une révolution comme certains ont essayé de nous le faire croire, mais un petit progrès dans la gestion des couleurs que seul un essai permet de confirmer qu'il est adapté à son écran.
Maintenant, il n'est pas possible dans une expo de dire que la photo  N°n est traitée en L* ou pas  :D, c'est quelquefois une aide pour régler les basses lumières.

oui Mbe, en fait je m'aperçois que j'ai inversé les 2 rendus dans ma question ( le rendu écran en L* est plus lumineux que le Gamma 2.2 ), mais le problème reste le même : la correspondance écran tirage est meilleure avec un écran en gamma 2.2  ;)

comme quoi une question toute simple a priori donne un débat intéressant, et selon l'utilisation que l'on a des ses images certains préfèrent un écran en L* , d'autres en gamma 2.2 ...

C Métairie

Citation de: MBe le Septembre 14, 2015, 22:19:32
je viens de vérifier sur les profils de mon écran réalisés avec ColorNavigator , les TRC 2, 2 ou  L* sont codés avec 256 niveaux, donc pas de différence. Il n'est pas impossible que le soft de l'écran réalise une interpolation (?).

Pour info, un ProStar RGB (qui est en L* avec un gamut Prophoto), vanté comme le "up to date" est codé avec 700 niveaux, alors que mon sRGB est codé avec 4096 points, mon Prophoto est codé à l'ancienne avec une équation linéaire... (TRC = 1.796875)
Pour en revenir au L*, il faut l'essayer et le tester, personnellement, je vois une différence uniquement dans les basses lumières et sur quelques photos, ce n'est donc pas une révolution comme certains ont essayé de nous le faire croire, mais un petit progrès dans la gestion des couleurs que seul un essai permet de confirmer qu'il est adapté à son écran.
Maintenant, il n'est pas possible dans une expo de dire que la photo  N°n est traitée en L* ou pas  :D, c'est quelquefois une aide pour régler les basses lumières.

Comme l'expliquait très bien Pio2001, la courbe gamma utilisée pour la calibration écran ne devrait théoriquement pas avoir d'influence sur le résultat final, puisque le profil écran doit corriger les valeurs envoyées vers celui-ci afin de restituer une luminance et des couleurs dérivées d'un espace couleur de connexion commun aux divers périphériques qui si mes souvenirs sont bons est le CIE XYZ. Donc quelque soit la calibration écran, l'application à travers le profil d'écran devrait corriger pour afficher les bonnes couleurs et luminances. On ne devrait donc pas percevoir de différence entre une calibration L* et son profil associé, et une calibration gamma 2.2 et son profil associé.

Oui mais, c'est sans tenir compte d'une part de la précision de la calibration écran, et d'autre part de la précision de la transmission des valeurs RVB vers l'écran. Il y a plusieurs cas de figure à ce niveau :

- Calibration écran hardware, typiquement 12 ou 14 bits par canal

- Calibration écran par la carte vidéo, donc 8 ou 10 bits par canal dans le meilleur des cas

- Pilotage de l'écran en 8 bits par canal, ou 10 bits par canal, peut être plus dans l'avenir lorsque le Rec 2020 deviendra plus courant.
Lorsque la calibration se fait avec une faible profondeur de quantification, il est logiquement préférable de triturer le moins possible le gamma Natif du moniteur afin d'éviter d'introduire des erreurs de quantification dans les valeurs RVB. Dans ce cas de figure, le L* me semble peut recommandable puisqu'il tentera de modifier le gamma natif 2.2 par des courbes tonales appliquées en 8 bits avec les erreurs de quantification que cela implique. On risque donc de se retrouver avec un écran qui ne sera ni exactement en gamma 2.2, ni en L*. :(

Lorsque la calibration se fait en 12 ou 14 bits, les calculs deviennent plus raisonnables en terme de précision, on peut dans ce cas obtenir une bonne calibration L* à partir d'une dalle plutôt gamma 2.2.
Théoriquement, dans ces conditions, et si l'on considère que le L* est mieux corrélé par rapport à la perception visuelle pour l'étagement en luminance dans les bas niveaux, le L* devrait donner de meilleurs résultats lorsqu'on l'utilise avec un moniteur piloté par une liaison vidéo RVB de faible quantification (8 bits par canal). NB : Le 8 bits sur PC était la norme à l'époque ou le L* est apparu. Alors que le 10 bits existait depuis longtemps en vidéo.

Pour des moniteurs pilotés en 30 bits (cela devient de plus en plus une réalité aujourd'hui sur PC), l'intérêt devient moins évident car même s'il est calibré sur un gamma 2.2, donc un gamma moins bien adapté à la perception de l'œil,  le système pourra quand même afficher des valeurs intermédiaires grâce à la liaison 10 bits par canal.

Il reste quand même à prendre en compte les influences des divers espaces colorimétriques au niveau de la précision des conversions. Et là il faut être mathématicien et spécialiste en colorimétrie pour y voir clair. il y a peut être des influences, même si l'on parle uniquement de luminance et sur les faibles niveaux.

Enfin, n'oublions pas que la gestion des couleurs n'est pas une science exacte, puisqu'elle fait correspondre les couleurs à travers un concept de perception tri-stimuli, alors que dans la réalité physique les couleurs se transforment et sont perçues sur la base de leur rayonnement spectral à travers des illuminants qui eux aussi ont un contenu spectral, ce qui est autrement plus complexe et ne peut pas être caractérisé exactement par des approximations basées sur un système tri-stimuli. Sans parler des différences entre les divers observateurs qui ne sont pas forcément tous proches de l'observateur standard et des conditions de visualisation de cet observateur standard.

Donc même lorsque nous auront des boitiers numériques capables de capturer des spectres et non des valeurs RVB, même si un jour les imprimantes seront capables de reproduire exactement ces spectres originaux, il subsistera encore des différences dans la perception des couleurs parce que tous les observateurs n'ont pas la même perception d'un même rayonnement spectral :(

A moins que dans quelques années les profils écrans prennent en charge les caractéristiques visuelles de chaque observateur :)

Des différences également par rapport à ce que voudrait le photographe parce qu'un observateur ne regardera pas forcément le tirage avec le bon illuminant (le bon éclairage pour ceux qui ne connaissent pas le terme illuminant qui est une notion utilisée en colorimétrie). Même un tirage qui serait réalisé en impression "spectrale" ne délivrerait pas les mêmes couleurs selon l'illuminant utilisé.

Conclusion messieurs les photographes, si vous voulez que les observateurs de vos tirages voient ce que vous voulez qu'ils voient, n'oubliez pas de leur demander de faire des tests de perception visuelle pour vous assurer qu'ils ne soient pas trop différents de vous ou de l'observateur standard, et préconisez leur un éclairage adapté, éventuellement, vendez leur l'éclairage avec le tirage :)
Pour finir, les essais que j'ai fait en gamma 2.2, moniteur calibré en hardware sur 14 bits, et liaison vidéo en 10 bits par canal, montrent qu'on ne voit aucun banding ni dans les noirs ni dans les dégradés de gris. La précision du système semble suffisante pour l'oeil humain. Ce n'est pas le cas si je passe la liaison vidéo en 8 bits par canal. Là on peut clairement voir apparaître un léger banding dans les dégradés, qu'ils soient gris, verts, rouges ou bleus. L'œil arrive donc à percevoir les sauts de valeur en 8 bits, tout du moins sur des dégradés monochromes. Je n'ai pas fait d'essais sur des dégradés passants d'une couleurs à une autre où je pense que le banding risque d'être moins flagrant.
Donc lorsqu'on recherche la perfection, et avant d'incriminer telle ou telle cible de calibration, profil ou système CMS, il me parait important de passer obligatoirement sur un moniteur à calibration hardware 12 ou 14 bits, et de s'assurer que les logiciels, la carte vidéo et l'écran sont capables d'afficher en 30 bits, soit 10 bits par canal. C'est à cette condition il me semble que vous pourrez juger du bien fondé ou non de telle ou telle cible de calibration. Sinon vous risquez bien d'être aveuglés par les défauts de quantification du système d'affichage. Désolé pour ceux qui possèdent des machines Apple, pas de 10 bits pour l'écran :( Mais du 16 bits pour l'impression :)

Citation de: olivier1010 le Septembre 15, 2015, 00:18:56
Comme l'expliquait très bien Pio2001, la courbe gamma utilisée pour la calibration écran ne devrait théoriquement pas avoir d'influence sur le résultat final, puisque le profil écran doit corriger les valeurs envoyées vers celui-ci afin de restituer une luminance et des couleurs dérivées d'un espace couleur de connexion commun aux divers périphériques qui si mes souvenirs sont bons est le CIE XYZ. Donc quelque soit la calibration écran, l'application à travers le profil d'écran devrait corriger pour afficher les bonnes couleurs et luminances. On ne devrait donc pas percevoir de différence entre une calibration L* et son profil associé, et une calibration gamma 2.2 et son profil associé.

Ben non ! L* et gamma 2.2  sont deux rendus à intention perceptive différente et le profil final rendra compte de ces intentions !!

oui c'est ce j'allais dire, d'autant que les différences d'affichage dans les très basses lumières entre L* et gamma 2.2 sont assez énormes, ce ne sont pas de simples petites erreurs d'interpolation ou autre, il y a véritablement un rendu différent pour ces valeurs. Sur l'image ci-dessous j'ai reproduit la différence, elle est quand même bien visible sur cet extrait  ;)

C Métairie

le fichier imprimé sur un bon papier baryté avec un profil sur mesure et compensation du point noir activée ressemble beaucoup plus à l'extrait gamma 2.2 que celui L*
NB: pour plus d'infos sur la compensation du point noir c'est ici: http://www.cmp-color.fr/BPC.html (http://www.cmp-color.fr/BPC.html)

C Métairie

Il serait peut être intéressant de faire un essai avec une calibration en tonecurve sRGB, qui théoriquement se rapproche de la perception de l'œil comme le L* est censé le faire.

Un fichier tonecurve sRGB est disponible sur ce site :

http://simon.tindemans.eu/cm/displaygamma

Citation de: restoc le Septembre 15, 2015, 08:10:56
Ben non ! L* et gamma 2.2  sont deux rendus à intention perceptive différente et le profil final rendra compte de ces intentions !!

Je ne suis pas de cet avis, le profil d'écran ne devrait pas avoir d'influence sur la sortie impression qui passe par un autre profil, qui lui est bidirectionnel. Table A2B pour la connexion de l'espace XYZ vers la sortie, et table B2A pour la connexion entre la sortie et le profil écran.

En quoi le profil écran et sa calibration associée devraient ils avoir une influence ? Je suis preneur pour des explications plus détaillées sur le mécanisme qui entraine une influence de ce profil écran.

le profil écran ne modifie pas la sortie papier qui est identique quel que soit le profil écran choisi, mais la correspondance entre l'écran et l'impression est plutôt bonne dans un cas ( écran en gamma 2.2 ) et assez fausse dans les très basses lumières quand l'écran est en L*

bonne idée, je vais tester la courbe tonale en sRGB , BasICColor Display 5 propose cette courbe directement dans le logiciel.

C Métairie

L  eccran plus lumineux artifiçiellement dans les basses lumieres pour travailler les ombres.
Soit repasser en 2.2 pour la correspondance avec l impression ou avoir le bon rip.
Ecran trop lumineux tirages trop sombres. Je suis d accord aussi avec la torture du matériel qui donne une mauvaise visualisation

Citation de: Christophe Métairie le Septembre 15, 2015, 08:55:15
oui c'est ce j'allais dire, d'autant que les différences d'affichage dans les très basses lumières entre L* et gamma 2.2 sont assez énormes, ce ne sont pas de simples petites erreurs d'interpolation ou autre, il y a véritablement un rendu différent pour ces valeurs. Sur l'image ci-dessous j'ai reproduit la différence, elle est quand même bien visible sur cet extrait  ;)

C Métairie

Merci Christophe pour ces clichés éclairants, si j'ose dire. J'observe aussi ces différences dans les ombres sur mon écran NEC entre L* et 2.2.
Ceci dit, je ne suis pas sûr de bien comprendre le problème. La TRC L* a été introduite précisément pour se rapprocher de la qualité de discernement de l'oeil humain, particulièrement performant dans les basses lumières, par rapport aux autres TRC, dont la gamma = 2.2 notamment. Mais les imprimantes peuvent-elles suivre à ce niveau dans les tons foncés et les noirs ? Je ne peux répondre à cette question, mon imprimante test étant un jouet d'enfant comparé aux imprimantes de course, Epson R3880 ou autre  :D

Je complète mon propos avec cette illustration des deux profils avec lesquels je travaille. En gris, celui de mon écran NEC étalonné (presque Adobe RGB). En couleur, celui de mon imprimante/papier/encre (réalisé par CMP  ;)).
On voit que les noirs sont à la traîne avec mon imprimante. Je ne sais ce qu'il en est des plus performantes.

l'utilisation de la compensation du point noir à l'impression permet d'adapter le point noir max de votre fichier a imprimer au noir max de votre système d'impression, donc même si votre papier n'a pas une Dmax énorme, le moteur de gestion des couleurs gère au mieux pour que les détails de votre fichier soient restitués même si ils sont en dessous du niveau de noir max de votre imprimante  ;)

j'ai pu refaire des profils écran ce matin en L*, sRGB et Gamma 2.2, testés dans photoshop sur un dégradé circulaire assez impitoyable, le rendu dans les ombres du sRGB est entre L* et gamma 2.2, avec un passage du noir pur au dégradé plus doux qu'en L* et Gamma 2.2.

vous pouvez vous fabriquer ce genre d'image pour tester le rendu de votre écran, c'est assez révélateur si il y a un problème! ( tiff 16 bits, dégradé circulaire du noir au blanc ).

C Métairie

je me suis amusé a faire une capture d'écran des courbes des différents profils dans les ombres:

on voit effectivement que chaque profil a des courbes et donc un rendu écran différent dans les ombres, pour le haut de la courbe c'est moins flagrant mais des différences existes aussi.

C Métairie

Citation de: PascalDespeaux le Septembre 14, 2015, 20:08:15
PS : Si vous voulez voir ce que donne un rendu en linéaire, donc sans gamma, il vous suffit dans C1 de mettre dans les courbes : Linear response, et vous verrez ce que cela donne..   :-\ Par contre ce type de rendu sert en étalonnage cinéma lorsque par exemple in applique une Lut sur les images que l'on développe avant donc en linéaire.

Oui mais non, car encore faut il que les profils fournis par C1 soient véritablement linéaires, ce qui n'est hélas pas le cas. Quand on veut véritablement avoir du linéaire dans C1 il faut se créer un profil maison, avec un logiciel comme Basiccolor Input par exemple. Avec un logiciel comme Iridient Developer (sous Mac mais dont l'équivalent est RawTherapy sous PC d'après ce que j'ai compris) vous pouvez aussi vous affranchir de la réponse tonale pour partir sur un vrai linéaire...Avec LR/ACR une solution devrait être commercialisée bientôt pour avoir des dcp linéaires...mais j'imagine que les profils fournis par CMP qui est est l'auteur de ce fil doivent l'être également. Travailler dans ce mode est un avantage énorme puisque l'on dispose ainsi de la maitrise complète sur la distribution tonale de sa photo en production.

Sinon pour en revenir au L* en ce qui me concerne je l'ai adopté il y a quelques mois maintenant et j'ai une meilleure correspondance écran/tirage dans mes ombres que le Gamma 2.2 enterrait un peu, en tout cas avec mon Eizo CG (en calibration via ColorNavigator). En ce qui me concerne et préparant actuellement une exposition, c'est une option de calibration très fiable que ce soit quand je procède moi même à mes tirages sur Epson ou via des prestataires spécialisés Fine Art.

Citation de: Benaparis le Septembre 15, 2015, 19:08:39
Oui mais non, car encore faut il que les profils fournis par C1 soient véritablement linéaires, ce qui n'est hélas pas le cas. Quand on veut véritablement avoir du linéaire dans C1 il faut se créer un profil maison, avec un logiciel comme Basiccolor Input par exemple. Avec un logiciel comme Iridient Developer (sous Mac mais dont l'équivalent est RawTherapy sous PC d'après ce que j'ai compris) vous pouvez aussi vous affranchir de la réponse tonale pour partir sur un vrai linéaire...Avec LR/ACR une solution devrait être commercialisée bientôt pour avoir des dcp linéaires...mais j'imagine que les profils fournis par CMP qui est est l'auteur de ce fil doivent l'être également. Travailler dans ce mode est un avantage énorme puisque l'on dispose ainsi de la maitrise complète sur la distribution tonale de sa photo en production.

Sinon pour en revenir au L* en ce qui me concerne je l'ai adopté il y a quelques mois maintenant et j'ai une meilleure correspondance écran/tirage dans mes ombres que le Gamma 2.2 enterrait un peu, en tout cas avec mon Eizo CG (en calibration via ColorNavigator). En ce qui me concerne et préparant actuellement une exposition, c'est une option de calibration très fiable que ce soit quand je procède moi même à mes tirages sur Epson ou via des prestataires spécialisés Fine Art.

Mais ton espace de travail est bien en L ?

Citation de: asak le Septembre 15, 2015, 19:21:21Mais ton espace de travail est bien en L ?

Oui Prostar ou ECI selon besoin respectivement en tirage fine art ou destination print. Cela dit à partir du moment où je n'intervient plus sur le fichier je ne suis pas certain que cela change quoi ce soit...les profils d'impression je suppose ne sont pas L*

Effectivement  nous avons probablement la meme config. Par contre colornavigator est en couleur native ou prostar ?

Citation de: Christophe Métairie le Septembre 15, 2015, 09:36:16
le profil écran ne modifie pas la sortie papier qui est identique quel que soit le profil écran choisi, mais la correspondance entre l'écran et l'impression est plutôt bonne dans un cas ( écran en gamma 2.2 ) et assez fausse dans les très basses lumières quand l'écran est en L*

bonne idée, je vais tester la courbe tonale en sRGB , BasICColor Display 5 propose cette courbe directement dans le logiciel.

C Métairie

Ok on est d'accord. Je pensais que vous aviez une différence à l'impression selon les profils écrans.

Il est logique que les courbes de calibration sRGB donnent un rendu intermédiaire. Reste à savoir pourquoi on obtient ces différences de rendu.

Les courbes gamma sont destinées à linéariser la liaison vidéo afin de profiter au mieux de la faible profondeur de quantification entre l'écran et le PC. Le profil écran qui tient compte de ces courbes gamma doit les décrire, et l'application doit en tenir compte pour au final avoir un rendu identique en théorie quelque soit la calibration adoptée, tout du moins sur du matériel haut de gamme supportant la calibration hardware et une liason PC / écran 30 bits.

Une explication probable de ces différences, est que Photoshop ne tient peut être pas compte de toutes les données du profil écran. Il ne lit peut être pas les courbe L* ou sRGB, il lit peut être simplement l'approximation gamma soit gamma 2.2, ce qui expliquerait les différences de luminosité dans les bas niveaux pour sRGB et L*, juste à l'endroit ou ces trois courbes diffèrent le plus.

Je ne suis même pas sur que ces courbes TRC sont toujours intégrées dans le profil écran. A ne pas confondre avec les tags vcgt qui sont les valeurs de calibration par la carte vidéo, également optionnelles. Il me semble de mémoire en tout cas pour ICCv2 que seules les valeurs gamma sont obligatoirement présentes en partenariat avec une simple matrice des primaires et que l'intégration est optionnelle. Si les courbes TRC ne sont pas présentes dans le profil ou pas lue par l'application il est logique qu'on obtienne des différences entre écran et impression selon la courbe de calibration choisie qui n'est donc connue dans ce cas que par l'écran mais pas par l'application qui a la responsabilité d'envoyer des données corrigées à l'écran à travers son profil.

Sinon si vous tenez réellement à utiliser L*, ce qui me semble un peu inutile puisque vous avez certainement un écran haut de gamme à calibration hardware et liaison 30 bits, vous pouvez toujours compenser l'affichage en mode aperçu d'épreuve en modifiant légèrement la table de correspondance inverse (B2A) du profil d'impression afin de faire concorder avec l'écran. C'est un peu du bricolage mais cela devrait marcher...

Le plus simple est peut être de rester en gamma 2.2... Puisque si votre écran est en 30 bits le L* ne devrait pas donner d'avantages notables en terme de précision de luminosité dans les basses lumières, sachant que les différences sont quand même faibles entre L* et gamma 2.2 : je pense qu'elles sont pratiquement gommées par le passage en 30 bits qui doit permettre avec une calibration en gamma 2.2 d'afficher toutes les valeurs que L* pourrait afficher sur une liaison 24 bits (un matheux pourrait il nous dire le delta maxi de pourcentage en luminance entre ces deux setups ?)

Je suis tout de même curieux de connaître la raison réelle de ces différences qui ne devraient pas exister avec un écran à calibration hardware 14 bits et une liaison vidéo 30 bits. Il faudrait peut être essayer avec un logiciel dont on est certain qu'il tient prend bien en compte les courbes TRC lors de la lecture du profil écran.

Je viens juste de vérifier que le mode écran 30 bits reste bien actif quand on passe en aperçu d'épreuve, et c'est bien le cas. Donc le problème ne vient pas de là (j'ai eu un doute à un moment).

.

Citation de: olivier1010 le Septembre 15, 2015, 20:17:46
Ok on est d'accord. Je pensais que vous aviez une différence à l'impression selon les profils écrans.

Il est logique que les courbes de calibration sRGB donnent un rendu intermédiaire. Reste à savoir pourquoi on obtient ces différences de rendu.

Les courbes gamma sont destinées à linéariser la liaison vidéo afin de profiter au mieux de la faible profondeur de quantification entre l'écran et le PC. Le profil écran qui tient compte de ces courbes gamma doit les décrire, et l'application doit en tenir compte pour au final avoir un rendu identique en théorie quelque soit la calibration adoptée, tout du moins sur du matériel haut de gamme supportant la calibration hardware et une liason PC / écran 30 bits.

Une explication probable de ces différences, est que Photoshop ne tient peut être pas compte de toutes les données du profil écran. Il ne lit peut être pas les courbe L* ou sRGB, il lit peut être simplement l'approximation gamma soit gamma 2.2, ce qui expliquerait les différences de luminosité dans les bas niveaux pour sRGB et L*, juste à l'endroit ou ces trois courbes diffèrent le plus.

Je ne suis même pas sur que ces courbes TRC sont toujours intégrées dans le profil écran. A ne pas confondre avec les tags vcgt qui sont les valeurs de calibration par la carte vidéo, également optionnelles. Il me semble de mémoire en tout cas pour ICCv2 que seules les valeurs gamma sont obligatoirement présentes en partenariat avec une simple matrice des primaires et que l'intégration est optionnelle. Si les courbes TRC ne sont pas présentes dans le profil ou pas lue par l'application il est logique qu'on obtienne des différences entre écran et impression selon la courbe de TRC choisie qui n'est donc connue dans ce cas que par l'écran mais pas par l'application qui a la responsabilité d'envoyer des données corrigées à l'écran à travers son profil.

Sinon si vous tenez réellement à utiliser L*, ce qui me semble un peu inutile puisque vous avez certainement un écran haut de gamme à calibration hardware et liaison 30 bits, vous pouvez toujours compenser l'affichage en mode aperçu d'épreuve en modifiant légèrement la table de correspondance inverse (B2A) du profil d'impression afin de faire concorder avec l'écran. C'est un peu du bricolage mais cela devrait marcher...

Le plus simple est peut être de rester en gamma 2.2... Puisque si votre écran est en 30 bits le L* ne devrait pas donner d'avantages notables en terme de précision de luminosité dans les basses lumières, sachant que les différences sont quand même faibles entre L* et gamma 2.2 : je pense qu'elles sont pratiquement gommées par le passage en 30 bits qui doit permettre avec une calibration en gamma 2.2 d'afficher toutes les valeurs que L* pourrait afficher sur une liaison 24 bits (un matheux pourrait il nous dire le delta maxi de pourcentage en luminance entre ces deux setups ?)

Je suis tout de même curieux de connaître la raison réelle de ces différences qui ne devraient pas exister avec un écran à calibration hardware 14 bits et une liaison vidéo 30 bits. Il faudrait peut être essayer avec un logiciel dont on est certain qu'il tient prend bien en compte les courbes TRC lors de la lecture du profil écran.

Je viens juste de vérifier que le mode écran 30 bits reste bien actif quand on passe en aperçu d'épreuve, et c'est bien le cas. Donc le problème ne vient pas de là (j'ai eu un doute à un moment).

Citation de: asak le Septembre 15, 2015, 19:51:13
Effectivement  nous avons probablement la meme config. Par contre colornavigator est en couleur native ou prostar ?

Couleur Native...je serai bien curieux de connaître, pour le domaine de la photo, de l'intérêt travailler en terme de gamut autrement qu'avec les capacités propres du moniteurs.

Avoir la meme courbe de réponse que l espace de travàil.

Citation de: asak le Septembre 15, 2015, 20:47:22Avoir la meme courbe de réponse que l espace de travàil.

Mais un gamut n'est pas une courbe de réponse...La courbe de réponse de mon moniteur est bien L* en revanche le gamut est bien "natif" pour utiliser toute la capacité couleur du moniteur (en l'occurence proche du Adobe), si vous utilisez ColorNavigator le distinguo est assez clair.

J étais comme toi il n y a pas longtemps. En changeant j ai trouvé que ça me semblais  plus juste notamment en faisant une BdB mais je n ai pas encore quantifié .

Citation de: asak le Septembre 15, 2015, 21:26:10J étais comme toi il n y a pas longtemps. En changeant j ai trouvé que ça me semblais  plus juste notamment en faisant une BdB mais je n ai pas encore quantifié .

Ça me paraît très bizarre...en plus je ne vois pas le rapport avec la balance des blancs...ce qui m'a donné des balances de blancs impeccable c'est d'avoir réalisé un bon profil boîtier...ce qui a du sens.

Je ne suis pas un spécialiste mais encore encore fois j'insiste je ne suis pas du tout sûr et ce d'autant que je ne vois rien qui justifie, pour la photo en tout cas, de choisir un gamut différent du gamut natif de l'écran.

Citationle delta maxi de pourcentage en luminance

Le delta c'est bien le end-to-end gamma ? (je viens de la video, hein) donc pour un gamma de 2.2 il faudrait qu'il soit entre 1.1 et 1.2, non ?
et pour le print vers 1.4 ?

Ensuite concernant les détails purement mathématiques il est préférable d'aller jeter un œil ici : https://fr.wikipedia.org/wiki/Loi_de_Weber-Fechner
Et pour les geek ici : http://www.normankoren.com/makingfineprints1A.html#QuickGamma

J'en profite pour poser la question du candide : j'avais cru comprendre que le gamut était un terme qui décrivait l'ensemble des couleurs reproductibles par un périphérique (un écran, par exemple). Voir définition WikiPédia ci-dessous :

"En synthèse des couleurs, synthèse additive ou synthèse soustractive, le gamut, ou gamut de couleur est la partie de l'ensemble des couleurs qu'un certain type de matériel, qu'il soit appareil photographique, scanner informatique, écran d'ordinateur, rétroprojecteur, vidéoprojecteur, procédé d'imprimerie ou imprimante, permet de reproduire."
Quand on parle de gamut 2.2 ou 1.8, il s'agit bien d'autre chose, n'est-ce pas ?

Plutôt lié à une courbe de réponse ?
Merci d'éclairer ma lanterne...
(c'est une vraie question, hein !  ;-)

Citation de: asak le Septembre 15, 2015, 20:47:22
Avoir la meme courbe de réponse que l espace de travàil.

Dans quel but ? Il est parfois utile d'utiliser un gamma de 1.0 pour améliorer la qualité de certains traitements. Tout dépend de ce qu'on a à faire.

Les systèmes CMS permettent justement de faire correspondre des espaces couleurs avec des gamuts et gamma différents, avec en plus la possibilité de choisir le rendu lorsque les couleurs sortent du gamut, ou même forcer la correspondance pour une colorimétrie absolue, ce qui est utile dans le domaine du textile par exemple si on veut une correspondance parfaite entre les tissus et les impressions. Ils permettent aussi d'adapter les contrastes avec l'adaptation du point noir.

En ce qui concerne les courbes de calibration écran, elles servent à utiliser au mieux la liaison vidéo de faible profondeur de quantification, en pratique 8 ou 10 bits par canal. Il faut donc choisir une courbe qui s'approche de celle de la vision humaine pour obtenir un espace couleur de visualisation le plus homogène possible.

Les différences sont faibles entre L* et gamma 2.2. Et comme je le disais sont certainement gommées par la possibilité d'attaquer aujourd'hui les écrans en 10 bits par canal.

Je pense que le L* n'a plus tellement sa raison d'être aujourd'hui en 10 bits par canal, surtout s'il pose des problèmes avec les logiciels comme cela semble être le cas ici. Cela changera peut être à l'avenir pour le Rec2020 qui est un espace plus large où 10 bits redeviendra un peu juste et ou il faudra donc peut être adopter à nouveau un gamma plus évolué que le 2.2 pour retrouver une bonne homogénéité. Idéalement en Rec2020 il faudra certainement passer en 12 bits par canal sur les configurations haut de gamme, ce qui est d'ailleurs prévu dans la nouvelle norme HDMI 2.0a.

Je dirais que le L* n'a sa raison d'être que sur les écrans à calibration hardware 12 ou 14 bits, et lorsque la liaison vidéo est en 8 bits. A condition que les logiciels sachent l'interpréter, ce qui visiblement n'est pas toujours le cas.

Citation de: Verso92 le Septembre 15, 2015, 21:41:19
J'en profite pour poser la question du candide : j'avais cru comprendre que le gamut était un terme qui décrivait l'ensemble des couleurs reproductibles par un périphérique (un écran, par exemple). Voir définition WikiPédia ci-dessous :

"En synthèse des couleurs, synthèse additive ou synthèse soustractive, le gamut, ou gamut de couleur est la partie de l'ensemble des couleurs qu'un certain type de matériel, qu'il soit appareil photographique, scanner informatique, écran d'ordinateur, rétroprojecteur, vidéoprojecteur, procédé d'imprimerie ou imprimante, permet de reproduire."
Quand on parle de gamut 2.2 ou 1.8, il s'agit bien d'autre chose, n'est-ce pas ?

Plutôt lié à une courbe de réponse ?
Merci d'éclairer ma lanterne...
(c'est une vraie question, hein !  ;-)

Alors, espace de couleurs ou gamut ?! ;)

At  olivier 1010
Ce n est pas moi qui te donnerai tord; mais entre photoshop et colornavgator dis moi que c est compatible CMS à mon avis non mais si tu as les info .

Citation de: Verso92 le Septembre 15, 2015, 21:41:19
J'en profite pour poser la question du candide : j'avais cru comprendre que le gamut était un terme qui décrivait l'ensemble des couleurs reproductibles par un périphérique (un écran, par exemple). Voir définition WikiPédia ci-dessous :

"En synthèse des couleurs, synthèse additive ou synthèse soustractive, le gamut, ou gamut de couleur est la partie de l'ensemble des couleurs qu'un certain type de matériel, qu'il soit appareil photographique, scanner informatique, écran d'ordinateur, rétroprojecteur, vidéoprojecteur, procédé d'imprimerie ou imprimante, permet de reproduire."
Quand on parle de gamut 2.2 ou 1.8, il s'agit bien d'autre chose, n'est-ce pas ?

Plutôt lié à une courbe de réponse ?
Merci d'éclairer ma lanterne...
(c'est une vraie question, hein !  ;-)

On parle de gamma 2.2 qui est la courbe de réponse tonale.

Citation de: Verso92 le Septembre 15, 2015, 21:41:19
J'en profite pour poser la question du candide : j'avais cru comprendre que le gamut était un terme qui décrivait l'ensemble des couleurs reproductibles par un périphérique (un écran, par exemple). Voir définition WikiPédia ci-dessous :

"En synthèse des couleurs, synthèse additive ou synthèse soustractive, le gamut, ou gamut de couleur est la partie de l'ensemble des couleurs qu'un certain type de matériel, qu'il soit appareil photographique, scanner informatique, écran d'ordinateur, rétroprojecteur, vidéoprojecteur, procédé d'imprimerie ou imprimante, permet de reproduire."
Quand on parle de gamut 2.2 ou 1.8, il s'agit bien d'autre chose, n'est-ce pas ?

Plutôt lié à une courbe de réponse ?
Merci d'éclairer ma lanterne...
(c'est une vraie question, hein !  ;-)

Le gamma (appellation de la courbe de réponse des tubes cathodiques Sortie = entrée ^ gamma) ou TRC ( Tonal Response Curve) correspond à une courbe de réponse.
Le gamut correspond à un "volume" de couleurs affichables ou imprimables. (http://www.chassimages.com/forum/index.php/topic,95384.msg1639591.html#msg1639591 (http://www.chassimages.com/forum/index.php/topic,95384.msg1639591.html#msg1639591) ;))
C'est bien, 2 caractéristiques bien différentes.

Citation de: ambre099 le Septembre 15, 2015, 22:21:54
On parle de gamma 2.2 qui est la courbe de réponse tonale.

Citation de: MBe le Septembre 15, 2015, 22:22:28
Le gamma (appellation de la courbe de réponse des tubes cathodiques Sortie = entrée ^ gamma) ou TRC ( Tonal Response Curve) correspond à une courbe de réponse.
Le gamut correspond à un "volume" de couleurs affichables ou imprimables. (http://www.chassimages.com/forum/index.php/topic,95384.msg1639591.html#msg1639591 (http://www.chassimages.com/forum/index.php/topic,95384.msg1639591.html#msg1639591) ;))
C'est bien, 2 caractéristiques bien différentes.

Oups, désolé : j'ai fait une confusion malencontreuse entre les deux termes (la fatigue ?)... merci de m'avoir remis dans le droit chemin !

;-)

Salut,

Sinon la question ou plutôt le soucis du L* c'est quoi au final?

Citation de: Verso92 le Septembre 15, 2015, 22:38:12
Oups, désolé : j'ai fait une confusion malencontreuse entre les deux termes (la fatigue ?)... merci de m'avoir remis dans le droit chemin !

;-)

Non non pas la fatigue, tu avais bien lu  ;)

Citation de: Christophe Métairie le Septembre 15, 2015, 17:51:07
je me suis amusé a faire une capture d'écran des courbes des différents profils dans les ombres:

Les courbes de TRC tracées  (il n'y a pas le sRGB)

La zone de basses lumières ou vous constatez un écart :

Citation de: Christophe Métairie le Septembre 15, 2015, 09:36:16
oui Mbe, en fait je m'aperçois que j'ai inversé les 2 rendus dans ma question ( le rendu écran en L* est plus lumineux que le Gamma 2.2 ), mais le problème reste le même : la correspondance écran tirage est meilleure avec un écran en gamma 2.2  Clin d'oeil

comme quoi une question toute simple a priori donne un débat intéressant, et selon l'utilisation que l'on a des ses images certains préfèrent un écran en L* , d'autres en gamma 2.2 ...

C Métairie

Je comprends mieux.

Avec un TRC L*, dans les basses lumières, la progression est plus linéaire, en limitant les aplats (si il est possible de les voir).

Citation de: Christophe Métairie le Septembre 15, 2015, 09:36:16
le profil écran ne modifie pas la sortie papier qui est identique quel que soit le profil écran choisi, mais la correspondance entre l'écran et l'impression est plutôt bonne dans un cas ( écran en gamma 2.2 ) et assez fausse dans les très basses lumières quand l'écran est en L*
C Métairie

Je suis bien d'accord avec cette assertion.

Quelques questions / commentaires
- Avec un profil d'affichage en L*, il est préférable de travailler dans espace de travail avec un TRC  L* ou de finaliser dans tiff avec un profil L* afin de garder la cohérence.
- La compensation du point noir modifie la dynamique du fichier, est ce qu'il ne participe pas à ce défaut de correspondance? (j'avoue que j'utilise quasiment jamais cette correspondance, trouvant bien souvent que l'effet de rendu globale sur une image est trop fade avec cette compensation)

Autre réflexion : Un tracé du codage du L* du profil icc de l'écran comparé à la version théorique serait peut être instructif (?)

Donc l écran ne code pas le TIFF mais l espace de travail choisi+le profil icc d export "image" + profil icc d imprimante.
Le soucis de dégradation 10, 8 bits... N'est qu'une dégradation d affichage et non de codage du fichier TIFF?

J'ai bon ou pas?

Vous avez un ensemble hardware 30bits....etc, vous traiter un TIFF avec un joli dégradé de gris perfecto que vous visualisez de manière parfaite et vous m'envoyer ce fichier.

Moi je l'ouvre dans Photoshop avec le même espace de travail sur un écran pourri mais je l'imprime avec le même matos que vous sans rien touché, j'ai le même résultat ou pas?

Pour Christophe Metairie :
Est ce que votre profil d'écran (en L*) comporte une balise vcgt? si oui, est ce bien une droite?

Citation de: MBe le Septembre 15, 2015, 23:55:27
Pour Christophe Metairie :
Est ce que votre profil d'écran (en L*) comporte une balise vcgt? si oui, est ce bien une droite?

Je vois où vous voulez en venir, pour rappel cette balise est utilisée pour charger une table LUT de calibration dans la carte vidéo afin de modifier les valeurs RVB envoyées vers l'écran (calibration par la carte vidéo).

Effectivement si ces courbes ne sont pas des droites, avec un écran à calibration hardware, il y aurait une double calibration, ce qui fausse tout.

Avec Colornavigator sur un écran EIZO, les courbes VCGT évidement sont des droites (codées en 16 bits), je l'ai vérifié avec l'utilitaire gretag pour ouvrir les tables vcgt. Il existe un utilitaire encore plus pointu dans displaycalgui qui permet de voir au choix les courbes VCGT du profil, ou celles réellement chargées dans la carte vidéo pour chaque écran. Dans les deux cas elles sont droites ce qui est normal en calibration hardware et ne doit pas en être autrement.

D'autre part ce serait un non sens d'utiliser ces courbes pour lire le gamma exact du profil, puisque ces courbes VCGT ne sont pas les courbes tonales théoriques, mais les courbes nécessaires à la calibration de l'écran, elles sont donc différentes des courbes théoriques L* ou gamma 2.2.
Moi je pense que Photoshop ne tient peut être pas compte de la courbe L* ou sRGB du profil et affiche simplement en gamma 2.2 avec les calibration L* ou sRGB.

Ce gamma 2.2 est peut être écrit dans le profil écran pour chaque canal R, V et B, en tant qu'approximation pour les logiciels qui ne vont pas plus loin dans la lecture du profil. Et aussi historiquement pour la rétrocompatibilité car le gamma des trois canaux R,V et B si mes souvenirs sont bons étaient pratiquement les seules valeurs disponibles avec les coordonnées xy des primaires pour un profil écran dans les débuts des CMS.

Il serait intéressant de basculer sur le CMS microsoft, dans Photoshop, pour voir s'il y a un comportement différent. Et tester également avec d'autres applications, par exemple rawtherapee.

Une question pour Christophe, quels sont les versions icc des profils d'écran et d'impression ? V2 ou V4 ? Il serait intéressant d'essayer avec un profil d'écran V4 si vous êtes en V2 ou vice versa. Et également de modifier manuellement la table B2A du profil d'impression pour voir si vous arrivez à rattraper ces écarts de luminosité avec le profil écran L* sans détruire le reste des correspondances au niveau colorimétrie. Pour rappel la table B2A est celle dans un profil V4 qui gère la correspondance entre l'image imprimée et l'affichage écran. Elle ne modifie en rien l'image imprimée, qui est elle gérée par la table A2B.

Sinon je pense que le but du L* à l'époque de son apparition était d'homogénéiser les couleurs écran dans le cadre d'une liaison vidéo minimaliste en 8 bits par canal, tout juste suffisante pour passer sans trop de banding un espace sRGB ou plus difficilement AdobeRGB. L'augmentation de luminance est plus à mon avis une conséquence fâcheuse de certains logiciels qui ne savent pas compenser pour le L* car ils se basent peut être sur un gamma 2.2 qui est l'approximation la plus proche.

Puis est arrivé le 10 bits, qui permet d'afficher un adobeRGB parfaitement lisse avec une simple calibration (hardware tout de même) gamma 2.2. Si on regarde ce que fait Eizo, leur réglage par défaut est gamma 2.2 pour le mode photo. Une remarque qui n'engage que moi : si L* était vraiment utile et sans faille coté implémentation, on le verrait plus souvent sur des systèmes très haut de gamme dans les réglages par défaut.

Si l'on regarde ce qu'il se passe dans colornavigator 6 lorsqu'on choisit une cible avec une courbe L*, il devient impossible de sélectionner "gamma" dans les options d'écriture du profil, seule la table LUT est disponible pour la caractérisation des courbes de tons pour la génération d'un profil V2, et idem pour la génération d'un profil V4 avec en plus la possibilité de générer une courbe paramétrique, ce qui est d'ailleurs une grosse nouveauté dans les profils en V4. L'option "gamma" est une simple écriture de trois valeurs gamma dans le profil, une pour chaque canal, à l'ancienne :)

Le tout est de savoir si les logiciels utilisés sont capables de lire ces tables LUT ou ces courbes paramétriques, et si non sur quoi ils se basent pour les courbes tonales, il faudrait regarder à l'intérieur d'un profil mais je pense que lorsqu'un logiciel de calibration écrit un profil écran avec des tables LUT pour décrire les trois gradations tonales de L* ou sRGB, il écrit également pour rétrocompatibilité une valeur gamma approchante, soit 2.2 pour L* et sRGB. C'est peut être cette valeur 2.2 qui est prise en compte par Photoshop au lieu des vrais valeurs de correspondances tonales écrites dans les courbes LUT caractérisant L* dans un profil d'écran V2 ou V4.

il serait intéressant également de générer des profils V4 avec description des courbes tonales par équations paramétriques, et de voir les réactions de Photoshop et des autres logiciels.

Je vois où vous voulez en venir, pour rappel cette balise est utilisée pour charger une table LUT de calibration dans la carte vidéo afin de modifier les valeurs RVB envoyées vers l'écran (calibration par la carte vidéo).

Effectivement si ces courbes ne sont pas des droites, avec un écran à calibration hardware, il y aurait une double calibration, ce qui fausse tout.

Avec Colornavigator sur un écran EIZO, les courbes VCGT évidement sont des droites (codées en 16 bits), je l'ai vérifié avec l'utilitaire gretag pour ouvrir les tables vcgt. Il existe un utilitaire encore plus pointu dans displaycalgui qui permet de voir au choix les courbes VCGT du profil, ou celles réellement chargées dans la carte vidéo pour chaque écran. Dans les deux cas elles sont droites ce qui est normal en calibration hardware et ne doit pas en être autrement.

D'autre part ce serait un non sens d'utiliser ces courbes pour lire le gamma exact du profil, puisque ces courbes VCGT ne sont pas les courbes tonales théoriques, mais les courbes nécessaires à la calibration de l'écran, elles sont donc différentes des courbes théoriques L* ou gamma 2.2.
Moi je pense que Photoshop ne tient peut être pas compte de la courbe L* ou sRGB du profil et affiche simplement en gamma 2.2 avec les calibration L* ou sRGB.

Ce gamma 2.2 est peut être écrit dans le profil écran pour chaque canal R, V et B, en tant qu'approximation pour les logiciels qui ne vont pas plus loin dans la lecture du profil. Et aussi historiquement pour la rétrocompatibilité car le gamma des trois canaux R,V et B si mes souvenirs sont bons étaient pratiquement les seules valeurs disponibles avec les coordonnées xy des primaires pour un profil écran dans les débuts des CMS.

Il serait intéressant de basculer sur le CMS microsoft, dans Photoshop, pour voir s'il y a un comportement différent. Et tester également avec d'autres applications, par exemple rawtherapee.

Une question pour Christophe, quels sont les versions icc des profils d'écran et d'impression ? V2 ou V4 ? Il serait intéressant d'essayer avec un profil d'écran V4 si vous êtes en V2 ou vice versa. Et également de modifier manuellement la table B2A du profil d'impression pour voir si vous arrivez à rattraper ces écarts de luminosité avec le profil écran L* sans détruire le reste des correspondances au niveau colorimétrie. Pour rappel la table B2A est celle dans un profil V4 qui gère la correspondance entre l'image imprimée et l'affichage écran. Elle ne modifie en rien l'image imprimée, qui est elle gérée par la table A2B.

Sinon je pense que le but du L* à l'époque de son apparition était d'homogénéiser les couleurs écran dans le cadre d'une liaison vidéo minimaliste en 8 bits par canal, tout juste suffisante pour passer sans trop de banding un espace sRGB ou plus difficilement AdobeRGB. L'augmentation de luminance est plus à mon avis une conséquence fâcheuse de certains logiciels qui ne savent pas compenser pour le L* car ils se basent peut être sur un gamma 2.2 qui est l'approximation la plus proche.

Puis est arrivé le 10 bits, qui permet d'afficher un adobeRGB parfaitement lisse avec une simple calibration (hardware tout de même) gamma 2.2. Si on regarde ce que fait Eizo, leur réglage par défaut est gamma 2.2 pour le mode photo. Une remarque qui n'engage que moi : si L* était vraiment utile et sans faille coté implémentation, on le verrait plus souvent sur des systèmes très haut de gamme dans les réglages par défaut.

Si l'on regarde ce qu'il se passe dans colornavigator 6 lorsqu'on choisit une cible avec une courbe L*, il devient impossible de sélectionner "gamma" dans les options d'écriture du profil, seule la table LUT est disponible pour la caractérisation des courbes de tons pour la génération d'un profil V2, et idem pour la génération d'un profil V4 avec en plus la possibilité de générer une courbe paramétrique, ce qui est d'ailleurs une grosse nouveauté dans les profils en V4. L'option "gamma" est une simple écriture de trois valeurs gamma dans le profil, une pour chaque canal, à l'ancienne :)

Le tout est de savoir si les logiciels utilisés sont capables de lire ces tables LUT ou ces courbes paramétriques, et si non sur quoi ils se basent pour les courbes tonales, il faudrait regarder à l'intérieur d'un profil mais je pense que lorsqu'un logiciel de calibration écrit un profil écran avec des tables LUT pour décrire les trois gradations tonales de L* ou sRGB, il écrit également pour rétrocompatibilité une valeur gamma approchante, soit 2.2 pour L* et sRGB. C'est peut être cette valeur 2.2 qui est prise en compte par Photoshop au lieu des vrais valeurs de correspondances tonales écrites dans les courbes LUT caractérisant L* dans un profil d'écran V2 ou V4.

il serait intéressant également de générer des profils écran V4 avec description des courbes tonales par équations paramétriques, et de voir les réactions de Photoshop et des autres logiciels à cette nouveauté des V4.

Citation de: fred94- le Septembre 15, 2015, 23:38:22
Donc l écran ne code pas le TIFF mais l espace de travail choisi+le profil icc d export "image" + profil icc d imprimante.

Les couleurs contenues dans le TIFF seront codées de façon différente suivant l'espace de couleur choisi (les différences seront d'autant plus importantes que les couleurs seront en limite de gamut).
L'écran affichera l'image en fonction de son profil icc propre (correction de ses défauts d'affichage) et le logiciel permettra, dans le cas d'un épreuvage, de simuler le rendu du papier choisi (via le profil icc imprimante + encre + papier).

Citation de: fred94- le Septembre 15, 2015, 23:38:22
Le soucis de dégradation 10, 8 bits... N'est qu'une dégradation d affichage et non de codage du fichier TIFF?

Oui, bien sûr : dans certains cas, l'affichage en 3 x 10 bits permettra de limiter les cassures dans les fins dégradés visualisées à l'écran par rapport à un affichage en 3 x 8 bits.

Citation de: fred94- le Septembre 15, 2015, 23:38:22
Vous avez un ensemble hardware 30bits....etc, vous traiter un TIFF avec un joli dégradé de gris perfecto que vous visualisez de manière parfaite et vous m'envoyer ce fichier.

Moi je l'ouvre dans Photoshop avec le même espace de travail sur un écran pourri mais je l'imprime avec le même matos que vous sans rien touché, j'ai le même résultat ou pas?

Même si tu n'as pas le même espace de travail (ça ne changera que la visualisation, sauf si conversion de ta part), tu auras le "même" résultat à l'impression (sous réserve que tu utilises le même matériel pour imprimer avec les mêmes profils d'impression).

Il serait bon de vérifier que photoshop donne bien un gris rvb à 128 et TSL a 50 avant de wspéculer  ;)

Citation de: asak le Septembre 16, 2015, 09:05:31
Il serait bon de vérifier que photoshop donne bien un gris rvb à 128 et TSL a 50 avant de wspéculer  ;)

A partir du moment où vous utilisez un espace de travail où un profil d'image qui est en L* (Prostar ou eciRGBv2 par exemple) vous pouvez être certain que ce sera le cas...Cela n'a rien à voir avec l'affichage à l'écran...à ce moment là ce n'est plus la pipette qu'il faut utiliser mais un spectromètre  ;)

Je pense que vous faites la confusion entre les espaces travail et l'affichage du moniteur à proprement parler.

Citation de: Benaparis le Septembre 16, 2015, 09:28:31
A partir du moment où vous utilisez un espace de travail où un profil d'image qui est en L* (Prostar ou eciRGBv2 par exemple) vous pouvez être certain que ce sera le cas...Cela n'a rien à voir avec l'affichage à l'écran...à ce moment là ce n'est plus la pipette qu'il faut utiliser mais un spectromètre  ;)

Je pense que vous faites la confusion entre les espaces travail et l'affichage du moniteur à proprement parler.

Non je ne fais pas de confusion  :D Je m'adresse à ceux qui calent leur écran en L et qui ne sont pas en espace L  ;) C'est un moyen de vérifier et qui peu expliquer le pourquoi du comment de certains écarts   :D

Citation de: asak le Septembre 16, 2015, 10:00:37
Non je ne fais pas de confusion  :D Je m'adresse à ceux qui calent leur écran en L et qui ne sont pas en espace L  ;) C'est un moyen de vérifier et qui peu expliquer le pourquoi du comment de certains écarts   :D

Au temps pour moi 😉

Citation de: asak le Septembre 16, 2015, 10:00:37
Non je ne fais pas de confusion  :D Je m'adresse à ceux qui calent leur écran en L et qui ne sont pas en espace L  ;) C'est un moyen de vérifier et qui peu expliquer le pourquoi du comment de certains écarts   :D

Vu le niveau des intervenants , cela me semblait évident ...

Quoi que ...

;D

Citation de: asak le Septembre 16, 2015, 10:00:37
Non je ne fais pas de confusion  :D Je m'adresse à ceux qui calent leur écran en L et qui ne sont pas en espace L  ;) C'est un moyen de vérifier et qui peu expliquer le pourquoi du comment de certains écarts   :D

Ouf alors?   ;D

Citation de: fred94- le Septembre 15, 2015, 23:38:22
Vous avez un ensemble hardware 30bits....etc, vous traiter un TIFF avec un joli dégradé de gris perfecto que vous visualisez de manière parfaite et vous m'envoyer ce fichier.

Moi je l'ouvre dans Photoshop avec le même espace de travail sur un écran pourri mais je l'imprime avec le même matos que vous sans rien touché, j'ai le même résultat ou pas?

Une mauvaise visualisation sur écran (soft proofing ou profil d'épreuve) n'a aucune incidence sur l'impression à condition que ce soit le même fichier et qu'on l'envoie sur la même imprimante avec le même profil.

Il me vient une idée permettant à coup sur de déterminer si Photoshop prend correctement en compte la courbe tonale L* à l'affichage : créer un leurre, un profil écran incluant pour chaque canal RVB :

- les valeurs gamma 1.0, 1.0, 1.0

- trois courbes LUT L*
Si Photoshop sait lire les courbes LUT du profil, il affichera correctement l'image. Sinon il affichera une image complétement délavée croyant que l'écran est en gamma 1.0. Valeur qu'il aura été chercher dans la matrice de base du profil au lieu de lire les courbes LUT.

Faire cet essai en générant un profil V2 et un V4, les deux formats prenant en charge les LUT (le V4 permet aussi de prendre en charge une description de courbe tonale par équation paramétrique).

Evidement il faudra bricoler à la main dans le profil car je doute qu'il soit possible de générer un tel profil avec une application de gestion de profil. Cela dit modifier les trois valeurs de gamma doit être simple avec un éditeur hexa, si tant est qu'il ne faille pas recréer une clé de hachage pour le fichier. Ce qui ne semble pas être le cas après vérification rapide dans le standard icc v4.

En regardant dans la spécification icc V4 en page 27, je m'aperçois comme je le pensais qu'un profil peut contenir optionnellement un tag gamutTag lorsqu'il contient déjà des courbes LUT pour décrire les courbes tonales.

http://www.color.org/specification/ICC1v43_2010-12.pdf

Je m'aperçois également de cela :

In addition to the tags listed in 8.2 an N-component LUT-based Input profile shall contain the following tags:  
⎯  AToB0Tag (see 9.2.1);
⎯  BToA0Tag (see 9.2.6).

Le profil devrait donc contenir en plus du gamma et des courbes LUT non seulement une table de transformation couleur de A vers B en rendu perception, mais aussi de B vers A dont je ne vois pas trop l'utilité pour un profil écran. Elle doit être là parce qu'un profil écran peut être utilisé pour autre chose qu'un écran puisque c'est un profil RGB standard.

Si l'application prend en charge uniquement cette table de transformation pour corriger la luminance de l'affichage, et si cette table ne contient pas assez de patchs dans les bas niveaux, ce qui me semble être le cas dans les réglages standards des logiciels de calibration écran où l'on a généralement environ 50 patchs, alors on peut raisonnablement penser que le rendu ne sera très précis en terme de luminance. Cela pourrait expliquer ces différences de rendu en luminance entre L* et gamma 2.2.
Pour vérifier cette hypothèse, il suffirait de générer un profil écran avec 30 ou 40 patchs en niveaux de gris en plus des patchs couleurs, pour être sur que la correspondance par rapport à la courbe tonale théorique serait bien respectée. Dans le cas d'une application qui ne s'aiderait pas des courbes LUT pour établir une correspondance exacte en terme de luminance, mais se baserait uniquement sur la table de correspondance couleur AToB0Tag.

Ces tables de correspondance couleurs peuvent d'ailleurs être codées au choix  en 8 ou 16 bits, ce qui peut influer sur la précision du résultat final, mais il me semble que tout est passé en 16 bits dans les logiciels de génération de profil depuis longtemps. Egalement les différences qu'on voit sur l'exemple de Christophe, facilement visibles, sont certainement supérieures aux différences qu'on pourrait avoir en passant de tables LUT 8 bits à des tables 16 bits. Il faudrait vérifier dans les profils générés mais je suis presque sur que toutes les LUT sont aujourd'hui en 16 bits.

Deux choses à prendre en compte si vous tentez de réaliser ce type de profil écran très précis avec 30 ou 40 patchs en niveaux de gris : il faut absolument utiliser du matériel haut de gamme pour éviter de mettre en évidence des défauts qui seraient induits par le hardware :

- écran stable à calibration hardware et compensation en température

- liaison avec l'écran en 10 bits par canal (utilisation du Display Port obligatoire pour les ecrans Eizo, carte vidéo supportant ce mode, mode 30 bits activé dans le driver de la carte vidéo)

- logiciel de profilage prenant en charge la liaison vidéo en 10 bits par canal pour afficher les patchs (oui on ne pense pas forcément à vérifier ça !)

- générer des tables LUT en 16 bits dans le profil écran (ce qui doit être toujours le cas je pense car ce réglage n'est même plus disponible dans les logiciels de création de profil écran)

- et enfin utiliser un colorimètre écran haut de gamme corrigé en température, surtout pas un spectro qui a une mauvaise précision dans les noirs et produirait un résultat pouvant aller jusqu'au désastreux dans l'affichage des noirs et des tons sombres. Le i1 Display Pro ou peut être mieux le Discus me semblent les plus appropriés pour faire ces expérimentations.

Attention également aux anciens spectro comme le i1 pro, qui en plus d'une mauvaise précision dans les noirs, souffrent d'une très forte dépendance à l'orientation des sources polarisées, ce qui est la cas sur un écran LCD. Toujours les placer parfaitement verticalement sur l'écran sinon les différences sur les valeurs mesurées sont colossales d'une sessions de mesure à une autre.

Pour info quelques explications très intéressantes données dans un autre fil par Jean Delmas. Explications qui confirment comme je le pensais que les courbes tonales de l'écran qu'elles soient gamma 2.2, L* ou sRGB ne devrait pas beaucoup changer la perception à partir du moment ou l'on est en 10 bits par canal pour la liaison écran.

"Berns rappelle en outre que la recherche d'un « gamma optimal » n'a de sens que si la résolution tonale n'est que de 8 bits."

Donc à mon avis, les causes des différences visibles entre gamma 2.2 et L* qu'a remarqué Christophe sont à rechercher dans une mauvaise gestion du profil écran par l'application, ou bien dans un profil écran dont la table conversion couleur ne contiendrait pas assez de patchs N/B pour assurer une représentation précise des niveaux de luminance, si l'application utilise seulement cette table et non les LUT de courbes tonales du profil pour assurer le codage de la luminance.

CitationPour ces questions de quantification, mais aussi pour celles, bien plus graves, qui concernent les écrêtages de gamut, vous pouvez consulter la récente étude (2014) de Roy S. Berns, dont MBe a rappelé ici le lien il y a qq semaines : https://www.google.fr/search?q=camera+encoding+evaluation&ie=utf-8&oe=utf-8&rls={moz:distributionID}:{moz:locale}:{moz:official}&gws_rd=cr&ei=7RRaVfT6C6aAywOPsoCoBw

Cette étude aborde un domaine photographique exigeant en matière de colorimétrie, celui de la reproduction des œuvres d'art et des autres objets patrimoniaux. Dans sa partie consacrée aux erreurs de quantification, Berns conclut qu'avec une résolution tonale de 16 bits, les différences obtenues entre gamma=1,8 et gamma=2,2 ou L* sont négligeables. Berns rappelle en outre que la recherche d'un « gamma optimal » n'a de sens que si la résolution tonale n'est que de 8 bits. Et il conclut finalement que le « Studio for Scientific Imaging and Archiving of Cultural Heritage » continuera de définir ses images dans ProPhoto RGB... Bon, cette décision péremptoire n'est peut-être que provisoire et pourrait changer s'il parcourre ce fil.

3 - Perte de niveaux à l'affichage par erreur de quantification

Pour en terminer avec les mauvais tours que nous jouent les erreurs de quantification, examinons ce qui se passe chez un photographe possédant un écran dont le comportement natif est la courbe gamma 2,2 (ce qui n'est pas rare) et qui, séduit par les austérités de la Très Sainte Clarté L*, décide de le calibrer sur la courbe L*. Supposons qu'il fasse cette opération en chargeant les données correctives dans la LUT de sa carte graphique. Eh bien, si la carte graphique fait ses calculs sur 8 bits (ce qui n'est pas rare non plus), son affichage perdra 8,59% des niveaux d'entrée (8,35% si la carte graphique travaille sur 12 bits).

Tabernacle ! Un raisonnement basé sur la « cohérence » des courbes tonales militerait donc ici pour la conservation du comportement natif de l'écran à la place de la courbe L* ?  Rassurez vous, adopter L* pour l'affichage reste un bon choix et présente un avantage qualitatif (*) marginal mais incontestable pour les écrans qui le permettent. Et les inconvénients ci-dessus dus à la quantification ne pèsent pas bien lourd vis-à-vis de cet avantage.

De même qu'avec une résolution tonale de 16 bits, « l'inconvénient de cohérence » présenté par ProPhoto RGB et sa courbe gamme 1,8 compte pour du ghee (beurre clarifié à la clarté L*) à coté des écrêtages de gamut provoqués par un espace comme eciRGB_v2 qui présente l'avantage de L* mais aussi et surtout les inconvénients sévères d'un gamut trop petit pour les impressions à jet d'encre modernes. Et quid de ProStar RGB alors ? Eh bien le gaillard possède tous les avantages, celui du gamut de ProPhoto RGB et ceux de la courbe de réponse L*. C'est donc un choix optimal, mais ne rêvons pas, il n'apporte probablement aucun progrès visible à l'affichage de ceux qui, comme Berns, utilisent aujourd'hui déjà ProPhoto RGB.

Les photographes qui trouvent que leur noirs affichés sont moins bouchés avec un écran réglé sur L* sont des artisans attentifs et bien équipés d'un écran pour arts graphique soigneusement étalonné. En revanche, je ne vois pas par quel prodige de la Très Sainte Clarté leur affichage (et même leurs impressions !) pourraient être améliorés  en 16 bits par une définition des images dans un espace RGB ayant L* comme courbe tonale...

Quant à la bonne idée consistant à créer un espace de travail RGB avec L* comme courbe de réponse tonale, merci Salomé de lever les doutes de votre ami blogueur taquin et sceptique. Je confirme que c'est par un mail du sympathique Bruce Lindbloom daté du 20 septembre 2007 (c'était un jeudi) qu'il m'a annoncé que c'était probablement lui qui en avait eu le premier l'idée dans une conférence donnée en 1989 au SIGGRAPH dont il m'a envoyé un exemplaire en PJ que j'ai conservé depuis sous mon oreiller.

(*) A quoi devons nous cet avantage ? Mais à la sempiternelle racine cubique ! Je rappelle que la courbe L* est un bon modèle de notre perception des luminances parce que, la clarté L* variant linéairement avec la racine cubique de la luminance, elle se conforme au fait que, quand on multiplie une luminance par 2x2x2, notre perception ne ressent qu'un doublement de la luminosité (2 est la racine cubique de 2x2x2). Voila pourquoi la courbe L* est vraiment intéressante et non parce qu'elle donne une clarté de 50% (127 sur l'échelle 0-255) pour le gris moyen de luminance relative=18%, car la courbe gamma=2,47 et bien d'autres encore possèdent la même agréable propriété.

salut

Donc si je résume en gros car je ne comprends que les courbes et les couleurs "avec mon ptit cerveau":

Peut importe le choix pour calibrer son écran entre L* ou 2.2 car l'essentiel est de choisir un "espace de travail en L*".

Citation de: asak le Septembre 13, 2015, 19:04:55
C est peut etre normal si on utilise un espace de travail gamma avec une visu L..
Espace de tra ail gamma visu gamma. Espace de travail L visu L.
;)

Deuxieme reponse du fil de 4 pages  :D

Citation de: fred94- le Septembre 16, 2015, 15:31:10
salut

Donc si je résume en gros car je ne comprends que les courbes et les couleurs "avec mon ptit cerveau":

Peut importe le choix pour calibrer son écran entre L* ou 2.2 car l'essentiel est de choisir un "espace de travail en L*".

Non, l'essentiel est d'avoir un système qui marche correctement pour le travail qu'on a à réaliser. Dans le cas de la question du début de ce fil, il y a un problème avec L* sur les niveaux de luminance produits par le profil écran et j'ai proposé quelques pistes pour essayer de déterminer d'où il vient. Il est suffisamment prononcé pour être facilement visible et donc gênant dans un processus de tirage qualité expo.

L'harmonisation des courbes tonales entre espaces est un autre débat. Berns montre par exemple qu'à une résolution de 16 bits le choix de la courbe tonale de l'espace n'a que peu d'influence sur le résultat des conversions entre espaces. 16 bits est la norme depuis longtemps pour les tables de correspondance dans les profils même s'il est toujours possible de créer des profils avec des tables 8 bits ce qui n'a plus de sens aujourd'hui vu la puissance des machines.

Ensuite il y a l'influence des courbes tonales sur la linéarité perceptuelle d'un espace, et cela peut avoir une influence sur les traitements qu'on applique dans l'image selon les algorithmes utilisés. Encore ici il faut faire attention à ce qu'on dit, par exemple certains logiciels dont Lightroom utilisent des espaces internes différents pour la visualisation et le traitement. La visualisation en gamma 1.8 pour Lightroom avec Melissa, et un espace avec les mêmes primaires mais en gamma 1.0 pour les traitements internes.

Je pense qu'on ne peut pas tirer des règles définitives en ce qui concerne le bienfait de tel ou tel espace ou courbe tonale. Il y a tellement de paramètres qui entrent en ligne de compte, depuis les besoins de l'utilisateur du CMS jusqu'aux performances possibles voir les bugs des logiciels employées, qui ne savent pas toujours gérer correctement tel ou tel aspect des conversions icc. En passant par la profondeur de quantification ou de calcul de chaque logiciel, fichier image et de chaque périphérique, sans parler de la précision des sondes de mesure, de l'influence de la couleur des papiers et de la présence ou non de produits azurants, de l'influence de l'éclairage pour la visualisation des tirages (conditions de visualisation). Lorsqu'on veut aller au bout des choses il faut prendre le problème dans son ensemble et avoir une bonne compréhension de la colorimétrie, sinon on risque d'être fortement déçu par ce que peut apporter le CMS qui ne traite qu'une partie du problème de la transmission des couleurs de leur source vers leur destination.

Le mieux je pense est de rester dans la limite de ce qu'on comprend et de ce qui fonctionne pour le travail qu'on a besoin de réaliser. Plutôt que de jouer aux apprentis sorcier pour se rendre compte au final qu'on perd sont temps à essayer d'améliorer quelque chose qui marche déjà bien avec les paramètres par défaut qui sont souvent mieux pris en compte dans les matériels et les logiciels.

Si on ne comprend pas, ce qui n'est pas condamnable au vu de la complexité de la gestion des couleurs, ou parce que on a trop petit cerveau ce qui peut arriver :( , soit on essai d'apprendre pour aller jusqu'au bout des choses, soit on fait avec des méthodes standards qui marchent bien dans la plupart des situations.

Il y a tant de choses à améliorer avant de se prendre la tête avec les systèmes CMS, comme par exemple l'éclairage de la pièce et la qualité de son écran :) , la qualité de son imprimante, de ses sondes, ses connaissances globales en gestion des couleurs... Des choses qui apporteront certainement plus que changer les profils CMS dans tous les sens.

Citation de: olivier1010 le Septembre 16, 2015, 17:50:05
Non, l'essentiel est d'avoir un système qui marche correctement pour le travail qu'on a à réaliser. Dans le cas de la question du début de ce fil, il y a un problème avec L* sur les niveaux de luminance produits par le profil écran et j'ai proposé quelques pistes pour essayer de déterminer d'où il vient. Il est suffisamment prononcé pour être facilement visible et donc gênant dans un processus de tirage qualité expo.

L'harmonisation des courbes tonales entre espaces est un autre débat. Berns montre par exemple qu'à une résolution de 16 bits le choix de la courbe tonale de l'espace n'a que peu d'influence sur le résultat des conversions entre espaces. 16 bits est la norme depuis longtemps pour les tables de correspondance dans les profils même s'il est toujours possible de créer des profils avec des tables 8 bits ce qui n'a plus de sens aujourd'hui vu la puissance des machines.

Ensuite il y a l'influence des courbes tonales sur la linéarité perceptuelle d'un espace, et cela peut avoir une influence sur les traitements qu'on applique dans l'image selon les algorithmes utilisés. Encore ici il faut faire attention à ce qu'on dit, par exemple certains logiciels dont Lightroom utilisent des espaces internes différents pour la visualisation et le traitement. La visualisation en gamma 1.8 pour Lightroom avec Melissa, et un espace avec les mêmes primaires mais en gamma 1.0 pour les traitements internes.

Je pense qu'on ne peut pas tirer des règles définitives en ce qui concerne le bienfait de tel ou tel espace ou courbe tonale. Il y a tellement de paramètres qui entrent en ligne de compte, depuis les besoins de l'utilisateur du CMS jusqu'aux performances possibles voir les bugs des logiciels employées, qui ne savent pas toujours gérer correctement tel ou tel aspect des conversions icc. En passant par la profondeur de quantification ou de calcul de chaque logiciel, fichier image et de chaque périphérique, sans parler de la précision des sondes de mesure, de l'influence de la couleur des papiers et de la présence ou non de produits azurants, de l'influence de l'éclairage pour la visualisation des tirages (conditions de visualisation). Lorsqu'on veut aller au bout des choses il faut prendre le problème dans son ensemble et avoir une bonne compréhension de la colorimétrie, sinon on risque d'être fortement déçu par ce que peut apporter le CMS qui ne traite qu'une partie du problème de la transmission des couleurs de leur source vers leur destination.

Le mieux je pense est de rester dans la limite de ce qu'on comprend et de ce qui fonctionne pour le travail qu'on a besoin de réaliser. Plutôt que de jouer aux apprentis sorcier pour se rendre compte au final qu'on perd sont temps à essayer d'améliorer quelque chose qui marche déjà bien avec les paramètres par défaut qui sont souvent mieux pris en compte dans les matériels et les logiciels.

Si on ne comprend pas, ce qui n'est pas condamnable au vu de la complexité de la gestion des couleurs, ou parce que on a trop petit cerveau ce qui peut arriver :( , soit on essai d'apprendre pour aller jusqu'au bout des choses, soit on fait avec des méthodes standards qui marchent bien dans la plupart des situations.

Il y a tant de choses à améliorer avant de se prendre la tête avec les systèmes CMS, comme par exemple l'éclairage de la pièce et la qualité de son écran :) , la qualité de son imprimante, de ses sondes, ses connaissances globales en gestion des couleurs... Des choses qui apporteront certainement plus que changer les profils CMS dans tous les sens.

+1000 😊

Savoir rester pragmatique dans ce domaine m'apparaît en effet essentiel.

Citation de: MBe le Septembre 15, 2015, 23:21:43
- Avec un profil d'affichage en L*, il est préférable de travailler dans espace de travail avec un TRC  L* ou de finaliser dans tiff avec un profil L* afin de garder la cohérence.

Ah? Tant qu'on est pas limité par la quantification (et on ne va pas se remettre à bosser en 8bits comme il y a 20 ans hein?), quel intérêt de mettre le L* dans l'espace de travail?

Citation de: olivier1010 le Septembre 14, 2015, 10:57:25
Il me semble en tout cas que pour profiter du L*, un écran avec calibration hardware est nécessaire.

Mon gravier à l'édifice : en essayant L* sur un moniteur bas de gamme, les pbs de linéarité étaient plus gênants que le gain de détails dans les BL... et je trouvais, mais c'est peut-être surtout une question d'environnement, que les BL étaient un poil trop éclaircies à mon goût.
Je retiens que la courbe sRGB pourrait faire un juste milieu.

Citation de: fred94- le Septembre 16, 2015, 15:31:10
Peut importe le choix pour calibrer son écran entre L* ou 2.2 car l'essentiel est de choisir un "espace de travail en L*".

C'est l'inverse, non? On peut se faire un espace de travail tarabiscoté OSEF, et par contre entre L* et 2.2 à l'écran l'affichage n'est pas le même.

Citation de: Nikojorj le Septembre 16, 2015, 20:42:35
Mon gravier à l'édifice : en essayant L* sur un moniteur bas de gamme, les pbs de linéarité étaient plus gênants que le gain de détails dans les BL... et je trouvais, mais c'est peut-être surtout une question d'environnement, que les BL étaient un poil trop éclaircies à mon goût.
Je retiens que la courbe sRGB pourrait faire un juste milieu.

C'est l'inverse, non? On peut se faire un espace de travail tarabiscoté OSEF, et par contre entre L* et 2.2 à l'écran l'affichage n'est pas le même.

Je pense que L* ou 2.2 n'a plus tellement d'importance aujourd'hui puisqu'on peut attaquer l'écran en 10 bits par canal. Les deux courbes sont suffisamment proches je pense pour qu'en 10 bits on ne voit plus trop de différence entre l'une ou l'autre, à condition évidement que l'application corrige l'affichage correction en fonction de ces deux différentes courbes.

Par contre je viens de lire dans l'étude "A New Encoding System for Image Archiving of Cultural Heritage :ETRGB"   que L* est plus proche de gamma 2.4. Je pensais initialement que L* est était plus proche de gamma 2.2.

Fort de ce constat, j'ai repris les images de Christophe et quand j'ajoute 0.2 à l'image de Christophe en gamma 2.2, ce qui fait un gamma de 2.4,  je retombe approximativement sur l'image de gauche en L*.

J'en déduit qu'il y a effectivement un problème avec Photoshop sur la gestion du profil écran en L*. Je pense qu'il considère que l'écran est en gamma 2.2, ce qui explique que l'image apparaisse trop claire avec une calibration L* qui s'approche donc de gamma 2.4.

C'est une supposition, il faudrait vérifier en modifiant le profil L* comme je l'ai proposé plus haut : modifier les tags gamma en par exemple en 1.0 pour voir si Photoshop tient compte de ce ces tags, ou s'il tient réellement compte des courbes tonales L* du profil.

Il faudrait aussi tout simplement regarder comment est construit le profil L* de Christophe. Il y a peut être un problème à ce niveau, il pourrait contenir des tags gamma 2.2 au lieu de 2.4 ou pas de tags gamma du tout.

je réitère :
Le delta c'est bien le end-to-end gamma ? (je viens de la video, hein) donc pour un gamma de 2.2 il faudrait qu'il soit entre 1.1 et 1.2, non ?
et pour le print vers 1.4 ?

Sachant qu'il y ai bien trois gamma. (moniteur, correction, endtoend)

Citation de: Nikojorj le Septembre 16, 2015, 19:36:20
Ah? Tant qu'on est pas limité par la quantification (et on ne va pas se remettre à bosser en 8bits comme il y a 20 ans hein?), quel intérêt de mettre le L* dans l'espace de travail?

les CMM qui utilisent les espaces de travail qui réalisent les calculs sur des quantifications bien supérieure à 8 bits, la TRC L* définie une courbe, pas la quantification.

Salut,

Suivant l avis d olivier1010 et l étude ETRGB donc c'est logique la différence entre les deux images de M.Metairie. Mais il faudrait savoir comment a été traité cette image, développement seul ou développement+retouche dans Topshop?

"Un autre avantage de L * est son terme explicite de pente pour des couleurs presque noir. Bien que cela a été développé pour éviter des valeurs L * négatives, il sert également comme un terme linéaire pour éviter une pente infinie à 0. Ainsi, la fonction de L * a été sélectionné."
Pi être il y a confusion avec les espaces de travail en L*?

Citation de: olivier1010 le Septembre 16, 2015, 14:46:06
Pour info quelques explications très intéressantes données dans un autre fil par Jean Delmas. Explications qui confirment comme je le pensais que les courbes tonales de l'écran qu'elles soient gamma 2.2, L* ou sRGB ne devrait pas beaucoup changer la perception à partir du moment ou l'on est en 10 bits par canal pour la liaison écran.

"Berns rappelle en outre que la recherche d'un « gamma optimal » n'a de sens que si la résolution tonale n'est que de 8 bits."

Donc à mon avis, les causes des différences visibles entre gamma 2.2 et L* qu'a remarqué Christophe sont à rechercher dans une mauvaise gestion du profil écran par l'application, ou bien dans un profil écran dont la table conversion couleur ne contiendrait pas assez de patchs N/B pour assurer une représentation précise des niveaux de luminance, si l'application utilise seulement cette table et non les LUT de courbes tonales du profil pour assurer le codage de la luminance.

Olivier1010, tu as bien fait de remonter l'analyse de Jean Delmas  ;) et je suis globalement d'accord avec tes analyses.

J'ai quelques questions pour toi :

- Est ce que tu sais comment il a calculé les erreurs de quantification entre TRC 2,2 et L*?

Pour en revenir au profil calculé par ColorNavigator (Eizo) :

- La balise vcgt est bien une droite, j'ai vérifié (donc en effet tout est normal et conforme à tes explications détaillées).
-La TRC  L* et 2, 2 ont chacune un offset, ce qui fait que la courbe ne se superpose pas dans les basses lumières, est ce que tu peux regarder sur tes profils?
Pour un profil L* j'ai :

0 64
1 93
2 121
3 149
4 177
[...]
pour un profil en 2,2  je relève :
0 259
1 259
2 260
3 262
4 266
[...]
==> c'est codé de 0 à 255 en entrée et de 0 à 65535 en sortie

Merci.

Citation de: Verso92 le Septembre 15, 2015, 22:38:12
Oups, désolé : j'ai fait une confusion malencontreuse entre les deux termes (la fatigue ?)... merci de m'avoir remis dans le droit chemin !

;-)

Votre lexique est un brin faussé, et c'est lu en diagonale.
Exemple avec le GAIN, le gain est une opération de multiplication, alors que le contraste est de l'ordre de la puissance.
Donc il ne peut en aucun cas : permet de régler (en %) l'intensité de l'augmentation du contraste des zones de transition.
La CHROMINANCE, attention car il y a plusieurs termes...la CHROMINANCE (générale) est plutôt de l'ordre d'une information de couleurs -YCBCR- (et sous-échantillonnage) et non d'artefacts colorés dans l'image
Si vous parlez de BRUIT il faut une partie dédiée au GRAIN aussi.
INTERPOLATION : très mal traduit de l'anglais "subsampling" qui lui même est lié à l'aliasing.
Si vous parlez de QUANTIFICATION il faut expliquer l'échantillonnage aussi et non de SHANNON ;)
...
bref, la fatigue surement.

Citation de: Miaz3 le Septembre 16, 2015, 22:41:49
je réitère :
Le delta c'est bien le end-to-end gamma ? (je viens de la video, hein) donc pour un gamma de 2.2 il faudrait qu'il soit entre 1.1 et 1.2, non ?
et pour le print vers 1.4 ?

Sachant qu'il y ai bien trois gamma. (moniteur, correction, endtoend)

Dans un système CMS (color management system) les courbes tonales (qui peuvent être gamma ou non) n'ont pas vraiment d'importance puisque le CMS réalise les conversions entre périphériques afin que le résultat soit identique quelque soit la cible. On entend encore parler de gamma surtout pour l'écran, car il peut se calibrer sur diverses courbes tonales, dont gamma généralement entre 1.8 et 2.4, ou courbe tonale sRGB ou L* ou tout autre courbe tonale spécifique comme celle du système DICOM pour l'imagerie médicale. Cette possibilité de réglage est principalement liée à l'histoire des écrans qui ont évolué et ont du surtout s'adapter à divers périphériques d'impression à l'époque ou les CMS n'existaient pas. Aujourd'hui la courbe tonale de l'écran a tendance à se standardiser, et ce sera encore plus vrai avec le nouvel espace REC 2020.

Dans un système CMS, on calibrera généralement l'écran sur une courbe non linéaire proche de la sensibilité de l'œil, afin de profiter au mieux de la liaison vidéo qui est en 8 ou 10 bits par canal seulement. Soit sRGB ou L* de préférence, mais pas obligatoirement. Gamma 2.2 ou 2.4 sont également suffisamment proches pour donner de bons résultats. Dans tous les cas ce réglage ne devrait pas influencer les niveaux de luminance affichés puisqu'il y aura une compensation du coté de l'application pour afficher les bons niveaux. Selon la courbe choisie et à cause de la liaison vidéo en faible profondeur de quantification (surtout si elle est en 8 bits), il y aura effectivement des légères différences de rendu dans les bas niveaux et un peu de banding, à cause des écarts en luminance (mais aussi en chrominance) induits par cette liaison de faible profondeur de quantification. Ces écarts sont quand même minimes si l'écran est calibré hardware.

Idem pour l'impression connaître le gamma de l'imprimante n'a plus de sens aujourd'hui, elle est décrite bien plus précisément dans son profil couleur avec des tables de couleurs composées parfois de plusieurs milliers de correspondances. Ce qui est nettement plus précis qu'un simple système de courbe tonale. Et le système Icc V4 propose même une table de correspondance inverse dans les profils d'impressions, afin de faire concorder au mieux les couleurs écran.

Pour ceux qui sont débutants dans les systèmes CMS, je leur conseil le livre de Jean Delmas : "La gestion des couleurs". Sinon c'est impossible de suivre ce genre de fil.

Citation de: olivier1010 le Septembre 16, 2015, 23:16:42
Dans un système CMS (color management system) les courbes tonales (qui peuvent être gamma ou non) n'ont pas vraiment d'importance puisque le CMS réalise les conversions entre périphériques afin que le résultat soit identique quelque soit la cible. On entend encore parler de gamma uniquement pour l'écran, car il peut se calibrer sur diverses courbes tonales, dont gamma généralement entre 1.8 et 2.4, ou courbe tonale sRGB ou L* ou tout autre courbe tonale spécifique comme celle du système DICOM pour l'imagerie médicale.

Dans un système CMS, on calibrera généralement l'écran sur une courbe non linéaire proche de la sensibilité de l'œil, afin de profiter au mieux de la liaison vidéo qui est en 8 ou 10 bits par canal seulement. Soit sRGB ou L* de préférence, mais pas obligatoirement. Gamma 2.2 ou 2.4 sont également suffisamment proches pour donner de bons résultats. Dans tous les cas ce réglage ne devrait pas influencer les niveaux de luminance affichés puisqu'il y aura une compensation du coté de l'application pour afficher les bons niveaux. Selon la courbe choisie et à cause de la liaison vidéo en faible profondeur de quantification (surtout si elle est en 8 bits), il y aura effectivement des légères différences de rendu dans les bas niveaux et un peu de banding, à cause des écarts en luminance (mais aussi en chrominance) induits par cette liaison de faible profondeur de quantification. Ces écarts sont quand même minimes si l'écran est calibré hardware.

Idem pour l'impression connaître le gamma de l'imprimante n'a plus de sens aujourd'hui, elle est décrite bien plus précisément dans son profil couleur avec des tables de couleurs composées parfois de plusieurs milliers de correspondances. Ce qui est nettement plus précis qu'un simple système de courbe tonale. Et le système Icc V4 propose même une table de correspondance inverse dans les profils d'impressions, afin de faire concorder au mieux les couleurs écran.

Pour ceux qui sont débutants dans les systèmes CMS, je leur conseil le livre de Jean Delmas : "La gestion des couleurs". Sinon c'est impossible de suivre ce genre de fil.

Bien sur, mais cela ne répond toujours pas à ma question ?!

Citation de: Miaz3 le Septembre 16, 2015, 22:41:49
je réitère :
Le delta c'est bien le end-to-end gamma ? (je viens de la video, hein) donc pour un gamma de 2.2 il faudrait qu'il soit entre 1.1 et 1.2, non ?
et pour le print vers 1.4 ?

Sachant qu'il y ai bien trois gamma. (moniteur, correction, endtoend)

Je comprends pas bien ta question...

Si ta question correspond à : (mais j'ai un doute)

Si plusieurs appareils se succèdent dans une chaîne avec g1,g2, g3, la résultante sera :

sortie = entrèe^g1*g2*g3

Citation de: MBe le Septembre 16, 2015, 23:06:50
Olivier1010, tu as bien fait de remonter l'analyse de Jean Delmas  ;) et je suis globalement d'accord avec tes analyses.

J'ai quelques questions pour toi :

- Est ce que tu sais comment il a calculé les erreurs de quantification entre TRC 2,2 et L*?

Pour en revenir au profil calculé par ColorNavigator (Eizo) :

- La balise vcgt est bien une droite, j'ai vérifié (donc en effet tout est normal et conforme à tes explications détaillées).
-La TRC  L* et 2, 2 ont chacune un offset, ce qui fait que la courbe ne se superpose pas dans les basses lumières, est ce que tu peux regarder sur tes profils?
Pour un profil L* j'ai :

0 64
1 93
2 121
3 149
4 177
[...]
pour un profil en 2,2  je relève :
0 259
1 259
2 260
3 262
4 266
[...]
==> c'est codé de 0 à 255 en entrée et de 0 à 65535 en sortie

Merci.

Pour le calcul des erreurs de quantification entre TRC 2,2 et L* je ne sais pas.

Je suis en train de réaliser diverses cible sur mon CG277 et voir ce qu'il se passe exactement. J'ai rapidement testé Lightroom qui semble bien compenser pour chaque cible, mais nécessite quand même un redémarrage pour prendre en compte le changement de profil écran système effectué lors du changement de cible dans Colornavigator.

J'ai crée des cibles de calibration entre gamma 1.5 et 2.4 ainsi que L*. Je ne vois pas de différence notable dans l'affichage écran. il faudrait néanmoins que je fasse des repros d'écran pour comparer car à l'œil c'est difficile de mémoriser chaque image entre les redémarrages de Lightroom.

Je crée ces profils écrans en icc V4, avec l'option "reflect black level in tone curve" activée (réglage par défaut), sauf pour une cible afin de voir la différence. Cette option est importante car elle permet de mapper le début de la tone curve sur le point noir réel mesuré, ou bien si on la désactive sur un point noir fictif à 0 cd/m² qui se trouve donc en dessous du point noir mesuré. Ce dernier se trouve à 0.12 cd/m² sur mon écran pour un point blanc à 100 cd/m² soit un contraste de 864 : 1.

L'explication en anglais de cette option :

"Basically anything other than OLED doesn't allow for perfect black so you can either use true pitch black as the starting point or decide to uses the darkest black that the monitor can show for how it's currently set as the starting point.

You can have the monitor calibrate itself using it's darkest tone as the dark point and then it gets no missing blacks so sending 1,1,1 to the screen shows a trace brighter than 0,0,0 or you can have it calibrate to true pitch black and then it might take until maybe tones 2,2,2 or even 9,9,9 to show as different from 0,0,0."
Je ne vois pas trop l'intérêt de désactiver cette option, sauf pour des raisons de compatibilité si un logiciel va lire la valeur de noir dans le profil (je crois que c'est possible en V4) et appliquer lui même un offset sur la tone curve, auquel cas il faudrait désactiver l'option "reflect black level in tone curve" dans le logiciel qui crée le profil et la calibration écran. Dans ce cas également la calibration écran devrait logiquement réserver une zone morte entre le noir fictif à 0 et le noir mesurée au lieu de faire débuter la calibration hardware sur le noir mesuré.

Il me faut maintenant extraire les courbes LUT TRC des profils écrans, j'utilise iccdump qui me donne des valeurs entre 0 et 1. Je dois convertir en valeurs 16 bits pour correspondre avec vos valeurs. Vous avez utilisé quel utilitaire pour extraire vos valeurs en entiers 16 bits ?

Citation de: MBe le Septembre 16, 2015, 22:48:58
les CMM qui utilisent les espaces de travail qui réalisent les calculs sur des quantifications bien supérieure à 8 bits, la TRC L* définie une courbe, pas la quantification.

C'est bien pour ça que je me demande quel est l'intérêt de tripatouiller la courbe de contraste de l'espace de travail, oui.

Interessant  mais confus
A la question d origine aucune précisions sur l environement de travail par l interessé
Néenmoins je me pose des questions
La courbeL* est elle normalisée
Comment se défini l espace de traivail photoshop quelles sont les interactions avec ACR
Quelles sont les interactions entre le hardware eizo par exemple; et l espace de travail photoshop
Pour rester pragmatique et conscient de bug possible.
;)

Citation de: asak le Septembre 17, 2015, 09:37:04
Interessant  mais confus
A la question d origine aucune précisions sur l environement de travail par l interessé
Néenmoins je me pose des questions
La courbeL* est elle normalisée
Comment se défini l espace de traivail photoshop quelles sont les interactions avec ACR
Quelles sont les interactions entre le hardware eizo par exemple; et l espace de travail photoshop
Pour rester pragmatique et conscient de bug possible.
;)

Oui certaines choses restent confuses dans les relations entre CMS et applications, icc V4 améliore certains aspects mais les applications n'implémentent pas forcément les modifications qui vont avec.

C'est pour cela qu'on voit apparaître des options dans les logiciels de calibration, comme la possibilité de changer la version de profil généré en v2 ou v4, ou bien la possibilité de générer les courbes LUT dans un mode que j'appellerais bien "superblack" (le noir à 0 cd/m², en dessous donc du noir mesuré, représente le zéro des courbes tonales).

Théoriquement L* est bien définie puisque c'est l'axe L de l'espace L*a*b*. Reste à voir comment c'est implémenté dans les logiciels de calibration, et si l'on peut voir des différences d'implémentation au niveau de la création des profils (notamment que fait le logiciel de création de profil au niveau des tags gamma lorsqu'il inclut une courbe tonale L* sous forme de 3 tables LUT RVB). Ce que nous sommes en train de regarder.

Que font également les applications lorsqu'elles trouvent des courbes LUT TRC dans le profil. Se basent elles sur les coefficients gamma du profil, sur ces courbes, ou uniquement sur la table de correspondance couleur si elle est présente dans le profil. Chaque application ou CMS pouvant avoir un comportement différent. Que se passe t'il également lorsque le profil est généré en V2 ou en V4. Est ce que cela déclenche un comportement différent de l'application ou du CMS.

Des questions auxquelles on ne peut répondre qu'en faisant des tests précis pour mettre en évidence chaque aspect.

En fait je penses que le probléme est plus paramétrages. Puisque on arrive a avoir une correspondance écran tirage avec un profil imprimante.

Quelques infos intéressantes concernant la structure des profils générés par Eizo ColorNavigator 6 :
- Lorsqu'on sélectionne L* en tant que courbe tonale, on ne peut générer qu'un profil avec des balises de courbes tonales (TRCTag). Ce qui est logique puisqu'on ne peut pas décrire L* avec des coefficients gamma.

- Les profils ne contiennent pas de balises gamma lorsqu'on choisit le type de profil courbe tonale. Donc pour un profil Eizo, pas de crainte qu'un CMS ou une application utilise les valeur gamma RVB approchantes à la place des courbe tonales RVB.

- Les profils ne contiennent pas de table de correspondance couleur. Les patchs utilisés lors de la validation du profil ne sont donc pas utilisés pour générer une table de correspondance couleur.

- Les profils contiennent la valeur en luminance du point blanc, mais pas celle du point noir.
Cela m'amène à penser qu'il serait intéressant de vérifier que pour Christophe, le comportement du logiciel de calibration est le même concernant l'inclusion ou non des balises gamma surtout lorsqu'une courbe L* est demandée.
Ensuite il faudrait vérifier en demandant une validation contenant un nombre assez élevé de patchs sur l'axe des gris qu'il n'y a pas de déviation des valeurs de luminance dans les bas niveaux.

En outre les profils écran ne contiennent pas de table de correspondance couleur. il faut donc se référer au résultat de la phase de validation du profil pour connaître quelles sont les déviations par rapport aux valeurs théorique de la cible de calibration. Éventuellement il faudra ajouter des patchs de mesure dans cette phase de validation pour connaître plus précisément tel ou tel aspect de l'affichage, par exemple la neutralité de l'axe des gris, et la précision des valeurs de luminance sur cet axe, ce dernier point nous intéressant particulièrement dans le cadre de l'étude de L*.

Un autre aspect de cette absence de table de correspondance couleur dans le profil écran est qu'on ne peut pas l'éditer pour modifier la colorimétrie de l'affichage.
Il faut donc éventuellement ajuster manuellement la calibration du moniteur si on remarque des écarts de colorimétrie constants et indépendants des périphériques d'impression. ColorNavigator permet de faire cela avec des outils de correction couleur : point blanc, luminosité, teinte saturation et luminance sur 6 couleurs.

Si les écarts proviennent de l'imprimante, cela doit être mesurable au spectro, dans ce cas il faut refaire un profil d'impression ou l'ajuster. Si l'impression est bonne après vérification au spectro mais que l'affichage écran ne correspond pas, il est possible de modifier la table de correspondance inverse du profil d'imprimante afin d'ajuster la relation entre cette imprimante et l'écran sans toucher aux couleurs imprimées.

Je regarde de plus près maintenant les courbes tonales gamma 2.2 et L* générées par ColorNavigator.

Voici les courbes tonales générées par le logiciel de calibration écran ColorNavigator 6.
Toutes sont en mode "reflect measured black level in tone curve". C'est à dire que le zéro des courbes correspond au noir minimum réel mesuré de l'écran.

On voit que L* est globalement plus proche de gamma 2.4, sauf dans les basses lumières ou elle est même plus haute que gamma 2.2 jusqu'au niveau d'entrée 60 environ.

Chaque table LUT contient 256 valeurs codées sur 16 bits. (c'est extrait en virgule flottante avec une échelle de de 0 à 100 par l'utilitaire ProfileDump, j'ai réalisé une conversion en 16 bits entier).

Et un agrandissement de la partie basse.

On remarque L* n'est vraiment très différente d'un gamma que jusqu'à la valeur 2500 environ, soit une luminance très faible de 4%. mais on remarque quand même une différence de forme de la courbe jusqu'à environ 10000, soit 16% de luminance, par rapport à un gamma de 2.4.
Les petites ondulations dans les courbes sont dues je pense à l'arrondi sur l'axe des abscisses qui n'est pas en nombres entier à l'origine une fois extrait du profil.

Citation de: MBe le Septembre 16, 2015, 23:47:44
Je comprends pas bien ta question...

Si ta question correspond à : (mais j'ai un doute)

Si plusieurs appareils se succèdent dans une chaîne avec g1,g2, g3, la résultante sera :

sortie = entrèe^g1*g2*g3

Effectivement ce n'est pas ça.
Olivier1010 parlait du dela maxi, venant de la vidéo je me demande ce que le delta signifie.
Car en vidéo et CG il y a plusieurs méthodes de travail, dont celle-ci, qui consiste à travailler sur des fichiers linéaires (sans profil colorimétrique) afin d'avoir le minimum d'approximation.
Le travail sous LUT (normalisée (aces, spi, ocio)) ce fait donc en temps réel.
Suivant les logiciels des paramètres sont prédéfinit, comme pour le moniteur qui par défaut est sur sRGB, les fichier en 8-bit en sRGB aussi. Les fichier log pour du cineon et le float pour les fichier linéaire...ect, ect.

bref, partant du constat que je n'y connais pas grand chose en étalonnage d'écran je suis partis sur cette déduction de correction de gamma,  end to end > réponse linéaire > 1, ou 1 peut varier en fonction du type de support utilisé + perception.

Puis finalement après recherche sur la toile il c'est avéré que non, j'étais à coté de la plaque ;) il s'agissait du delta E.

Citation de: Miaz3 le Septembre 17, 2015, 21:51:23
Effectivement ce n'est pas ça.
Olivier1010 parlait du dela maxi, venant de la vidéo je me demande ce que le delta signifie.
Car en vidéo et CG il y a plusieurs méthodes de travail, dont celle-ci, qui consiste à travailler sur des fichiers linéaires (sans profil colorimétrique) afin d'avoir le minimum d'approximation.
Le travail sous LUT (normalisée (aces, spi, ocio)) ce fait donc en temps réel.
Suivant les logiciels des paramètres sont prédéfinit, comme pour le moniteur qui par défaut est sur sRGB, les fichier en 8-bit en sRGB aussi. Les fichier log pour du cineon et le float pour les fichier linéaire...ect, ect.

bref, partant du constat que je n'y connais pas grand chose en étalonnage d'écran je suis partis sur cette déduction de correction de gamma,  end to end > réponse linéaire > 1, ou 1 peut varier en fonction du type de support utilisé + perception.

Puis finalement après recherche sur la toile il c'est avéré que non, j'étais à coté de la plaque ;) il s'agissait du delta E.

Oui il y a aussi Delta H et Delta C. Avec plusieurs déclinaisons pour chaque delta (des formules légèrement différentes selon l'évolution des CMS et les besoins des utilisateurs)

Et delta L aussi pour la luminance, très simple à calculer si on est en espace L*a*b*.

Voir ici :

http://www.codeproject.com/Articles/613798/Colorspaces-and-Conversions

https://dl.dropboxusercontent.com/u/1244963/0/Color_Formula_Code.pdf

Cool de la doc ! merci olivier1010

Voici deux courbes tonales de profil écran générées par Colornavigator 6. C'est un zoom de la région des 10% de luminance de l'écran. Au dessus les courbes se rejoignent progressivement jusqu'à se retrouver exactement au point de luminance 100%.

L'une est en L* avec option RBL (reflect measured black luminance in tone curve)

L'autre en L* (NRBL) sans cette option.

L'écran est réglé à son contraste maxi avec un noir à 0.12 cd/m² et un blanc à 100 cd/m². Le niveau de noir mini est un trait bleu sur le graphique.

On voit que la courbe RBL (option par défaut) fait correspondre un signal vidéo de 0 en entrée à la valeur de noir mini sur l'écran. Il n'y a donc aucune rupture dans les noirs par rapport à l'entrée vidéo.

La courbe NRBL fait correspondre le niveau vidéo 0 avec un noir fictif à zero cd/m² en dessous du noir mesuré. il y a donc une non linéarité d'affichage dans les noirs puisqu'il faut attendre le niveau vidéo 3% environ pour arriver au noir minimum affichable par l'écran. Entre 0 et 3% vidéo, il n'y a que du noir affiché à l'écran avant d'arriver au noir mini affichable.

Je suppose que dans les deux cas, la calibration hardware de l'écran fait correspondre le 0% de l'axe vertical avec un noir fictif à zero cd/m² dans les tables de correspondance internes de l'écran. Ce qui permet en utilisant la courbe RBL d'afficher sans défaut de linéarité par rapport aux premiers niveaux de noir vidéo en entrée.

En pratique je pense que la différence est minime lorsque l'écran est calibré à son contraste maximum, avec un niveau de noir mini aux environs de 0.12 cd/m² pour un niveau de blanc à 100 cd/m².

Pour un écran réglé à un contraste plus faible, avec par exemple un noir à 0.5 ou 1 cd/m², l'influence de cette option serait moins négligeable.

L'inconvénient de la courbe L* RBL est qu'elle n'est pas précisément réversible. L'utilitaire de validation de profil dans profiledump nous le signale :

Warning! - redTRCTag - Curve cannot be accurately inverted.
Warning! - greenTRCTag - Curve cannot be accurately inverted.
Warning! - blueTRCTag - Curve cannot be accurately inverted.

Les courbes gamma ne sont pas plus réversibles que L* lorsque l'option RBL est activée.

Je ne pense pas que ce soit un problème pour un profil écran qui ne travaille que dans le sens PCS vers écran. (PCS = profil connection space ou espace de connexion des profiles).
Je pense que le problème rencontré par Christophe n'est pas lié à cette option de génération de profil. Les différences observées sur les images qu'il a donné en exemple de l'ordre de 0.2 en gamma entre la calibration L* et la calibration en gamma 2.2 me semblent plus importantes que celles qui peuvent être induites ici.

Citation de: olivier1010 le Septembre 17, 2015, 02:13:37

Je suis en train de réaliser diverses cible sur mon CG277 et voir ce qu'il se passe exactement. J'ai rapidement testé Lightroom qui semble bien compenser pour chaque cible, mais nécessite quand même un redémarrage pour prendre en compte le changement de profil écran système effectué lors du changement de cible dans Colornavigator.
J'ai crée des cibles de calibration entre gamma 1.5 et 2.4 ainsi que L*. Je ne vois pas de différence notable dans l'affichage écran. il faudrait néanmoins que je fasse des repros d'écran pour comparer car à l'œil c'est difficile de mémoriser chaque image entre les redémarrages de Lightroom.

C'est surprenant, car sur mon écran je vois bien la différence entre L* et 2,2, je n'ai pas fait d'essais particuliers avec d'autres valeurs, mais dans le livre de J. Delmas les photos en p 88/89 sont explicites.

Citation de: olivier1010 le Septembre 17, 2015, 02:13:37
Je crée ces profils écrans en icc V4, avec l'option "reflect black level in tone curve" activée (réglage par défaut), sauf pour une cible afin de voir la différence. Cette option est importante car elle permet de mapper le début de la tone curve sur le point noir réel mesuré, ou bien si on la désactive sur un point noir fictif à 0 cd/m² qui se trouve donc en dessous du point noir mesuré. Ce dernier se trouve à 0.12 cd/m² sur mon écran pour un point blanc à 100 cd/m² soit un contraste de 864 : 1.

L'explication en anglais de cette option :

"Basically anything other than OLED doesn't allow for perfect black so you can either use true pitch black as the starting point or decide to uses the darkest black that the monitor can show for how it's currently set as the starting point.

You can have the monitor calibrate itself using it's darkest tone as the dark point and then it gets no missing blacks so sending 1,1,1 to the screen shows a trace brighter than 0,0,0 or you can have it calibrate to true pitch black and then it might take until maybe tones 2,2,2 or even 9,9,9 to show as different from 0,0,0."
Je ne vois pas trop l'intérêt de désactiver cette option, sauf pour des raisons de compatibilité si un logiciel va lire la valeur de noir dans le profil (je crois que c'est possible en V4) et appliquer lui même un offset sur la tone curve, auquel cas il faudrait désactiver l'option "reflect black level in tone curve" dans le logiciel qui crée le profil et la calibration écran. Dans ce cas également la calibration écran devrait logiquement réserver une zone morte entre le noir fictif à 0 et le noir mesurée au lieu de faire débuter la calibration hardware sur le noir mesuré.

Il me faut maintenant extraire les courbes LUT TRC des profils écrans, j'utilise iccdump qui me donne des valeurs entre 0 et 1. Je dois convertir en valeurs 16 bits pour correspondre avec vos valeurs. Vous avez utilisé quel utilitaire pour extraire vos valeurs en entiers 16 bits ?

j'utilise très peu ou pas les icc en V4 car tous les CMM ne les gèrent pas et les applications  photos n'utilisent pas leurs nombreuses possibilités.
Ce black level semble correspondre à une compensation du point noir. Attention la techno des Oled est assez particulière et de mémoire pas comparable à nos dalles IPS.

j'utilise icc profil inspector (mais j'ai également icc dump)

Je te confirme qu'avec ColorNavigator il y a un offset sur la TRC L*, et c'est encore pire avec une TRC de 2,2 ! je vais regarder si je ne fais pas une erreur dans les options de réalisation du profil (en icc V2).  Mais ce problème n'est pas celui de Christophe Metairie, j'aurais tendance à penser à un problème de cohérence de profil ou de transformation dans le process de réalisation l'image avant l'impression (avec le profil dédié encre /papier).

CitationC'est surprenant, car sur mon écran je vois bien la différence entre L* et 2,2, je n'ai pas fait d'essais particuliers avec d'autres valeurs, mais dans le livre de J. Delmas les photos en p 88/89 sont explicites.

Je dois faire des repros écran pour vérifier. Il y a peut être une différence mais le temps de redémarrage de Lightroom m'empêche de la voir.

Vous êtes en 24 bits ou 30 bits pour la liaison écran ?

Citation de: olivier1010 le Septembre 17, 2015, 20:23:10
Et un agrandissement de la partie basse.

On remarque L* n'est vraiment très différente d'un gamma que jusqu'à la valeur 2500 environ, soit une luminance très faible de 4%. mais on remarque quand même une différence de forme de la courbe jusqu'à environ 10000, soit 16% de luminance, par rapport à un gamma de 2.4.
Les petites ondulations dans les courbes sont dues je pense à l'arrondi sur l'axe des abscisses qui n'est pas en nombres entier à l'origine une fois extrait du profil.

Voici le résultat que j'ai, si tu pouvais faire "une loupe" du bas de ta courbe, je me demande si elle commence à zéro?
Le départ serait lié au noir mini de la dalle ? du ratio de contraste demandé ou possible?

Citation de: olivier1010 le Septembre 17, 2015, 23:14:52
Je dois faire des repros écran pour vérifier. Il y a peut être une différence mais le temps de redémarrage de Lightroom m'empêche de la voir.

Vous êtes en 24 bits ou 30 bits pour la liaison écran ?

en HDMI, de mémoire je dirais en 3 x 8, mais joker, il faut que je révise  :D

Citation de: olivier1010 le Septembre 17, 2015, 23:14:52
Vous êtes en 24 bits ou 30 bits pour la liaison écran ?

En ce qui me concerne, 30 bits (Nec PA241w + ATI FirePro V5800 + câble DisplayPort).
(au moins sous Photoshop CS6. Pour les autres logiciels, je ne sais pas si c'est géré...)

Citation de: Miaz3 le Septembre 17, 2015, 21:51:23
Effectivement ce n'est pas ça.
Olivier1010 parlait du dela maxi, venant de la vidéo je me demande ce que le delta signifie.
Car en vidéo et CG il y a plusieurs méthodes de travail, dont celle-ci, qui consiste à travailler sur des fichiers linéaires (sans profil colorimétrique) afin d'avoir le minimum d'approximation.
Le travail sous LUT (normalisée (aces, spi, ocio)) ce fait donc en temps réel.
Suivant les logiciels des paramètres sont prédéfinit, comme pour le moniteur qui par défaut est sur sRGB, les fichier en 8-bit en sRGB aussi. Les fichier log pour du cineon et le float pour les fichier linéaire...ect, ect.

bref, partant du constat que je n'y connais pas grand chose en étalonnage d'écran je suis partis sur cette déduction de correction de gamma,  end to end > réponse linéaire > 1, ou 1 peut varier en fonction du type de support utilisé + perception.

Puis finalement après recherche sur la toile il c'est avéré que non, j'étais à coté de la plaque ;) il s'agissait du delta E.

Delta E correspond à un écart entre 2 couleurs, calculé dans l'espace L*a*b*,perceptuel, donc représentatif du ressenti de la vision humaine). un autre lien ou tu trouveras beaucoup de chose, c'est un site de référence  : http://www.brucelindbloom.com/ (http://www.brucelindbloom.com/), il y les équations des "Delta E"

Citation de: Verso92 le Septembre 17, 2015, 23:21:39
En ce qui me concerne, 30 bits (Nec PA241w + ATI FirePro V5800 + câble DisplayPort).
(au moins sous Photoshop CS6. Pour les autres logiciels, je ne sais pas si c'est géré...)

Oui le Displayport permet le 3 x 10 bits, c'est plus adapté pour la vidéo de qualité, mais mon PC n'a pas cet interface, le prochain?

Citation de: MBe le Septembre 17, 2015, 23:19:41
en HDMI, de mémoire je dirais en 3 x 8, mais joker, il faut que je révise  :D

Il faudrait une liaison HDMI 2.0 pour pouvoir passer 30 bits de mémoire. En pratique c'est Display Port sur les Eizo actuellement pour le 30 bits. Ca doit être idem sur les autres marques.

Vous pouvez tester avec le fichier test dispo ici :

http://www.imagescience.com.au/kb/getattachment.php?data=MTUyfDEwIGJpdCB0ZXN0IHJhbXAuemlw

Vous ne devez voir aucun banding si vous êtes en 30 bits.

des infos ici :

http://www.imagescience.com.au/kb/questions/152/10+Bit+Output+Support

Citation de: Nikojorj le Septembre 17, 2015, 08:20:42
C'est bien pour ça que je me demande quel est l'intérêt de tripatouiller la courbe de contraste de l'espace de travail, oui.

Je partage totalement ton avis, aucun intérêt dans un espace de travail d'avoir une TRC différente de 1, la gestion des couleurs se charge correctement des transferts.

Citation de: MBe le Septembre 17, 2015, 23:28:53
Oui le Displayport permet le 3 x 10 bits, c'est plus adapté pour la vidéo de qualité, mais mon PC n'a pas cet interface, le prochain?

Suffit de changer la carte vidéo.

CitationLe départ serait lié au noir mini de la dalle ? du ratio de contraste demandé ou possible?

Oui le départ correspond au noir mini.

Voici les valeurs pour le Lstar avec l'option RBL activé (désolé c'est pas la même échelle que vous) :

BEGIN_LUT In_Out 1 1
IN OUT
  0.000   0.117
  0.392   0.160
  0.784   0.203
  1.176   0.246
  1.569   0.288
  1.961   0.331
  2.353   0.375
  2.745   0.418
  3.137   0.461
  3.529   0.504
  3.922   0.546
  4.314   0.589
  4.706   0.632
  5.098   0.676
  5.490   0.719
  5.882   0.761
  6.275   0.804
  6.667   0.847
  7.059   0.890
  7.451   0.934
  7.843   0.980
  8.235   1.025
  8.627   1.074
  9.020   1.123
  9.412   1.175
  9.804   1.227
10.196   1.282
10.588   1.337
10.980   1.395
11.373   1.454
11.765   1.514
12.157   1.576
12.549   1.640
12.941   1.706
13.333   1.773
13.725   1.842
14.118   1.913
14.510   1.987
14.902   2.060
15.294   2.136
15.686   2.216
16.078   2.295
16.471   2.377
16.863   2.461
17.255   2.547
17.647   2.635
18.039   2.725
18.431   2.817
18.824   2.910
19.216   3.006
19.608   3.105
20.000   3.204
20.392   3.307
20.784   3.412
21.176   3.519
21.569   3.627
21.961   3.738
22.353   3.851
22.745   3.967
23.137   4.085
23.529   4.205
23.922   4.327
24.314   4.453
24.706   4.579
25.098   4.709
25.490   4.842
25.882   4.976
26.275   5.113
26.667   5.252
27.059   5.394
27.451   5.539
27.843   5.686
28.235   5.835
28.627   5.988
29.020   6.143
29.412   6.300
29.804   6.461
30.196   6.624
30.588   6.789
30.980   6.958
31.373   7.129
31.765   7.303
32.157   7.480
32.549   7.659
32.941   7.842
33.333   8.026
33.725   8.214
34.118   8.406
34.510   8.600
34.902   8.797
35.294   8.997
35.686   9.200
36.078   9.406
36.471   9.615
36.863   9.827
37.255  10.042
37.647  10.260
38.039  10.481
38.431  10.707
38.824  10.935
39.216  11.165
39.608  11.400
40.000  11.638
40.392  11.879
40.784  12.123
41.176  12.370
41.569  12.621
41.961  12.876
42.353  13.132
42.745  13.393
43.137  13.658
43.529  13.925
43.922  14.197
44.314  14.472
44.706  14.751
45.098  15.032
45.490  15.317
45.882  15.607
46.275  15.900
46.667  16.196
47.059  16.497
47.451  16.800
47.843  17.107
48.235  17.418
48.627  17.733
49.020  18.051
49.412  18.373
49.804  18.700
50.196  19.030
50.588  19.364
50.980  19.702
51.373  20.044
51.765  20.389
52.157  20.739
52.549  21.093
52.941  21.450
53.333  21.811
53.725  22.177
54.118  22.547
54.510  22.921
54.902  23.299
55.294  23.680
55.686  24.067
56.078  24.457
56.471  24.852
56.863  25.251
57.255  25.653
57.647  26.061
58.039  26.473
58.431  26.888
58.824  27.309
59.216  27.733
59.608  28.162
60.000  28.595
60.392  29.033
60.784  29.476
61.176  29.921
61.569  30.373
61.961  30.829
62.353  31.289
62.745  31.754
63.137  32.222
63.529  32.697
63.922  33.176
64.314  33.658
64.706  34.147
65.098  34.640
65.490  35.137
65.882  35.639
66.275  36.146
66.667  36.657
67.059  37.174
67.451  37.694
67.843  38.221
68.235  38.752
68.627  39.287
69.020  39.828
69.412  40.374
69.804  40.925
70.196  41.480
70.588  42.042
70.980  42.606
71.373  43.177
71.765  43.754
72.157  44.334
72.549  44.920
72.941  45.512
73.333  46.108
73.725  46.709
74.118  47.315
74.510  47.927
74.902  48.545
75.294  49.168
75.686  49.795
76.078  50.428
76.471  51.066
76.863  51.710
77.255  52.360
77.647  53.014
78.039  53.674
78.431  54.339
78.824  55.010
79.216  55.688
79.608  56.368
80.000  57.057
80.392  57.749
80.784  58.448
81.176  59.153
81.569  59.863
81.961  60.578
82.353  61.300
82.745  62.026
83.137  62.759
83.529  63.497
83.922  64.242
84.314  64.991
84.706  65.748
85.098  66.509
85.490  67.277
85.882  68.051
86.275  68.829
86.667  69.615
87.059  70.407
87.451  71.203
87.843  72.006
88.235  72.816
88.627  73.631
89.020  74.452
89.412  75.279
89.804  76.114
90.196  76.953
90.588  77.798
90.980  78.650
91.373  79.509
91.765  80.372
92.157  81.244
92.549  82.119
92.941  83.003
93.333  83.893
93.725  84.788
94.118  85.690
94.510  86.600
94.902  87.514
95.294  88.435
95.686  89.363
96.078  90.297
96.471  91.238
96.863  92.184
97.255  93.140
97.647  94.099
98.039  95.067
98.431  96.040
98.824  97.020
99.216  98.007
99.608  99.001
100.000 100.000

Et sans l'option RBL :

BEGIN_LUT In_Out 1 1
IN OUT
  0.000   0.000
  0.392   0.043
  0.784   0.085
  1.176   0.130
  1.569   0.172
  1.961   0.215
  2.353   0.258
  2.745   0.301
  3.137   0.343
  3.529   0.388
  3.922   0.430
  4.314   0.473
  4.706   0.516
  5.098   0.558
  5.490   0.603
  5.882   0.645
  6.275   0.688
  6.667   0.731
  7.059   0.774
  7.451   0.818
  7.843   0.864
  8.235   0.909
  8.627   0.958
  9.020   1.007
  9.412   1.059
  9.804   1.111
10.196   1.166
10.588   1.221
10.980   1.279
11.373   1.338
11.765   1.398
12.157   1.460
12.549   1.524
12.941   1.590
13.333   1.657
13.725   1.727
14.118   1.798
14.510   1.871
14.902   1.946
15.294   2.022
15.686   2.100
16.078   2.181
16.471   2.261
16.863   2.345
17.255   2.432
17.647   2.519
18.039   2.609
18.431   2.702
18.824   2.795
19.216   2.892
19.608   2.989
20.000   3.090
20.392   3.192
20.784   3.297
21.176   3.404
21.569   3.513
21.961   3.624
22.353   3.737
22.745   3.853
23.137   3.970
23.529   4.091
23.922   4.215
24.314   4.338
24.706   4.466
25.098   4.596
25.490   4.729
25.882   4.863
26.275   5.000
26.667   5.139
27.059   5.281
27.451   5.426
27.843   5.574
28.235   5.724
28.627   5.876
29.020   6.030
29.412   6.189
29.804   6.349
30.196   6.513
30.588   6.677
30.980   6.847
31.373   7.018
31.765   7.192
32.157   7.369
32.549   7.549
32.941   7.730
33.333   7.916
33.725   8.104
34.118   8.296
34.510   8.490
34.902   8.687
35.294   8.887
35.686   9.091
36.078   9.297
36.471   9.506
36.863   9.718
37.255   9.934
37.647  10.153
38.039  10.375
38.431  10.599
38.824  10.828
39.216  11.058
39.608  11.293
40.000  11.531
40.392  11.772
40.784  12.016
41.176  12.264
41.569  12.515
41.961  12.770
42.353  13.028
42.745  13.289
43.137  13.553
43.529  13.822
43.922  14.093
44.314  14.368
44.706  14.647
45.098  14.929
45.490  15.215
45.882  15.505
46.275  15.798
46.667  16.094
47.059  16.394
47.451  16.698
47.843  17.006
48.235  17.317
48.627  17.633
49.020  17.952
49.412  18.274
49.804  18.601
50.196  18.932
50.588  19.266
50.980  19.605
51.373  19.947
51.765  20.293
52.157  20.642
52.549  20.996
52.941  21.353
53.333  21.717
53.725  22.083
54.118  22.452
54.510  22.826
54.902  23.204
55.294  23.587
55.686  23.973
56.078  24.364
56.471  24.759
56.863  25.159
57.255  25.562
57.647  25.971
58.039  26.383
58.431  26.798
58.824  27.219
59.216  27.645
59.608  28.074
60.000  28.507
60.392  28.946
60.784  29.389
61.176  29.836
61.569  30.288
61.961  30.744
62.353  31.205
62.745  31.670
63.137  32.140
63.529  32.615
63.922  33.094
64.314  33.577
64.706  34.066
65.098  34.559
65.490  35.056
65.882  35.560
66.275  36.066
66.667  36.579
67.059  37.096
67.451  37.618
67.843  38.145
68.235  38.676
68.627  39.213
69.020  39.754
69.412  40.301
69.804  40.851
70.196  41.408
70.588  41.968
70.980  42.536
71.373  43.107
71.765  43.684
72.157  44.265
72.549  44.851
72.941  45.443
73.333  46.041
73.725  46.642
74.118  47.250
74.510  47.863
74.902  48.481
75.294  49.104
75.686  49.732
76.078  50.367
76.471  51.005
76.863  51.650
77.255  52.300
77.647  52.955
78.039  53.616
78.431  54.282
78.824  54.954
79.216  55.631
79.608  56.315
80.000  57.003
80.392  57.697
80.784  58.396
81.176  59.101
81.569  59.812
81.961  60.529
82.353  61.251
82.745  61.979
83.137  62.713
83.529  63.452
83.922  64.196
84.314  64.948
84.706  65.705
85.098  66.467
85.490  67.236
85.882  68.009
86.275  68.791
86.667  69.577
87.059  70.369
87.451  71.167
87.843  71.971
88.235  72.781
88.627  73.597
89.020  74.420
89.412  75.248
89.804  76.083
90.196  76.924
90.588  77.771
90.980  78.624
91.373  79.483
91.765  80.348
92.157  81.219
92.549  82.098
92.941  82.982
93.333  83.873
93.725  84.768
94.118  85.672
94.510  86.581
94.902  87.498
95.294  88.420
95.686  89.349
96.078  90.285
96.471  91.226
96.863  92.175
97.255  93.130
97.647  94.092
98.039  95.059
98.431  96.034
98.824  97.015
99.216  98.004
99.608  98.999
100.000 100.000

Citation de: olivier1010 le Septembre 17, 2015, 23:29:11
Il faudrait une liaison HDMI 2.0 pour pouvoir passer 30 bits de mémoire. En pratique c'est Display Port sur les Eizo actuellement pour le 30 bits. Ca doit être idem sur les autres marques.

Vous pouvez tester avec le fichier test dispo ici :

http://www.imagescience.com.au/kb/getattachment.php?data=MTUyfDEwIGJpdCB0ZXN0IHJhbXAuemlw

Vous ne devez voir aucun banding si vous êtes en 30 bits.

des infos ici :

http://www.imagescience.com.au/kb/questions/152/10+Bit+Output+Support

Merci je vais regarder cela demain...

SI tu peux me dire pour le départ de ta courbe L* de ton profil, cela m' a donné des idées (et du travail ;))

Merci beaucoup pour tes courbes et tes commentaires sur ce sujet.

Citation de: olivier1010 le Septembre 17, 2015, 23:34:53
Suffit de changer la carte vidéo.

Oui le départ correspond au noir mini.
[...]

Super (l'échelle n'est pas un problème...), merci, nos messages se sont croisés, cela voudrait dire qu'il y a correspondance avec le départ de la courbe et le niveau de noir possible sur la dalle (probablement en fonction des valeurs cibles demandées). Je vais regarder.
Tu es en icc V2 ou V4 pour ton profil d'écran? (le codage de l'échelle provient peut être également de l'outil utilisé pour lire les données ?)
Tu utilises bien ColorNavigator6? (moi également, en icc V2)

Oui pour la carte graphique, mais sur un portable, c'est compliqué, il faut changer le processeur graphique ???

Citation de: MBe le Septembre 17, 2015, 23:28:53
Oui le Displayport permet le 3 x 10 bits, c'est plus adapté pour la vidéo de qualité, mais mon PC n'a pas cet interface, le prochain?

Rhôôôô, MBe... mon PC est pourtant un vieux clou (5 ans) !

;-)

Citation de: Verso92 le Septembre 17, 2015, 23:49:12
Rhôôôô, MBe... mon PC est pourtant un vieux clou (5 ans) !

;-)

Le mien doit pas en être très loin...mais c'est dans les vieux pots que l'on fait... :)

Citation de: MBe le Septembre 17, 2015, 23:43:49
Super (l'échelle n'est pas un problème...), merci, nos messages se sont croisés, cela voudrait dire qu'il y a correspondance avec le départ de la courbe et le niveau de noir possible sur la dalle (probablement en fonction des valeurs cibles demandées). Je vais regarder.
Tu es en icc V2 ou V4 pour ton profil d'écran? (le codage de l'échelle provient peut être également de l'outil utilisé pour lire les données ?)
Tu utilises bien ColorNavigator6? (moi également, en icc V2)

Oui pour la carte graphique, mais sur un portable, c'est compliqué, il faut changer le processeur graphique ???

Oui oui il y a correspondance avec le noir mini mesuré. Je suis en V4, mais en regardant les mêmes profils en V2 je ne vois aucune différence. A mon avis la version du profil pour un profil écran ne change rien. En tout cas pour un profil ColorNavigator. La seule différence c'est qu'en V4 on peut en théorie ajouter d'autres données comme la valeur en luminance du point noir et utiliser des courbes paramétriques pour décrire les courbes tonales. La V4 impose le tag d'adaptation chromatique mais il est présent aussi en V2 avec ColorNavigator. Les deux matrices sont néanmoins légèrement différente entre V2 et V4 dans ce tag.

Oui le codage doit provenir de l'utilitaire pour extraire les LUT. J'utilise profiledump.

http://www.color.org/wxProfileDump.zip

http://www.color.org/profdump.xalter

Je pense que le codage dans le profil lui même est en 16 bits entier. Il doit exister la possibilité de coder en float dans un profile V4 mais je ne suis pas sur que ce soit applicable pour les courbes LUT 1D. à vérifier mais cela n'a pas d'importance dans le contexte de toutes façons.

J'utilise bien ColorNavigator 6.4. Avec génération de profile vers V4. il n'y a aucune raison que les courbes tonales soit différentes entre V2 et V4.
Je vais créer une cible de validation avec un tas de patchs en niveaux de gris, pour vérifier la différence de delta E moyen et de Delta E maxi entre une calibration L* et gamma 2.2. A mon avis il n'y aura pas grande différence avec une liaison 30 bits. En tout cas rien qui ne pourrait expliquer les différences vues sur l'exemple de Christophe.

Il faudrait regarder à l'intérieur de ses profils, voir s'il n'y aurait pas des tags gamma 2.2 ou 2.4 qui trainent et perturbent la lecture des LUT L*. Il me semble qu'il utilise des écrans Dell et Basiccolor Display 5 pour la calibration ?

ColorNavigator, je rigole ... cette merde ... idem LR

un EIZO + basICColor display, et là on en reparle ...
MBe et son gamma lineaire, tu as une altération ou quoi ?

C'est bien connu les Ig de chez Eizo ne sont que des billes  ;D ;D ;D

Juste un truc au passage, sait on si El Capitan le prochain OSX autorisera l'affichage 3x10 bits?
Car jusqu'à présent sous Mac on est cantonné au 3x8 bits, perso je le vis très bien, tout comme avec ColorNavigator d'ailleurs n'en déplaise à Salomé.

 [at]   Benaparis

Je t'ai fait découvrir le Lstar (encore faut il savoir s'en servir), et bien maintenant tu vas découvrir "basICColor display".

Je sais que cela te fait mal au gland d'apprendre que ton ColoNavigator (sur ton CG à 2000 Euros) n'est pas au niveau tant espéré mais c'est la réalité.

Il est disponible gratuitement pendant 14 jours :

http://www.basiccolor.de/basiccolor-display-5-en/
Un conseil à tous : lisez le PDF vous allez en apprendre ...

Est-ce que l'affichage 3x10bits ne dépend pas de la carte graphique ?
Sur PC j'ai la carte Quadro 2000 qui affiche le 3x10 bits.
Mais bon, je me sens mieux sur MAC et puis je suis prête à faire le deuil de CN

Citation de: ambre099 le Septembre 18, 2015, 11:19:41
Est-ce que l'affichage 3x10bits ne dépend pas de la carte graphique ?
Sur PC j'ai la carte Quadro 2000 qui affiche le 3x10 bits.
Mais bon, je me sens mieux sur MAC et puis je suis prête à faire le deuil de CN

bonjour,

As-tu une Quadro 2000 uniquement pour le 30bits??  avec quel écran?

Citation de: fred94- le Septembre 18, 2015, 11:55:53
bonjour,

As-tu une Quadro 2000 uniquement pour le 30bits??  avec quel écran?

Un écran Eizo CG243W.
J'avais soigneusement choisi tous les composants du PC pour la photo avec pour objectif de passer au moyen format.
Mais à partir du moment où j'ai migré sous win 8 le temps passé à régler les problèmes lié au système d'exploitation était supérieur au temps passé à traiter mes images.
Je suis donc passée sur MAC Pro.

Citation de: Salomé_B le Septembre 18, 2015, 11:16:47[at]   Benaparis

Je t'ai fait découvrir le Lstar (encore faut il savoir s'en servir), et bien maintenant tu vas découvrir "basICColor display".

Je sais que cela te fait mal au gland d'apprendre que ton ColoNavigator (sur ton CG à 2000 Euros) n'est pas au niveau tant espéré mais c'est la réalité.

Il est disponible gratuitement pendant 14 jours :

http://www.basiccolor.de/basiccolor-display-5-en/


Un conseil à tous : lisez le PDF vous allez en apprendre ...

Pascal sort de ce corps 😂😂😂

Je te rassures, ou pas d'ailleurs, mais puisque l'on évoque les parties basses ça m'en touche une sans secouer l'autre...ça ne me fait mal nul part parceque cela fait bien longtemps que je me serai plaint ou aurai cherché des solutions pour résoudre des problèmes lors de tirages pour mes expositions entres autres...le fait est que tout va bien et quand je fais partir une commande qui coûte plusieurs fois le prix de l'Eizo je continue de dormir sur mes deux oreilles sans avoir à passer des heures avec le labo pour corriger une mauvaise source...je dois pas si mal me démerder en fin de compte 😉
Mais puisqu'il faut rendre à César ce qui appartient César je te sais gré de m'avoir remis dans la voie du L*, qui m'avait été conseillé il y a quelques années déjà par OlivierP quand j'utilisais ColorEyes Display Pro (quand on connait les personnes qui sont derrière ce soft ainsi que Display l'histoire est assez amusante), mais j'avoue ne pas avoir été à l'aise et suis retourné à mon Gamma 2.2 et à l'espace AdobeRVB jusqu'au mois de mai dernier...certes pas franchement idéal j'en conviens le plus volontiers du monde, mais sans surprises et c'est tout sauf négligeable pour ne pas dire essentiel quand on produit et pas quand on joue au savant ...Bref, le fameux pragmatisme. Mais encore une fois j'apprecie le gain réel mais objectivement marginal du L* dans ma configuration.
Quand à Basiccolor Display plutôt que de lire un document commercial je vais directement m'adresser à Franz qui m'en avais déjà touché un mot lors de nos conversations, si tu es aussi bien renseigné(e) que je le crois tu dois savoir précisément de qui je parle 😉
Mais encore une fois si je ne suis pas du tout client de la forme autoritaire et sans mise en perspective pratique, au moins je te reconnais la vertu de donner du grain à moudre et de secouer le cocotier.

Bonne journée à toi et aux autres.

Citation de: Benaparis le Septembre 18, 2015, 12:44:52
Pascal sort de ce corps 😂😂😂

Rhôôô ils sont grands ils font ce qu'ils veulent!

Citation de: ambre099 le Septembre 18, 2015, 12:05:45
Un écran Eizo CG243W.
J'avais soigneusement choisi tous les composants du PC pour la photo avec pour objectif de passer au moyen format.
Mais à partir du moment où j'ai migré sous win 8 le temps passé à régler les problèmes lié au système d'exploitation était supérieur au temps passé à traiter mes images.
Je suis donc passée sur MAC Pro.

salut,

ah ok dans un Macpro je passe mon tour ^^

par contre sur ce sont des AMD dans ton Macpro?

En fait pour ceux qui sont en windows perso je ne pense pas que cela soit vraiment nécessaire d'acheter une quadro à 500€ juste pour le 30bits. Pour l'instant j'ai un DELL U2413 pas trop mal même si effectivement à l'affichage il y a des cassures mais bon on verra lors de mes premières impression directement avec un fichier .eip. :D

Citation de: fred94- le Septembre 18, 2015, 13:24:12
salut,

ah ok dans un Macpro je passe mon tour ^^

par contre sur ce sont des AMD dans ton Macpro?

En fait pour ceux qui sont en windows perso je ne pense pas que cela soit vraiment nécessaire d'acheter une quadro à 500€ juste pour le 30bits. Pour l'instant j'ai un DELL U2413 pas trop mal même si effectivement à l'affichage il y a des cassures mais bon on verra lors de mes premières impression directement avec un fichier .eip. :D

Salut
AMD FirePro D500 3072 Mo sur MAC
Oui, mais tout dépend de l'importance qu'on donne au chose.
Pour moi l'informatique c'est une drogue... très néfaste dans les relations humaines.... mais bon  :(

Je viens d'essayer le basiccolor pour le calibrage de l'écran.
J'ai l'erreur 2 qui s'est pointée lors de la mesure de la lumière ambiante et impossible de sortir du système.
Je relance le tout et j'obtiens la même erreur  ???

Citation de: ambre099 le Septembre 18, 2015, 11:19:41
Est-ce que l'affichage 3x10bits ne dépend pas de la carte graphique ?
Sur PC j'ai la carte Quadro 2000 qui affiche le 3x10 bits.
Mais bon, je me sens mieux sur MAC et puis je suis prête à faire le deuil de CN

Il faut :
- que l'écran soit capable d'afficher le 3 x 10 bits,
- que la carte graphique soit capable de le gérer (hard, mais aussi pilote),
- que la connexion entre la CG et l'écran l'autorise,
- que l'OS le permette,
- que le logiciel le prenne en compte.
En ce qui me concerne, j'ai bien fait attention que tous ces éléments soient réunis (mais j'ai un vieux PC de 5 ans, aussi...).

Citation de: ambre099 le Septembre 18, 2015, 11:19:41
Est-ce que l'affichage 3x10bits ne dépend pas de la carte graphique ?
Sur PC j'ai la carte Quadro 2000 qui affiche le 3x10 bits.
Mais bon, je me sens mieux sur MAC et puis je suis prête à faire le deuil de CN

L'affichage en 3x10 bits dépend effectivement de la carte graphique mais pas seulement. Le système doit aussi le prendre en charge, il doit être activé dans le driver de la carte, et l'application également doit savoir ouvrir une fenêtre de rendu OpenGL en 10 bits par canal ce qui n'est le cas que de quelques rares applications comme Lightroom et Photoshop. Il y en a peut être d'autres maintenant mais je ne les connais pas.

Enfin, sous windows, le 3 x 10 bits est rendu inopérant par un bureau en mode aéro... Il faut choisir un thème basique.

Cela dépend aussi de la liaison entre la carte vidéo et l'écran. Actuellement en pratique c'est le Display Port qui supporte ce mode, dans l'avenir HDMI devrait aussi le supporter.

Et évidement l'écran doit posséder une dalle 8 bits FRC  ou une vrai dalle 10 bits ainsi que le processing et la liaison vidéo qui vont avec. Le 8 bits FRC (frame rate control) permet de simuler une quantification 10 bits par multiplexage temporel. Pour la photo on ne voit pas la différence entre 8 bits FRC et 10 bits, mais en vidéo le 8 bits FRC peut créer de l'aliasing puisqu'il risque d'interagir avec la cadence élevée des images.

Donc attention, le 10 bits c'est pointu à mettre en place. Il faut vérifier avec le fichier ramp.psd pour être certain que c'est actif.
A ma connaissance sur Mac ce n'est pas encore pris en charge. Mais vous avez l'impression 16 bits en contrepartie sans passer par un RIP :)
Sur PC aussi l'impression 16 bits existe avec le modèle de driver XPS, mais ce n'est pas pris en charge par Epson à ma connaissance. Donc RIP obligatoire pour aller au delà de 8 bits en impression, ce qui sera certainement de plus en plus utile avec les espaces couleurs très large qu'on peut obtenir aujourd'hui sur une Epson (99 % du Pantone solid aux dernières nouvelles !! )

Citation de: ambre099 le Septembre 18, 2015, 13:40:13
Je viens d'essayer le basiccolor pour le calibrage de l'écran.
J'ai l'erreur 2 qui s'est pointée lors de la mesure de la lumière ambiante et impossible de sortir du système.
Je relance le tout et j'obtiens la même erreur  ???

error 2 avec un Eizo?

look ici: http://www.basiccolor.de/faqs-en/

Citation de: fred94- le Septembre 18, 2015, 14:25:16
error 2 avec un Eizo?

look ici: http://www.basiccolor.de/faqs-en/

Merci pour le lien
Je suis en DisplayPort sur TB2, ça ne devrait pas poser de problème.

Citation de: olivier1010 le Septembre 18, 2015, 14:21:33
L'affichage en 3x10 bits dépend effectivement de la carte graphique mais pas seulement. Le système doit aussi le prendre en charge, il doit être activé dans le driver de la carte, et l'application également doit savoir ouvrir une fenêtre de rendu OpenGL en 10 bits par canal ce qui n'est le cas que de quelques rares applications comme Lightroom et Photoshop. Il y en a peut être d'autres maintenant mais je ne les connais pas.

Enfin, sous windows, le 3 x 10 bits est rendu inopérant par un bureau en mode aéro... Il faut choisir un thème basique.

Cela dépend aussi de la liaison entre la carte vidéo et l'écran. Actuellement en pratique c'est le Display Port qui supporte ce mode, dans l'avenir HDMI devrait aussi le supporter.

Et évidement l'écran doit posséder une dalle 8 bits FRC  ou une vrai dalle 10 bits ainsi que le processing et la liaison vidéo qui vont avec. Le 8 bits FRC (frame rate control) permet de simuler une quantification 10 bits par multiplexage temporel. Pour la photo on ne voit pas la différence entre 8 bits FRC et 10 bits, mais en vidéo le 8 bits FRC peut créer de l'aliasing puisqu'il risque d'interagir avec la cadence élevée des images.

Donc attention, le 10 bits c'est pointu à mettre en place. Il faut vérifier avec le fichier ramp.psd pour être certain que c'est actif.
A ma connaissance sur Mac ce n'est pas encore pris en charge. Mais vous avez l'impression 16 bits en contrepartie sans passer par un RIP :)
Sur PC aussi l'impression 16 bits existe avec le modèle de driver XPS, mais ce n'est pas pris en charge par Epson à ma connaissance. Donc RIP obligatoire pour aller au delà de 8 bits en impression, ce qui sera certainement de plus en plus utile avec les espaces couleurs très large qu'on peut obtenir aujourd'hui sur une Epson (99 % du Pantone solid aux dernières nouvelles !! )

Merci pour ces explications.
Dans le cadre de l'utilisation de Capture One l'OpenCL peut être activée, mais pas l'affichage 10bits.  C'est ce que j'ai compris.
Donc je n'ai pas eu de réticence à quitter PC pour MAC.

Citation de: ambre099 le Septembre 18, 2015, 15:35:40
Merci pour ces explications.
Dans le cadre de l'utilisation de Capture One l'OpenCL peut être activée, mais pas l'affichage 10bits.  C'est ce que j'ai compris.
Donc je n'ai pas eu de réticence à quitter PC pour MAC.

Oui OpenCL et affichage 10 bits sont deux choses différentes.

OpenCL est une interface de programmation qui permet de dialoguer de façon standardisée avec un système de calcul fortement parallèle, comme celui qu'on peut trouver dans une carte vidéo, mais pas seulement. OpenCL sert donc en général à l'accélération des fonctions graphiques d'une application. Il existe aussi CUDA qui est un similaire mais propriétaire (Nvidia).

C'est OpenGL et non pas OpenCL, interface de programmation pour l'affichage en 3D, qui permet l'affichage en 10 bits. Direct X le permet aussi je crois dans sa dernière version à condition de faire le rendu sur une fenêtre Direct X plein écran. Les applications graphiques utilisent pour le moment OpenGL.

Citation de: olivier1010 le Septembre 18, 2015, 16:04:41
Les applications graphiques utilisent pour le moment OpenGL.

are you sure?

https://www.phaseone.com/en/Search/Article.aspx?articleid=1720 (https://www.phaseone.com/en/Search/Article.aspx?articleid=1720)

Citation de: olivier1010 le Septembre 18, 2015, 14:21:33
A ma connaissance sur Mac ce n'est pas encore pris en charge. Mais vous avez l'impression 16 bits en contrepartie sans passer par un RIP :)

En tout cas de manière certaine jusqu'à l'actuel système Yosemite...Quid de El Capitan qui sera dispo fin de mois. Pour l'impression chez moi en effet je coche l'impression 16bits puisque j'imprime directement depuis mes masters sur mon Epson, donc j'en profite mais surtout parceque je peux le faire sans autre motivation particulière...En revanche pour mes prestataires vu que les fichiers n'ont pas besoin d'être repris je livre des Tiff 8 bits (voire des Jpeg)...je n'ai pas constaté de différence particulières.

Citation de: olivier1010 le Septembre 18, 2015, 14:21:33Sur PC aussi l'impression 16 bits existe avec le modèle de driver XPS, mais ce n'est pas pris en charge par Epson à ma connaissance. Donc RIP obligatoire pour aller au delà de 8 bits en impression, ce qui sera certainement de plus en plus utile avec les espaces couleurs très large qu'on peut obtenir aujourd'hui sur une Epson (99 % du Pantone solid aux dernières nouvelles !! )

Si l'interêt de l'impression 16 bits réside essentiellement dans la possibilité de s'approcher au plus de la gamme Pantone, alors l'interêt en photographie devient très discutable. Les fameuses nouvelles Espon SureColor 7000 et 9000 avec le système 10 encres UltraChrome HDX surtout destinées à l'épreuvage au lieu des 8 des encres Ultrachrome HD (des nouvelles SureColor 6000 et 8000 ainsi que des traceurs de la génération précédente) permettent d'atteindre en effet 99% du Pantone en remplaçant la cartouche Light Light Black par une cartouche violette (sinon c'est 98% sans la cartouche violette), mais cette configuration est impropre à la photographie.

CitationAlso for the P7000 and P9000 printers, Epson provides an alternative Violet ink that shares the same ink stall and can be used instead of the LLK (light-light black) and can be switched as needed. This new Violet ink provides expanded color gamut delivering 99% of the Pantone(R) Formula Guide Solid Coated; something of interest to designers. The Violet ink is not recommended for photos, however.

source : http://www.imaging-resource.com/news/2015/09/14/epsons-new-large-format-printers-blacker-blacks-and-less-ink-waste (http://www.imaging-resource.com/news/2015/09/14/epsons-new-large-format-printers-blacker-blacks-and-less-ink-waste)

Mais si quelqu'un a une bonne expérience de l'impression 16bits pour le domaine de la photographie le sujet mérite bien entendu d'être développé.

Citation de: Benaparis le Septembre 18, 2015, 12:44:52
Pascal sort de ce corps 😂😂😂
[..]

Pascal,... Pascal .... celui qui est déranger  ;)
Non ça n'est pas une faute d'orthographe   :)
;D ;D

99% des pantones mais comme chaque année, il me semble qu'ils en inventent d'autres...

 [at]  ambre099

Je l'utilise depuis plus d'1 an. Il a planté 1 fois suite à l'installation sur OSX 10.9 du fameux ColorNavigator. Après suppression de ce dernier, tout est rentré dans l'ordre. Il ne doit pas aimer les autres soft comme CN ou i1Profiler par exemple ...

Envoi un mail au support, ils vont te répondre.

Courage car il en vaut la peine.

Bye, je retourne à mes études ...

Citation de: Salomé_B le Septembre 18, 2015, 17:49:49
[at]  ambre099

Je l'utilise depuis plus d'1 an. Il a planté 1 fois suite à l'installation sur OSX 10.9 du fameux ColorNavigator. Après suppression de ce dernier, tout est rentré dans l'ordre. Il ne doit pas aimer les autres soft comme CN ou i1Profiler par exemple ...

Envoi un mail au support, ils vont te répondre.

Courage car il en vaut la peine.

Bye, je retourne à mes études ...

Merci Salomé, je tenter de supprimer CN.

J'ai réalisé une cible de validation avec 256 patchs en niveaux de gris pour ColorNavigator, sans aucun patch couleur, pour obtenir une mesure du Delta E moyen et maxi qui caractérise uniquement l'axe des gris.

Voici les résultats de validation sur un écran Eizo CG277 dont la liaison vidéo est en 30 bits :
Gamma 2.2 (D50, Blanc à 100 cd/m², Noir à 0.12 cd/m²) :

- Delta E 2000 moyen : 0.41

- Delta E 2000 maxi : 2.23

- Delta E sur le blanc : 0.19
L* (D50, Blanc à 100 cd/m², Noir à 0.12 cd/m²) :

- Delta E 2000 moyen : 0.37

- Delta E 2000 maxi : 2.21

- Delta E sur le blanc : 0.32
Les différences sont faibles, même si L* est légèrement devant en ce qui concerne les valeurs de Delta E dans les noirs.

Ci dessous les premiers niveaux de noir en gamma 2.2 :

Et ci dessous les premiers niveaux de noir en calibration L*. Le Delta E est un peu meilleur, il descend à 0.42 dès le 10 ème patch, alors que en gamma 2.2 le 10 ème patch est à 1.34. Mais rien d'alarmant. Après le dixième patch, soit tout de même un niveau de noir très bas, le delta E descend rapidement et se stabilise autour de 0.5.

Aux alentours ou en dessous d'un Delta E de 1 il est très difficile de voir une différence à l'œil nu.

Donc rien à mon sens qui puisse expliquer les différences vues sur les exemples de Christophe.

Citation de: Salomé_B le Septembre 18, 2015, 09:54:06
ColorNavigator, je rigole ... cette merde ... idem LR

un EIZO + basICColor display, et là on en reparle ...
MBe et son gamma lineaire, tu as une altération ou quoi ?

Quelle classe!  surtout ne change rien  :P

 [at]  olivier1010

Sur une échelle de gris la tolérance max est de 1.5,
sur mon ecran de MBP (non retina et non 30 bits), j'ai un max à 0.55,
et en chromatique un max à 0.88 (pour une tolérance max de 3).

Faut changer de sonde et surtout de logiciel ...

Citation de: olivier1010 le Septembre 18, 2015, 18:13:19
Donc rien à mon sens qui puisse expliquer les différences vues sur les exemples de Christophe.

Oui avec une grande probabilité, mais sous  réserve que BasiCColor Display + Dell (hypothèse) soit totalement compatible. Les autres hypothèses causales du défaut émises me paraissent  plus pertinentes.

Citation de: Salomé_B le Septembre 18, 2015, 18:33:32
[at]  olivier1010

Sur une échelle de gris la tolérance max est de 1.5,
sur mon ecran de MBP (non retina et non 30 bits), j'ai un max à 0.55,
et en chromatique un max à 0.88 (pour une tolérance max de 3).

Faut changer de sonde et surtout de logiciel ...

Je viens de refaire les tests avec une sonde externe à l'écran, une i1 display pro, les résultats sont très similaires. De toutes façons à moins d'avoir une sonde très haut de gamme il ne faut pas s'attendre à une précision miraculeuse en chrominance autour du noir à 0.12 cd/m².

Ce sont les premiers niveaux seulement qui posent problème en chrominance, si on peut parler de problème car on est quand même en dessous d'un Delta E de 3. Mais si vous regardez bien le Delta en luminance est pratiquement parfait y compris sur les premiers niveaux.

Le but est de caractériser les différences entre L* et gamma 2.2. Pas de lancer une discussion sur la précision des sondes et des logiciels.

Ici les conditions de mesure et de calcul sont les mêmes pour gamma 2.2 et L*. C'est ce qui est important.

Tant mieux si vous avez des résultats encore meilleurs avec un matériel et des logiciels différents mais ce n'est pas le propos du fil.

être juste en dessous de 3 en delta E, c'est un gouffre pour moi. 1,5 est acceptable.

Citation de: olivier1010 le Septembre 18, 2015, 19:16:57
Je viens de refaire les tests avec une sonde externe à l'écran, une i1 display pro, les résultats sont très similaires. De toutes façons à moins d'avoir une sonde très haut de gamme il ne faut pas s'attendre à une précision miraculeuse en chrominance autour du noir à 0.12 cd/m².

Ce sont les premiers niveaux seulement qui posent problème en chrominance, si on peut parler de problème car on est quand même en dessous d'un Delta E de 3. Mais si vous regardez bien le Delta en luminance est pratiquement parfait y compris sur les premiers niveaux.

Le but est de caractériser les différences entre L* et gamma 2.2. Pas de lancer une discussion sur la précision des sondes et des logiciels.

Ici les conditions de mesure et de calcul sont les mêmes pour gamma 2.2 et L*. C'est ce qui est important.

Tant mieux si vous avez des résultats encore meilleurs avec un matériel et des logiciels différents mais vraiment ce n'est pas le propos du fil et votre manque de retenue n'a rien de très attrayant dans une discussion sur la calibration.

Oui, les résultats sont excellents, et c'est bien la mesure relative entre les 2 TRC qui est riche d'enseignement*. A 0,12 cd/m², la mesure est difficile à faire en raison du bruit au niveau de la dalle et du bruit au niveau des capteurs du colorimètre (ce bruit est d'ailleurs l'objet d'un travail de compensation interne).

* En prenant l'hypothèse que le colorimètre à une perception visuelle identique à celle de l'observateur, les écarts relatifs en delta E sont suffisamment faibles pour ne pas être considérés. Jean Delmas a dit cette semaine que la courbe L* était pour les esthètes, ces détracteurs ont compris "élitistes"  ;D (des commentaires supplémentaires n'apporteraient rien quand on en arrive à faire ce type de confusion)

Je viens de refaire un profil L* avec ColorNavigator avec les mêmes valeurs cibles et en décochant "Reflect black level in tone curve", la courbe L* a son point de départ maintenant à 0.  Ce paramètre m'avait échappé...la doc n'est pas très explicite non plus.
je ne suis  pas certain également de voir la différence, car dans les basses lumières, il est pas facile de voir de si petits écarts pour l'œil.

bonsoir,

Alors je mets de côté les 30bits car sur mac....et DELL U2413....pas beaucoup de bits

mais voici les deux rapports en delta E 94 et 2000 et ce en D50 qui à priori est assez difficile d'obtenir en dehors des Eizo...

alors c'est juste pour ceux qui comme moi n'ont pas ou ne veulent pas dépenser pour un eizo.....peut-être que ce DELL finalement....

alors la teinte jaune en D50.....oui et non

oui si vous regardez un écran en sRVB à côté entre deux retouches d'images
non si vous restez devant le DELL pendant votre travail.
et oui le test du dégradé est horrible sur ce modèle mais bon entre dire:

"la plupart des couleurs ne dépassent pas le Srvb"

et

"va falloir trouver l'image qui reproduit un dégradé perfecto comme sur le psd à cet effet"
mon choix est tout fait

bon week
ps: macbook pro retina mi 2012 en OS X 10.9.5

Citation de: fred94- le Septembre 18, 2015, 19:57:36
bonsoir,

Alors je mets de côté les 30bits car sur mac....et DELL U2413....pas beaucoup de bits

mais voici les deux rapports en delta E 94 et 2000 et ce en D50 qui à priori est assez difficile d'obtenir en dehors des Eizo...

Le niveau de noir est à 0.29 cd/m² dans vos mesures. Cela change tout pour le delta E maxi dans les noirs. Dans mon cas je suis à 0.12 cd/m², et j'arrive donc aux limites de la sonde (limite à 0.1 cd/m² sur une display pro).

Mon Delta E max dans les premiers niveaux de noir n'est pas représentatif de la qualité de la calibration mais de celui de la sonde dans les bas niveaux.

Si je refais les mesures avec un noir à 0.29 mon Delta E max va baisser fortement.

Citation de: belnea le Septembre 18, 2015, 19:35:59
être juste en dessous de 3 en delta E, c'est un gouffre pour moi. 1,5 est acceptable.

Cela dépend des couleurs. Delta E n'est pas une mesure parfaitement homogène au niveau perceptuel.

en outre dans le cas de mes mesures, il faut bien voir que le noir est à 0.12 cd/m², une zone ou la chrominance du colorimètre n'est pas bonne. Il faut plutôt regarder les valeurs en luminance qui sont bonnes. C'est ce qui nous intéresse ici principalement dans ce fil.

Pourquoi choisir le minimum neutre et pas le minimum natif ?

Citation de: MBe le Septembre 18, 2015, 19:50:01
Oui, les résultats sont excellents, et c'est bien la mesure relative entre les 2 TRC qui est riche d'enseignement*. A 0,12 cd/m², la mesure est difficile à faire en raison du bruit au niveau de la dalle et du bruit au niveau des capteurs du colorimètre (ce bruit est d'ailleurs l'objet d'un travail de compensation interne).

* En prenant l'hypothèse que le colorimètre à une perception visuelle identique à celle de l'observateur, les écarts relatifs en delta E sont suffisamment faibles pour ne pas être considérés. Jean Delmas a dit cette semaine que la courbe L* était pour les esthètes, ces détracteurs ont compris "élitistes"  ;D (des commentaires supplémentaires n'apporteraient rien quand on en arrive à faire ce type de confusion)

Je viens de refaire un profil L* avec ColorNavigator avec les mêmes valeurs cibles et en décochant "Reflect black level in tone curve", la courbe L* a son point de départ maintenant à 0.  Ce paramètre m'avait échappé...la doc n'est pas très explicite non plus.
je ne suis  pas certain également de voir la différence, car dans les basses lumières, il est pas facile de voir de si petits écarts pour l'œil.

Oui avec un noir à 0.12 cette option ne doit pas avoir une grosse influence. Essayez avec un noir à 0.5 et vous verrez qu'il y a un soucis si cette option est désactivée...

Au regard des mesures le L* effectivement ne me semble pas d'une grande nécessité. On arrive déjà à de très bon résultats en gamma 2.2.

Mon avis : le L* risque de poser des problèmes de compatibilité et certains utilisateurs ne s'en rendront jamais compte.

A moins de vouloir à tout pris le maximum d'homogénéité de l'espace couleur d'affichage et un delta E au plus bas dans les noirs, il est certainement plus sage de rester en gamma 2.2 et de mettre à jour son système avec un écran et une liaison vidéo 30 bits si ce n'est déjà fait, ainsi qu'acquérir un écran haut de gamme stable et précis.

Citation de: olivier1010 le Septembre 18, 2015, 20:11:19
Le niveau de noir est à 0.29 cd/m² dans vos mesures. Cela change tout pour le delta E maxi dans les noirs. Dans mon cas je suis à 0.12 cd/m², et j'arrive donc aux limites de la sonde (limite à 0.1 cd/m² sur une display pro).

Mon Delta E max dans les premiers niveaux de noir n'est pas représentatif de la qualité de la calibration mais de celui de la sonde dans les bas niveaux.

Si je refais les mesures avec un noir à 0.29 mon Delta E max va baisser fortement.

Bonsoir,

Oups mes résultats sont uniquement la pour donner une petite vision sur le trio DELL U2413+i1 display pro+basic color display.

Vous êtes beaucoup plus débrouillard que moi sur les test, je suis bien incapable de les réaliser comme vous le fait.

Ps: il est ou M.Metairie car a priori selon vos test ce n'est pas un soucis de gamma 2.2 ou L*?

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?

Citation de: fred94- le Septembre 18, 2015, 20:28:16
Bonsoir,

Oups mes résultats sont uniquement la pour donner une petite vision sur le trio DELL U2413+i1 display pro+basic color display.

Vous êtes beaucoup plus débrouillard que moi sur les test, je suis bien incapable de les réaliser comme vous le fait.

Ps: il est ou M.Metairie car a priori selon vos test ce n'est pas un soucis de gamma 2.2 ou L*?

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?

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.

Citation de: olivier1010 le Septembre 18, 2015, 14:21:33
Enfin, sous windows, le 3 x 10 bits est rendu inopérant par un bureau en mode aéro... Il faut choisir un thème basique.

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 ?

CitationMais en vidéo le 8 bits FRC peut créer de l'aliasing puisqu'il risque d'interagir avec la cadence élevée des images.

Les artfacts dans les basses lumières aussi, que ce soit sous CentOS/RHEL, Windows.

Citation de: Verso92 le Septembre 18, 2015, 21:18:01
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 ?

Windows classic,

Citation de: Miaz3 le Septembre 18, 2015, 21:21:37
Windows classic,

Tu me conseillerais donc le thème "Windows Classique", plutôt que l'actuel ?
(je n'ai rien changé de ce côté là*... mais la machine a été montée et configurée par un pote, pas par moi : il a peut-être changé le thème de base ?)
*sauf le fond d'écran...

Citation de: Verso92 le Septembre 18, 2015, 21:24:51
Tu me conseillerais donc le thème "Windows Classique", plutôt que l'actuel ?
(je n'ai rien changé de ce côté là*... mais la machine a été montée et configurée par un pote, pas par moi : il a peut-être changé le thème de base ?)
*sauf le fond d'écran...

normalement l'aero est désactivé, mais s'il est activé il doit y apparaitre une notification dans ton panel Nvidia.
http://nvidia.custhelp.com/app/answers/detail/a_id/3049/~/how-to-enable-30-bit-color-on-windows-platforms

Donc oui pardon, il ne doit pas y avoir de soucis... c'est qu'au travail il nous l'on mis en classic pour d'autre raison.

Edit: j'ai vu que tu avais un Eizo et ils en parlent dans leur docs (pour confirmer)
http://www.eizoglobal.com/support/compatibility/monitors/20.pdf

++

Citation de: olivier1010 le Septembre 18, 2015, 20:52:31
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.

En tout cas bravo pour le temps passé à réalisé les test, chapeau.
Suivant les conseils de mon formateur je caractérise en L* et en D50 et ça passe pas trop mal à l'exception du dégradé....j'en conviens mais je vais me soigner avec un Eizo mais pas de suite.

Citation de: Miaz3 le Septembre 18, 2015, 21:29:28
normalement l'aero est désactivé, mais s'il est activé il doit y apparaitre une notification dans ton panel Nvidia.
http://nvidia.custhelp.com/app/answers/detail/a_id/3049/~/how-to-enable-30-bit-color-on-windows-platforms

Donc oui pardon, il ne doit pas y avoir de soucis... c'est qu'au travail il nous l'on mis en classic pour d'autre raison.

Edit: j'ai vu que tu avais un Eizo et ils en parlent dans leur docs (pour confirmer)
http://www.eizoglobal.com/support/compatibility/monitors/20.pdf

++

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 :

Citation de: olivier1010 le Septembre 18, 2015, 20:26:08
Oui avec un noir à 0.12 cette option ne doit pas avoir une grosse influence. Essayez avec un noir à 0.5 et vous verrez qu'il y a un soucis si cette option est désactivée...

Au regard des mesures le L* effectivement ne me semble pas d'une grande nécessité. On arrive déjà à de très bon résultats en gamma 2.2.

Mon avis : le L* risque de poser des problèmes de compatibilité et certains utilisateurs ne s'en rendront jamais compte.

A moins de vouloir à tout pris le maximum d'homogénéité de l'espace couleur d'affichage et un delta E au plus bas dans les noirs, il est certainement plus sage de rester en gamma 2.2 et de mettre à jour son système avec un écran et une liaison vidéo 30 bits si ce n'est déjà fait, ainsi qu'acquérir un écran haut de gamme stable et précis.

Dans le rapport de calibration, le niveau de noir annoncé est de 0,08 cd/m2 (valeur probablement inférieure à la précision de l'instrument et de l'incertitude de mesure...), mais j'avais exactement la même réflexion (influence de l'option) si le niveau noir avait présenté un niveau plus élevé. Comme je te disais, je doute de pouvoir faire la différence entre les 2 calibrations avec et sans ce "reflect black level in tone curve" de coché pour un profil en L* (en 2,2 l'écart est bien plus grand).
Oui également pour une liaison 30 bits entre le PC et l'écran, c'est au cahier des charges pour le prochain. (d'autant plus que l'on gagne vis à vis du bruit sur les LSB).
Un profil en L* reste intéressant pour un écran de qualité à la condition d'avoir une connaissance en gestion des couleurs, autrement en effet il est préférable de rester avec une TRC de 2,2.

Citation de: Verso92 le Septembre 18, 2015, 21:18:01
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 :(

Citation de: fred94- le Septembre 18, 2015, 20:28:16

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?

Citation de: olivier1010 le Septembre 18, 2015, 20:52:31
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 ?

Citation de: olivier1010 le Septembre 18, 2015, 21:59:07
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 !).

Citation de: Verso92 le Septembre 18, 2015, 21:44:02
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 :D, j'ai du me planter avec Mbe...

Citation de: Verso92 le Septembre 18, 2015, 22:30:23
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).

Citation de: MBe le Septembre 18, 2015, 22:26:48
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.

ColorNavigator

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

Citation de: Salomé_B le Septembre 19, 2015, 11:22:09
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.

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.

Citation de: Salomé_B le Septembre 19, 2015, 12:57:46
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 :(

Citation de: Salomé_B le Septembre 19, 2015, 11:22:09
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  :-\

CitationICC 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.

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 (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.....

Citation de: olivier1010 le Septembre 19, 2015, 01:51:38
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.

Citation de: olivier1010 le Septembre 19, 2015, 01:51:38
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.

Citation de: olivier1010 le Septembre 19, 2015, 01:51:38
[...]

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.

Citation de: olivier1010 le Septembre 19, 2015, 17:51:43
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?

Citation de: MBe le Septembre 19, 2015, 22:57:17

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 ???

Citation de: fred94- le Septembre 20, 2015, 11:53:13
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)

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é.

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.

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.

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  ...

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

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  ...

Citation de: MBe le Septembre 20, 2015, 22:55:12
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.

Citation de: olivier1010 le Septembre 20, 2015, 23:19:36
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.

Oui j'ai noté cela également pour les 100 patchs en Lab et les quick tests.
Le pas de 2 en Lab correspond a peu près à la sensibilité de la vision humaine.

Citation de: MBe le Septembre 20, 2015, 23:56:00
Oui j'ai noté cela également pour les 100 patchs en Lab et les quick tests.
Le pas de 2 en Lab correspond a peu près à la sensibilité de la vision humaine.

J'attends une réponse de BabelColor sur 2 points :

1) Est ce que PatchTool peut afficher en 30 bits

2) Est ce qu'il ya aurait possibilité de faire une analyse Display Data avec un fichier source plus fourni en patchs dans les noirs, si possible en source Lab.
Concernant votre question précédente sur les icc en V4, la génération des profils écrans en V4 avec Colornavigator ne semble pas poser de problèmes. Il faut dire que les différences sont minimes entre V2 et V4 dans ce cas là.

En ce qui concerne les profils d'impression, ma sonde i1 pro ancienne génération ne me donne pas satisfaction avec i1 match et bizarrement je ne peux pas l'utiliser avec 1i profiler pour la génération de profils d'impression RGB. Il semble qu'il faille acheter une mise à jour de la licence :(. Il faudrait que je passe sur une i1 pro II. En espérant que la modification de l' i1io ne me posera pas de soucis.

Donc pas trop d'expérience avec les profils en V4 pour le moment. Un peu de lecture quand même pour m'apercevoir que c'est devenu passablement compliqué et que certaines choses sont toujours encore peu standardisées, comme la façon dont le rendu en mode perception est calculé lorsqu'il y a des différences de gamut importantes.

Ce qui est clair et significatif : on mélange encore une fois les torchons et les serviettes.

La question initiale : Diff entre L* et G22 sous bICC

et on nous fait une pseudo demo, sous colonavigator avec la sonde interne du CG

J'ai un scoop pour vous :

Le L* de CN et le L* de bICC ne correspondent pas à la même chose (2.34 pour l'un, 2.47 pour l'autre).

et ce qu'il faut retenir : Le L* de CN est une fausse sRGB TRC. (ah les Ig de chez EIZO ...)

Source : T.John A.Koffmann - Cambridge - fin 2014 - c'est un dans un rapport d'Astrophysique

Bonne journée à vous

Bonjour,

Citation de: Salomé_B le Septembre 21, 2015, 09:50:51
Ce qui est clair et significatif : on mélange encore une fois les torchons et les serviettes.

La question initiale : Diff entre L* et G22 sous bICC

et on nous fait une pseudo demo, sous colonavigator avec la sonde interne du CG

J'ai un scoop pour vous :

Le L* de CN et le L* de bICC ne correspondent pas à la même chose (2.34 pour l'un, 2.47 pour l'autre).

et ce qu'il faut retenir : Le L* de CN est une fausse sRGB TRC. (ah les Ig de chez EIZO ...)

Source : T.John A.Koffmann - Cambridge - fin 2014 - c'est un dans un rapport d'Astrophysique

Bonne journée à vous

Surprenant. Depuis combien de temps dure cette tromperie ?

Merci pour une référence précise. Un lien vers la source ?

Salutations

Citation de: Salomé_B le Septembre 21, 2015, 09:50:51
Ce qui est clair et significatif : on mélange encore une fois les torchons et les serviettes.

La question initiale : Diff entre L* et G22 sous bICC

et on nous fait une pseudo demo, sous colonavigator avec la sonde interne du CG

J'ai un scoop pour vous :

Le L* de CN et le L* de bICC ne correspondent pas à la même chose (2.34 pour l'un, 2.47 pour l'autre).

et ce qu'il faut retenir : Le L* de CN est une fausse sRGB TRC. (ah les Ig de chez EIZO ...)

Source : T.John A.Koffmann - Cambridge - fin 2014 - c'est un dans un rapport d'Astrophysique

Bonne journée à vous

Non, la validation des profils a été faite dans un logiciel externe, en l'occurrence PatchTool 4.7 et en utilisant une sonde externe, une i1 Display pro. Cette validation montre d'ailleurs que les courbes tonales de calibration hardware dans l'écran (générées par ColorNavigator) sont parfaitement correctes.

Le scoop est intéressant (un lien ?), mais en soit il ne change pas grand chose au fait que L* ou gamma 2.2 ne change pas radicalement la perception des bas niveaux de luminance à l'écran.
Sauf évidemment si une application ne sait pas gérer correctement L* ce qui semble être le cas ici sous toutes réserves puisqu'on a pas eu de retour de la part de Christophe Métairie qui n'est pas repassé sur ce fil.

Même si la courbe tonale L* est différente d'un logiciel de calibration à l'autre, elle est de toutes façons entièrement décrite dans les courbes TRC du profil. On peut d'ailleurs le vérifier en faisant une extraction de ces courbes TRC L* et en les comparant sur un graphique.

Concernant le support de l'affichage 10 bits pour la validation de profil, PatchTool ne gère pas ce mode, les patchs sont donc affichés en 8 bits par canal. Ce qui est certainement le cas des autres applications de calibration pour la chaine graphique. Dans le monde de la vidéo les applications de calibration haut de gamme savent afficher des patchs en 10 voir 12 bits par canal.

Ce ne serait pas plus mieux comme entête !

salut

désolé pour la qualité de l'image mais c'est j'ai trouvé celle-ci dans le manuel de colornavigator:

(https://webcube-general.s3.amazonaws.com/eizo/media/contentassets/2014/10/27/kamijiro_06b.jpg)
Alors c'est simplement pour le soucis du départ et non des résultats d'olivier1010 que je ne juge pas car incapable.
Mais à priori dans color navigator le gamma en L* n'est pas un 2.2 mais un 2.60 "mais n'ayant pas le logiciel".....

Non je ne crois pas
Soit tu choisis un gamma entre 1,00 et 2,60 soit tu choisis L*

Le fait que L* soit juste après 2,6 ne veut pas dire que le gamma  de L* soit égal à 2,60 (pour autant que ça veuille dire quelque chose le gamma de L* ;) )

Citation de: Pat20d le Septembre 21, 2015, 14:52:39
Non je ne crois pas
Soit tu choisis un gamma entre 1,00 et 2,60 soit tu choisis L*

Le fait que L* soit juste après 2,6 ne veut pas dire que le gamma  de L* soit égal à 2,60 (pour autant que ça veuille dire quelque chose le gamma de L* ;) )

pas sur la tête  ::) ::)

comme quoi les interface logiciel sont....^^

Je retourne sur Cambridge mi-novembre, on en reparle, avec le rapport ...

Citation de: fred94- le Septembre 21, 2015, 14:04:56
salut

désolé pour la qualité de l'image mais c'est j'ai trouvé celle-ci dans le manuel de colornavigator:

(https://webcube-general.s3.amazonaws.com/eizo/media/contentassets/2014/10/27/kamijiro_06b.jpg)
Alors c'est simplement pour le soucis du départ et non des résultats d'olivier1010 que je ne juge pas car incapable.
Mais à priori dans color navigator le gamma en L* n'est pas un 2.2 mais un 2.60 "mais n'ayant pas le logiciel".....

Non non c'est bien un L*. C'est juste une simplification au niveau de la programmation de l'interface graphique pour rajouter L* sans trop se prendre la tête.

Je remets ci-dessous les courbes générées par ColorNavigator. Un gamma 2.6 serait très loin du L* observé. L* se comporte comme un gamma 2.4 dans sa partie haute.

Il y a bien une différence marquée entre le L* de Basiccolor et celui de Eizo ColorNavigator.
Voici la comparaison en vue d'ensemble des deux courbes L* Basiccolor / ColorNavigator avec les deux courbes gamma théoriques gamma 2.2 / gamma 2.4.
Le L* de Basiccolor est proche de gamma 2.2 dans la partie haute, alors que celui de Eizo est proche de gamma 2.4. Cela fait quand même une bonne différence...

Comme quoi le L* n'est pas standardisé. Pour cette simple raison, à moins de savoir ce qu'on fait, il est quand même prudent de s'en méfier.

Et voici le plus intéressant.

Basiccolor pour sa courbe L* est très proche de gamma 2.4 dans sa partie basse, pour se rapprocher d'un gamma 2.2 dans sa partie haute.
Alors que Eizo commence beaucoup plus raide, plus vers un gamma 1.8, pour rejoindre un gamma 2.4 dans la partie haute de la courbe.

Ces deux L* sont vraiment très différents. Je suis même surpris de voir autant de différence.

Question pour un champion, quel est le bon à votre avis :) ?

Vous venez enfin de comprendre pourquoi c'est plus intéressant d'utiliser bICC (display et input) ...

Ne vous inquiétez pas, je vais revenir vers vous avec l'extrait du rapport (il n'est consultable que sur place).

CitationVous venez enfin de comprendre pourquoi c'est plus intéressant d'utiliser bICC (display et input) ...

Il aurai été plus intéressant d'avoir une explication de votre part dès le début, c'est certain...

 [at]  Miaz3

Ca ne m'en touche pas une, n'en n'ayant pas ..., mais c'est sympa pour les autres intervenants.

Vous savez, le seul intérêt c'est de faire réfléchir, rien de plus.

Donc L* n est pas normé . Ben alors c est comment le L* d un espace de travail.
En grossomodo ça veut dire qu on fait n importe quoi?
Autant faire ces courbes soimêrme.  :D
Donc salomé nous dis qu il faut bosser dans un espace basiccolor pour etre pile poil du début à la fin; mais il existe pas cet espace. ;)

Citation de: Salomé_B le Septembre 21, 2015, 18:40:59
[at]  Miaz3
Ca ne m'en touche pas une, n'en n'ayant pas ..., mais c'est sympa pour les autres intervenants.
Vous savez, le seul intérêt c'est de faire réfléchir, rien de plus.

J'en attendais pas moins, mais continuez dans ce sens vous avez tout à y gagner !

Donc en fait tout va bien non?

L* avec Basiccolor display= l'écran affiche des valeurs "qui existent"
L* avec Colornavigator= j'assombris de suites mes valeurs dans les basses lumières

J'ai bon?

C'est ce que nous voyons sur les exemples en page 2, sur celui qui est bon comme toujours c'est un choix.
Car je pense que le choix de traitement "que je ne juge pas" c'est d'avoir un noir et blanc très marqué.
Même si le zoom que vous nous donnez ne montre une aussi grosse différente entre un 2.2 et le L* de BCDisplay, mais entre les deux L*.

 [at]  asak

. bICC input pour ton APN
. bICC display pour ton écran
. un espace de travail LABL v4 de chez Elle Stone (le 'AllColorsRGB' est très bien)
[at]  Miaz3

Quelle est votre question ?

Citation de: Salomé_B le Septembre 21, 2015, 17:40:59
Vous venez enfin de comprendre pourquoi c'est plus intéressant d'utiliser bICC (display et input) ...

Ne vous inquiétez pas, je vais revenir vers vous avec l'extrait du rapport (il n'est consultable que sur place).

Sauf que le bon L* c'est celui de ColorNavigator. Il se superpose parfaitement avec le L* de EciRGBv2 après vérification. Voir ci-dessous.

Pour ceux qui pensent qu'il est important d'utiliser des espaces couleurs avec les mêmes courbes tonales pour l'écran et le profil de travail, et s'ils utilisent Basiccolor, le L* de Basiccolor étant très différent du vrai L*, c'est plutôt raté pour l'homogénéité des conversions.

Citation de: olivier1010 le Septembre 21, 2015, 20:06:21

Sauf que le bon L* c'est celui de ColorNavigator. Il se superpose parfaitement avec le L* de EciRGBv2 après vérification. Voir ci-dessous.

Pour ceux qui pensent qu'il est important d'utiliser des espaces couleurs avec les mêmes courbes tonales pour l'écran et le profil de travail, et s'ils utilisent Basiccolor, le L* de Basiccolor étant très différent du vrai L*, c'est plutôt raté pour l'homogénéité des conversions.

Tu as tout à fait raison Olivier, j'ai tracé le L* théorique et comparé avec le L* de ColorNavigator, les courbes se superposent... heureusement les mathématiques et les chiffres sont têtus :D

Pour celles et ceux qui sont intéressés par le CIE L*a*b* : https://fr.wikipedia.org/wiki/CIE_L*a*b* (https://fr.wikipedia.org/wiki/CIE_L*a*b*) et ses équations.
Bruce Lindbloom a également apporté sa contribution : http://www.brucelindbloom.com/index.html?LContinuity.html (http://www.brucelindbloom.com/index.html?LContinuity.html)

je rappelle que le L* ( la clarté) varie grosso modo comme la racine cubique de la luminance relative (Y/YD), a été définie pour représenter "au mieux" la perception visuelle d'un observateur , 2 espaces perceptuels uniformes ont été définis : CIE L*u*v* et CIE L*a*b* en 1976...

Maintenant nous avons un "L(BasiCColor)", pourquoi pas, mais est ce qu'il été accompagné d'une publication? en quoi est il meilleur que le L* et le 2,2? Pourquoi l'appeler L*, entretenir la confusion?

Bon alors si on parle conversion.....on n'a pas fini car nous ne savons même pas dans quel logiciel a été réalisé l'exemple ainsi que l'espace utilisé donc bon.

Je lance une question "peut-être" idiote mais bon.

Est-ce que "moi photographe" je ne voudrais pas récupérer "un peu ou beaucoup" d'information dans les basses lumières à l'affichage?.......a mon avis oui et j'avise par la suite du traitement final.
J'ai lancé monmacbookpro pour voir un truc, effectivement "de visu" les profil ECI ont une trc plus proche du L* de color navigator. Mais j'ai un autre qui ressemble plus à celui de basic color.....
Est-ce que ce n'est pas à la conversion que j'ajuste au final les pertes ou problèmes lié au profil choisi?

 [at]  olivier1010, et le célèbre MBe

Manifestement c'est toujours la débâcle de votre coté, je reviens vers vous, mais après votre guérison.

Citation de: fred94- le Septembre 21, 2015, 21:10:28
Je lance une question "peut-être" idiote mais bon.

Est-ce que "moi photographe" je ne voudrais pas récupérer "un peu ou beaucoup" d'information dans les basses lumières à l'affichage?.......a mon avis oui et j'avise par la suite du traitement final.
J'ai lancé monmacbookpro pour voir un truc, effectivement "de visu" les profil ECI ont une trc plus proche du L* de color navigator. Mais j'ai un autre qui ressemble plus à celui de basic color.....
Est-ce que ce n'est pas à la conversion que j'ajuste au final les pertes ou problèmes lié au profil choisi?

Le système icc est là pour faire correspondre correctement les couleurs et sur demande les dynamiques. Pas pour arranger le photographe qui voudrait voir plus de détail dans les ombres.

Gamma 2.2 ou L* ne change pas le détail dans les ombres, voir les analyses ci-dessus. Les différences de clarté sont très minimes, en dessous du seuil de perception si l'application graphique sait gérer les profils icc correctement. Une calibration en L* peut éventuellement délivrer un espace couleur plus homogène à l'affichage, encore faudrait il voir une étude qui montre la différence en Delta E par rapport à gamma 2.2. A mon avis la différence est très faible également. Surtout sur un affichage 30 bits qui deviendra la norme d'ici un an ou deux avec la généralisation du 4K et du HDMI 2.0.

Si vous voulez avoir du détail dans les ombres, alors remontez le niveau de noir de l'écran en le calibrant avec un contraste plus faible, peut être 200:1, qui se rapprochera du contraste d'un tirage.

Ou alors laisser l'écran à son contraste maxi et utilisez la fonction d'aperçu d'épreuve, avec simulation d'encre, qui diminuera le contraste à l'affichage. Dans ce cas pour compenser la perte de résolution tonale de l'écran vous pourrez éventuellement vous concocter un système qui affiche en 30 bits. Cela compensera grosso modo la perte de résolution tonale due à la différence entre une calibration en contraste 800:1 par rapport à une calibration en 200:1. Seuls Photoshop et Zoner Photo Studio savent gérer un affichage en 30 bits dans le monde du graphisme. En vidéo c'est un peu mieux fourni coté logiciels supportant le 30 bits.
Lightroom après vérification fait du dithering pour simuler un affichage 30 bits. Puisque si vous ouvrez un dégradé 16 bits de test (ramp.psd)dans Lightroom il apparaîtra lisse sur un système 24 bits.
Quelqu'un sait il d'ailleurs comment désactiver ce dithering ?

Le manque de détail dans les ombres peut aussi provenir d'un éclairage pièce trop fort, de reflets dans la dalle (même de légers reflets), ou bien d'une luminance écran trop faible. Ou d'une calibration de mauvaise qualité dans les noirs. Contrôlez tout ça c'est très important. Éventuellement passez sur un écran à calibration hardware pour améliorer la précision dans les courbes tonales.

En vieillissant on devient aussi moins sensible aux différences dans les niveaux de noir, donc si c'est votre cas remontez un peu le niveau de luminance de l'écran et celui de l'éclairage de la pièce dans la même proportion.

Les réglages qui vont bien en général sont 100 à 120 cd/m² pour l'écran, et 32 à 64 lux pour la pièce, mesuré au niveau de l'écran.

Citation de: fred94- le Septembre 21, 2015, 21:10:28
Je lance une question "peut-être" idiote mais bon.

Est-ce que "moi photographe" je ne voudrais pas récupérer "un peu ou beaucoup" d'information dans les basses lumières à l'affichage?.......a mon avis oui et j'avise par la suite du traitement final.
J'ai lancé monmacbookpro pour voir un truc, effectivement "de visu" les profil ECI ont une trc plus proche du L* de color navigator. Mais j'ai un autre qui ressemble plus à celui de basic color.....
Est-ce que ce n'est pas à la conversion que j'ajuste au final les pertes ou problèmes lié au profil choisi?

autant pour moi je me suis trompé car je n'avais pas le profil "espace de travail" eciRGB_v2.icc

par contre quand j'ouvre le eciRGB_v2.icc j'ai un doute car:

le tag créateur est le même pour:

mon profil écran: basiccolor display 5.7
mon profil APN: basiccolor input
eciRGB_v2: je ne sais pas mais "bICC" 

???

Juste pour information le gris moyen est bien à 18 % dans la calibration L* de ColorNavigator, contre 21 % dans le L* de Basiccolor.

L* Basiccolor est quand même loin du vrai L* ce qui porte à confusion. Elle diffère non seulement sur son gamma dans le haut de la courbe, 2.2 au lieu de 2.4, mais aussi dans le bas de la courbe ou elle est bien plus aplatie que le vrai L*. En simulant un gamma 2.4 dans cette zone elle est non seulement plus aplatie que le vrai L*, mais aussi plus aplatie que gamma 2.2 qui est déjà plus aplatie que le vrai L*.

Pourquoi Basiccolor appelle sa courbe L* ainsi ? Est ce pour profiter de l'effet de mode de L*, tout en proposant une autre courbe dont le but ne serait pas tellement d'améliorer la cohérence entre l'espace couleur de calibration et la perception visuelle, mais plutôt d'améliorer un peu la résolution tonale dans les tons sombres avec une courbe plus aplatie ?

Dans tous les cas ce L* est quand même assez étrange, tantôt il pose problème, tantôt il est différent d'un logiciel à l'autre, tantôt il est mal compris des utilisateurs faute d'explications claires de la part de ceux qui le propose, tantôt il semble peut être utilisé à des fins marketing.

Mbe, pourrais tu vérifier le tracé de la courbe L* de Basiccolor, j'ai vérifié à deux reprises tellement cela m'a étonné mais j'aimerais bien avoir une confirmation externe.

Ci-dessous le tracé agrandi de la partie basse des courbes L* ColorNavigator et Basiccolor, ainsi que Gamma 2.2 et 2.4.

Bonjour,

Juste une question : avec quel(s) logiciel(s) faites-vous ces courbes ?

Merci

Salutations

 [at]  Olivier ok pour la courbe, si tu pouvais me mettre un profil ou datas ( ou ds un post ) en telechargrment, je fais cela ce soir.

Citation de: matopho le Septembre 22, 2015, 12:24:24
Bonjour,

Juste une question : avec quel(s) logiciel(s) faites-vous ces courbes ?

Merci

Salutations

Les dernières courbes sont faites avec Excel car j'avais besoin d'un graphique en nuage de points qui permet d'avoir des séries de données dont le nombre d'échantillons est différent (256 échantillons pour les courbes en provenance des profils écrans, 700 échantillons pour la courbe en provenance de EciRGB v4.
Sinon avec Libre Office Calc lorsque les séries de données ont des tailles identiques.

Pour Mbe ci-dessous le tag TRC (canal rouge) d'un profil écran en L* réalisé avec Basiccolor.
BEGIN_LUT In_Out 1 1
IN OUT
 0.000   0.000
 0.392   0.005
 0.784   0.008
 1.176   0.012
 1.569   0.015
 1.961   0.020
 2.353   0.023
 2.745   0.027
 3.137   0.032
 3.529   0.035
 3.922   0.040
 4.314   0.050
 4.706   0.063
 5.098   0.076
 5.490   0.090
 5.882   0.107
 6.275   0.125
 6.667   0.145
 7.059   0.166
 7.451   0.189
 7.843   0.214
 8.235   0.241
 8.627   0.270
 9.020   0.301
 9.412   0.333
 9.804   0.368
10.196   0.404
10.588   0.443
10.980   0.484
11.373   0.525
11.765   0.571
12.157   0.618
12.549   0.667
12.941   0.722
13.333   0.780
13.725   0.839
14.118   0.903
14.510   0.969
14.902   1.038
15.294   1.109
15.686   1.184
16.078   1.262
16.471   1.343
16.863   1.427
17.255   1.514
17.647   1.604
18.039   1.697
18.431   1.793
18.824   1.892
19.216   1.996
19.608   2.101
20.000   2.211
20.392   2.324
20.784   2.441
21.176   2.560
21.569   2.684
21.961   2.811
22.353   2.940
22.745   3.075
23.137   3.212
23.529   3.354
23.922   3.499
24.314   3.647
24.706   3.798
25.098   3.955
25.490   4.112
25.882   4.273
26.275   4.437
26.667   4.607
27.059   4.779
27.451   4.955
27.843   5.135
28.235   5.318
28.627   5.505
29.020   5.696
29.412   5.892
29.804   6.090
30.196   6.293
30.588   6.499
30.980   6.709
31.373   6.923
31.765   7.141
32.157   7.362
32.549   7.588
32.941   7.819
33.333   8.052
33.725   8.290
34.118   8.531
34.510   8.777
34.902   9.026
35.294   9.281
35.686   9.537
36.078   9.799
36.471  10.065
36.863  10.333
37.255  10.607
37.647  10.884
38.039  11.147
38.431  11.414
38.824  11.684
39.216  11.957
39.608  12.233
40.000  12.514
40.392  12.798
40.784  13.086
41.176  13.376
41.569  13.671
41.961  13.970
42.353  14.272
42.745  14.577
43.137  14.885
43.529  15.198
43.922  15.514
44.314  15.834
44.706  16.158
45.098  16.484
45.490  16.815
45.882  17.150
46.275  17.488
46.667  17.830
47.059  18.175
47.451  18.524
47.843  18.877
48.235  19.234
48.627  19.594
49.020  19.957
49.412  20.325
49.804  20.696
50.196  21.071
50.588  21.448
50.980  21.828
51.373  22.213
51.765  22.600
52.157  22.992
52.549  23.388
52.941  23.786
53.333  24.189
53.725  24.594
54.118  25.005
54.510  25.420
54.902  25.837
55.294  26.259
55.686  26.683
56.078  27.114
56.471  27.546
56.863  27.982
57.255  28.423
57.647  28.867
58.039  29.316
58.431  29.767
58.824  30.222
59.216  30.681
59.608  31.145
60.000  31.612
60.392  32.084
60.784  32.558
61.176  33.037
61.569  33.519
61.961  34.006
62.353  34.496
62.745  34.990
63.137  35.453
63.529  35.921
63.922  36.391
64.314  36.867
64.706  37.346
65.098  37.829
65.490  38.315
65.882  38.807
66.275  39.301
66.667  39.802
67.059  40.304
67.451  40.812
67.843  41.323
68.235  41.839
68.627  42.358
69.020  42.882
69.412  43.410
69.804  43.943
70.196  44.479
70.588  45.020
70.980  45.565
71.373  46.114
71.765  46.668
72.157  47.227
72.549  47.790
72.941  48.357
73.333  48.930
73.725  49.505
74.118  50.086
74.510  50.671
74.902  51.261
75.294  51.856
75.686  52.532
76.078  53.211
76.471  53.895
76.863  54.582
77.255  55.273
77.647  55.967
78.039  56.664
78.431  57.365
78.824  58.070
79.216  58.776
79.608  59.487
80.000  60.203
80.392  60.920
80.784  61.640
81.176  62.365
81.569  63.091
81.961  63.822
82.353  64.555
82.745  65.292
83.137  66.030
83.529  66.773
83.922  67.518
84.314  68.266
84.706  69.017
85.098  69.770
85.490  70.527
85.882  71.286
86.275  72.047
86.667  72.811
87.059  73.577
87.451  74.347
87.843  75.119
88.235  75.860
88.627  76.606
89.020  77.357
89.412  78.111
89.804  78.869
90.196  79.631
90.588  80.398
90.980  81.167
91.373  81.942
91.765  82.721
92.157  83.503
92.549  84.289
92.941  85.080
93.333  85.873
93.725  86.673
94.118  87.475
94.510  88.281
94.902  89.091
95.294  89.906
95.686  90.726
96.078  91.548
96.471  92.375
96.863  93.207
97.255  94.041
97.647  94.881
98.039  95.723
98.431  96.570
98.824  97.421
99.216  98.277
99.608  99.136
100.000 100.000

Bonjour,

Merci pour l'info sur la traçage des courbes.

Question de quelqu'un qui suit et ne peut plus contribuer compte du niveau atteint mais qui a eu une idée, peut-être sotte et grenue

Le profil eciRGB_v2.icc est un profil indépendant, qui peut être incorporé dans une photo ou servir d'espace de travail. Les profils générés par CN ou Basiccolor sont des profils d'écran qui définissent les valeurs RVB à transmettre pour avoir le bon affichage.

N'est-il donc pas normal d'avoir des courbes de TRC différentes, éventuellement différentes pour chaque composante RVB, de la courbe L* de eciRGB_v2.icc  ?

Ma question suppose que les corrections sont faites à travers ces 3 courbes. Est-ce le cas ? Si oui le profil généré par CN serait ... (je ne sais pas)

Merci de votre réponse à cette question peut-être complètement out (of gamut ...).

Salutations

Citation de: matopho le Septembre 22, 2015, 17:22:09
Bonjour,

Merci pour l'info sur la traçage des courbes.

Question de quelqu'un qui suit et ne peut plus contribuer compte du niveau atteint mais qui a eu une idée, peut-être sotte et grenue

Le profil eciRGB_v2.icc est un profil indépendant, qui peut être incorporé dans une photo ou servir d'espace de travail. Les profils générés par CN ou Basiccolor sont des profils d'écran qui définissent les valeurs RVB à transmettre pour avoir le bon affichage.

N'est-il donc pas normal d'avoir des courbes de TRC différentes, éventuellement différentes pour chaque composante RVB, de la courbe L* de eciRGB_v2.icc  ?

Ma question suppose que les corrections sont faites à travers ces 3 courbes. Est-ce le cas ? Si oui le profil généré par CN serait ... (je ne sais pas)

Merci de votre réponse à cette question peut-être complètement out (of gamut ...).

Salutations

nous sommes deux alors  ;D

Citation de: matopho le Septembre 22, 2015, 17:22:09
Bonjour,

Merci pour l'info sur la traçage des courbes.

Question de quelqu'un qui suit et ne peut plus contribuer compte du niveau atteint mais qui a eu une idée, peut-être sotte et grenue

Le profil eciRGB_v2.icc est un profil indépendant, qui peut être incorporé dans une photo ou servir d'espace de travail. Les profils générés par CN ou Basiccolor sont des profils d'écran qui définissent les valeurs RVB à transmettre pour avoir le bon affichage.

N'est-il donc pas normal d'avoir des courbes de TRC différentes, éventuellement différentes pour chaque composante RVB, de la courbe L* de eciRGB_v2.icc  ?

Ma question suppose que les corrections sont faites à travers ces 3 courbes. Est-ce le cas ? Si oui le profil généré par CN serait ... (je ne sais pas)

Merci de votre réponse à cette question peut-être complètement out (of gamut ...).

Salutations

Non les courbes TRC définissent avec les couleurs des primaires RVB l'espace couleur de l'écran et donc le type de calibration à appliquer à celui-ci. Elles doivent donc être identiques pour chaque canal et normalisées si possible pour éviter des discordances entre les différents logiciels de calibration. Sinon également l'espace couleur produit aurait un axe des gris avec des valeurs RVB différentes, ce qui n'est pas forcément gênant en soit pour l'espace couleur de l'écran (puisque le CMS convertit les couleurs entre les différents espaces) mais le serait beaucoup plus dans un espace de travail. Par exemple les gris neutres relevés à la pipette montreraient des valeurs RVB avec une valeur non identique pour chaque canal.

Je pense que vous confondez avec les courbes qui définissent la calibration en elle même, c'est à dire soit les 3 tags VCGT (video card gamma type) présents dans le profil et qui servent à envoyer à la carte vidéo les valeurs de correction à appliquer à chaque canal de sortie vidéo, soit la calibration hardware, envoyée par une application de calibration dans un slot mémoire calibration de l'écran, auquel cas les courbes VCGT sont des droites puisque la carte vidéo ne doit pas corriger dans ce cas.

Le seul cas où il peut y avoir des courbes tonales TRC différentes pour chaque canal, à ma connaissance, est le cas ou il n'y a pas calibration possible de l'écran, ni par la carte vidéo ni par l'écran. Dans ce cas l'application de profilage de l'écran se contente de décrire le comportement de celui-ci à travers les tags de luminance, couleurs des primaires, et courbes tonales TRC du profil écran.

Un autre cas quand même serait celui où l'utilisateur voudrait délibérément avoir une calibration avec un gamma différent sur chaque canal RVB, dans le cadre d'une expérimentation peut être.

salut,

Alors d'accord mais les trois Trc de mon profil écran créés par Basiccolor display sont bien identiques.
Comment extraites les valeurs de ce profil écran comme vous?

svp

Citation de: fred94- le Septembre 22, 2015, 20:34:30
salut,

Alors d'accord mais les trois Trc de mon profil écran créés par Basiccolor display sont bien identiques.
Comment extraites les valeurs de ce profil écran comme vous?

svp

Avec l'utilitaire gratuit de l'icc : wxprofileDump.exe

Dispo ici :

http://www.color.org/profdump.xalter

Puis copier et enregistrer les données dans un fichier texte pour import dans Excel, ou Libre Office Calc (gratuit celui-ci).

Attention au point décimal qui peut poser problème si votre système est en séparateur décimal ",". Dans ce cas le plus simple est de faire un rechercher / remplacer avec un éditeur de texte comme Notepad++ (gratuit :) )
Ensuite il vous reste plus qu'à créer des beaux graphiques avec les tableurs.

merci mais suis sur mac  ;D

Citation de: fred94- le Septembre 22, 2015, 21:18:08
merci mais suis sur mac  ;D

Il y a un équivalent sous Mac qui trace également des vues 2D ou 3D des gamuts des profils, de mémoire il est livré avec l'OS, mais j'ai abandonné Apple il y a tellement longtemps....
Il y a bien un spécialiste "Mac" qui va te renseigner.

La courbe Lstar théorique versus "Lstar" BasiCColor Display :

Je trouve la même représentation que toi Olivier.

La même, mais avec une loupe dans les basses lumières:

Je suis vraiment interrogatif sur le départ de la courbe, son comportement sur les basses lumières, après l'intersection des 2 courbes, je pense qu'il n'y a pas d'incidence majeure pour la vision humaine, sauf que l'utilisation de cette courbe dans un profil rompt l'homogénéité avec les profils icc Lstar de travail ( perte possible lors des calculs pour passer d'un espace vers un autre).

je ne comprends pas pourquoi BasiCColor qui est une entreprise très sérieuse appelle cette courbe Lstar qui ne respecte pas l'équation de la CIE? devrait (à mon avis) au minimum communiquer quelques explications vers les utilisateurs.
J'ai fait une recherche sur le web pour voir si il y avait une information sur la non concordance de ces courbes, sans succès.

Je peux dire une connerie?

Vous comparer une courbe à partir d'une équation puis vous la comparer avec des valeurs qui résultent de mesures physiques sur l'écran?

Citation de: fred94- le Septembre 22, 2015, 22:39:55
Je peux dire une connerie?

Vous comparer une courbe à partir d'une équation puis vous la comparer avec des valeurs qui résultent de mesures physiques sur l'écran?

à ^par

La courbe théorique Lstar est décrite par des équations, j'ai utilisé Excel pour tracer cette courbe à partir de ces équations.
Avec la table de valeurs TRC "Lstar" Basiccolor communiquée par Olivier, j'ai tracé la courbe de Basicolor display.
Donc en effet c'est bien la comparaison de la courbe théorique Lstar avec la courbe qui est dans le profil icc d'un écran réalisé avec BasiCColor Display.

Mais attention, cette courbe n'est pas issue de valeur physique d'un écran, cette courbe (en fait 3 courbes , 1 pour chacun des canaux RVB)  est insérée au moment de la fabrication du profil, BasiCColor Display écrit dans le format ad 'hoc 3 tables (identiques) pour les canaux RVB correspondant au TRC (Tone Reproduction curve) du Lstar.(Olivier a expliqué quelques posts au-dessus le pourquoi de cette courbe).

Donc en théorie, nous devrions retrouver une superposition parfaite de ces courbes (c'est vrai par exemple avec ColorNavigator (Eizo)), mais nous ne comprenons pas pourquoi nous ne retrouvons pas cette correspondance avec BasiCColor Displauy, malgré une appellation identique (Lstar).

Il y a peut être une explication, mais je cherche encore, et comme je le disais un peu plus haut, dans les basses lumières, la courbes "Lstar" de BasiCColor Display est vraiment surprenante.
J'espère que c'est un peu plus clair avec ces explications et toutes les questions sont intéressantes.

Bonsoir,

Merci à  tous pour vos précisions.

Néanmoins

Citation de: fred94- le Septembre 22, 2015, 22:39:55
Je peux dire une connerie?
Vous comparer une courbe à partir d'une équation puis vous la comparer avec des valeurs qui résultent de mesures physiques sur l'écran?

cette remarque me semble valable. C'est une autre façon de dire ma pensée.

Pour moi, cela n'a pas de sens de comparer une courbe définie par une suite de points (couples de valeurs x-Y) et une courbe définie par une équation : comparaison entre les courbes réalisées par basiccolor ou CN et et la courbe de eciRGB_v2.icc. Cette comparaison ne permet pas de dire que la courbe établie par CN est juste.

Sauf si la norme permet de définir la courbe par les deux méthodes. Dans ce cas j'ai tout faux.

La seule solution pour moi : étudier la norme définissant les profils ICC et l'appliquer aux différences relevées par Salomé.

Salutations

Citation de: matopho le Septembre 22, 2015, 23:15:07
Bonsoir,

Merci à  tous pour vos précisions.

Néanmoins cette remarque me semble valable. C'est une autre façon de dire ma pensée.

Pour moi, cela n'a pas de sens de comparer une courbe définie par une suite de points (couples de valeurs x-Y) et une courbe définie par une équation : comparaison entre les courbes réalisées par basiccolor ou CN et et la courbe de eciRGB_v2.icc. Cette comparaison ne permet pas de dire que la courbe établie par CN est juste.

Sauf si la norme permet de définir la courbe par les deux méthodes. Dans ce cas j'ai tout faux.

La seule solution pour moi : étudier la norme définissant les profils ICC et l'appliquer aux différences relevées par Salomé.

Salutations

Est-ce que la suite de points est exempte du choix de l adaptation chromatic?

Bonsoir,

Citation de: MBe le Septembre 22, 2015, 23:08:11
La courbe théorique Lstar est décrite par des équations, j'ai utilisé Excel pour tracer cette courbe à partir de ces équations.
Avec la table de valeurs TRC "Lstar" Basiccolor communiquée par Olivier, j'ai tracé la courbe de Basicolor display.
Donc en effet c'est bien la comparaison de la courbe théorique Lstar avec la courbe qui est dans le profil icc d'un écran réalisé avec BasiCColor Display.

Mais attention, cette courbe n'est pas issue de valeur physique d'un écran, cette courbe (en fait 3 courbes , 1 pour chacun des canaux RVB)  est insérée au moment de la fabrication du profil, BasiCColor Display écrit dans le format ad 'hoc 3 tables (identiques) pour les canaux RVB correspondant au TRC (Tone Reproduction curve) du Lstar.(Olivier a expliqué quelques posts au-dessus le pourquoi de cette courbe).

Donc en théorie, nous devrions retrouver une superposition parfaite de ces courbes (c'est vrai par exemple avec ColorNavigator (Eizo)), mais nous ne comprenons pas pourquoi nous ne retrouvons pas cette correspondance avec BasiCColor Displauy, malgré une appellation identique (Lstar).

Il y a peut être une explication, mais je cherche encore, et comme je le disais un peu plus haut, dans les basses lumières, la courbes "Lstar" de BasiCColor Display est vraiment surprenante.
J'espère que c'est un peu plus clair avec ces explications et toutes les questions sont intéressantes.

Donc si je comprends bien, pour un profil écran il y a deux jeux de tables pour les 3 canaux RVB : 1 jeux qui définit les TRC et 1 jeux qui définit les corrections à appliquer.

Donc mon message précédent est tout faux, sauf qu'il me faut étudier la norme.

Salutations

Citation de: matopho le Septembre 22, 2015, 23:15:07
Bonsoir,

Merci à  tous pour vos précisions.

Néanmoins cette remarque me semble valable. C'est une autre façon de dire ma pensée.

Pour moi, cela n'a pas de sens de comparer une courbe définie par une suite de points (couples de valeurs x-Y) et une courbe définie par une équation : comparaison entre les courbes réalisées par basiccolor ou CN et et la courbe de eciRGB_v2.icc. Cette comparaison ne permet pas de dire que la courbe établie par CN est juste.

Sauf si la norme permet de définir la courbe par les deux méthodes. Dans ce cas j'ai tout faux.

La seule solution pour moi : étudier la norme définissant les profils ICC et l'appliquer aux différences relevées par Salomé.

Salutations

La norme Icc permet de définir une courbe tonale (L* ou autre) par les deux méthodes. Courbe tonale TRC ou équation paramétrique. :)
La courbe L* présente dans le profil icc ECIRGB V2 est présente sous forme de courbe tonale TRC. Et elle correspond bien à la courbe théorique de l'espace L*a*b*, ce qu'a vérifié Mbe.

J'ai simplement extrait la courbe tonale TRC d'un profil Basiccolor en L*, pour la comparer à la bonne courbe L* (que j'ai récupérée dans le profil EciRGB), et je me suis aperçu que cette soit disant L* n'en est pas une.

C'est en fait un mélange entre un gamma 2.4 dans les bas niveaux, et un gamma 2.2 dans les hauts niveaux, ce qui n'a rien à voir avec un L*.
Et ce qui rompt également, comme l'a dit Mbe et comme je l'avais souligné il y a quelques messages, la correspondance avec un espace de travail en L*, correspondance que beaucoup d'utilisateurs semblent apprécier, sans se douter que le L* de Basiccolor n'en est pas un.
ColorNavigator utilise la vrai courbe L* (et peut aussi importer d'autres courbes si besoin comme DICOM ou sRGB).

Citation de: matopho le Septembre 22, 2015, 23:22:38
Bonsoir,

Donc si je comprends bien, pour un profil écran il y a deux jeux de tables pour les 3 canaux RVB : 1 jeux qui définit les TRC et 1 jeux qui définit les corrections à appliquer.

Donc mon message précédent est tout faux, sauf qu'il me faut étudier la norme.

Salutations

Oui il y a un Jeux de 3 tables identique TRC ( courbes Lstar ou 2,2 par exemple) et des tables pour décrire le comportement colorimétrique de 'l'écran.
Si calibration matérielle (hardware), ces tables ont chargées dans de l'espace mémoire de l'écran ( 14/16 bits)
Si calibration "classique" (software), ces tables (vcgt, elles sont appelées comme cela dans le profil) sont chargées dans un espace mémoire de la carte graphique du PC ou Mac (8 bits).

Citation de: matopho le Septembre 22, 2015, 23:22:38
Bonsoir,

Donc si je comprends bien, pour un profil écran il y a deux jeux de tables pour les 3 canaux RVB : 1 jeux qui définit les TRC et 1 jeux qui définit les corrections à appliquer.

Donc mon message précédent est tout faux, sauf qu'il me faut étudier la norme.

Salutations

Oui il y a deux jeux de tags : un pour le gamma, qui peut être décrit de trois façons :

- matrice gamma (donne simplement les trois valeurs de gamma), utilisable seulement pour décrire un vrai gamma.

- courbes TRC (utilisable pour décrire n'importe quelle courbe tonale, comme L* ou sRGB)

- équations paramétriques (le plus précis mais uniquement disponible en V4).
Et un jeu de tags pour la calibration à envoyer à la carte vidéo, sous forme de 3 tables LUT 16 bits. Si la calibration est faite en hardware dans le moniteur, ce qui est toujours le cas pour les écrans haut de gamme graphiques, les courbes décrites par ces tags sont remplacées par des droites ( x = y ).

Leur but est de faire correspondre au mieux les courbes tonales d'affichage (on dit couramment le gamma de l'écran) avec les courbes tonales décrites au niveau du profil d'écran qui décrivent son espace couleur.

Ces derniers tags (appelés "VCGT" : video card gamma table) ne sont pas normalisés, ils ont été inventés par Apple, mais sont devenus un standard de faite. Le logiciel d'extraction de l'icc ne sait donc pas les lire. Mais d'autres utilitaire comme DispCalGui ou Gretag Calibration tester, ou LUT loader, savent les lire et même parfois exporter leur table.

DispCalGUI sait même comparer ces tags avec ce qui se trouve réellement dans la carte vidéo.

Attention, ces tables VCGT sont en 16 bits, mais agissent sur la sortie vidéo, donc leur précision est en réalité de 8 ou 10 bits par canal, selon la liaison disponible vers l'écran. D'où l'intérêt d'une calibration hardware qui portera cette résolution à 12 ou 14 bits (avec d'autres avantages comme l'uniformisation de la surface de la dalle).
Ce système double, permet entre autres d'avoir un écran proche d'un gamma normalisé (sRGB par exemple), ce qui est heureux pour les applications qui ne savent pas gérer les couleurs par icc.

Citation de: matopho le Septembre 22, 2015, 23:15:07
Pour moi, cela n'a pas de sens de comparer une courbe définie par une suite de points (couples de valeurs x-Y) et une courbe définie par une équation : comparaison entre les courbes réalisées par basiccolor ou CN et et la courbe de eciRGB_v2.icc. Cette comparaison ne permet pas de dire que la courbe établie par CN est juste.
Salutations

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.

Bonsoir,

Merci à tous. C'est clair maintenant.

Mais le canard est toujours vivant !

Salutations

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.

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.

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

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

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.

piouuuuu  tu nous a fait peur ^^

en tout cas merci encore pour les test.

bonne journée

CN vs bICC

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

Là BC correspond a ce que j'imaginais  ;)

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.

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?

 [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.

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).

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 ...

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...

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*.

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).

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.

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.

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.

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.

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.

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.

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

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.

La liste est dans le fichier HW_Suppot_List.txt dans le dossier d'installation de Basiccolor.

Pour la version 5.7, pas de calibration hardware pour la gamme CX.

Displays (hardware calibration):
- 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
- NEC SpectraView 1980
- NEC SpectraView 1990
- NEC SpectraView 1990p
- NEC SpectraView 2090
- NEC SpectraView 2180
- NEC SpectraView 2190
- NEC SpectraView 2190p
- NEC SpectraView 2490
- NEC SpectraView 2490-2
- NEC SpectraView 2690
- NEC SpectraView 3090
- NEC SpectraView Reference 2690
- NEC SpectraView Reference 3090
- NEC SpectraView Reference 21
- NEC MultiSync P221W
- NEC SpectraView 231
- NEC SpectraView 232
- NEC SpectraView 241
- NEC SpectraView 242
- NEC MultiSync EA244UHD
- NEC SpectraView 271
- NEC SpectraView 272
- NEC SpectraView Reference 241
- NEC SpectraView Reference 242
- NEC SpectraView Reference 271
- NEC SpectraView Reference 272
- NEC SpectraView Reference 301
- NEC SpectraView Reference 302
- NEC SpectraView Reference 322UHD
- NEC SpectraView P552
- NEC MultiSync LCD 1980
- NEC MultiSync LCD 1990SX
- NEC MultiSync LCD 1990SXi
- NEC MultiSync LCD 2090UXi
- NEC MultiSync LCD 2180UX
- NEC MultiSync LCD 2190UXp
- NEC MultiSync LCD 2190UXi
- NEC MultiSync LCD 2490WUXi
- NEC MultiSync LCD 2490WUXi2
- NEC MultiSync LCD 2690WUXi
- NEC MultiSync LCD 2690WUXi2
- NEC MultiSync LCD 3090WQXi
- NEC MultiSync LCD PA231W
- NEC MultiSync LCD P232W
- NEC MultiSync LCD PA241W
- NEC MultiSync LCD PA242W
- NEC MultiSync LCD PA271W
- NEC MultiSync LCD PA272W
- NEC MultiSync LCD PA301W
- NEC MultiSync LCD PA302W
- NEC MultiSync PA322UHD
- NEC MultiSync LCD 4020
- NEC MultiSync LCD 4620
- NEC MultiSync LCD 5220
- NEC MultiSync LCD 6520L
- NEC MultiSync LCD 6520P
- NEC MultiSync P403
- NEC MultiSync P463
- NEC MultiSync P521
- NEC MultiSync P552
- NEC MultiSync P553
- NEC MultiSync P703
- NEC MultiSync P801
- NEC Multeos M40
- NEC Multeos M46
- Quato Intelli Proof 190
- Quato Intelli Proof 201
- Quato Intelli Proof 213
- Quato Intelli Proof 220 LE
- Quato Intelli Proof 220 Excellence
- Quato Intelli Proof 240 Excellence LED
- Quato Intelli Proof 242 LE
- Quato Intelli Proof 242 Excellence
- Quato Intelli Proof 260 / 264 Excellence
- Quato Intelli Proof 262 Excellence
- Quato Intelli Proof 270 Excellence
- Quato Intelli Proof 300 Excellence
- Quato Intelli Proof 420 Excellence
- Quato Proof View 700-42

J'ai trouvé ceci

(Image 2 : calibration imposée par bICC pour l'écran du MacBook)

Les gammes CX / CS ne sont pas dans la liste, mais regardez ceci :

Calibration imposée par bICC pour l'écran EIZO (idem pour CG et pour CX)

Citation de: aziber le Septembre 24, 2015, 13:44:30
Les gammes CX / CS ne sont pas dans la liste, mais regardez ceci :

Calibration imposée par bICC pour l'écran EIZO (idem pour CG et pour CX)

Utilisez un utilitaire pour voir si des tables de calibration sont vraiment chargées dans la table vidéo.

Si c'est le cas ce n'est pas une calibration hardware.
Sur PC vous pouvez utiliser l'utilitaire "calibration tester" de gretag, qu'on doit encore trouver sur le site X-rite.
Sur mac je ne sais pas.

Citation de: olivier1010 le Septembre 21, 2015, 23:14:35
Le système icc est là pour faire correspondre correctement les couleurs et sur demande les dynamiques. Pas pour arranger le photographe qui voudrait voir plus de détail dans les ombres.
Gamma 2.2 ou L* ne change pas le détail dans les ombres, voir les analyses ci-dessus.

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.

Après avoir trouvé comment activer les fonctions cachées (des CG) sur les CX/CS, voilà le résultat (et il n'y a plus la ptite étoile vous remarquerez) :

Cela permet de rendre totalement compatible bICC sur les CX/CS.

C'est disponible en cherchant sur Google !!!

Citation de: tenmangu81 le Septembre 24, 2015, 17:40:24
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.

Citation de: tenmangu81 le Septembre 24, 2015, 17:40:24
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.

Même constat chez moi (Nec PA241w + SpectraViewII dernière version + i1 Display Pro) :

Ou, du moins, les ombres sont comme relevées quand je choisis l'étalonnage réalisé en choisissant L* au lieu de gamma = 2,2 (85 cd/m2, D55).
Si j'ai bien compris le post initial de Christophe, j'obtiens donc l'inverse de ce qu'il constate (?)...

(l'espace de travail de Photoshop CS6 est ProPhoto L*. J'ai converti dans ce profil (à l'ouverture) l'image en Adobe RVB qui m'a servi à faire la comparaison)

Citation de: Verso92 le Septembre 24, 2015, 20:35:56
Même constat chez moi (Nec PA241w + SpectraViewII dernière version + i1 Display Pro) :

Ou, du moins, les ombres sont comme relevées quand je choisis l'étalonnage réalisé en choisissant L* au lieu de gamma = 2,2 (85 cd/m2, D55).
Si j'ai bien compris le post initial de Christophe, j'obtiens donc l'inverse de ce qu'il constate (?)...

Je crois qu'il avait corrigé le tir ensuite, en disant que les noirs étaient moins bouchés avec L* qu'avec gamma = 2.2.

Citation de: tenmangu81 le Septembre 24, 2015, 21:01:50
Je crois qu'il avait corrigé le tir ensuite, en disant que les noirs étaient moins bouchés avec L* qu'avec gamma = 2.2.

Dans ce cas, alors, je fais la même constatation que lui...

Citation de: Verso92 le Septembre 24, 2015, 20:35:56
Même constat chez moi (Nec PA241w + SpectraViewII dernière version + i1 Display Pro) :

Ou, du moins, les ombres sont comme relevées quand je choisis l'étalonnage réalisé en choisissant L* au lieu de gamma = 2,2 (85 cd/m2, D55).
Si j'ai bien compris le post initial de Christophe, j'obtiens donc l'inverse de ce qu'il constate (?)...

(l'espace de travail de Photoshop CS6 est ProPhoto L*. J'ai converti dans ce profil (à l'ouverture) l'image en Adobe RVB qui m'a servi à faire la comparaison)

Dans le cas de Christophe, j'avais relevé une différence de gamma d'environ 0.2 dans son exemple, ce qui est une erreur assez importante.

Faire une repro de l'écran, et utiliser l'outil exposition de Photoshop qui dispose d'un curseur gamma peut être intéressant pour voir si c'est une déviation gamma.

Cela pourrait être aussi dans d'autres cas un simple décalage du niveau de noir. Une analyse à la pipette doit permettre de montrer d'où vient le problème.
Mes exemples montrent que dans le cas d'une calibration hardware les niveaux de luminance qui devraient être affichés par l'application sont pratiquement identiques, qu'on soit en L* ou gamma 2.2.

Mes tests utilisent LCMS, ce qui n'est pas le même CMS que Photoshop.

Il serait intéressant également de changer de CMS dans Photoshop pour voir si les réactions sont différentes. Il est possible de sélectionner le CMS Microsoft.

Je remonte les 2 messages (en page 2 de ce fil) de Christophe Metairie que vous évoquez :

Citation de: Christophe Métairie le Septembre 14, 2015, 23:11:12
oui Mbe, en fait je m'aperçois que j'ai inversé les 2 rendus dans ma question ( le rendu écran en L* est plus lumineux que le Gamma 2.2 ), mais le problème reste le même : la correspondance écran tirage est meilleure avec un écran en gamma 2.2  ;)

comme quoi une question toute simple a priori donne un débat intéressant, et selon l'utilisation que l'on a des ses images certains préfèrent un écran en L* , d'autres en gamma 2.2 ...

C Métairie

Citation de: Christophe Métairie le Septembre 15, 2015, 08:55:15
oui c'est ce j'allais dire, d'autant que les différences d'affichage dans les très basses lumières entre L* et gamma 2.2 sont assez énormes, ce ne sont pas de simples petites erreurs d'interpolation ou autre, il y a véritablement un rendu différent pour ces valeurs. Sur l'image ci-dessous j'ai reproduit la différence, elle est quand même bien visible sur cet extrait  ;)

C Métairie

Citation de: olivier1010 le Septembre 24, 2015, 21:17:59

Dans le cas de Christophe, j'avais relevé une différence de gamma d'environ 0.2 dans son exemple, ce qui est une erreur assez importante.

Faire une repro de l'écran, et utiliser l'outil exposition de Photoshop qui dispose d'un curseur gamma peut être intéressant pour voir si c'est une déviation gamma.

Cela pourrait être aussi dans d'autres cas un simple décalage du niveau de noir. Une analyse à la pipette doit permettre de montrer d'où vient le problème.
Mes exemples montrent que dans le cas d'une calibration hardware les niveaux de luminance qui devraient être affichés par l'application sont pratiquement identiques, qu'on soit en L* ou gamma 2.2.

Mes tests utilisent LCMS, ce qui n'est pas le même CMS que Photoshop.

Il serait intéressant également de changer de CMS dans Photoshop pour voir si les réactions sont différentes. Il est possible de sélectionner le CMS Microsoft.

En fait, pas facile de faire des comparaisons "directes" : l'écran met plusieurs secondes à passer d'un profil à l'autre, en passant par un certain nombre de configurations intermédiaires...
Dans un premier temps, j'ai voulu faire des copies d'écran pour illustrer ("Impr écran" + collage dans un nouveau fichier), mais j'ai eu peur en voyant le résultat : le presse-papier de Windows ne semble pas gérer les couleurs (ou alors je m'y prends mal ?).

Je viens de faire une manip qui vaut ce qu'elle vaut (elle va faire hurler les puristes, je sais...  ;-) : j'ai photographié mon écran (dans l'obsucité) avec les deux profils (en full manuel, expo et BdB. TdP = 4", long devant le rafraichissement écran).
1/2 - profil réalisé en gamma 2.2 :

2/2 - profil réalisé en L* :

La différence visuelle constatée entre L* et 2,2 sur ces 2 photos (je trouve environ 0,3L sur la zone la plus noire et beaucoup plus dans les gris) est bien plus importante que celle que je constate au quotidien dans les basses lumières, peut être également parce que je fais peu de N&B (?).

Remarque : En L*, la zone gauche , c'est à dire l'eau avec un dégradé de gris n'a rien de naturelle et les micro-nuances me paraissent comme gommée.

Tenmangu81 et Verso92, le constat que vous faites sur vos écrans respectifs, est il du même ordre, inférieur ou supérieur? (avec vos photos)

Ps : Verso, je viens de voir que tu as devancé ma question... (les grands esprits .... ;))

Citation de: MBe le Septembre 24, 2015, 22:23:29
Tenmangu81 et Verso92, le constat que vous faites sur vos écrans respectifs, est il du même ordre, inférieur ou supérieur? (avec vos photos)

Ps : Verso, je viens de voir que tu as devancé ma question... (les grands esprits .... ;))

Finalement, la comparaison est malaisée, à cause de l'écran qui passe par tout un tas de configurations avant de proposer le profil final (la mémoire visuelle vaut ce qu'elle vaut...).
Apparemment, ma dernière manip semble invalider en partie ma première appréciation...

Citation de: Verso92 le Septembre 24, 2015, 22:09:17
En fait, pas facile de faire des comparaisons "directes" : l'écran met plusieurs secondes à passer d'un profil à l'autre, en passant par un certain nombre de configurations intermédiaires...
Dans un premier temps, j'ai voulu faire des copies d'écran pour illustrer ("Impr écran" + collage dans un nouveau fichier), mais j'ai eu peur en voyant le résultat : le presse-papier de Windows ne semble pas gérer les couleurs (ou alors je m'y prends mal ?).

Je viens de faire une manip qui vaut ce qu'elle vaut (elle va faire hurler les puristes, je sais...  ;-) : j'ai photographié mon écran (dans l'obsucité) avec les deux profils (en full manuel, expo et BdB. TdP = 4", long devant le rafraichissement écran).
1/2 - profil réalisé en gamma 2.2 :

Une capture d'écran n'est pas une solution viable, car elle ne délivre que des valeurs RVB qui passent normalement à travers le profil écran dans l'autre sens, alors que les tables du profil ne sont pas forcément précisément réversibles. Elle ne délivre pas les valeurs de luminance réelles qui s'affichent à l'écran.

Seule une analyse directe avec une sonde et un logiciel de lecture de patch peut donner des résultats précis et facilement comparable.

La méthode infaillible consiste à créer des images uniformes avec un seul niveau de gris, les ouvrir dans l'application graphique et lire la valeur de luminance de ces images avec la sonde et un logiciel de mesure de patch.

Recommencer les mêmes mesures avec l'autre profil écran, et regarder les différences.
Vous aurez ainsi le comportement exact d'un logiciel face à deux profils écrans différents.
Faire des repros d'écran est possible aussi, mais plus délicat à réaliser et à analyser.

Citation de: olivier1010 le Septembre 24, 2015, 22:35:39
Une capture d'écran n'est pas une solution viable, car elle ne délivre que des valeurs RVB qui passent normalement à travers le profil écran dans l'autre sens, alors que les tables du profil ne sont pas forcément précisément réversibles. Elle ne délivre pas les valeurs de luminance réelles qui s'affichent à l'écran.

Seule une analyse directe avec une sonde et un logiciel de lecture de patch peut donner des résultats précis et facilement comparable.

La méthode infaillible consiste à créer des images uniformes avec un seul niveau de gris, les ouvrir dans l'application graphique et lire la valeur de luminance de cette image avec la sonde et un logiciel de mesure de patch.

Recommencer les mêmes mesures avec l'autre profil écran, et regarder les différences.
Vous aurez ainsi le comportement exact d'un logiciel face à deux profils écrans différents.
Faire des repros d'écran est possible aussi, mais plus délicat à réaliser et à analyser.

Il n'était bien sûr pas question, tu l'auras compris, de caractériser quoi que ce soit avec ma modeste manip.

La sonde est bien sûr le seul moyen fiable de le faire.
Par contre, les conditions de PdV étant rigoureusement identiques entre mes deux clichés, il s'agissait juste de mettre en évidence d'éventuelles différences (les images, bien sûr, ne reflètent pas exactement le rendu à l'écran. Mais elles sont capables, je pense, de montrer des différences)...

Citation de: Verso92 le Septembre 24, 2015, 22:09:17
En fait, pas facile de faire des comparaisons "directes" : l'écran met plusieurs secondes à passer d'un profil à l'autre, en passant par un certain nombre de configurations intermédiaires...
Dans un premier temps, j'ai voulu faire des copies d'écran pour illustrer ("Impr écran" + collage dans un nouveau fichier), mais j'ai eu peur en voyant le résultat : le presse-papier de Windows ne semble pas gérer les couleurs (ou alors je m'y prends mal ?).

Je viens de faire une manip qui vaut ce qu'elle vaut (elle va faire hurler les puristes, je sais...  ;-) : j'ai photographié mon écran (dans l'obsucité) avec les deux profils (en full manuel, expo et BdB. TdP = 4", long devant le rafraichissement écran).
1/2 - profil réalisé en gamma 2.2 :

Attention également certaines applications nécessitent un redémarrage pour prendre en compte le changement de profil écran système.

Citation de: olivier1010 le Septembre 24, 2015, 22:47:35
Attention également certaines applications nécessitent un redémarrage pour prendre en compte le changement de profil écran système.

Une chose est sûre : ce n'est pas le cas avec Nec SpectraView II.
(quand tu passes d'un profil à 6 500K à un D50, il n'y a pas photo : ça se voit tout de suite* !)
*façon de parler, étant donné que la commutation n'est pas instantanée : je veux dire par là que la différence est telle que la mémoire visuelle suffit, dans ce cas...  ;-)

Citation de: Verso92 le Septembre 24, 2015, 22:30:25
Finalement, la comparaison est malaisée, à cause de l'écran qui passe par tout un tas de configurations avant de proposer le profil final (la mémoire visuelle vaut ce qu'elle vaut...).

Oui ce test est très difficile à faire avec une la commutation, et de plus la mauvaise mémoire visuelle n'arrange pas les choses pour faire ces comparaisons.

L'idéal pour une comparaison visuelle objective serait d'avoir 2 écrans identiques , l'un calibré en 2, 2 et l'autre en L* et d'afficher un dégradé du noir au gris par secteur sur les 2 écrans, mais je n'ai pas cette possibilité...
J'ai procédé un peu différemment en affichant ce dégradé de gris alternativement en essayant de distinguer correctement les niveaux, la manip est assez fatigante visuellement et également assez dépendante de l'ambiance lumineuse.
Dans l'obscurité je pense avoir une meilleure distinction des paliers en L*, mais le test est je le reconnais bien subjectif.

La méthode proposée par Olivier avec PatchTool est plus rigoureuse et répétitive aux fluctuations près de bruits et de luminance de l'écran (assez faibles avec des  écrans en calibration hardware et qu'il est certainement possible de négliger)

Les 2 méthodes sont intéressantes car je souhaitais voir visuellement l'apport du L* versus 2,2.

Citation de: olivier1010 le Septembre 24, 2015, 20:13:57

[...]

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.

[...]

Oui la doc, comment dire, ressemble à une liste de fonctions énumérées sans explications et sans le moindre début de consistance  ???

Pour Reflect black level in tone curve, j'ai refait un profil  L* avec et sans et vérifier les TRC et avec PatchTool, c'est bien meilleur avec. Reflect black level, correspond à une compensation du point noir.

Est ce que tu as compris la signification de "version" qui indique "Allows you to select the profile version "2.2" normally" j'en déduis que le manuel parle de la version icc en V2 ou V4, mais comme je n'ai pas fait l'essai, est ce que tu as déjà testé? (je suis resté en 2,2 pour l'instant)

Pour info, j'ai dit l'année dernière aux commerciaux d'Eizo sur la salon de la photo que la documentation de ColorNavigator était ce qu'il y a de plus mauvais dans le genre...

Citation de: Verso92 le Septembre 24, 2015, 22:49:22
Une chose est sûre : ce n'est pas le cas avec Nec SpectraView II.
(quand tu passes d'un profil à 6 500K à un D50, il n'y a pas photo : ça se voit tout de suite* !)
*façon de parler, étant donné que la commutation n'est pas instantanée : je veux dire par là que la différence est telle que la mémoire visuelle suffit, dans ce cas...  ;-)

Je parlais du redémarrage de l'application, Photoshop par exemple. Pas du système. Effictivement dans le système les changements de profil sont pris en compte instantanément, mais pas forcément dans les applications.
J'ai comparé les deux images, il y a quelque chose qui me gêne.

Le gris marron à droite de l'image, qui fait parti de l'interface de photoshop, n'a pas la même chrominance. Il y a un Delta E 2000 de 3.54, avec un Delta L* 2000 = 1.75 et Delta C* 2000 = 3.26. (Calculé avec BabelColor CT&A version 2.8.6 depuis les valeurs RVB en Adobe RGB du fichier). En chroma cela fait une rotation d'angle de 19.5 degré Delta h*.

C'est le gris marron du profil gamma 2.2 qui est plus sombre de -1.75 L*

C'est beaucoup je trouve. Normalement on devrait être en dessous d'un Delta E de 3 quelque soit la calibration sur un écran qualité graphique. Cela trahit un problème quelque part, soit dans la calibration, soit avec la sonde, soit la stabilité de l'écran.

Vous pouvez nous rappeler quel est l'environnement, sonde de mesure, logiciel de calibration, type de calibration hardware ou software, modèle d'écran et combien de temps écoulé entre la mise en marche de l'écran et les prises de vue. Stabilité en température dans la pièce entre les deux photos également (au cas ou) et délai entre les deux prises de vue.

Citation de: olivier1010 le Septembre 24, 2015, 23:28:40
J'ai comparé les deux images, il y a quelque chose qui me gêne.

Le gris marron à droite de l'image, qui fait parti de l'interface de photoshop, n'a pas la même chrominance. Il y a un Delta E 2000 de 3.54, avec un Delta L 2000 = 1.75 et Delta C 2000 = 3.26. (Calculé avec BabelColor CT&A version 2.8.6 depuis les valeurs RVB en Adobe RGB du fichier).

J'ai été surpris par la différence, aussi...
A vrai dire, j'avais tout d'abord fait les photos en BdB auto. Dans le doute, en voyant le résultat, je les ai refaites en BdB manuelle... mêmes différences.

Citation de: olivier1010 le Septembre 24, 2015, 23:28:40
C'est beaucoup je trouve. Normalement on devrait être en dessous d'un Delta E de 3 quelque soit la calibration sur un écran qualité graphique. Cela trahit un problème quelque part, soit dans la calibration, soit avec la sonde, soit la stabilité de l'écran.

Vous pouvez nous rappeler quel est l'environnement, sonde de mesure, logiciel de calibration, type de calibration hardware ou software, modèle d'écran et combien de temps écoulé entre la mise en marche de l'écran et les prises de vue. Stabilité en température dans la pièce entre les deux photos également (au cas ou) et délai entre les deux prises de vue.

Ne perds pas de vue que les valeurs que tu relèves n'ont rien d'absolues : ce sont juste des photos faites dans des conditions rigoureusement identiques, rien de plus (D810 + f/2.8 60 micro AF-D, sur trépied, dans l'obscurité. f/11~4s, 100 ISO, BdB = "ensoleillé", retardateur + Mup, obturateur d'oculaire fermé, au cas où...), à quelques secondes d'intervalle (le temps de changer de profil écran).

Seules les différences éventuelles sont intéressantes (mais pas quantifiables, bien sûr, puisqu'il s'agit de photos d'écran).
Sinon, il s'agit d'un Nec PA241w, étalonné de façon hardware avec Nec SpectraView II (dernière version) + sonde XRite i1 Display Pro.

Écran allumé depuis une ou deux heures, à la louche.

Citation de: Verso92 le Septembre 24, 2015, 23:36:59
Ne perds pas de vue que les valeurs que tu relèves n'ont rien d'absolues : ce sont des photos juste faites dans des conditions identiques, rien de plus (D810 + f/2.8 60 micro AF-D, sur trépied, dans l'obscurité. f/11~4s, 100 ISO, BdB = ensoleillé, retardateur, obturateur d'oculaire fermé, au cas où), à quelques secondes d'intervalle (le temps de changer de profil écran).
Sinon, il s'agit d'un Nec PA241w, étalonné de façon hardware avec Nec SpectraView II (dernière version) + sonde XRite i1 Display Pro.

Écran allumé depuis une ou deux heures.

Ce qui est important c'est la différence entre les images, pas les valeurs absolues. Il faudrait photographier une charte en même temps posée sur l'écran pour être sur que rien de bouge durant le processus de prise de vue ou développement du fichier.

Aussi dans ce type de photo il faut mieux générer un fichier soit en Lab, soit dans un espace en D50, car les calculs Delta E se font en D50 dans l'espace Lab. Cela évite des adaptations chromatiques qui engendrent des erreurs lors des conversions. Le Adobe RGB est en D65.
Vérifier aussi que Photoshop sait suivre un changement de profil écran en temps réel. Par sécurité un redémarrage de Photoshop ne coute pas bien cher en temps.

Citation de: Verso92 le Septembre 24, 2015, 23:33:37
J'ai été surpris par la différence, aussi...

A mon avis, le ressenti visuelle est beaucoup plus faible (1) que celui montré par tes 2 photos d'écran, mais je ne suis pas surpris non plus, car un APN (son capteur + Bayer) ne se comporte pas comme la vision humaine.
(1) c'est ce que je constate également sur mon écran

Citation de: MBe le Septembre 24, 2015, 23:13:56
Oui la doc, comment dire, ressemble à une liste de fonctions énumérées sans explications et sans le moindre début de consistance  ???

Pour Reflect black level in tone curve, j'ai refait un profil  L* avec et sans et vérifier les TRC et avec PatchTool, c'est bien meilleur avec. Reflect black level, correspond à une compensation du point noir.

Est ce que tu as compris la signification de "version" qui indique "Allows you to select the profile version "2.2" normally" j'en déduis que le manuel parle de la version icc en V2 ou V4, mais comme je n'ai pas fait l'essai, est ce que tu as déjà testé? (je suis resté en 2,2 pour l'instant)

Pour info, j'ai dit l'année dernière aux commerciaux d'Eizo sur la salon de la photo que la documentation de ColorNavigator était ce qu'il y a de plus mauvais dans le genre...

Oui j'ai regardé ça, apparemment la seule chose qui change quand on passe en version 4.2 je pense ce sont les valeurs de la matrice dans le tag d'adaptation chromatique. à confirmer quand même.

Il me semble avoir testé il y a quelque jours un profil en V2.2 et le même en V4.2 et ne n'ai pas vu de comportement différent.

Effectivement c'est bien meilleur avec l'option RBL au niveau de la justesse en luminance. Le seul problème est que cela décale les courbes TRC et qu'elles ne sont donc plus réversibles si le profil doit être utilisé à l'envers pour une capture d'écran.

Citation de: olivier1010 le Septembre 24, 2015, 23:45:11
Ce qui est important c'est la différence entre les images, pas les valeurs absolues. Il faudrait photographier une charte en même temps posée sur l'écran pour être sur que rien de bouge durant le processus de prise de vue ou développement du fichier.

Aussi dans ce type de photo il faut mieux générer un fichier soit en Lab, soit dans un espace en D50, car les calculs Delta E se font en D50 dans l'espace Lab. Cela évite des adaptations chromatiques qui engendrent des erreurs lors des conversions. Le Adobe RGB est en D65.
Vérifier aussi que Photoshop sait suivre un changement de profil écran en temps réel. Par sécurité un redémarrage de Photoshop ne coute pas bien cher en temps.

Tu sais, il ne faut pas perdre de vue que je suis un photographe amateur, et que je découvre la gestion des couleurs seulement depuis trois ou quatre ans (je n'ai pas l'expérience pointue de ceux qui fréquentent assidument cette section).
Par contre, j'ai une bonne expérience de la métrologie en général (je suis électronicien de métier), et je suis, comment dire... surpris par les différences qui peuvent exister entre les même matériels (à savoir Nec PA241w + SpectraView II "à la maison") dès qu'on change juste de sonde (d'une Spyder à une X-Rite, par exemple, et pas seulement aux mesures, mais à ce que je vois à l'écran : ce qui me fait penser que la justesse des mesures qu'on peut faire avec ces outils "grand-public" est toute relative... et il semblerait que je ne sois pas le seul à faire ce type de constat).

Citation de: Verso92 le Septembre 24, 2015, 22:30:25
Finalement, la comparaison est malaisée, à cause de l'écran qui passe par tout un tas de configurations avant de proposer le profil final (la mémoire visuelle vaut ce qu'elle vaut...).

Difficile à faire pour moi aussi, et pour les mêmes raisons. C'est vraiment dans les noirs que j'ai l'impression de voir une différence.
Je ne suis pas sûr qu'une copie d'écran dans les deux étalonnages soit concluante.

Citation de: Verso92 le Septembre 24, 2015, 23:59:24
Tu sais, il ne faut pas perdre de vue que je suis un photographe amateur, et que je découvre la gestion des couleurs seulement depuis trois ou quatre ans (je n'ai pas l'expérience pointue de ceux qui fréquentent assidument cette section).
Par contre, j'ai une bonne expérience de la métrologie en général (je suis électronicien de métier), et je suis, comment dire... surpris par les différences qui peuvent exister entre les même matériels (à savoir Nec PA241w + SpectraView II "à la maison") dès qu'on change juste de sonde (d'une Spyder à une X-Rite, par exemple, et pas seulement aux mesures, mais à ce que je vois à l'écran : ce qui me fait penser que la justesse des mesures qu'on peut faire avec ces outils "grand-public" est toute relative... et il semblerait que je ne sois pas le seul à faire ce type de constat).

Moi aussi, et j'ai découvert la gestion des couleurs depuis moins longtemps que toi  ;)
Et en tant que physicien, je sais aussi combien les différences peuvent être grandes dans la mesure d'une même grandeur avec deux instruments ou deux protocoles ou méthodologies différents....

Citation de: aziber le Septembre 24, 2015, 18:47:15
Après avoir trouvé comment activer les fonctions cachées (des CG) sur les CX/CS, voilà le résultat (et il n'y a plus la ptite étoile vous remarquerez) :

Cela permet de rendre totalement compatible bICC sur les CX/CS.

C'est disponible en cherchant sur Google !!!

C est bien et ç a m'interesse; mais avec un lien c est mieux   ;)

Citation de: Verso92 le Septembre 24, 2015, 23:59:24
Tu sais, il ne faut pas perdre de vue que je suis un photographe amateur, et que je découvre la gestion des couleurs seulement depuis trois ou quatre ans (je n'ai pas l'expérience pointue de ceux qui fréquentent assidument cette section).
Par contre, j'ai une bonne expérience de la métrologie en général (je suis électronicien de métier), et je suis, comment dire... surpris par les différences qui peuvent exister entre les même matériels (à savoir Nec PA241w + SpectraView II "à la maison") dès qu'on change juste de sonde (d'une Spyder à une X-Rite, par exemple, et pas seulement aux mesures, mais à ce que je vois à l'écran : ce qui me fait penser que la justesse des mesures qu'on peut faire avec ces outils "grand-public" est toute relative... et il semblerait que je ne sois pas le seul à faire ce type de constat).

Les colorimètres actuels sont quand même assez précis. Surtout en luminance avec un niveau de bruit de l'ordre de 0.1 cd/m². Bien plus précis par exemple que la stabilité des écrans bureautique.

Je me souviens avoir eu une sonde Spyder 1, qui était tout sauf précise et stable, elle est d'ailleurs vite partie à la poubelle car moins précise qu'une calibration à l'œil nu.

Il faut d'ailleurs différencier la stabilité et la précision. La stabilité sera importante pour par exemple homogénéiser un parc d'écrans, et pour maintenir la même calibration mois après mois.

La précision absolue est importante lorsqu'on a besoin de faire correspondre des couleurs entre divers écrans ou diverses entreprises par exemple dans le cadre de l'impression d'un catalogue contenant des couleurs pour la vente de produits ayant trait à la couleur (textile, tissus, décoration...).

Dans le domaine des écrans, il est judicieux lorsqu'on utilise des colorimètres (qui sont par nature plus précis qu'un spectro dans les bas niveaux de luminosité quel l'on rencontre dans les noirs d'un écran), de compenser ces colorimètres par une référence extérieure plus précise en chrominance, c'est à dire un spectrophotomètre.

Par exemple si vous disposez de plusieurs écrans CG Eizo, il est possible avec ColorNavigator de compenser la sonde interne de chaque écran par un même spectro externe, qui servira de référence pour tous les écrans, afin de réduire l'erreur absolue du parc d'écrans. Cela permet de garder le confort d'utilisation des sondes internes tout en apportant la précision en colorimétrie absolue d'une sonde externe unique plus onéreuse.

Cette possibilité est présente dans les logiciels de calibration haut de gamme comme Calman ou Lightspace, mais pas seulement. On la trouve aussi dans des logiciels gratuits comme HCFR et DispCalGUI, ainsi que dans ColorNavigator qui est livré avec les écrans Eizo.

Je ne l'ai pas trouvé cette fonction dans Basiccolor Display par contre, à moins que je sois passé à coté.
Il faut aussi bien être conscient qu'en gestion des couleurs, il n'est pas toujours utile d'avoir une précision redoutable à 0.5 Delta E. En effet l'œil est très peu performant quand il s'agit de comparer des couleurs qui ne se trouvent pas l'une à coté de l'autre en même temps.

C'est pour cela qu'il est généralement admis que dans le cadre d'une communication commerciale, des erreurs de 3 à 6 Delta E sont acceptables.

Citation de: olivier1010 le Septembre 25, 2015, 14:43:47

Il faut aussi bien être conscient qu'en gestion des couleurs, il n'est pas toujours utile d'avoir une précision redoutable à 0.5 Delta E. En effet l'œil est très peu performant quand il s'agit de comparer des couleurs qui ne se trouvent pas l'une à coté de l'autre en même temps.

C'est pour cela qu'il est généralement admis que dans le cadre d'une communication commerciale, des erreurs de 3 à 6 Delta E sont acceptables.

Voilà qui me réconforte dans ce que je pensais et que je mentionnais plus haut.

Citation de: olivier1010 le Septembre 25, 2015, 14:43:47
Les colorimètres actuels sont quand même assez précis. Surtout en luminance avec un niveau de bruit de l'ordre de 0.1 cd/m². Bien plus précis par exemple que la stabilité des écrans bureautique.

En ce qui me concerne, je n'ai pas été satisfait de l'étalonnage de mon écran avec une Spyder3 (les chiffres affichés à l'issue de l'étalonnage étaient bons, mais je n'étais pas satisfait par ce que je voyais).
Tout est fort heureusement rentré dans l'ordre suite à l'achat de la X-Rite i1 Display Pro (qui était livrée en bundle avec les Nec SpectraView que j'ai fait acheter au club photo... coïncidence ?).

Quel sujet!!! Mais débutant dans ce domaine, je souhaiterais savoir avec quel logiciel et appareil vous faites une calibration de l'écran en L*. J'ai acheté une spyder 3 quand j'avais un Mac mini avec un écran externe Dell classique (2311h de mémoire). Cet outil ne m'avait pas transcendé et je passais par le réglage "interne" que propose Mac OS.
Depuis 2 ans, je suis repassé sur un MacBook Pro Retina.
Est il stupide de vouloir faire un calibrage en L* avec un tel écran?
Merci pour votre éclairage.
Envoyé de mon iPad en utilisant Tapatalk

Citation de: olivier1010 le Septembre 24, 2015, 23:55:00
Oui j'ai regardé ça, apparemment la seule chose qui change quand on passe en version 4.2 je pense ce sont les valeurs de la matrice dans le tag d'adaptation chromatique. à confirmer quand même.

Il me semble avoir testé il y a quelque jours un profil en V2.2 et le même en V4.2 et ne n'ai pas vu de comportement différent.

Effectivement c'est bien meilleur avec l'option RBL au niveau de la justesse en luminance. Le seul problème est que cela décale les courbes TRC et qu'elles ne sont donc plus réversibles si le profil doit être utilisé à l'envers pour une capture d'écran.

Je vais un essai en sélectionnant 4.2 et et essayer de faire des comparaisons pour comprendre. Je ferais un retour si je vois des choses intéressantes.

Pour l'option RBL, l'inconvénient me paraît mineur vis a vis des avantages constatés.

Citation de: Lambs le Septembre 25, 2015, 20:41:24
Quel sujet!!! Mais débutant dans ce domaine, je souhaiterais savoir avec quel logiciel et appareil vous faites une calibration de l'écran en L*. J'ai acheté une spyder 3 quand j'avais un Mac mini avec un écran externe Dell classique (2311h de mémoire). Cet outil ne m'avait pas transcendé et je passais par le réglage "interne" que propose Mac OS.
Depuis 2 ans, je suis repassé sur un MacBook Pro Retina.
Est il stupide de vouloir faire un calibrage en L* avec un tel écran?
Merci pour votre éclairage.
Envoyé de mon iPad en utilisant Tapatalk

j'ai pas de Macbook pro Retina, donc pas facile de conseiller. Mais par défaut sur un écran de portable, une calibration-caractérisation est un compromis, tout en étant bien mieux que rien.
Donc oui, c'est utile. La spyder 3 avec son logiciel (version Elite) permet de le faire, j'en ai une, mais, comme j'ai eu des soucis de reproductibilité / plantage pendant les mesures, de plus il paraît (c'est du conditionnel car je n'ai pas été vérifié sur ma sonde) que les gélatines ne vieillissent pas très bien,  j'ai commuté vers une I1 display Pro. j'en suis très content, elle me donne toute satisfaction.

Donc pour ton écran de MacBook, je commencerais avec ces valeurs cibles : D65, 100cd/m², gamma 2,2.

Ensuite je ferais un essais avec : blanc Natif, 100cd/m² et gamma de 2,2. les softs de Spyder ou de I1display pro donnent la possibilité de générer un rapport de mesures et je regarderais le profil qui offre le meilleur compromis gamut / corrections colorimétriques. Une fois cet exercice effectué, si le soft que tu utilises permet une calibration-caractérisation avec un TRC L*, je ferais un essais et je regarderais si je peux gagner encore quelque "pouillèmes".
Un profil avec L* est plutôt à conseiller pour des écrans avec une calibration hardware, une excellente homogénéité de dalle , sur mon portable je n'ai même pas essayé compte tenu de la qualité de l'écran, par contre je le calibre-caractérise car j'y gagne en confort et un peu en fidélité sur les couleurs.

En synthèse, je te conseille de calibrer ton écran, tu verras nettement la différence.

Merci pour ta reponse
Envoyé de mon iPad en utilisant Tapatalk

Citation de: Lambs le Septembre 25, 2015, 20:41:24
Quel sujet!!! Mais débutant dans ce domaine, je souhaiterais savoir avec quel logiciel et appareil vous faites une calibration de l'écran en L*. J'ai acheté une spyder 3 quand j'avais un Mac mini avec un écran externe Dell classique (2311h de mémoire). Cet outil ne m'avait pas transcendé et je passais par le réglage "interne" que propose Mac OS.
Depuis 2 ans, je suis repassé sur un MacBook Pro Retina.
Est il stupide de vouloir faire un calibrage en L* avec un tel écran?
Merci pour votre éclairage.

J'ai aussi un MacBook Pro retina, dont le gamut couvre à peu près sRGB. Compte tenu de cette "limitation" et du peu de différence visible entre les TRC en L* et en gamma = 2.2, je te suggèrerais d'étalonner ton écran avec une TRC à gamma = 2.2, plus "passe-partout".
Une calibration en L* n'est permise en outre que par certains logiciels, tels que basICColor display. Sinon, bien sûr, presque n'importe quelle sonde permettra la mesure.
J'ai étalonné mon écran graphique (NEC) en TRC L*, et mon MBP en gamma = 2.2.
Le réglage interne proposé par Mac OS est, disons, rudimentaire.....

Oui, j'ai oublié de préciser qu'il existe des espaces sRGB en L*, mais sur l'écran d'un MBP, encore une fois, je doute de leur utilité.

salut,

Alors juste histoire de "peut-être" faire réfléchir un peu, voici le résultat de la caractérisation de ma surface pro 3 en L*

à comparer avec le résultat en gamma 2.2

Faux : Le L* n'a de l'influence "que" sur les basses lumières:le pied de courbe.

Oui, il ya un défaut dans la démonstration de Fred94!  ;)

On tourne en rond dans ce fil  :o

La question initiale, et la seule qui ait une utilité réelle dans la pratique :" ... que constatez vous de visu ?" est posée par l'initiateur du fil ici:
http://www.chassimages.com/forum/index.php/topic,241228.0.html (http://www.chassimages.com/forum/index.php/topic,241228.0.html)

Pour moi des réponses  de bon sens ont été apportées dès la première page.
Mais ça n'enlève rien à l'intérêt Théorique des interventions.

Citation de: MBe le Octobre 08, 2016, 23:45:27
Oui, il ya un défaut dans la démonstration de Fred94!  ;)

bonjour,

oui effectivement mais en fait je ne sais pas si c'est basic color display qui bug ou windows 10.....obligé de mesurer et de régler la luminosité avant de lancer la caractérisation??
j'ai effectué d'autres tests mais les résultats sont vraiment variable donc....bref

Pour répondre à la question: je ne vois pas grand chose sur mon CG277

bon dimanche