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

[jweizineau]

je la comprend pas trop celle la on dit que sur un appareille il y a 15 MP ...mais que seulement 14,1 sont effectif, a quoi sert les 0,9 autre alors??

[olivier_aubel]

15 millions de PHOTOSITES.
et 14,1 millions de PIXELS
nuance...

L'ecart, c'est les phosites des bords du capteur qui ne sont exploités qu'en partie au moment du dématriçage.

[Caton]

A la périphérie du capteur, il y a une zone "cachée" qui sert de référence de noir.
Ces pixels existent, mais ne sont pas utilisés pour former l'image.

[louparou]

élémentaire c'est pour te faire kaguer.
c'est un défaut de réglage du boitier retour au sav ou bien te faire rembourser les 0,9  manquant.
le mien faisait 15,6  j'ai ralé et le sav me la rendu et maintenant il fait 14,9  si bien que je fais de mauvaises photos !!!
j'envisage d'acheter un 0,1 pour faire 15 mais ou vais-je le mettre

[PLG]

Ca existe des apn avec 15 megapixels ?
Je connaissais les 10,12,14,16,18 mais 15 ?

[Verso92]

A la périphérie du capteur, il y a une zone "cachée" qui sert de référence de noir.
Ces pixels existent, mais ne sont pas utilisés pour former l'image.

Oui.

[seba]

De noir ou pour le dématriçage ?
Car pour le dématriçage, le calcul se fait avec les pixels tout autour du pixel à calculer (parfois un nombre assez important), mais au bord du capteur il n'y a pas de pixels tout autour.

[jweizineau]

A la périphérie du capteur, il y a une zone "cachée" qui sert de référence de noir.
Ces pixels existent, mais ne sont pas utilisés pour former l'image.

qui sert de référence de noir...mais ne sont pas utilisé pour former l'image ,je comprend pas ,qu'est ce que tu veut dire par la?

[kaylo]

Ca existe des apn avec 15 megapixels ?
Je connaissais les 10,12,14,16,18 mais 15 ?

50D et 500D

[Verso92]

qui sert de référence de noir...mais ne sont pas utilisé pour former l'image ,je comprend pas ,qu'est ce que tu veut dire par la?

Ces pixels, qui sont à la périphérie de l'image et qui ne sont pas utilisés pour la former (hors cadre), servent au boitier pour s'étalonner, en quelque sorte...

[seba]

Je me demande si ça ne vient pas plutôt du dématriçage.
Car les logiciels ne peuvent pas calculer les pixels des bords de l'image (par manque de pixels autour).
Par exemple on peu lire ça.

[seba]

Ou ça...un peu la même chose partout.

[Verso92]

Je me demande si ça ne vient pas plutôt du dématriçage.

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

[chelmimage]

J'ai lu que les images jpg étaient crées en partant de blocs de 16 pixels (je croyais que c'était , il est probablement intéressant d'éliminer la première rangée de 16 pixels

[vernhet]

le stab?

[Lyr]

J'ai lu que les images jpg étaient crées en partant de blocs de 16 pixels (je croyais que c'était , il est probablement intéressant d'éliminer la première rangée de 16 pixels

Blocs de 8x8.

Le choix vient du graph gain en compression vs. largeur du bloc, on voit que ça monte vite jusqu'à 8, puis ça augmente encore par la suite, mais moins vite, donc la norme JPG a été établie à des blocs de 8 de côté.
Par contre, le jpg n'a pas besoin de retirer des trucs au bord, tu prends n'importe quelle image, tu peux la convertir en jpg, c'est simplement un algorithme de compression exploitant la redondance à courte distance sur une image ainsi qu'un filtrage (si moins que 100%) des fréquences spatiales.

[Lyr]

Je me demande si ça ne vient pas plutôt du dématriçage.
Car les logiciels ne peuvent pas calculer les pixels des bords de l'image (par manque de pixels autour).
Par exemple on peu lire ça.

C'est possible, mais c'est quand même des feignasses. La plupart des algorithmes de traitement d'image ont un soucis avec les bords, donc soit tu adaptes ton algo pour changer la formule à appliquer quand tu arrives aux bords, soit tu inscris ton image dans une matrice plus grande de la largeur nécessaire, avec des 0 autours, par exemple, ce qui reviendrait comme ici à un senseur masqué sur le bord.

Sauf si ça leur permet de faire un dark à chaque photo, auquel cas oui, on a besoin d'avoir des pixels actifs mais non éclairés.

[jweizineau]

ahh (I) d'accord...maitenant je comprend mieux...merci de vos réponse

[astrophoto]

Ces pixels, qui sont à la périphérie de l'image et qui ne sont pas utilisés pour la former (hors cadre), servent au boitier pour s'étalonner, en quelque sorte...

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.

