[Jean-Christophe]

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

Voir la licence pour TkPDC

Télécharger l'application TkPDC pour Windows

Télécharger l'application TkPDC pour Linux

[Jean-Christophe]

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.

[Jean-Christophe]

Autre demande ... si l'un d'entre vous sait compiler pour iPhone, nous sommes aussi preneurs

[Heywood Floyd]

... et n'hésitez pas à nous faire un retour sur ce que vous en pensez.

[ldn83]

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 

[Heywood Floyd]

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.

[tigerwoods]

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...

[Heywood Floyd]

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

[tigerwoods]

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 

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...

[Heywood Floyd]

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.

[tigerwoods]

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...

[Heywood Floyd]

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 ?

[Heywood Floyd]

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.

[Heywood Floyd]

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
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.

[tigerwoods]

suite par MP...