Nikon Passion : Communauté Photo
Apprendre la photo - pratiquer => Apprendre la photo : quel appareil photo choisir ? => Discussion démarrée par: Jean-Christophe le 25 Mai, 2010, 21:38:16 pm
-
TkPDC est une application (codée en Tcl/Tk pour les curieux) destinée à tout photographe qui souhaite visualiser facilement :
- la distance hyperfocale
- la profondeur de champ
autorisées par les ouvertures du diaphragme et les focales de son choix. En outre TkPDC permet de calculer les diamètres de cercles de confusion correspondant à tout format de film/capteur, tout format de tirage photo, en tenant compte de la distance à laquelle la photo est regardée.
TkPDC est surtout une application entièrement développée par l'un de nos modos, Heywood Floyd, qui met ainsi à disposition le fruit de son travail (comme quoi les modos ne sont pas que des méchants ;)).
On rappelle que la PDC ou Profondeur De Champ dépend de 4 facteurs :
- la focale
- l'ouverture du diaphragme
- la distance de mise au point
- le diamètre des cercles de confusion.
L'interface permet à l'utilisateur de jouer sur la distance de mise au point pour voir l'évolution des courbes de PDC, un peu comme le permettent les échelles de PDC sur le fût des objectifs, ou les courbes de PDC portées par certains zooms à pompe.
Les copies d'écran ci-dessous vous donneront un aperçu de l'interface de l'application disponible dans sa première deuxième version pour Windows et Linux. Nous cherchons d'ailleurs des volontaires capables de compiler les sources pour Mac, iPhone, Blackberry et autres Androïd !! (qu'on se le dise !!).
*****************************************************************************************
ATTENTION IMPORTANT !!! Lorsqu'on installe une nouvelle version il faut effacer le fichier TkPDC.sav qui existait déjà si on utilisait une version précédente de TkPDC. Sinon l'application pourrait ne pas fonctionner correctement.
NOUVEAUTES V1.1
CORRECTIONS DE BUGS :
- l'export d'image en gif fonctionne désormais en plus du jpg.
- sous Linux, lors d'un export sous forme d'image, l'appli n'ajoutait pas l'extension au nom de fichier. Pb résolu. Solution compatible Windows (sur ce système le bug était absent).
NOUVELLES FONCTIONNALITES :
- documentation en anglais
BUG CONNU PERSISTANT DANS LA V1.1 :
- sous Linux, si on exporte une courbe sous forme d'une image jpg après avoir exporté en gif dans la même session, alors le jpg créé est vide. Il faut fermer puis relancer TkPDC pour que l'export jpg fonctionne à nouveau.
*****************************************************************************************
Un grand merci à penpen sans qui la version Linux ne serait pas disponible aujourd'hui !
Toutes vos remarques sont les bienvenues pour faire évoluer l'application, à vous et félicitation à HF pour le boulot :)
Voir la documentation de TkPDC + généralités sur la profondeur de champ (http://www.nikonpassion.com/wp-content/uploads/tkpdc/TkPDC_doc.xml)
Voir la licence pour TkPDC (http://www.nikonpassion.com/wp-content/uploads/tkpdc/TkPDC_licence.txt)
Télécharger l'application TkPDC pour Windows (http://www.nikonpassion.com/wp-content/uploads/tkpdc/TkPDC_V1.1.exe)
Télécharger l'application TkPDC pour Linux (http://www.nikonpassion.com/wp-content/uploads/tkpdc/TkPDC_v1.1.linux_bin.zip)
-
Mise en ligne (enfin !!) de l'application TkPDC ce soir, un grand bravo à Heywood :)
Nous sommes à la recherche de quelqu'un capable de compiler les sources pour Mac et pour Linux.
-
Autre demande ... si l'un d'entre vous sait compiler pour iPhone, nous sommes aussi preneurs :)
-
... et n'hésitez pas à nous faire un retour sur ce que vous en pensez. ;)
-
Super l'application, je viens juste de la télécharger ;)
Très parlant les visuels en tout cas... une très bonne idée 8)
ps : un grand merci à Heywood Floyd pour ce petit soft ;)
-
Merci ldn83. N'hésite pas à nous remonter tes impressions et d'éventuels bugs que tu remarquerais. L'appli a fait l'objet d'une validation en version beta mais on n'est jamais à l'abri. ;)
-
Je lis dans la doc "Par exemple, le Nikon D3 est doté d'un capteur 24x36mm fournissant des images de 4256x2832 pixels (soit 12.05 Mpixels effectifs environ, de 8.45µm de côté)."
Ne serait ce pas confondre deux notions biens distinctes : pixels et photosites ? la notion de taille réelle d'un pixel n'a aucune signification physique, sur un capteur il n'y a que des photosites. Dans un capteur organisé en matrice de Bayer comme le D3, 4 photosites sont requis pour obtenir chaque pixel avec réemploi de 2 de ces photosites pour le pixel voisin, soit au final deux fois plus de photosites que de pixels. On ne peut en aucune manière attribuer une "surface" de (8.45µm)² à un pixel...
-
Tigerwoods, je parle bien de pixels effectifs, que l'on voit dans l'image finale. Je ne parle pas de photosites. Si on rapporte les dimensions du capteur au nombre de pixels effectifs, alors on aboutit à un pixel de 8.45 microns de côté. Il ne s'agit pas d'un photosite mais bien d'un pixel effectif.
Sur le capteur un pixel effectif n'a effectivement pas de réalité physique puisque dans la matrice de Bayer plusieurs photosites contribuent à un pixel effectif. Mais sur la photo finale que l'on regarde, un pixel effectif a bien une réalité physique (c'est un carré de couleur uniforme) ! C'est donc cette réalité qui doit être considérée pour estimer la limite inférieure du diamètre des cercles de confusion.
A la limite, peu importe ce qui se passe un niveau des photosites puisque le DCC est influencé uniquement par le tirage de la photo et les conditions d'observation. Comme je le dis au début de ce paragraphe : le DCC ne dépend fondamentalement pas de la taille des photosites (et donc pas de la résolution du capteur). Il ne dépend que de la capacité de l'oeil à discerner des détails sur le tirage de la photo à une certaine distance, ce paramètre étant rapporté aux dimensions du capteur.
Cette discussion porte sur le § Cercle de confusion et résolution du support (http://www.nikonpassion.com/wp-content/uploads/tkpdc/TkPDC_doc.xml#t2_7.)
-
je suis tout à fait d'accord sur le fait que le pixel soit une réalité sur l'image. encore heureux. Mais désolé, par souci de rigueur, on ne peut absolument pas attribuer une dimension à un pixel sur surface d'un capteur. Sinon, montre moi une photo d'un pixel ;D
Diviser la surface d'un capteur par le nbre de pixels a le même intérêt que diviser la taille d'un choux par le nombre de carottes.
enfin, j'dis çà, j'dis rien. C'est par souci de rigueur. La physique, ca aime raisonner avec des "dimensions" qui ont un sens...
-
Pour faire de la physique il faut parfois passer par l'abstraction mathématique. Ici c'est le cas. Quand on fait le raccourci "la focale en DX est équivalente à 1.5 fois la focale en FX", c'est aussi de l'abstraction mathématique ; ça n'a pas de réalité physique. ;)
-
bien d'accord avec toi. je souhaitais simplement suggérer une amélioration à ta document de référence, par ailleurs fort bien faite. Le fond de l'affaire est bien que la notion de pdc dépend d'hypothèses faites sur l'observations d'images, sur supports de type écran ou papier. Et que la "taille d'un pixel" n'a non seulement rien à voir avec ces calculs, mais pas de signification du tout.
Un autre sujet, à mon humble avis bien plus profond que le raccourci que tu as adopté, est l'étude des phénomènes physiques intervenant en limite basse des CoC... Mais c'est un tout autre sujet, du niveau d'une thèse...
-
Si tu veux, le DCC lui-même n'est qu'une abstraction mathématique, un raccourci qui permet d'appréhender facilement, avec une précision et une robustesse suffisantes dans la vie quotidienne, une réalité physique bien plus complexe.
Sa réalité physique n'est liée qu'au tirage photo, mais il se trouve que par convention on exprime cette dimension en mm et on la rapporte (rigoureusement il s'agit bien d'une opération mathématique, et c'est bien aussi le terme que j'utilise dans la doc) aux dimensions du capteur.
Donc, revenons à nos moutons ;) : comment suggères-tu que je le formule ?
-
Et que la "taille d'un pixel" n'a non seulement rien à voir avec ces calculs, mais pas de signification du tout.
Là je ne suis pas d'accord. C'est précisément la taille d'un photosite qui n'a rien à voir avec le DCC. Même si le photosite avait "davantage" de réalité physique qu'un pixel.
Le pixel ici a une réalité physique liée au tirage photo. Il se trouve que par convention il faut rapporter ses dimensions à celles du capteur.
-
Diviser la surface d'un capteur par le nbre de pixels a le même intérêt que diviser la taille d'un choux par le nombre de carottes.
Là non plus je ne suis pas d'accord :D
Il y a un gouffre conceptuel entre les deux démarches.
Ma démarche est strictement équivalente à dire, par exemple lors d'une randonnée en regardant une carte, qu'on a encore 2cm à parcourir avant de s'arrêter pour la nuit. Ces 2cm n'ont pas de réalité physique du point de vue de la marche à pied, mais c'est une abstraction qui permet de se repérer sur la carte.
Ici rapporter le DCC aux dimensions du capteur est nécessaire pour pouvoir s'abstraire des conditions d'observation et des dimensions du tirage photo, et comparer deux capteurs entre eux : toutes choses étant égales par ailleurs, un capteur APS-C offre un DCC 1.5 fois plus petit qu'un capteur 24x36. Et ça n'a rien à voir avec la taille des photosites !!
Si on ne rapportait pas la taille d'un pixel de l'image finale aux dimensions du capteur on ne pourrait pas comparer deux capteurs indépendamment des conditions d'observation et de la taille de l'image finale.
Autre analogie prise au hasard : la performance d'un ergol utilisé pour les moteurs fusée est donnée par la mesure de l'impulsion spécifique, exprimée en secondes. Cette mesure en secondes n'a pas directement de sens physique, mais elle permet de comparer deux lanceurs spatiaux entre eux indépendamment de leur masse et de la nature chimique de leurs ergols.
-
suite par MP... :)
-
Félicitation et merci Heywood Floyd ! Je vais tester ça :)
-
Pour la compilation linux, je peux essayer de regarder, mais... les sources sont où ?
-
penpen, la suite par MP ;)
-
Adopté !
Merci ;)
Si quelqu'un sait compiler pour Blackberry, je suis preneur ::)
-
Testé et adopté
Merci
-
Félicitation pour ce petit soft bien utile....à défaut de l'avoir sous android je vais me faire un petit memo avec quelques données prédéfinies
j'ai pas encore tout compris mais je m'entraine ;D
-
Mise à jour de l'application TkPDC en version 1.1. Les nouveautés sont mentionnées dans le premier message :)
-
Un grand merci à penpen sans qui la version Linux n'existerait pas ! ;)
-
Félicitation Heywood Floyd et bravo ;)
A quand la version Mac ? ;D
-
A quand la version Mac ? ;D
... quand on aura trouvé une âme charitable pour compiler le soft sur Mac ! ;D
-
:)
-
J'ai des demandes pour une version iPhone ...
-
Hélas, je ne crois pas que le langage Tcl/Tk soit supporté sur iphone pour le moment. =|
-
Un Grand Merci à Heywood Floyd
Super et attrayante application que je viens de télécharger.
Par exemple je suis complètement nul en développement de logiciel informatique :-X.
Par contre je suis équipé depui pas mal d'année d'un PALM TX et j'ai pu télécharger un logiciel pour le calcul de la profondeur de champ, certes il est nettement moins génial que celui de Heywood Floyd et pas aussi évolutif.
Mais il dépanne quand même bien quand on est sur le terrain ;C.
http://www.dofmaster.com/ (http://www.dofmaster.com/)
Ce lien pour ceux que cela peut intéresser.
Passionnement à tous
Centaure
Site qui propose sa DOF(Depth Of Field) Pour Windows, pour palm OS, pour Iphone.
-
En m'intéressant au calcul de la profondeur de champs, j'ai découvert que apple et android ont développé des applications, c'est nickel !
-
Très pratique, merci !
-
Mise en ligne (enfin !!) de l'application TkPDC ce soir, un grand bravo à Heywood :)
Nous sommes à la recherche de quelqu'un capable de compiler les sources pour Mac et pour Linux.
Est-ce toujours d'actualité?
-
salut Valken. oui pourquoi pas. je t'envoie un mp un petit peu plus tard. Merci !
-
Nous sommes à la recherche de quelqu'un capable de compiler les sources pour Mac et pour Linux.
Je viens tout juste d'installer TkPDC V1.1 sur linux (Xubuntu 12.10), ça roule sans problème, apparemment (essai très court pour l'instant).
Plutôt que vous remerciez par blahblahblah et, dans la mesure où l'appli me semble être en Perl/Tk, je me propose comme candidat pour compiler les sources sur Mac OS X Mointain Lion (dernère release).
Pour linux, il me semble que vous avez trouvé quelqu'un, mais bon, si besoi, quand j'aurai compilé la V1.1 sur Mac, pourquoi pas quand vous changerez de version.
-
je programme un peu sur iOS et mac os X
je peut toujours essaye de compiler une application.
mais il me faut les detail technique sur celle ci
cela m'arrangerais car je suis plus sur mac au lieu de l'avoir par une VM windows
-
Très intéressant ! Qui va en faire une version android et iOS à emporter avec soi ?