Quand le marketing dit que le capteur fait 15 Mpixels (enfin, il faudrait plutôt dire : photosites) alors que ceux qui sont visibles par l'utilisateur ne sont que 14, c'est le même tour de passe-passe que pour les écrans CRT : quand un écran était vendu pour 17 pouces, en fait c'était la taille du tube cathodique, mais la partie visible de l'image ne faisait que 15 pouces. Du coup, quand les écrans LCD sont apparus, ils ont été pris à leur propre piège car il a fallu qu'ils nous expliquent qu'un LCD de 15 pouces était en fait équivalent à un cathodique de 17 pouces. Il y a aussi les tailles de capteurs : un capteur 1/2 pouce ne fait pas du tout 1/2 pouce (12,7 mm) de diagonale mais plutôt dans les 8 mm (là aussi, c'est une sombre histoire de taille de tube, du temps des caméras vidéo analogiques). Quand le marketing s'empare des mathématiques, on dirait que ce n'est plus une science exacte   

Pour revenir à nos moutons, il faut quand même bien distinguer photosite et pixel.
Le photosite, c'est l'élément de base du capteur, une "cellule" individuelle qui recueille la lumière. Sur tous les capteurs couleur (sauf le Foveon), chaque photosite est recouvert d'un filtre rouge, vert ou bleu, en damier (c'est la matrice de Bayer).
Pixel, c'est la contraction de Picture Element, c'est l'élément de base d'une image. En général un pixel contient 3 infos : une bleue, une verte et une rouge.
Un capteur ne connaît que des photosites. Le pixel est une notion qui n'existe pas au niveau du capteur, ça n'existe que quand on a dématricé l'info brute sortant du capteur.

Prenons un capteur classique de 8 millions de photosites : dans son fichier raw, il délivre 8 millions d'informations élémentaires (4 millions de vertes, 2 millions de rouges et 2 millions de bleues). De ça, le dématriçage va en tirer 8 millions de pixels, soit 24 millions d'infos élémentaires (8 millions de chaque couleur). Les informations se sont multipliées comme des petits pains, par le miracle des interpolations. Là encore, on peut considérer que l'amalgame entre pixel et photosites est un joli tour de passe-passe. Et ça complique bien la vie des promoteurs du Foveon, capteur qui recueille les 3 infos RVB sur un même photosite (en couches successives), sans aucun filtre coloré : du coup, ils sont obligés d'expliquer qu'un Foveon de 15 millions de photosites recueille en fait 45 millions d'infos élémentaires, ce qui est vrai, donc qu'il est équivalent à un capteur Bayer de 45 "Mpixels", ce qui n'est pas faux dans la logique des autres constructeurs.

[Verso92]

Et ça complique bien la vie des promoteurs du Foveon, capteur qui recueille les 3 infos RVB sur un même photosite (en couches successives), sans aucun filtre coloré : du coup, ils sont obligés d'expliquer qu'un Foveon de 15 millions de photosites recueille en fait 45 millions d'infos élémentaires, ce qui est vrai, donc qu'il est équivalent à un capteur Bayer de 45 "Mpixels", ce qui n'est pas faux dans la logique des autres constructeurs.

Heu... attention à ne pas faire de raccourcis trop rapides.

C'est vrai en chrominance, mais pas en luminance !

[seba]

Prenons un capteur classique de 8 millions de photosites : dans son fichier raw, il délivre 8 millions d'informations élémentaires (4 millions de vertes, 2 millions de rouges et 2 millions de bleues). De ça, le dématriçage va en tirer 8 millions de pixels,...

Justement, c'est ça qui n'est pas si évident.
Pour dématricer, les algorithmes ont besoin d'un certain nombres de photosites tout autour du pixel à calculer. Et au bord du capteur il n'y a pas de photosites tout autour.
C'est d'ailleurs clairement explicité dans un certain nombre de documents sur le dématriçage (voir ci-dessous).

Et vernhet a fait une remarque intéressante : pour les capteurs stabilisés, comment ça se passe ?

[astrophoto]

Justement, c'est ça qui n'est pas si évident.
Pour dématricer, les algorithmes ont besoin d'un certain nombres de photosites tout autour du pixel à calculer. Et au bord du capteur il n'y a pas de photosites tout autour.

oui, mais de toute façon l'existence de photosites masqués en bordure de la zone sensible ne résoud en rien le problème : le logiciel peut tout aussi bien rajouter des pixels en bordure d'image lui-même s'il en a besoin.

[astrophoto]

Heu... attention à ne pas faire de raccourcis trop rapides.

C'est vrai en chrominance, mais pas en luminance !

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 ?   

[seba]

oui, mais de toute façon l'existence de photosites masqués en bordure de la zone sensible ne résoud en rien le problème : le logiciel peut tout aussi bien rajouter des pixels en bordure d'image lui-même s'il en a besoin.

Rajouter des pixels...mais lesquels ?
Il faut quand même calculer quelque chose de correct.

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