Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Écrans, couleur, étalonnage...
#11
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.
Répondre
#12
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
Répondre
#13
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.
Mes photos : jpverrue.fr
Répondre
#14
(17-04-18, 17:35)jpverrue a écrit : 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).

Ça c'est ce qu'on aimerait avoir en théorie, mais ce n'est pas le cas en pratique avec darktable : https://redmine.darktable.org/issues/10507

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).
Répondre
#15
[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.
Répondre
#16
@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
  • mixeur de canaux,
  • effet Orton,
  • vignettage,
  • virage partiel,
  • velvia,
  • cadre décoratif,
  • filigrane,
  • homogénéisation,
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 !!! Big Grin Allez, je vous laisse ! -->[]
Mes photos : jpverrue.fr
Répondre
#17
(18-04-18, 11:24)jpverrue a écrit : @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
  • mixeur de canaux,
  • effet Orton,
  • vignettage,
  • virage partiel,
  • velvia,
  • cadre décoratif,
  • filigrane,
  • homogénéisation,
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 ?

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.

(18-04-18, 11:24)jpverrue a écrit : Et j'ignorais également que darktable appliquait des missiles ; certes nous sommes bientôt en guerre, mais quand même !!! Big Grin Allez, je vous laisse ! -->[]

Oups, message tapé sur mon téléphone et le correcteur automatique a fait des siennes. Corrigé, merci.
Répondre
#18
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...

Bref, si quelqu'un a un début de piste, merci!
Répondre
#19
Peux-tu rappeler précisément ce que tu observes. Pour le moment j'ai:

1. sur un ordi O1, 3 Linux installé (ubu 16.04, xubu 18.04 et debian stretch), histogramme identique et affichage identique sur écran A

2. sur un autre ord O2i, histogramme différent que sur O1 et affichage différent que sur O1 avec même écran A.

==> ce qui me manque (c'est peut-être déjà dit plus haut mais un résume précis dans le même poste aidera grandement):

- O2 tourne avec quel OS
- 01 utilise quelle carte graphique
- O2 utilise quelle carte graphique
- sur quel port est branché l'écran A sur l'ordi O1
- sur quel port est branché l'écran A sur l'ordi O2
- est-ce que tu as calibré l'écran A sur O1
- est-ce que tu as calibré l'écran A sur O2
- quel environnement graphique tu utilises sur O1
- quel environnement graphique tu utilises sur O2

Voilà, je pense que cela peut aider...
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre
#20
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

-Carte graphique O2: VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) (prog-if 00 [VGA controller])
    Kernel driver in use: i915
    Kernel modules: i915

-Carte graphique O1: VGA compatible controller [0300]: intel corporation 3rd Gen Core processor graphics controller [8086:0166] (rev09)
Kernel driver in use: i915
Kernel modules: i915

-A1 est branché sur O1 par DVI

-A2 est branché sur O2 par VGA

-environnement O1: gnome et xfce

-Environnement O2: xfce

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
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 4 visiteur(s)