Messages : 7
Sujets : 2
Inscription : May 2020
Réputation :
0
Système d'exploitation:
Distribution(s) Linux: Manjaro
Bonjour à tous,
Utilisateur de darktable (3.0.2 actuellement) depuis plusieurs années sous Linux, je me suis converti comme beaucoup à filmique.
Je suis régulièrement les tutos d'Aurélien, JC, et Luc, merci à eux ! Cependant il me reste parfois des difficultés à traiter (et surtout à comprendre).
L'un d'entre eux est la gestion des lumières surexposées.
Je prend souvent des photos sans trop pouvoir gérer la scène sur le moment (beaucoup de photos sur le vif), et donc même si je fais attention à ne pas surexposer des zones, parfois, en plein soleil c'est impossible. Je me retrouve donc avec des raw surexposés.
Jusqu'ici pas de problème, j'active la détection des zones surexposées raw et j'identifie les zones irrécupérables (et en fais le deuil ^^).
Mon problème est le suivant, moi pas comprendre.
Je rencontre souvent des zones surexposées selon le détecteur en pourcentage (pas raw) de DT, qui ne sont pas blanches, voir très loin du blanc. D'ailleurs sur mon boîtier seules les zones surex raw s'affichent. En explorant le forum j'ai cru comprendre que mon coquelicot (voir fichier raw joint) est en fait cramé sur un seul des trois canaux RVB (le rouge j'imagine...). J'ai voulu m'en assuré.
Or quand j'affiche les surex (avec 100% de limite) tout mon coquelicot est détecté cramé... ce que ne me dit pas le module courbe RVB sur le canal rouge (227,6) ! La séparation (cramé ou pas) semble se faire autour de 217 et non 255.
==> pourquoi ?
Ensuite lorsque je tente de retravailler cette image, filmique ou la balance couleur je ne sais pas très bien, me font un aplat horrible sur mon coquelicot, qui pourtant sur le raw vierge semblait garder quelques détails.
==> comment remédier à cela selon vous ?
Question accessoire : activer filmique semble me densifie les noirs très fortement sur cette image. Je perds beaucoup d'info dans les cheveux au dessus de la ceinture. Pour y remédier j'ai cru comprendre qu'il ne fallait pas toucher au point noir dans le module exposition.
==> il faut donc remonter les tons sombres dans la balance couleur ?
De plus j'ai une plage dynamique de 17 IL dans mon filmique afin de récupérer cette zone sans rendre le visage aplati dans les blancs.
==> est-ce une bonne manière de faire ? est-ce logique d'avoir une plage dynamique bien plus élevée que mon capteur ?
Je vous joins des captures de la chambre noire, mon raw, ainsi que mon xmp.
https://www.dropbox.com/sh/kz52beljczcel...9tcua?dl=0
Merci d'avance pour vos réponses les amis.
Dorian.
Messages : 1,564
Sujets : 38
Inscription : Jun 2019
Réputation :
17
Système d'exploitation:
03-05-20, 09:25
(Modification du message : 03-05-20, 09:37 par FrançoisH.)
(03-05-20, 09:19)perecastor a écrit : Bonjour à tous,
Utilisateur de darktable (3.0.2 actuellement) depuis plusieurs années sous Linux, je me suis converti comme beaucoup à filmique.
Je suis régulièrement les tutos d'Aurélien, JC, et Luc, merci à eux ! Cependant il me reste parfois des difficultés à traiter (et surtout à comprendre).
L'un d'entre eux est la gestion des lumières surexposées.
Je prend souvent des photos sans trop pouvoir gérer la scène sur le moment (beaucoup de photos sur le vif), et donc même si je fais attention à ne pas surexposer des zones, parfois, en plein soleil c'est impossible. Je me retrouve donc avec des raw surexposés.
Jusqu'ici pas de problème, j'active la détection des zones surexposées raw et j'identifie les zones irrécupérables (et en fais le deuil ^^).
Mon problème est le suivant, moi pas comprendre.
Je rencontre souvent des zones surexposées selon le détecteur en pourcentage (pas raw) de DT, qui ne sont pas blanches, voir très loin du blanc. D'ailleurs sur mon boîtier seules les zones surex raw s'affichent. En explorant le forum j'ai cru comprendre que mon coquelicot (voir fichier raw joint) est en fait cramé sur un seul des trois canaux RVB (le rouge j'imagine...). J'ai voulu m'en assuré.
Or quand j'affiche les surex (avec 100% de limite) tout mon coquelicot est détecté cramé... ce que ne me dit pas le module courbe RVB sur le canal rouge (227,6) ! La séparation (cramé ou pas) semble se faire autour de 217 et non 255.
==> pourquoi ?
Ensuite lorsque je tente de retravailler cette image, filmique ou la balance couleur je ne sais pas très bien, me font un aplat horrible sur mon coquelicot, qui pourtant sur le raw vierge semblait garder quelques détails.
==> comment remédier à cela selon vous ?
Question accessoire : activer filmique semble me densifie les noirs très fortement sur cette image. Je perds beaucoup d'info dans les cheveux au dessus de la ceinture. Pour y remédier j'ai cru comprendre qu'il ne fallait pas toucher au point noir dans le module exposition.
==> il faut donc remonter les tons sombres dans la balance couleur ?
De plus j'ai une plage dynamique de 17 IL dans mon filmique afin de récupérer cette zone sans rendre le visage aplati dans les blancs.
==> est-ce une bonne manière de faire ? est-ce logique d'avoir une plage dynamique bien plus élevée que mon capteur ?
Je vous joins des captures de la chambre noire, mon raw, ainsi que mon xmp.
https://www.dropbox.com/sh/kz52beljczcel...9tcua?dl=0
Merci d'avance pour vos réponses les amis.
Dorian.
Salut Davian et bienvenu,
j'ai eu le même souci d'applat gris que l'on peut atténuer "reconstruction des hautes lumières" avec le curseur seuil de troncature.
Cordialement
François
EOS 1Ds, 7D Mark I/II, #M42, FujiX20
Flickr
Messages : 458
Sujets : 23
Inscription : Feb 2020
Réputation :
8
Système d'exploitation:
Distribution(s) Linux: Kubuntu 24.04
03-05-20, 10:47
(Modification du message : 03-05-20, 11:50 par Cobert.)
Hello,
En essayant la photo, on voit que seule la main est cramée, pas le coquelicot ( bouton carré rouge et vert, chambre noire en bas de l'image).
L'applat vient de la saturation des haute lumières, il faut compresser les blancs.
Avec une exposition de +1IL, on peut régler la plage dynamique :
La plage dynamique de 17 IL est celle de la scène pas de l'appareil f22 1/350 entre 17 et 18:
https://fr.wikipedia.org/wiki/Indice_de_lumination
J'ai compris ça il n'y a pas longtemps
lien intéressant:
https://darktable.fr/2020/03/fr-darktabl...-lumieres/
colorisation et filtre passe bas sur la zone cramée
Cordialement
Messages : 38
Sujets : 7
Inscription : Aug 2019
Réputation :
0
Système d'exploitation:
Distribution(s) Linux: Debian GNU/Linux bullseye/sid
Bonsoir,
Voici ma contribution.
J'ai réalisé un masque dessinée sur le coquelicot pour le saturer à partir du module zones de couleurs.
Les réglages xmp sont dans le jpeg.
Merci @Cobert pour le lien wikipedia sur les IL en fonction des ouvertures et temps de pose.
Grâce à toi, moi je viens de comprendre
Belle soirée à tous
NIKON Z 6_2
Nikkor Z 24-120mm f/4 S
Debian GNU/Linux trixie/sid / Fedora 38 / Gnome-Shell
Darktable github 4.4.0 et master
Messages : 666
Sujets : 31
Inscription : Dec 2017
Réputation :
17
Système d'exploitation:
Distribution(s) Linux: Manjaro XFCE
03-05-20, 23:06
(Modification du message : 03-05-20, 23:14 par JacoTux.)
@ perecastor
> Or quand j'affiche les surex (avec 100% de limite) tout mon coquelicot est détecté cramé...
Non il est loin d'être cramé ce coquelicot, désactive la vérification de gamut prend un échantillon à la pipette et tu verras que seul le canal rouge est assez fort... pas franchement anormal pour un coquelicot, mais rien qui s'approche pour les canaux RVB de la punition rédhibitoire... cramé à la prise de vue.
Surexposé avec l 'alerte des pixels qui s'approchent des limites du blanc et du noir ne dit pas cramé, il y a de l'information dans les pixels, même s'ils s'approchent du blanc pur RVB = 255,255,255 (lui est théorique quand même dans la vraie vie)
La seule zone dont le capteur aura été saturée à la prise de vue est sur la main... effectivement si la plage est grande il faut en faire son deuil.
Par chance ici ce n'est pas le cas, quelques canaux n'ont pas été touchés, la bonne option dans ce cas est la reconstruction des hautes lumières avec option reconstruire les couleurs qui va utiliser la teinte des pixels adjacents. Bien dans les ciels ou ce cas, la peau est censée d'une teinte uniforme sous un même éclairage, surtout à cet âge... au mien c'est foutu .
Quant à la vérification de gamut, elle n'a rien à voir avec l'exposition, elle indique des pixels borderline à l'espace couleur.
Pour un écran ce n'est pas trop le problème... il ne faut pas non plus se prendre la tête avec ça, la preuve le rouge du coquelicot se voit bien, mais ça peut devenir problématique si la destination de ton traitement est un tirage sur papier.
Et il est vrai que filmique dans sa première version avait quelques difficultés à mapper certaines teintes, certaines sont toujours difficiles à travailler filmique ou pas, le bleu des LEDs par exemple.
Voilà les seules zones concernées par une saturation de lumière sur les photosites à la prise de vue, l'icône d’alerte de surexposition RAW
est là pour les identifier, ailleurs tout est gérable avec dt sans faire des aplats gris sale.
C'est ton premier post, pense à te présenter ici.
Messages : 7
Sujets : 2
Inscription : May 2020
Réputation :
0
Système d'exploitation:
Distribution(s) Linux: Manjaro
04-05-20, 09:12
(Modification du message : 04-05-20, 09:13 par perecastor.)
D'abord merci pour vos réponses rapides !
FrançoisH ==> reconstruction des hautes lumières (en mode reconstruire les couleurs) fonctionne très bien en effet, merci !
Cobert ==> ton argument de plage dynamique évolutive me convainc plutôt... sauf que j'ai déclenché à f/2,2 et pas 22
JacoTux ==> la détection violette n'est pas l'épreuvage gamut mais bien celui des hautes lumières en pourcentages, j'ai changé le rouge par défaut parce que pour voir sur un coquelicot pas top. Mais du coup je ne comprend toujours pas pourquoi ce détecteur de lumières cramées me signale tout mon coquelicot (la limite haute a bien été fixée à 100% sur la capture). Dois-je supposer qu'il n'est pas fiable et m'en tenir à la détection raw uniquement ?
GegeL==> en effet ça rend bien !
Sinon une idée sur ma question accessoire ?
Messages : 666
Sujets : 31
Inscription : Dec 2017
Réputation :
17
Système d'exploitation:
Distribution(s) Linux: Manjaro XFCE
Bonjour perecastor
> JacoTux ==> la détection violette n'est pas l'épreuvage gamut mais bien celui des hautes lumières en pourcentages, j'ai changé le rouge par défaut parce que pour voir sur un coquelicot pas top.
Non je n'arrive à reproduire ton effet qu'en activant l'alerte sur ex/sous ex + vérification de gamut
Messages : 38
Sujets : 7
Inscription : Aug 2019
Réputation :
0
Système d'exploitation:
Distribution(s) Linux: Debian GNU/Linux bullseye/sid
Bonjour Perecastor
Je confirme ce que dit @JacoTux.
Voici 2 captures d'écran qui montre les 2 alertes concernées à l'étape exposition où j'ajoute 0.8IL :
Alerte sur/sous exposition :
Alerte gamut :
Tu peux le vérifier en reprenant le développement qui est inclus dans le jpeg de mon message #4. Table lumineuse > développement > charger un xmp
Belle journée.
NIKON Z 6_2
Nikkor Z 24-120mm f/4 S
Debian GNU/Linux trixie/sid / Fedora 38 / Gnome-Shell
Darktable github 4.4.0 et master
Messages : 458
Sujets : 23
Inscription : Feb 2020
Réputation :
8
Système d'exploitation:
Distribution(s) Linux: Kubuntu 24.04
---pourquoi ce détecteur de lumières cramées me signale tout mon coquelicot (la limite haute a bien été fixée à 100% sur la capture).
Je ne comprends pas "la capture",
Le niveau haut de détection est-il autour de 100 (clic droit sur le bouton détection)?
cordialement.
Messages : 1,190
Sujets : 47
Inscription : Mar 2016
Réputation :
71
Système d'exploitation:
Distribution(s) Linux: Fedora 29
04-05-20, 10:29
(Modification du message : 04-05-20, 10:30 par aurelienpierre.)
La détection de sur-exposition de darktable n'est pas une détection de sur-exposition.
La sur-exposition implique que la luminance dépasse 100 %. 100 % de quoi ? De la luminance "pic" du medium de sortie, c'est à dire du blanc le plus blanc que ce medium (papier ou écran) peut restituer.
Dans darktable, premièrement on n'affiche pas les valeurs qui dépassent 100 % mais 99 % ou moins, à la demande de l'utilisateur. Ce qui veut dire qu'il y a encore des pixels valides là dedans. (Il y a des raisons techniques qui font qu'on ne pourrait pas afficher les pixels strictement au-delà de 100 %).
Donc il faut exercer son jugement, en fonction de la taille de la zone marquée, pour décider si c'est grave ou pas.
Deuxièmement, darktable n'affiche pas la luminance supérieure à 99 % mais les canaux RGB individuels supérieurs à 99 %. Ce qui veut dire que si 2 canaux sont ok, mais un canal est saturé, vous voyez une alerte haute lumière quand même. Dans ce cas, il n'y a pas sur-exposition mais dépassement de gamut, et les zones de hautes lumières vont coïncider avec celles de l'alerte gamut. Mais l'alerte hautes lumière de dt ne fait ps la différence entre les deux.
Ce que dit l'alerte hautes lumières, c'est donc qu'un au moins de vos canaux RGB est supérieur à 99 %. À vous de voir si c'est grave ou pas, en fonction de la taille de la zone impactée et du résultat visuel.
|