Messages : 666
Sujets : 31
Inscription : Dec 2017
Réputation :
17
Système d'exploitation:
Distribution(s) Linux: Manjaro XFCE
(28-04-20, 14:32)Cobert a écrit : Hello,
Je reviens sur ce sujet car je n'ai pas compris le PDR (définition?) et pour moi la dynamique donnée par DXO en EV me semble pas mal.
Par contre j'ai un problème avec la correspondance IL et nombre de bits.
J'ai une photo prise à f/22, 1/25ième, 100 iso , je je suis juste à la limite du cramage.(quelques pixels bleus) donc j'utilise toute la dynamique du capteur.
D'après
https://fr.wikipedia.org/wiki/Indice_de_...sc%C3%A8ne
Tableau valeur usuel: je suis autour de 13 IL (13,46). DXO me donne aussi autour de 13, donc ça me parait cohérent.
https://www.dxomark.com/Cameras/Sony/A60...asurements
Mais le codage est 12 bits sur mon boiter et à y réfléchir je ne vois pas pourquoi il y aurait corrélation nombre de bits et dynamique en IL.
On a dans le capteur une conversion lumière/ tension électrique puis quantification (CAN), pas forcément de rapport quantité de lumière et le pas de quantification en nombre de bits.
Quand on est passé du CD audio 20 bits à 24 bits on a pas changés la dynamique des micros simplement un meilleur rendu.
qu'en pensez-vous?
PDR pour Photographic Dynamic Range (c'est du british)
Oui pour ta scène prise à f/22, 1/125 à 100 ISO selon la page Wikipedia, mais qui n'a rien à voir avec la plage admissible d'un capteur fournie par DXO.
Tant mieux si ton APN est en capacité de couvrir cette plage sans pixels brûlés ou sans signal (tout dépend sur quoi la mesure a été faite... f/22 je suppose sur les hautes lumières)... attention le bleu et le rouge dans dt indiquent des pixels sous-ex ou sur-ex... pas forcement cramés. Ceux là sont identifiables avec le bouton en damier.
Ici c'est du cramé :
Oui la conversion fonctionne comme l'audio, les 12 bits de ton capteur seront moins définis que les 14 du Sony que je citais... j'ai peut-être dis une bêtise plus haut.
La taille des photosites a son importance et le rapport signal/bruit pour le gain d'un capteur.
Pour aller plus loin, ici un pdf assez complet sur la sensitométrie des capteurs photo.
Mais pour en revenir à DXO vs Photons 2 Photos, ils font une analyse des images probablement avec une appli de ce genre, pas une mesure des capteurs, encore une fois il faudrait connaître leur protocole de test plus précisément et quelles limites ils se donnent pour considérer un signal/bruit acceptable.
DXO me parait optimiste pour un capteur x-trans (Fuji X100 premier du nom, rien d'autre) qui n'est pas du Bayer ceci explique peut-être cela.
Messages : 3,201
Sujets : 49
Inscription : Feb 2016
Réputation :
72
Système d'exploitation:
Distribution(s) Linux: opensuse tumbleweed
Petite erreur : le capteur du premier X100 était un capteur avec une matrice de Bayer. La matrice Xtrans n'est apparue que sur le second de la série : le x100s
Messages : 666
Sujets : 31
Inscription : Dec 2017
Réputation :
17
Système d'exploitation:
Distribution(s) Linux: Manjaro XFCE
28-04-20, 17:59
(Modification du message : 28-04-20, 18:01 par JacoTux.)
(28-04-20, 16:31)JaCo a écrit : @JacoTux
Bonjour,
Je ne saisis pas ta remarque sur l'échelle ...
Mais j'en ai une. Lorsque j'utilise le tableau blanc Witheboard de microsoft, certaines actions ne sont pas possibles avec le stylo et cà me barbe d' alterner stylo et souris. Mais je vais faire un effort.
PS : peut-être avez-vous remarqué que je ne joue jamais avec le curseur "Echelle de la plage dynamique". Ce n'est qu'en dernier recours que je m'en sers.
Oui, je n'aurai pas du entrer dans cette notion de repère graphique venu brouiller ton message.
Tablette : ceci explique cela, de mon coté j'ai openboard (linux of course) et c'est bien pratique... pas simple à la souris de tirer un trait droit ou d'écrire.
Encore merci pour tes tutos, le dernier m'a rassuré je pensais être le dernier des Mohicans à regarder l'histogramme après les propos d'Aurélien ( il n'a pas tort quand même, il ne faut pas trop avoir l’œil rivé dessus)
(28-04-20, 17:48)jpverrue a écrit : Petite erreur : le capteur du premier X100 était un capteur avec une matrice de Bayer. La matrice Xtrans n'est apparue que sur le second de la série : le x100s
Au temps pour moi, j'ai eu un x100f, la comparaison ne pouvait donc pas du tout aller.
Messages : 1,124
Sujets : 51
Inscription : Jun 2016
Réputation :
15
Système d'exploitation:
Distribution(s) Linux: Ubuntu 22.04
28-04-20, 18:02
(Modification du message : 28-04-20, 18:04 par manu.)
Est-ce que, pour répondre à la question initiale, qui est un peu la mienne aussi :
(16-04-20, 15:23)Lamiche1457 a écrit : Je trouve des valeurs différentes suivant les sites consultés:
https://www.photonstophotos.net/Charts/DXOPDR.htm me donne 11.57 IL à 100 iso alors que
https://www.dxomark.com/Cameras/Nikon/D6...asurements me donne 14.36.
Qui dois-je croire On peut dire que l'une et l'autre se basent sur des méthodes différentes, éventuellement erronées (cf. le commentaire d'Aurélien) et qu'on n'a pas plus de garantie que telle ou telle méthode, et donc valeurs de plage dynamique ou PDR soient celles du capteur qui nous intéressent ?
Et partant de là, chacun voit midi à sa porte et choisit sa référence et, pour l'application qui peut nous intéresser dans Filmique RVB, en fait ce qu'il voudra ou pourra ?
dt stable / Ubuntu 22.04
Messages : 1,190
Sujets : 47
Inscription : Mar 2016
Réputation :
71
Système d'exploitation:
Distribution(s) Linux: Fedora 29
28-04-20, 18:07
(Modification du message : 28-04-20, 18:18 par aurelienpierre.)
(28-04-20, 14:32)Cobert a écrit : Hello,
Je reviens sur ce sujet car je n'ai pas compris le PDR (définition?) et pour moi la dynamique donnée par DXO en EV me semble pas mal.
Par contre j'ai un problème avec la correspondance IL et nombre de bits.
J'ai une photo prise à f/22, 1/25ième, 100 iso , je je suis juste à la limite du cramage.(quelques pixels bleus) donc j'utilise toute la dynamique du capteur.
D'après
https://fr.wikipedia.org/wiki/Indice_de_...sc%C3%A8ne
Tableau valeur usuel: je suis autour de 13 IL (13,46). DXO me donne aussi autour de 13, donc ça me parait cohérent.
https://www.dxomark.com/Cameras/Sony/A60...asurements
Mais le codage est 12 bits sur mon boiter et à y réfléchir je ne vois pas pourquoi il y aurait corrélation nombre de bits et dynamique en IL.
On a dans le capteur une conversion lumière/ tension électrique puis quantification (CAN), pas forcément de rapport quantité de lumière et le pas de quantification en nombre de bits.
Quand on est passé du CD audio 20 bits à 24 bits on a pas changés la dynamique des micros simplement un meilleur rendu.
qu'en pensez-vous?
Le nombre de bits, c'est la borne supérieure de la plage dynamique qu'on peut encoder en échelle linéaire. Pas la valeur directe.
12 bits, ça donne 4096 valeurs entre 0 et 4095.
Le premier EV sous le blanc est encodé entre 4095 (= 2^12 - 1) et 2048 (= 2^11).
Le deuxième EV sous le blanc est encodé entre 2047 (= 2^11 - 1) et 1024 (= 2^10).
Le 3e EV entre 1023 (2^10 - 1) et 512 (2^9)
4e entre 511 (2^9 - 1) et 256 (2^8)
5e entre 255 (2^8 - 1) et 128 (2^7)
6e entre 127 (2^7 - 1) et 64 (2^6)
7e entre 63 (2^6 - 1) et 32 (2^5)
8e entre 31 (2^5 - 1) et 16 (2^4)
9e entre 15 (2^4 - 1) et 8 (2^3)
10e entre 7 (2^3 - 1) et 4 (2^2)
11e entre 3 (2^2 - 1) et 2 (2^1)
12e entre 1 (2^1 - 1) et 0 (2^0).
Déjà, y a un truc qui devrait apparaître clairement : on est autant sensible au premier qu'au dernier EV, pourtant le premier avale la moitié de la plage de codage, alors que le dernier, c'est pile ou face (0 ou 1). Pour régler ça, il faudrait utiliser une échelle logarithmique en base 2 (comme les valeurs d'exposition), mais les raw sont tous encodés linéairement jusqu'à présent.
Ensuite, j'ai menti. Le codage numérique utilise 0 à 4095 mais le capteur n'atteint jamais 0 ampère car il est alimenté par un amplificateur. La valeur minimum correspond au courant de l'ampli, qu'on appelle dark current en anglais, qui varie d'un capteur à l'autre, mais en gros on peut supposer que les valeurs codées de 0 à 255 sont perdues. Ça veut dire que même les pixels dans le noir n'atteignent jamais 0. La valeur exacte du dark current est lisible dans darktable, dans le module "point noir/blanc raw" (caché par défaut), dans les paramètres "niveau de noir", et estimée par rawspeed dans la zone noire du capteur (une portion de capteur que les rayons de l'objectif n'atteignent jamais, faite spécialement pour estimer cette valeur, image par image).
Donc il n'y a aucun moyen pour un capteur 12 bits d'encoder plus que 12 EV. Mais ça ne veut pas dire que 12 bits encode forcément 12 EV. C'est juste le maximum théorique.
darktable manipule les codes raw pour que le dark current soit redirigé vers 0 (c'est l'objectif du point noir/blanc raw). Donc au niveau de filmic, on a perdu la connexion avec la plage dynamique initiale, d'autant que le logarithme de 0 n'est pas défini.
C'est pour ça que ça ne sert à rien de vouloir faire des préréglages pour filmique en fonction de la plage dynamique précise. Arrêtez de vous prendre la tête avec des nombres que vous ne comprenez pas, allez y à l'œil, ça marchera mieux et ça suscitera moins d'incompréhensions.
Messages : 99
Sujets : 2
Inscription : Sep 2016
Réputation :
4
Bonjour,
@Cobert, " je n'ai pas compris le PDR (définition?) et pour moi la dynamique donnée par DXO en EV me semble pas mal". PDR n'est pas une unité de mesure mais en anglais à peu près la même chose que "dynamique". Les graphiques de Dxo et Photons représentent la même chose, dans les mêmes unités. Les résultats sont différents parce que si on sait en théorie ce que l'on mesure en pratique c'est beaucoup moins évident, voir @manu. D'ailleurs le nom donné à l'unité sur l'axe vertical est sans importance, ce qui compte c'est que la chose mesurée est située sur une échelle de puissances de 2, @JaCo l'explique en détail. Si ça te convient mieux tu peux compter en nombre de diaphragmes.
"Par contre j'ai un problème avec la correspondance IL et nombre de bits." Dans l'exemple de ton APN tu ne tiens compte que de la valeur maximale, disons le blanc, mais pas de la valeur minimale, le noir, que ton APN est capable de distinguer. Or qui dit plage dit différence, au sens intuitif du terme. Tu as raison de dire "pas forcément de rapport quantité de lumière et le pas de quantification en nombre de bits" car tu penses quantité de lumière dans l'absolu. Mais il s'agit ici de différence ; c'est bien la quantification de cette différence qui nous intéresse et même si le matériel était parfait on ne pourrait distinguer plus de pas que ce que permet le nombre de bits de codage. En fait l'utilisation des EV comme unité est trompeuse. Pour les calculs, et donc pour le module filmique, l'important est de se placer dans une échelle de puissances de 2. Je pense que c'est pour ça que Photons a marqué seulement log2 sur un des graphes, celui qui est calculé à partir des données de DXO. Il est précisé qu'il vaut mieux utiliser celui qui est mesuré, en pratique peu différent.
Il est probable que Photons et DXO ne représentent pas exactement la même chose, mais il n'y a pas de contradiction dans les résultats puisque les données calculées par Photons à partir des données DXO collent bien aux données mesurées. Personnellement je crois que pour ce qui nous occupe le résultat Photons est plus utilisable.
Pour ceux qui lisent l'anglais le site CambridgeInColours, déjà cité je crois par quelqu'un, a une excellente page sur Dynamic Range in digital photography.
Note mathématique : c'est bien parce qu'on prend des log qu'une quantité qui est au départ un rapport s'exprime en différence, ce qui est plus intuitif.
Messages : 1,124
Sujets : 51
Inscription : Jun 2016
Réputation :
15
Système d'exploitation:
Distribution(s) Linux: Ubuntu 22.04
(28-04-20, 19:04)chloma a écrit : Pour ceux qui lisent l'anglais le site CambridgeInColours, déjà cité je crois par quelqu'un, a une excellente page sur Dynamic Range in digital photography.
https://www.cambridgeincolour.com/tutori...-range.htm
Merci @chloma... et @aurelienpierre
dt stable / Ubuntu 22.04
Messages : 459
Sujets : 23
Inscription : Feb 2020
Réputation :
8
Système d'exploitation:
Distribution(s) Linux: Kubuntu 24.04
Merci pour vos réponses, Aurelien chloma jacotux
Ayant un peu fait du traitement de signal je raisonne sans doute différemment, une dynamique en db où une fonction de transfert me parlerait sans doute un peu plus.
Ce que je ne comprends pas dans la réponse d'aurelien c'est qu'on considère à priori que doubler la valeur numerique correspond à + 1 IL.
Pour moi tout dépends comment on a quantifier le signal, à quantité constante de lumière, sur 8,10,12 bits c'est pas la même chose.
https://forum.lesnumeriques.com/t/dynami...dage/33801
Sinon mon point blanc est à 16300 qui serait plutot du 14 bits.
Je ne vais pas me prendre le choux avec ça.
Je vais continuer à m'éclater avec DT, mais manque de photo, confinement oblige.
Cordialement
Messages : 1,190
Sujets : 47
Inscription : Mar 2016
Réputation :
71
Système d'exploitation:
Distribution(s) Linux: Fedora 29
29-04-20, 02:15
(Modification du message : 29-04-20, 02:18 par aurelienpierre.)
Doubler la valeur, c'est la définition même de l'IL. D'un stop ou d'un IL à un autre, on retrouve le même incrément perceptuel, mais on double le nombre de photons, c'est la loi de
Weber-Fechner : https://fr.wikipedia.org/wiki/Loi_de_Weber-Fechner. C'est un log en base 2.
Quand tu sépares ta plage dynamique d'IL en IL, tu te retrouves avec une échelle qui correspond au zone system d'Ansel Adams. Si tu commences à encoder linéairement à partir du seuil de saturation (4095 en 12 bits - 100% - "blanc", tout ça c'est la même notion), et que tu déroules IL après IL vers le bas, tu vas te rendre compte qu'à la douzième zone, en 12 bits, tu est arrivé à 0 (c'est que que j'ai montré en haut).
Le lien vers le forum lesnumeriques, c'est la fête du slip.
La quantification ne change pas la réponse au pic du luminance, mais la finesse du pas de quantification, ce qui est crucial dans les basses lumières, parce que les valeurs de luminosité sont de l'ordre de l'erreur de quantification. Donc ton capteur peut capturer 24 EV de lumière tant qu'il veut, si c'est codé sur 12 bits, les zones -12 à -24 EV seront toutes codées entre 0 et 1, donc tu verras pas la différence.
Messages : 666
Sujets : 31
Inscription : Dec 2017
Réputation :
17
Système d'exploitation:
Distribution(s) Linux: Manjaro XFCE
Une idée avec les moyens du bord, vous voulez vraiment avoir un ordre de grandeur de ce qu'a votre APN dans le ventre, prenez vous par la main... pas besoin d'être matheux.
L'objectif, connaître l'écart en IL entre le noir et le blanc complets, les pixels à RVB = 0,0,0 et RVB = 255,255,255
- Prendre un panneau blanc éclairé de façon uniforme.
- APN sur pied, ce sera plus simple, équipé d’un objectif qui vignette le moins possible et reconnu dans lensfun
- En mode manuel of course
- Se mettre en ISO à la valeur native du capteur et une ouverture de diaph fixe
- Parcourez la plage de vitesse en partant de la plus rapide.
- Puis shootez par palier de 1 IL en divisant la vitesse d'un facteur de 2 entre chaque vue. 1/4000, 1/2000, 1/1000, 1/500, etc...
Enfin analysez vos vues dans dt, sans rien corriger si ce n'est la correction objectif
Pour le blanc on peut se donner comme limite dès qu'un canal est cramé avec le bouton d'alerte de surexposition raw
Pour le noir l'alerte de sur/sous exposition fera l'affaire avec un seuil bas à 0, voire avec la pipette en mode point et RVB
Et arrêtez de vous prendre la tête avec la fiche technique de vos APN, on savait faire de belles photos il y a quelques années avec des capteurs bien moins performants.
|