[Long] Pixels et DPI pour les débutants/Micro Pratique
36 réponses
Papy Bernard
Slt,
Michel Archambault sa fait sa pub sur le fourum pour l'article qu'il signe
dans Micro Pratique. Après tout pourquoi pas.
Introduction de l'article :
"Les caractéristiques principales d'un appareil photo numérique, d'une
imprimante ou d'un scanner s'expriment en pixels ou, selon le cas, en dpi.
Ces unités nouvelles concernent l'image numérique et il est devenu
*indispensable de bien les maîtriser*, non seulement lors d'achat de
matérielmais aussi dans son utilisation rationnelle pour imprimer ou pour
expédier une photo par Internet."
Mais voilà, quand on se produit, il vaut mieux savoir de quoi on parle.
Exemple (première phrase) :
"Le pixel est le plus petit élément constituant une image."
Jusque là, d'accord. et le pixel devient une unité de mesure.
"II a une dimension "physique" et une teinte uniforme."
Ben, non.
Un pixel n'a pas de dimension physique. C'est une unité logique virtuelle.
Si le pixel avait une dimension physique, (référence aux systèmes
CGS -centimètre, gramme, seconde-, MKS -mètre, kilogramme,seconde), il ne
serait pas "élastique" comme on peut le faire varier dans son affichage
selon la configuration d'écran que chacun adapte à son confort et/ou les
possibilités de l'écran et de la carte d'écran.
Bon. On continue. Phrase suivante :
"Sur un écran, (le pixel) c'est un triplet de trois minuscules rectangles
lumineux rouge, vert et bleu. Sur un capteur d'APN, c'est un carré
microscopique regroupant quatre photosites sensibles (rouge, bleu et deux
pour le vert)"
Là, on s'éloigne, que dis-je, on sombre dans le jargonage et l'abus de
langage. Une unité de mesure qui varie selon l'appareil de mesure, là je ne
comprends plus. Je n'ai jamais vu qu'une seconde était élastique ! Sauf
quand on trouve le temps long !
Un peu plus loin (toujours sur la première page):
"Pour un moniteur, la taille du pixel est "fixe" et voisine de 0,28 mm.
C'est la valeur de son "pitch". En revanche, pour un scanner, une imprimante
ou un APN, la taille du pixel est paramétrable."
Le pitch est la valeur de la taille de la maille du masque d'écran des tubes
cathodique. C'est une question de maîtrise de technologie de fabrication.
C'est du physique, de l'électronique qui conduit à des limites de qualité
d'affichage. Point/Barre. Le mieux que je connaisse à ce jour est un pitch
de .20; superbe en qualité d'affichage.
Ce n'est pas de l'informatique ni du logique. On n'y peut rien. C'est par
construction.
Alors que, par configuration (par programme), on peut sur un
même écran avoir différentes défiitions : 800x600, 1024x768, etc...
Et même en dessous, 640x480 sur le même écran. Là on est dans le domaine du
logique.
Et la taille du pixel n'est pas fixe. CQFD.
La seule chose qu'on puisse dire est que c'est la technologie des écrans qui
limite les possibilités d'affichage car il est difficile de "construire" un
pixel à moins de trois photophores RVB.
On poursuit ?
"Pour un moniteur, et quels que soient sa taille et son type d'affichage,
c'est *toujours* du 92 dpi pour un PC car 25,4 / 0,28 = 92 (ou 72 dpi sur
Macintosh).
1/ 25.4/.028 = 90.7 disons 91 et non 92.
2/ Pourquoi 92 sur un PC et 72 sur Macintosh. Z'ont pas les mêmes
calculettes chez Mac' ?
La seule affirmation qui a mon assentiment est :
"Parler de dpi pour un fichier image est un non-sens."
Michel aurait pu ajouter que cela n'a AUCUN impact sur la qualité de l'image
enregistrée.
On continue ?
"Dans les formats Tif et BMP, il faut trois octets en couleur et un en *noir
et blanc* par pixel."
Le N&B, au trait, est codé sur 1 bit,
Le 16 Couleurs est codé sur 4 bits
Le 256 couleurs (*.GIF) et le 256 Niveaux de Gris sont codés sur 8 bits (1
octet)
Le 16 millions de couleurs (RVB) est codé sur 24 bits ("octets)
"En format Tif, cela donne 2,5 Mo et, compressé en JPeg, environ 130 Ko par
photo, ce qui est raisonnable."
Si pour 1067 x 800 pixels, 2.5Mo en *.TIF est juste, 130 Ko n'a pas de sens.
Tout dépend du facteur de compression d'une part et de la complexité de
l'image d'autre part.
Alors, moi, je veux bien. Mais désolé, l'initiation/vulgarisation n'autorise
pas pour autant à raconter n'importe quoi et surtout d'abonder dans le
jargonnage.
Ce n'est pas apporter une contribution positive dans la compréhension d'un
sujet où règne la plus grande confusion, confusion largement entretenue par
les marketeux et vendeurs dont c'est l'intérêt et des journaleux qui
manquent de connaissances -y compris des formateurs-, que de produire de
tels articles.
Michel, si tu m'as lu jusque là : Cordialement.
--
A+
Papy Bernard
Chaque photosite se comporte comme une cellule photovolaïque devant laquelle on a placé un filtre.
Exact et je suis d'accord avec l'aspect électrique du problème, néanmoins il faut apporter quelques précisions sur le fonctionnement de la matrice de Bayer.
C'est le programmme, (l'informatique, le logique) qui, en transposant ces signaux électriques et en regroupant les triplets va générer les pixels R(x), B(y), V(z) va créer l'image complète avant stockage dans le fichier définitif (avec ou sans compression).
Dans le cas d'une matrice de Bayer, c'est un peu plus compliqué. La matrice comporte quatre teintes, typiquement c'est du VRVB, c'est à dire deux fois plus de capteurs verts que de rouge et de bleu et ceci pour respecter la sensibilité de l'oeil. Mais on utilise aussi des matrices CJVM (cyan, jaune, vert, magenta) et Sony pour son nouveau DSC-F828 utilise une matrice RVBE (rouge, vert, bleu, émeraude).
Chaque photosite du capteur va, à la fin de l'histoire, devenir un pixel. Puisque chaque photosite, appelé "Canal", délivre un signal unique, nous n'avons pour le futur pixel qu'une composante sur les trois nécessaires (RVB), les valeurs manquantes sont interpolées.
La démonstration que tu as faite est valable pour un tri-CCD, là c'est simple, chaque CCD donne une des composantes RVB et il suffit de combiner les signaux à la sortie. Avec la technique de la matrice de Bayer c'est beaucoup plus tordu...
Une belle explication ici : http://lcavwww.epfl.ch/~alleysso/Publication/paperGretsi.pdf
-- Jean-Claude Ghislain http://www.grimart.com
Interpolation ou regroupement d'informations ?
Malheureusement, c'est bien une interpolation.
Chaque photosite se comporte comme une cellule photovolaïque devant
laquelle on a placé un filtre.
Exact et je suis d'accord avec l'aspect électrique du problème,
néanmoins il faut apporter quelques précisions sur le fonctionnement de
la matrice de Bayer.
C'est le programmme, (l'informatique, le logique) qui, en transposant
ces signaux électriques et en regroupant les triplets va générer les
pixels R(x), B(y), V(z) va créer l'image complète avant stockage dans
le fichier définitif (avec ou sans compression).
Dans le cas d'une matrice de Bayer, c'est un peu plus compliqué. La
matrice comporte quatre teintes, typiquement c'est du VRVB, c'est à dire
deux fois plus de capteurs verts que de rouge et de bleu et ceci pour
respecter la sensibilité de l'oeil. Mais on utilise aussi des matrices
CJVM (cyan, jaune, vert, magenta) et Sony pour son nouveau DSC-F828
utilise une matrice RVBE (rouge, vert, bleu, émeraude).
Chaque photosite du capteur va, à la fin de l'histoire, devenir un
pixel. Puisque chaque photosite, appelé "Canal", délivre un signal
unique, nous n'avons pour le futur pixel qu'une composante sur les trois
nécessaires (RVB), les valeurs manquantes sont interpolées.
La démonstration que tu as faite est valable pour un tri-CCD, là c'est
simple, chaque CCD donne une des composantes RVB et il suffit de
combiner les signaux à la sortie. Avec la technique de la matrice de
Bayer c'est beaucoup plus tordu...
Une belle explication ici :
http://lcavwww.epfl.ch/~alleysso/Publication/paperGretsi.pdf
Chaque photosite se comporte comme une cellule photovolaïque devant laquelle on a placé un filtre.
Exact et je suis d'accord avec l'aspect électrique du problème, néanmoins il faut apporter quelques précisions sur le fonctionnement de la matrice de Bayer.
C'est le programmme, (l'informatique, le logique) qui, en transposant ces signaux électriques et en regroupant les triplets va générer les pixels R(x), B(y), V(z) va créer l'image complète avant stockage dans le fichier définitif (avec ou sans compression).
Dans le cas d'une matrice de Bayer, c'est un peu plus compliqué. La matrice comporte quatre teintes, typiquement c'est du VRVB, c'est à dire deux fois plus de capteurs verts que de rouge et de bleu et ceci pour respecter la sensibilité de l'oeil. Mais on utilise aussi des matrices CJVM (cyan, jaune, vert, magenta) et Sony pour son nouveau DSC-F828 utilise une matrice RVBE (rouge, vert, bleu, émeraude).
Chaque photosite du capteur va, à la fin de l'histoire, devenir un pixel. Puisque chaque photosite, appelé "Canal", délivre un signal unique, nous n'avons pour le futur pixel qu'une composante sur les trois nécessaires (RVB), les valeurs manquantes sont interpolées.
La démonstration que tu as faite est valable pour un tri-CCD, là c'est simple, chaque CCD donne une des composantes RVB et il suffit de combiner les signaux à la sortie. Avec la technique de la matrice de Bayer c'est beaucoup plus tordu...
Une belle explication ici : http://lcavwww.epfl.ch/~alleysso/Publication/paperGretsi.pdf
-- Jean-Claude Ghislain http://www.grimart.com
aglaé & sidonie
"Papy Bernard" a écrit dans le message de news: bmompv$ugo$
;===== > "Le pixel est le plus petit élément constituant une image." "II a une dimension "physique" et une teinte uniforme." ;===== > Ben, non
Ben si, enfin parfois. Quand il a une representation physique Comme sur mon ecran d'ordinateur, que j'ai acheté et qui avait, doc IBM a l'appui une resolution (ok, on dira ici "definition") de 800x600 -il est un peut vieux maintenant.
En plus, les pixels, ils ne sont pas carré. PAS CARRE, ca veux bien dire dimension "physique".
sinon, un pixel pas carre, sans dimension "physique", je vois pas.
"Papy Bernard" <lenichoir@aol.com> a écrit dans le message de news:
bmompv$ugo$1@news-reader1.wanadoo.fr...
;===== > "Le pixel est le plus petit élément constituant une image."
"II a une dimension "physique" et une teinte uniforme."
;===== >
Ben, non
Ben si, enfin parfois. Quand il a une representation physique
Comme sur mon ecran d'ordinateur, que j'ai acheté et qui avait, doc IBM a
l'appui une resolution
(ok, on dira ici "definition") de 800x600 -il est un peut vieux maintenant.
En plus, les pixels, ils ne sont pas carré. PAS CARRE, ca veux bien dire
dimension "physique".
sinon, un pixel pas carre, sans dimension "physique", je vois pas.
"Papy Bernard" a écrit dans le message de news: bmompv$ugo$
;===== > "Le pixel est le plus petit élément constituant une image." "II a une dimension "physique" et une teinte uniforme." ;===== > Ben, non
Ben si, enfin parfois. Quand il a une representation physique Comme sur mon ecran d'ordinateur, que j'ai acheté et qui avait, doc IBM a l'appui une resolution (ok, on dira ici "definition") de 800x600 -il est un peut vieux maintenant.
En plus, les pixels, ils ne sont pas carré. PAS CARRE, ca veux bien dire dimension "physique".
sinon, un pixel pas carre, sans dimension "physique", je vois pas.
Jean-Claude Ghislain
sinon, un pixel pas carre, sans dimension "physique", je vois pas.
Des pixels pas carrés c'est pas ça qui manque, de l'Amiga avec ses pixels carrément rectangulaires, à la vidéo avec ses pixels légèrement rectangulaires...
Et dans un fichier image, les pixels ont-ils une dimension physique ?
-- Jean-Claude Ghislain http://www.grimart.com
sinon, un pixel pas carre, sans dimension "physique", je vois pas.
Des pixels pas carrés c'est pas ça qui manque, de l'Amiga avec ses
pixels carrément rectangulaires, à la vidéo avec ses pixels légèrement
rectangulaires...
Et dans un fichier image, les pixels ont-ils une dimension physique ?
sinon, un pixel pas carre, sans dimension "physique", je vois pas.
Des pixels pas carrés c'est pas ça qui manque, de l'Amiga avec ses pixels carrément rectangulaires, à la vidéo avec ses pixels légèrement rectangulaires...
Et dans un fichier image, les pixels ont-ils une dimension physique ?
-- Jean-Claude Ghislain http://www.grimart.com
Jean-Luc L'Hôtellier
"Jean-Claude Ghislain" a écrit dans le message de news:bms2ro$qa3cl$
Et dans un fichier image, les pixels ont-ils une dimension physique ?
Oui dans la mesure où ce fichier est doté d'une résolution.
D'après M.Archambault: "Pour un moniteur, la taille du pixel est "fixe" et voisine de 0,28 mm. C'est la valeur de son "pitch". ...
"Pour un moniteur, et quels que soient sa taille et son type d'affichage, c'est *toujours* du 92 dpi pour un PC car 25,4 / 0,28 = 92 (ou 72 dpi sur Macintosh).
Moi je ne la calculais pas comme ça la résolution d'une image sur un écran.
1) Comme les moniteurs ont un rapport L/H de 4/3, d'après Pythagore un écran de 17" de diagonale fait 13,6" de large.
2) En définition 1024x768, pour moi ça donne 1024/13,6 soit 75 DPI.
@+
-- Max PUECH - Toulouse - http://mxp.fr.st Ah mes amis, quel coup de sabot, de Pampérigouste on en verrait la fumée! La mule du pape
"Papy Bernard" <lenichoir@aol.com> wrote in
news:bmmo61$3k7$1@news-reader5.wanadoo.fr:
D'après M.Archambault:
"Pour un moniteur, la taille du pixel est "fixe" et voisine de
0,28 mm. C'est la valeur de son "pitch".
...
"Pour un moniteur, et quels que soient sa taille et son type
d'affichage, c'est *toujours* du 92 dpi pour un PC car 25,4 / 0,28
= 92 (ou 72 dpi sur Macintosh).
Moi je ne la calculais pas comme ça la résolution d'une image sur un écran.
1) Comme les moniteurs ont un rapport L/H de 4/3, d'après Pythagore un
écran de 17" de diagonale fait 13,6" de large.
2) En définition 1024x768, pour moi ça donne 1024/13,6 soit 75 DPI.
@+
--
Max PUECH - Toulouse - http://mxp.fr.st
Ah mes amis, quel coup de sabot, de Pampérigouste on en verrait la
fumée!
La mule du pape
D'après M.Archambault: "Pour un moniteur, la taille du pixel est "fixe" et voisine de 0,28 mm. C'est la valeur de son "pitch". ...
"Pour un moniteur, et quels que soient sa taille et son type d'affichage, c'est *toujours* du 92 dpi pour un PC car 25,4 / 0,28 = 92 (ou 72 dpi sur Macintosh).
Moi je ne la calculais pas comme ça la résolution d'une image sur un écran.
1) Comme les moniteurs ont un rapport L/H de 4/3, d'après Pythagore un écran de 17" de diagonale fait 13,6" de large.
2) En définition 1024x768, pour moi ça donne 1024/13,6 soit 75 DPI.
@+
-- Max PUECH - Toulouse - http://mxp.fr.st Ah mes amis, quel coup de sabot, de Pampérigouste on en verrait la fumée! La mule du pape
Jean-Luc L'Hôtellier
"Max PUECH" a écrit dans le message de news:
1) Comme les moniteurs ont un rapport L/H de 4/3, d'après Pythagore un écran de 17" de diagonale fait 13,6" de large.
2) En définition 1024x768, pour moi ça donne 1024/13,6 soit 75 DPI.
Oui, c'est comme ça qu'il faut faire. Dans la mesure où cette information a une utilité.
Parce que si je veux afficher un objet sur un ecran, avec la meme taille quelque soit la resolution de l'ecran, je suis bien obliger d'en tenir compte, de cette resolution. Peut etre que toi ca te sert a rien, mais il y a plein de programme qui commencent par aller chercher un "theDisplay->resx" et un "theDisplay->width" etc...
"Jean-Luc L'Hôtellier" <prosesdevues@free.fr>
Ça en a pour choisir les fontes.
Non.
J'aime beaucoup le cote affirmatif de la reponse.
Parce que si je veux afficher un objet sur un ecran, avec la meme taille
quelque soit la resolution de l'ecran,
je suis bien obliger d'en tenir compte, de cette resolution. Peut etre que
toi ca te sert a rien, mais
il y a plein de programme qui commencent par aller chercher un
"theDisplay->resx" et un "theDisplay->width"
etc...
Parce que si je veux afficher un objet sur un ecran, avec la meme taille quelque soit la resolution de l'ecran, je suis bien obliger d'en tenir compte, de cette resolution. Peut etre que toi ca te sert a rien, mais il y a plein de programme qui commencent par aller chercher un "theDisplay->resx" et un "theDisplay->width" etc...
