Interrogations sur la détection des lumières surexposées et filmique

[GegeL]

@chloma

Je viens de réaliser le chargement du fichier jpeg du post #4 dans un clone sur la dernière master compilée à l'instant et je n'ai pas le fonctionnement que tu décris.
Désolé
Clone 0 ou clone 1, l'historique est complet :




Je ne comprends pas ce qui se passe d'une version et/ou d'une distrib à l'autre si on considère que le problème est là.



Je remet ici le jpeg de hier soir au cas ou :

[chloma]

Merci GegeL, c'est bon.

[aurelienpierre]

La détection de sur-exposition... etc
Ce que dit l'alerte hautes lumières... etc

Aparté par rapport au sujet demandé.
Je ne veux pas me faire l'avocat du diable mais les utilisateurs, nouveaux venus principalement, ne sont pas aidés par deux définitions proches du manuel... certes suffit de lire la suite mais quant-ils posent une question sur le forum on ne sait jamais trop duquel des deux boutons ils parlent.
3.3.11.3 Alerte de surexposition, original RAW overexposed warning
3.3.11.4 Alerte de surexposition et sous exposition, original Over/underexposed warning

Ça c'est le résultat que tu obtiens quand tu as des dévs qui comprennent pas ce qu'ils codent… Bienvenue dans l'opensource. Je suis d'accord avec toi, mais j'ai pas de solution à proposer. C'est systémique.

[GegeL]

Pour info, je viens de faire une découverte très intéressante concernant ce problème de sur exposition du coquelicot.

Je possède également un portable HP sur lequel fonctionne les dernières version de DT 3.0.2 et master compilées avec une distribution Fedora 32.

En reprenant l'image de @perecastor sur ce portable et bien je reproduit exactement le même fonctionnement que dans sa vidéo du post #12 et donc le coquelicot est sur exposé dés le départ, en fait uniquement le canal rouge.
Une mesure avec la pipette sur le coquelicot me montre que sur la portable fedora 32 le canal rouge est à 255 tandis que sur le poste de travail debian il est à 242.

La différence c'est que les deux ordinateurs outre la distribution (fedora 32 vs debian testing) n'utilise pas du tout le même écran.
L'écran du portable avec fedora 32 affiche seulement 58% du sRVB tandis que celui utilisé avec la debian affiche pratiquement 100% du sRVB.
Les 2 sont calibrés avec DisplayCAL et une sonde X-Rite Colormunki.

Je ne suis pas du tout calé pour dire si cela est dû à la distribution ou à l'écran, mais le fait est que je reproduis le même "problème".

Les utilisateurs compétents comme Aurélien auront certainement un avis éclairé

[nicoauffray]

Ça c'est le résultat que tu obtiens quand tu as des dévs qui comprennent pas ce qu'ils codent… Bienvenue dans l'opensource. Je suis d'accord avec toi, mais j'ai pas de solution à proposer. C'est systémique.

Il y aurait probablement beaucoup d'autres choses à revoir dans le manuel. Le problème, c'est le boulot que ça demande et d'avoir les bonnes compétences/connaissances. Mais déjà pour cette partie du manuel, ça commencerait par de meilleurs intitulés.

J'ai bien envie de travailler un peu sur ce manuel mais j'aimerais déjà voir le passage vers markdown terminé, ça serait moins chiant pour travailler dessus. docbook, c'est pas la panacée...

[perecastor]

GegeL ==> il a donc bien différences, tu me rassures.
Cependant je n'ai pas compris si tu avais des zones détectées cramées à 255 ou en dessous. Parce que pour moi c'est aussi cela qui m'intrigue, outre le fait que nous n'ayons pas tous les mêmes zones détectées, mes zones détectées ne sont pas à 255, même sur le canal rouge.
Dois je comprendre que malgré une luminance à 227,6 sur le canal rouge (sur ma capture d'écran originale j'ai bien placé le module courbe RVB visible) le coquelicot est hors gamut, et donc apparaît dans l'alerte toute de même ? J'avais compris qu'être hors gamut nécessitait qu'au moins un des canaux RVB soit à 255.
Pour être clair, lorsque tu reproduis ma situation, tes zones détectées cramées le sont elles à 255 sur le rouge ou moins ?
Sinon j'ai réussi ta manip pour avoir l'xmp depuis le jpg. Merci !

Cobert ==> je suis en en RVB Rec2020 linéaire, j'ai cru comprendre qu'il ne fallait pas trop toucher à ce profil d'entrée.

Sinon sachez que mon écran est vieux, ASUS VH242, mais calibré avec une Spyder 4 et Display Cal. J'ai cru comprendre que cette information pouvait aider.

Ma distribution est Manjaro Cinnamon. Mais en testant sur mon portable Linux Mint, même phénomène.

[JacoTux]

Mais non, encore une fois, ce n'est pas en prenant un échantillon à la pipette où vous auriez le canal rouge à 255 que cette zone est surexposée.
Déjà la pipette globale donne un résultat en fonction de l'espace colorimétrique de l'écran (son espace couleur) et après traitement du pipe.
Faut-il le connaître et qu'il soit renseigné dans le système, sinon c'est "système" par défaut.
Voir à ce titre le bouton épreuvage qui permet activé et clic droite de modifier son rendu et son profil, ça change la donne, par défaut je crois que c'est  perceptif et système.

Si je prends ton image avec les seuls modules activés à l'ouverture, l'alerte de sur/sous exposition ne me fait rien virer sur le coquelicot, voilà ce que j'ai.



Ajout : et ne pas avoir touché à correction du profil d'entrée qui est différent de profil de couleur d'entrée.
Correction du profil d'entrée où nous retrouvons des curseurs similaires à filmique, luma gris moyen, expo relative noir, etc

