Bonjour,
Je ne débute pas en photo, mais je débute en colorimétrie, c’est un fait!
Alors voilà: j’ai depuis 5 ans un écran pas spécialement tourné vers l’image (samsung syncmaster f2380) que j’étalonnais jusque là avec win xp et une sonde spyder2.
J’ai acheté récemment un super excellent écran (eizo CS2420) que j’ai installé sur un portable (nouveau lui aussi, thinkpad W350 reconditionné) en multi écran sous ubuntu 16.04 en dual boot avec debian stretch. Pas de problème, tout fonctionne sous ubuntu (moins avec debian, l’eizo n’est pas reconnu malgré installation du pilote nvidia, si quelqu’un peut m’aider je suis preneur!). J’ai étalonné l’écran du portable et de l’eizo avec displaycal. J’ai réglé comme demandé la luminosité, et les canaux RVB par la touche « gain », avant de lancer l’étalonnage proprement dit. Résultats pour l’eizo (j’ai pas noté ceux du thinkpad): étendue du gamut: 99,7 % en sRGB, 98,2 en Adobe RGB, volume du gamut: 170,9 % sRGB et 117,8 % Adobe RGB. Ça parait pas mal comme résultats non?
Par ailleurs j’ai voulu faire la même chose pour le samsung, que je n’avais pas étalonné depuis très longtemps. Et là par contre, super dur de régler les canaux RVB qui n’arrétaient pas de bouger (bien que j’ai réussi à les amener « entre les flèches » comme demandé, ça a été au prix de couleurs visibles hyper rouges). J’ai quand même lancé la procédure d’étalonnage. Là les résultats sont… moins bons: 91,6 % du sRGB, 69 % du adobe avec un volume respectif de 104,9 % et 72,3.
Est ce à dire que cet écran est trop vieux, ou de mauvaise qualité, peut être plus du tout étalonnable?
Bon, tout ça pour quoi? En fait je m’aperçois que je n’y connais rien en colorimétrie! Par exemple, est ce qu’une luminosité plus ou moins intense va se répercuter sur l’histogramme dans DT? C’est quoi la différence entre profil d’entrée et de sortie? etc… Bref, ça existe un bon tuto sur ces notions appliquées à DT?
Un truc très important sur la qualité de l’écran, c’est que les couleurs doivent être sensiblement les mêmes pour des angles de vue différents. Pour les écrans plats LCD il y a essentiellement deux types de technologies : les dalles TN qui n’ont pas cette propriété (regarder l’écran en mettant les yeux au dessus de l’écran ou au contraire en contre-plongée : dans un cas l’écran est quasi-blanc et dans l’autre quasi-noir) et les dalles IPS.
Essayer d’étaloner une dalle TN est un cauchemard : la sonde va observer l’écran depuis un point de vue, pas forcément le même pour les différentes couleurs (sur ma sonde il y a un filtre à 4 cases derrière une lentille, donc les 4 cases correspondent à des angles de vue un peu différents), et qui n’est pas le même que celui de l’humain qui regarde. Bref, on mesure un peu n’importe quoi, on étalone en fonction des mesures, le résultat est n’importe quoi.
C’est fort possible que ton vieux samsung soit une dalle TN. Après, 91% de sRGB ce n’est pas non plus catastrophique pour un vieil écran non dédié a la photo.
Par exemple, est ce qu’une luminosité plus ou moins intense va se répercuter sur l’histogramme dans DT?
Non, mais c’est un point important car c’est le rendu de ton image sur l’écran. Un réglage trop clair et tu auras tendance à baisser la luminosité et lorsque tu imprimeras tu auras une image bien trop sombre. C’est un problème récurent de beaucoup de photographe qui ne comprennent pas cela. Le nombre de message du type « mes tirages sont trop sombres » ou « mes tirages sont trop clairs » peut attester de ce problème. Un écran doit être à 90-100 cd/m2 pour que le tirage corresponde. Bien évidemment cela va dépendre de la lumière ambiante donc une casquette sur l’écran est aussi un paramètre très important.
Il y a aussi ceux qui règlent la luminosité de leur écran à 150 cd/m2, voire plus et qui s’étonnent qu’on leur dise que leurs images sont bien sombres lorsqu’elle sont visionnées sur un écran dont la luminosité est plus raisonnable !
Pour les écrans EIZO il y a tout intérêt à utiliser le logiciel ColorNavigator fourni avec l’écran et retenir le profil « Photography » qui couvre à 98% le profil AdobeRGB1998.
Nota : En AdobeRGB1998 la luminosité devrait être fixée à 80 cd/m2; Heureusement nos yeux s’accoutument assez bien des variations de luminosité, dans la limite ou cela reste raisonnable, 120 cd/m2 semblerait être un max.
Attention la luminosité d’un écran de télé est bien supérieure à ces valeurs, mais il est conçu pour être vu de plus loin que celui d’un PC.
Pas mal du tout. Je travaille sur portable, je viens d’étalonner l’écran aujoud’hui et j’ai 86% de sRVB et 88% en volume. En AdobeRVB je suis dans les 65%. Je n’utilise que le sRVB comme tu t’en doutes.
Plusieurs questions suite à vos réponses:
-comment trouver la valeur de luminosité sur l’écran en cd/m2? Je n’ai que des valeurs relatives sans unités…
-J’ai fait quelques comparaisons que je joins (captures d’écrans). L’histogramme de l’eizo a un gros trou dans les basses lumières que ne présente pas celui du samsung (sur lequel j’ai fait les modifs avec DT). Ça se voit sur la photo, bien sur (celle de gauche). De plus les couleurs sur l’eizo sont beaucoup moins saturées. Je précise que j’ai exporté les fichiers raw et xmp pour faire ces comparaisons. Les modifs sont donc exactement les mêmes.
Alors je me pose la question: qui a raison?! Puisque l’étalonnage du samsung était assez erratique et que les résultats de eizo sont excellents je suppose que c’est l’eizo, mais en même temps ce trou dans les basses lumières apparait sur quasi toutes les photos, alors que dans mon souvenir (faudra que je vérifie) l’histogramme allait d’un bord à l’autre sur l’appareil photo…
Réponse à Jurande: mon écran n’était pas fourni avec colornavigator, mais il me semble que colordisplay est bien efficace aussi, non? Edit: ah si en fait, mais faut windows me semble-t-il…
-comment trouver la valeur de luminosité sur l’écran en cd/m2? Je n’ai que des valeurs relatives sans unités…
Cette valeur est indiqué au début de la phase d’étalonnage avec DisplayCAL.
[hr]
qui a raison?!
Personne, tout le monde Le « trou » que tu observes et les variations en générales des histogramme sont dû au profil écran. Les écrans ne sont pas parfait et donc la compensation ne peut pas être parfaite.
[hr]
Pour la saturation c’est probablement dû à l’explication juste avant, mais c’est un peu plus étrange! J’ai rarement observé de grosses différences de saturation sur différents écrans.
Tu pars vraiment dans une mauvaise direction, ton écran Ezio bénéficie du calibrage Hardware, ce qui veut dire que les données de correction sont stockées dans l’écran et non pas sur ton PC, c’est la meilleure façon d’avoir une calibration optimale
Pour cela Eizo met à disposition le logiciel ColorNavigator. Avec ce logiciel tout deviendra beaucoup plus simple pour toi. Par exemple tu ne te poseras pas la question de savoir qu’elle est la luminosité de ton écran, car c’est toi qui va la fixer et ColorNavigator va faire en sorte que cette valeur soit respectée.
Je ne me souviens plus si ColorNavigatorr était livré sur un CD avec l’écran ou si dans la doc il y avait l’adresse pour le télécharger, il faut que je ressorte la doc !
Je te conseille de visionner ceci : https://www.youtube.com/watch?v=LsCly1bBzFw
plusieurs choses pour répondre à vos interrogations.
Utilisez-vous toujours la Spyder 2 ? Il faut savoir que la Spyder2 date (un peu voire beaucoup) d’un temps où les écrans wide gamut étaient très rares. De fait, ce colorimètre n’est pas très adapté au wide gamut (ce qui correspond grosso modo à l’Adobe RGB) et vu son âge, il est fort probable que les filtres en gélatines aient vieillis et dénaturent les mesures. Un nouveau colorimètre serait le bienvenu …
Les valeurs de gamut que vous donnez sont bonnes et correspondent à chacun des deux écrans. Toutefois, le Samsung reste un écran à simple gamut (entendez par là du type sRGB) ce qui explique le rapport à l’Adobe RGB. Mais un gamut étendu ne garanti pas la qualité du profil …
Pour les types de profils, c’est simple :
Profil d’entrée c’est pour les périphériques d’entrée : scanner, appareil photo …
Profil de sortie, c’est pour les périphériques de sortie : écran, imprimante …
Votre CS2420 est un excellent écran wide gamut ! Le logiciel ColorNavigator est normalement fourni avec (sur le CD), mais ne vous servira pas puisqu’il n’est disponible que pour Mac et Windows. DisplayCal est parfait …
Pour les problèmes de saturation et d’histogramme, ils me paraissent liés au premier abord. Le « trou » que vous voyez peut être lié à la compression de saturation …
Pour cette désaturation, elle est typique de l’affichage d’une image sans profil dans un espace plus petit. Il se pourrait donc que votre profil écran ne soit pas bien déclaré ou bien pris en compte par votre OS (je ne connais rien à Linux, d’autant que si le CS est connecté sur un portable, il est possible que ce dernier ne soit pas à même de propager les bons profils sur 2 écrans).
Faites un essai: mettez votre profil écran dans le dossier Color/out et déclarez le dans dt comme profil écran pour voir …
Merci pour les réponses, tout ça n’est pas dramatique, et come d’habitude je panique un peu trop! Je sais que la spyder2 est obsolète, ce pourquoi j’ai acheté la spyder5 express (seul le logiciel diffère avec la version pro, donc pas besoin de payer plus cher avec displaycal!). Ce qui m’ennuie le plus est que j’ai du modifier les couleurs du samsung (très bonnes critiques à sa sortie en 2011) pour que ça rentre dans les clous du pré-étalonnage de dispcal. faut que je refasse ça.
Je reviens vers vous car je n’ai pas vraiment trouvé de solutions à la différence apparente des histogrammes sur mes 2 écrans, au niveau de ce « trou » dans les lumières sombres et de la saturation générale (voir ex sur photos jointes avant). Je suis très étonné que l’eizo présente ce trou à gauche, quasi systématique, qui n’apparaît pas sur l’histogramme du samsung ni bien sur sur celui de l’appareil photo. De plus, comme je le disais auparavant les couleurs sont très peu saturées. Du coup je continue à traiter mes raw sur le samsung, c’est con alors que je viens d’acheter un eizo!
Si quelqu’un a une idée ce serait chouette!
Merci
Je ne comprend pas bien. Pour moi, l’histogramme ne reflète que les informations de la photo ; pas celles de l’écran ! Le fait que tu visualise ta photo sur deux écrans différents, ne devrait absolument pas montrer des histogrammes différents - à configuration identique, bien sûr. Par contre l’aspect des photos elles mêmes peut être différent surtout si les écrans ont des perf différentes ou si leur calibration est différente (un calibré et l’autre non, par exemple).
Dans ta config, est-ce que les deux écrans sont connectés à la même machine ? Si c’est le cas, tu pourrais ouvrir ta photo dans DT sur l’un, puis glisser la fenêtre de DT sur l’autre et tu constaterais alors que l’histogramme ne bouge pas, alors que l’aspect de la photo elle même change.
Si ce n’est pas le cas, que les écrans sont connectés sur deux machines différentes, alors c’est qu’il y a quelque chose qui est différent entre les deux configs : un élément matériel, un élément logiciel, une configuration quelconque, difficile de le dire comme ça.
Donc pour commencer, je te conseille vivement de faire le premier test avec les deux écrans sur la même machine. On pourra ensuite y voir un peu plus clair.
Le problème est que pendant le développement, darktable applique les modules qui viennent après le module couleur de sortie dans l’espace de couleur de l’écran. La seule image calculée l’est dans l’espace de couleur de l’écran et c’est sur cette image qu’est calculé l’histogramme. Dans beaucoup de cas ça ne change pas grand chose, par exemple j’exporte toujours en sRGB et je travaille avec un profile d’écran proche de sRGB donc la différence sur l’histogramme est minime. Mais si le profile d’écran est très différent de l’espace de sortie alors ça peut changer pas mal.
Ça ne veut pas dire que l’image sera différente, c’est juste un effet de bord de la manière dont darktable fonctionne en interne (pour ne pas dire un bug).
Un « trou » de les petites valeurs me paraît plutôt bon signe pour la qualité de l’écran : ça veut dire que darktable n’a pas besoin d’aller jusqu’aux plus petites valeurs possibles pour rendre les couleurs sombres que tu observes à l’écran. Autrement dit, il reste de la marge de manœuvre pour faire encore plus sombre parce que l’écran peut rendre des noirs très profonds (qui ne sont pas utilisés dans l’image).
[Edit: Cette réponse a été écrite sans tenir compte de celle de mmoy, écrite en même temps!] Mais je suis bien d’accord! Donc, ces écrans sont bien connectés à 2 ordis différents. Je me doute bien que les histogrammes si je les connecte au même ordi seront les mêmes (ce que j’ai fait quand même pour être sur!). POur autant les histogrammes sur 2 ordis différents sont bien… différents, avec ce décalage très net dans les basses lumières. Lequel est donc le « vrai »? Il y a une différence de configuration, mais comment savoir laquelle? demain je vais déjà vérifier dans les préférences de DT les différences, et aussi (et avant tout) vérifier que cette différence d’histogramme apparaît ou pas dans un autre programme comme gimp… et je redonne des nouvelles.
@mmoy : Merci pour cette précision, j’ignorais ce mode de calcul, ce « bug » en quelque sorte.
Je viens de regarder le pipeline, effectivement, les modules
[list]
[]mixeur de canaux,
[]effet Orton,
[]vignettage,
[]virage partiel,
[]velvia,
[]cadre décoratif,
[]filigrane,
[]homogénéisation,
[/list]Sont appliqués après le module « profil de couleur de sortie ». Cela n’a pas d’importance concernant les modules qui ne touchent qu’au format tel filigrane et cadre décoratif, par contre qu’est-ce qui justifie ce choix concernant les modules qui influent sur les tonalités et les couleurs de l’image tels que mixeur de canaux ou velvia ?
Et j’ignorais également que darktable appliquait des missiles ; certes nous sommes bientôt en guerre, mais quand même !!! Allez, je vous laisse ! -->
Pour le mixeur de canaux ou velvia (et aussi virage partiel, cf. https://redmine.darktable.org/issues/10389), je soupçonne que ça soit un choix fait pour faciliter l’implementation. Avant le module « profil de couleur de sortie », tout est en Lab, c’est bien pour certaines opérations mais il y a aussi des cas ou algorithmiquement un espace RGB peut être plus pratique. Si mes souvenirs sont bons, certains modules font la conversion Lab → RGB en interne, puis la transformation, puis RGB → Lab. Sauf que « RGB tout court » ne veut pas dire grand chose, donc il faut choisir un espace de couleurs qui code l’info sur 3 canaux R, G, B. Le fait de se placer après « profil de couleur de sortie » donne un codage de type RGB « gratuitement » (donc par exemple le mixeur de canaux est trivial à coder), mais les valeurs, donc le résultat, ne sera pas le même selon si on affiche (profil écran), qu’on exporte pour le web (sRGB) ou pour l’impression (par exemple en AdobeRGB). Et c’est effectivement un peu triste.
Oups, message tapé sur mon téléphone et le correcteur automatique a fait des siennes. Corrigé, merci.
Je relance le sujet car mon problème n’a bien sur pas disparu… Ça m’énerve car je ne comprends pas pourquoi cette différence entre 2 ordis (et pas entre 2 écrans donc), sachant que les réglages de DT sont les mêmes sur les 2. J’ai de plus 3 linux sur le même ordi (ubu 16.04, xubu 18.04 et debian stretch), et les histogrammes sont exactement les mêmes, ce qui n’est guère surprenant en fait… mais tous différents de l’histo sur l’autre ordi. Nom di Diousse, je ne sais pas du tout où chercher pour expliquer cette différence et c’est assez frustrant car, comme je l’ai dit, je ne sais pas à qui me fier pour faire mes corrections…
Ouh la oui, je vais essayer de répondre à ces questions précises. Déjà, l’écran A n’est pas branché sur les 2 ordis, j’ai un écran A1sur O1 (eizo CS 2420) et un autre écran A2 sur O2 (samsung syncmaster F2380). Les 2 étalonnés avec dispcalgui et sonde spyder5 express.
-O2 est sous xubuntu 16.04
Résumé de la situation: sur O1 et O2 les histogrammes sous DT sont différents, montrant un « trou » à gauche sur O2 qu’il n’y a pas sur O1, ainsi qu’une saturation moindre. J’ai vérifié ça en prenant une capture d’écran de la même photo (nef image de base) sur O1 et en l’affichant sur O2. Le problème semblerait (?) donc venir de DT (l’histogramme ne dépend pas de l’étalonnage de l’écran, non?), pourtant les paramètres semblent bien semblables. Bref, à qui me fier?
Merciiii