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

[musiclive]

c'est comme les cyclos 50cm3 en réalité ils ne font que 49,9

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