perecastor > je suis en en RVB Rec2020 linéaire, j'ai cru comprendre qu'il ne fallait pas trop toucher à ce profil d'entrée.
Attention le profil de couleur d'entrée n'est pas RVB Rec2020 lineaire mais dans ton cas, standard color matrix, c'est le profil de travail qui est RVB Rec2020 lineaire, voir les options du module profil de couleur d'entrée.

Quant à l'espace couleur c'est celui qui est utilisable par tel ou tel matériel, papier, etc.. ils sont plus ou moins grands, le fait qu'une couleur ne puisse être rendue dans un espace ne la rend pas sursaturée sur sa teinte ni qu'elle n'existerait pas.
Le fameux sRGB c'est disons... le minimum syndical commun.

[GegeL]

Bonjour à tous,

@JacoTux
Je comprends parfaitement ce que tu explique et suis entièrement d'accord.
Merci pour l'explication et les précisions sur la pipette globale.

Concernant mon post #24 de hier soir, j'ai parlé de sur exposition du coquelicot dés le départ sur le portable et je comprends que c'est un abus de langage.
Il n'est pas réellement sur exposé, il est juste détecté par l'alerte de sur/sous exposition de DT. L'alerte de sur exposition RAW ne détecte que la main.

Reste que je ne comprends pas pourquoi sur le portable l'alerte de sur/sous exposition de DT détecte le coquelicot et pas sur mon poste de travail.
Je peux affirmer, pour l'avoir vérifier avant de poster, que tous les réglage de DT sont identiques.
Les seules différences sont celles que je cite dans le post #24 et je n'est absolument pas les compétences nécessaires pour savoir qui du profil écran ou de la distrib font que DT réagisse de cette façon sur le portable, mais c'est un fait.
Je posterai une copie d'écran venant du portable ce soir car là je suis au boulot et je profite de la pose pour poster.

Darktable est un superbe logiciel que j’adore et, entre guillemet, ce "problème" n'en est pas un pour moi car je suis en train d'apprendre à faire de plus en plus confidence à mes yeux pour développer les photos et à ce titre MERCI à ce forum et à ses contributeurs.

J'espère que quelqu'un ayant les compétences techniques pourra expliquer ce fonctionnement ou bien pourra mettre en avant un problème de réglage.

Merci.

[JacoTux]

@ GegeL
> Je peux affirmer, pour l'avoir vérifier avant de poster, que tous les réglage de DT sont identiques.
> Les seules différences sont celles que je cite dans le post #24 et je n'est absolument pas les compétences nécessaires pour savoir qui du profil écran ou de la distrib font que  DT réagisse de cette façon sur le portable, mais c'est un fait.

Je te crois sur parole, pas de problème.
Ôtes te toi de l'idée que la distri puisse avoir un effet, les compilations sont faites à partir des mêmes sources, éventuellement les dépendances peuvent-être de versions différentes chez les uns ou les autres, mais que je sache ça ne jouerait pas sur ce point. D'un OS à l'autre ou d'une version dt à l'autre le problème pourrait apparaître, bug ou autres raisons. 

Par contre l'écran impacte le rendu, c'est sûr, entre celui d'un portable un peu ancien pas du tout adapté à ce type de travail et un écran conçu pour, calibré et utilisant un espace couleur élargi tu ne vas pas du tout avoir le même rendu et la pipette globale ne s'y trompe pas. La vérification de gamut aussi qui selon l'écran et les options choisies ne vont pas retourner les mêmes plages identifiées hors gamut d'un écran à l'autre.
Si tu peux plugger un autre écran sur ton laptop HP, tu vas t'en rendre compte de suite... là ce sera avec exactement la même distri, version de dt, et même réglages.

Mais il ne faut pas parler de surexposition sur ce coquelicot, ça n'en est pas une.
Et garder à l'esprit que l'alerte sur/sous exposition sur l'image est en sortie, tous modules en aval du pipe peuvent faire varier la mise en évidence ou pas de pixels, contrairement à l'alerte surex RAW.

[aurelienpierre]

Pour info, je viens de faire une découverte très intéressante concernant ce problème de sur exposition du coquelicot.

Je possède également un portable HP sur lequel fonctionne les dernières version de DT 3.0.2 et master compilées avec une distribution Fedora 32.

En reprenant l'image de @perecastor sur ce portable et bien je reproduit exactement le même fonctionnement que dans sa vidéo du post #12 et donc le coquelicot est sur exposé dés le départ, en fait uniquement le canal rouge.
Une mesure avec la pipette sur le coquelicot me montre que  sur la portable fedora 32 le canal rouge est à 255 tandis que sur le poste de travail debian il est à 242.

La différence c'est que les deux ordinateurs outre la distribution (fedora 32 vs debian testing) n'utilise pas du tout le même écran.
L'écran du portable avec fedora 32 affiche seulement 58% du sRVB tandis que celui utilisé avec la debian affiche pratiquement 100% du sRVB.
Les 2 sont calibrés avec DisplayCAL et une sonde X-Rite Colormunki.

Je ne suis pas du tout calé pour dire si cela est dû à la distribution ou à l'écran, mais le fait est que je reproduis le même "problème".

Les utilisateurs compétents comme Aurélien auront certainement un avis éclairé

Ah oui, j'ai zappé ce détail.

L'alerte de sur-exposition prend en compte les valeurs RGB dans l'espace de couleur de l'écran. Ce comportement peut être changé en définissant l'espace de couleur de l'histogramme sur sRGB ou Adobe RGB (clic droit sur l'icône d'épreuvage écran -> profil de l'histogramme). Effectivement, si vous comparez tous la sortie de l'alerte dans un espace RGB différent, vous avez tous des résultats différents.