15 mégapixel.... mais seulement 14,1 effectif

[Verso92]

peu importe comment on triture les données de départ : on part de 8 et on arrive à 24, c'est aussi simple que ça. Quels que soient les algos de dématriçage, il n'y a aucune magie dedans, la génération spontanée des informations n'existe pas plus que celles des souris dans les tas de linge sale. Non ?   

Sauf que sur un Bayer, il n'y a aucune interpolation en luminance (l'information essentielle d'une image en terme de définition, faut-il le rappeler)...

[seba]

oui, et ils sont masqués de la lumière (référence de noir). Si c'était un problème de taille d'image par rapport à un algo de traitement qui veut un multiple de N ou qui a des soucis de bordures, le soft pourrait toujours rajouter des pixels autour de l'image de base, pas besoin de photosites masqués sur le capteur pour ça.

D'ailleurs par quoi seraient-ils masqués de la lumière ?
Ici on voit un capteur, il est comme ça dans l'appareil, aucune fenêtre matérielle ne masquait les bords.
Ensuite je vois mal comment, sur mon D200, un élément matériel pourrait masquer le nombre de photosites nécessaires pour n'en démasquer exactement que 10 036 224.

[astrophoto]

Sauf que sur un Bayer, il n'y a aucune interpolation en luminance (l'information essentielle d'une image en terme de définition, faut-il le rappeler)...

cette affirmation me trouble...si on prend en photo un objet à dominante verte (ou bleue ou rouge, peu importe), comment la luminance peut-elle bien être fabriquée sur la zone en question sans interpolations, à partir des informations calquées sur la matrice de Bayer (donc, en l'occurrence, pleine de trous là où se trouvent les photosites des couleurs absentes) ?  

[Verso92]

cette affirmation me trouble...si on prend en photo un objet à dominante verte (ou bleue ou rouge, peu importe), comment la luminance peut-elle bien être fabriquée sur la zone en question sans interpolations, à partir des informations calquées sur la matrice de Bayer (donc, en l'occurrence, pleine de trous là où se trouvent les photosites des couleurs absentes) ?  

Je ne suis pas un spécialiste... mais quand je vois le massacre effectué par les algorithmes de compression Jpeg sur l'information de chrominance et le résultat final, sans pratiquement aucune incidence sur la netteté (tant qu'on reste dans des taux faibles), je reste dubitatif...

[astrophoto]

D'ailleurs par quoi seraient-ils masqués de la lumière ?
Ici on voit un capteur, il est comme ça dans l'appareil, aucune fenêtre matérielle ne masquait les bords.
Ensuite je vois mal comment, sur mon D200, un élément matériel pourrait masquer le nombre de photosites nécessaires pour n'en démasquer exactement que 10 036 224.

il sont masqués par un cache métallique déposé à la fabrication même du capteur, ça en fait partie intégrante, ce n'est pas un élément rajouté ensuite. La largeur du masque est en général de quelques dizaines de photosites, donc c'est mince par rapport à la taille totale du capteur. Par exemple, le 5DII est annoncé pour 5616x3744 photosites utiles (soit 21 Mp), et pour 22 Mp au total. Ce 1 Mp de photosites masqués représente une bordure d'environ une cinquantaine de photosites sur le pourtour (en supposant que la largeur de cette bordure est identique sur les 4 côtés), soit 0,3 mm  : c'est vraiment très mince par rapport à la taille du capteur (24x36), environ 1%  

[astrophoto]

Précision : je viens de me souvenir que les infos de dimensions sont dispo dans les fichiers raw et je viens de regarder, pour le 5DII c'est 5616x3744 photosites exposés à la lumière et 5792x3804 au total : 176 de plus sur la largeur et 60 de plus sur la hauteur, soit 1,1 mm de bordure totale masquée en largeur et 0,4 mm en hauteur.

 

[seba]

L'un n'exclut pas forcément l'autre...

D'après C. Tauleigne, un certain nombre de photosites sont masqués et un certain nombre, démasqués, ne servent que pour les calculs.
Verso92 semblait donc bien avoir raison.

[astrophoto]

D'après C. Tauleigne, un certain nombre de photosites sont masqués et un certain nombre, démasqués, ne servent que pour les calculs.

oui, c'est bien pour les calculs de référence de noir, comme indiqué : ça donne à quel niveau est le "zéro" sur chaque ligne et/ou colonne. Le logiciel de dématriçage doit prendre ça en compte pour soustraire la valeur qui va bien, avant les calculs suivants (interpolations, balances de couleurs etc.). Mais encore une fois, c'est indépendant de la problématique des bordures pour les interpolations par exemple : là de toute façon, présence de photosites masqués ou non, l'info lumineuse "extérieure" n'existe pas et le logiciel doit se débrouiller pour fabriquer des bords qui ne sont pas aberrants.

[jweizineau]

est-ce pour cela que lorsque j'imprime une photo il manque toujours une partie de la photo?

[seba]

est-ce pour cela que lorsque j'imprime une photo il manque toujours une partie de la photo?

Euh non, là la raison est ailleurs.

[Verso92]

est-ce pour cela que lorsque j'imprime une photo il manque toujours une partie de la photo?

Heu... comment te débrouilles-tu donc ?

[olivier_aubel]

est-ce pour cela que lorsque j'imprime une photo il manque toujours une partie de la photo?

ça , la raison est ailleurs.
Sur imprimante, si on demande un eimpression sans marge, il y a toujours un peu de bordure qui est bouffée.
Si , en plus, l'image n'est pas homothetique au format du papier, il y a forcemment encore 2 cotés qui sont bouffés...
Avec un tirage en labo, ça te bouffe aussi toujours une marge. (c'etait pire en argentique  ).