J'ai pas mal de question concernant photoshop ou de confirmation (ou
non) à obtenir. Pourriez vous m'aider?
1) Pourquoi les outils disponibles dans photoshop ou les derawtiseurs,
affichent-ils des valeur d'echelle et de règlage allant de 0 à 255
lorsqu'on travail en 12 ou 16 bits?
2) un espace donné permet la correspondance entre des valeurs LAB et
RVB. SI l'on considère seulement les espaces neutres de travail,
sont-ils définis sur 8, 12 ou 16 bits? Je veux dire, le tableau de
correspondance RVB <-> LAB comprend il 16,7 million, 68 milliards ou
2,8 10 puissance 14 valeurs et leur correspondance ou est-ce une
fonction mathématique qui défini les correspondances?
3) En interne, photoshop fait-il ses calculs sur les valeurs LAB ou
RVB? Si c'est en RVB, j'imagine qu'il calcul sur la résolution réelle
(12 ou 16 bits) et non en 8 bits comme il l'affiche sur les outils?
4) Existe t-il des cartes graphiques et des moniteurs capable de
dépasser les 32 bits? (parceque rien qu'en RAW 12x3= 36). Vous me direz
qu'on ne peut pas les voir toutes en tant que nuances différentes
puisque l'oeil voit 8 millions de couleurs max mais au moins des
moniteurs ayant capable d'afficher toute l'étendue des couleurs de
l'espace RVB 1998?
Quand on défini un espace de tavail sous photoshop, selon ce que j'en
comprend, on y travaille reéllement que si le fichiers est soit
converti, soit possède déja un profil identique? Si j'ouvre un fichier
sRVB en conservant le profil d'origine, même si mon espace de travail
est Adobe RVB 1998, photoshop ignore l'espace de travail des
préférences tant que je n'ai pas converti le fichier dans son espace de
travail?
Un fichier possedant un profil Adobe RVB 1998 et sortant de mon APN,
est défini dans un espace neutre uniquement car on ne peut pas
caractériser un APN (calibration variable selon l'environnement)?
Je ne suis pas allé voir le site de Frich mais je suppose qu'il veut parler d'espace RGB "équilibré" (et non "neutre"). Un espace RGB équilibré est un espace dans lequel les couleurs pour lesquelles R=G=B sont neutres, c'est à dire achromatiques, c'est à dire "grises" du blanc au noir. Adobe RGB, par exemple, est un espace colorimétrique équilibré.
C'est ce qu'il en dit en effet. Il utilise très souvent le terme de "neutre" sur son site au dela des 2 exemples que j'ai cité. Pour autant, je retiens donc également le terme d'équilibré.
Sansame a présenté l'énoncé suivant :
Je ne suis pas allé voir le site de Frich mais je suppose qu'il veut parler
d'espace RGB "équilibré" (et non "neutre"). Un espace RGB équilibré est un
espace dans lequel les couleurs pour lesquelles R=G=B sont neutres, c'est à
dire achromatiques, c'est à dire "grises" du blanc au noir. Adobe RGB, par
exemple, est un espace colorimétrique équilibré.
C'est ce qu'il en dit en effet. Il utilise très souvent le terme de
"neutre" sur son site au dela des 2 exemples que j'ai cité. Pour
autant, je retiens donc également le terme d'équilibré.
Je ne suis pas allé voir le site de Frich mais je suppose qu'il veut parler d'espace RGB "équilibré" (et non "neutre"). Un espace RGB équilibré est un espace dans lequel les couleurs pour lesquelles R=G=B sont neutres, c'est à dire achromatiques, c'est à dire "grises" du blanc au noir. Adobe RGB, par exemple, est un espace colorimétrique équilibré.
C'est ce qu'il en dit en effet. Il utilise très souvent le terme de "neutre" sur son site au dela des 2 exemples que j'ai cité. Pour autant, je retiens donc également le terme d'équilibré.
Joel
Le 27/08/2006, Free-News a supposé :
Codifier chaque canal RGB sur plus de 8 bits présente de nombreux avantages,
Merci d'avoir pris le temps de répondre à mes question. Ceci est valable pour tout les contributeurs qui ont cette gentillesse. MAis vous n'avez pas fini! :-) j'en ais d'autres... :-)
Le 27/08/2006, Free-News a supposé :
Codifier chaque canal RGB sur plus de 8 bits présente de nombreux avantages,
Merci d'avoir pris le temps de répondre à mes question. Ceci est
valable pour tout les contributeurs qui ont cette gentillesse. MAis
vous n'avez pas fini! :-) j'en ais d'autres... :-)
Codifier chaque canal RGB sur plus de 8 bits présente de nombreux avantages,
Merci d'avoir pris le temps de répondre à mes question. Ceci est valable pour tout les contributeurs qui ont cette gentillesse. MAis vous n'avez pas fini! :-) j'en ais d'autres... :-)
Jean-Pierre Roche
- Pourquoi les dématriçeurs emcombrent-ils nos disques avec des bits inutiles ?
La pratique semble montrer que ces bits ne sont pas inutiles (loin de là) même s'ils sont éventuellement imprécis. Avec l'argentique on n'avait pas non plus une courbe sensitométrique droite (!!!) sur toute son étendue... C'était bien une courbe et pas avec un profil simple...
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
- Pourquoi les dématriçeurs emcombrent-ils nos disques avec des bits
inutiles ?
La pratique semble montrer que ces bits ne sont pas inutiles
(loin de là) même s'ils sont éventuellement imprécis. Avec
l'argentique on n'avait pas non plus une courbe
sensitométrique droite (!!!) sur toute son étendue...
C'était bien une courbe et pas avec un profil simple...
--
Jean-Pierre Roche
jproche@sanspubchello.fr
enlever sanspub pour m'écrire...
- Pourquoi les dématriçeurs emcombrent-ils nos disques avec des bits inutiles ?
La pratique semble montrer que ces bits ne sont pas inutiles (loin de là) même s'ils sont éventuellement imprécis. Avec l'argentique on n'avait pas non plus une courbe sensitométrique droite (!!!) sur toute son étendue... C'était bien une courbe et pas avec un profil simple...
-- Jean-Pierre Roche
enlever sanspub pour m'écrire...
http://jpierreroche.free.fr/
Charles VASSALLO
Sansame wrote:
Même si le dématriçage produit trois nombres définis sur 12 bits, la profondeur de couleur [en 16 bits] est un costume en partie illusoire. Ces nombres ne représentent pas la couleur avec la précision qu'ils semblent avoir. Autrement dit, les bits de droite (combien ?) sont à peu près tirés au hasard.
Je me pose donc deux questions :
- Pourquoi les dématriçeurs emcombrent-ils nos disques avec des bits inutiles ?
- Quelle est la profondeur de couleur réelle (utile) des nombres issus du dématriçage ?
Simple bon sens : la profondeur réelle reste la profondeur initiale. On travaille en 16 bits parce que l'atome de base des mémoires d'ordinateur est l'octet. Il faut donc 2 octets pour accueillir 12 bits. Le 2ème est à moitié vide au départ; il se remplit aucours des calculs, mais les 4 bits en supplément ne seront jamais significatifs, sinon pour minimiser les erreurs d'arrondi
Charles
Sansame wrote:
Même si le dématriçage produit trois nombres définis sur 12 bits, la
profondeur de couleur [en 16 bits] est un costume en
partie illusoire. Ces nombres ne représentent pas la couleur avec la
précision qu'ils semblent avoir. Autrement dit, les bits de droite
(combien ?) sont à peu près tirés au hasard.
Je me pose donc deux questions :
- Pourquoi les dématriçeurs emcombrent-ils nos disques avec des bits
inutiles ?
- Quelle est la profondeur de couleur réelle (utile) des nombres issus
du dématriçage ?
Simple bon sens : la profondeur réelle reste la profondeur initiale. On
travaille en 16 bits parce que l'atome de base des mémoires d'ordinateur
est l'octet. Il faut donc 2 octets pour accueillir 12 bits. Le 2ème est
à moitié vide au départ; il se remplit aucours des calculs, mais les 4
bits en supplément ne seront jamais significatifs, sinon pour minimiser
les erreurs d'arrondi
Même si le dématriçage produit trois nombres définis sur 12 bits, la profondeur de couleur [en 16 bits] est un costume en partie illusoire. Ces nombres ne représentent pas la couleur avec la précision qu'ils semblent avoir. Autrement dit, les bits de droite (combien ?) sont à peu près tirés au hasard.
Je me pose donc deux questions :
- Pourquoi les dématriçeurs emcombrent-ils nos disques avec des bits inutiles ?
- Quelle est la profondeur de couleur réelle (utile) des nombres issus du dématriçage ?
Simple bon sens : la profondeur réelle reste la profondeur initiale. On travaille en 16 bits parce que l'atome de base des mémoires d'ordinateur est l'octet. Il faut donc 2 octets pour accueillir 12 bits. Le 2ème est à moitié vide au départ; il se remplit aucours des calculs, mais les 4 bits en supplément ne seront jamais significatifs, sinon pour minimiser les erreurs d'arrondi
Charles
Sansame
Simple bon sens : la profondeur réelle reste la profondeur initiale. On travaille en 16 bits parce que l'atome de base des mémoires d'ordinateur est l'octet. Il faut donc 2 octets pour accueillir 12 bits. Le 2ème est à moitié vide au départ; il se remplit aucours des calculs, mais les 4 bits en supplément ne seront jamais significatifs, sinon pour minimiser les erreurs d'arrondi
Je me méfie un peu du bon sens et ne parviens pas à comprendre comment
la profondeur "réelle" utile (bits significatifs) de chacune des trois couches RGB dématriçées, pourrait être égale à la profondeur initiale sur 12 bits du fichier RAW capturé.
La capture initiale de luminance "monochrome" sur 12 bits contient en effet trois fois moins de quantité d'information que trois couches sur 12 bits. Ces trois couches RVB résultent d'une interprétation logicielle du filtrage par matrice de Bayer. Cette interprétation, purement mathématique, ne fait appel à aucune donnée supplémentaire acquise par le capteur et ne peut donc pas générer 36 bits pour 12 bits capturés.
Autre façon d'aborder le paradoxe : imaginons un "super-capteur" qui, pour le même nombre de pixels que notre capteur à matrice de Bayer, capturerait sur 12 bits TROIS valeurs de luminance RVB pour chaque pixel (plus besoin de dématriçage !). Ce super capteur ferait ainsi l'acquisition de TROIS fois plus d'informations que notre capteur banal filtré et il aboutirait à un fichier contenant trois couches RVB sur 12 bits. Je vois mal comment la capture "monochrome" sur 12 bits de trois fois moins d'information pourrait aboutir au même résultat...
Qu'en pensez vous ?
-- Sansame
Simple bon sens : la profondeur réelle reste la profondeur initiale. On
travaille en 16 bits parce que l'atome de base des mémoires d'ordinateur est
l'octet. Il faut donc 2 octets pour accueillir 12 bits. Le 2ème est à moitié
vide au départ; il se remplit aucours des calculs, mais les 4 bits en
supplément ne seront jamais significatifs, sinon pour minimiser les erreurs
d'arrondi
Je me méfie un peu du bon sens et ne parviens pas à comprendre comment
la profondeur "réelle" utile (bits significatifs) de chacune des trois
couches RGB dématriçées, pourrait être égale à la profondeur initiale
sur 12 bits du fichier RAW capturé.
La capture initiale de luminance "monochrome" sur 12 bits contient en
effet trois fois moins de quantité d'information que trois couches sur
12 bits. Ces trois couches RVB résultent d'une interprétation
logicielle du filtrage par matrice de Bayer. Cette interprétation,
purement mathématique, ne fait appel à aucune donnée supplémentaire
acquise par le capteur et ne peut donc pas générer 36 bits pour 12 bits
capturés.
Autre façon d'aborder le paradoxe : imaginons un "super-capteur" qui,
pour le même nombre de pixels que notre capteur à matrice de Bayer,
capturerait sur 12 bits TROIS valeurs de luminance RVB pour chaque
pixel (plus besoin de dématriçage !). Ce super capteur ferait ainsi
l'acquisition de TROIS fois plus d'informations que notre capteur banal
filtré et il aboutirait à un fichier contenant trois couches RVB sur 12
bits. Je vois mal comment la capture "monochrome" sur 12 bits de trois
fois moins d'information pourrait aboutir au même résultat...
Simple bon sens : la profondeur réelle reste la profondeur initiale. On travaille en 16 bits parce que l'atome de base des mémoires d'ordinateur est l'octet. Il faut donc 2 octets pour accueillir 12 bits. Le 2ème est à moitié vide au départ; il se remplit aucours des calculs, mais les 4 bits en supplément ne seront jamais significatifs, sinon pour minimiser les erreurs d'arrondi
Je me méfie un peu du bon sens et ne parviens pas à comprendre comment
la profondeur "réelle" utile (bits significatifs) de chacune des trois couches RGB dématriçées, pourrait être égale à la profondeur initiale sur 12 bits du fichier RAW capturé.
La capture initiale de luminance "monochrome" sur 12 bits contient en effet trois fois moins de quantité d'information que trois couches sur 12 bits. Ces trois couches RVB résultent d'une interprétation logicielle du filtrage par matrice de Bayer. Cette interprétation, purement mathématique, ne fait appel à aucune donnée supplémentaire acquise par le capteur et ne peut donc pas générer 36 bits pour 12 bits capturés.
Autre façon d'aborder le paradoxe : imaginons un "super-capteur" qui, pour le même nombre de pixels que notre capteur à matrice de Bayer, capturerait sur 12 bits TROIS valeurs de luminance RVB pour chaque pixel (plus besoin de dématriçage !). Ce super capteur ferait ainsi l'acquisition de TROIS fois plus d'informations que notre capteur banal filtré et il aboutirait à un fichier contenant trois couches RVB sur 12 bits. Je vois mal comment la capture "monochrome" sur 12 bits de trois fois moins d'information pourrait aboutir au même résultat...
Qu'en pensez vous ?
-- Sansame
Charles VASSALLO
Sansame wrote:
Autre façon d'aborder le paradoxe : imaginons un "super-capteur" qui, pour le même nombre de pixels que notre capteur à matrice de Bayer, capturerait sur 12 bits TROIS valeurs de luminance RVB pour chaque pixel (plus besoin de dématriçage !). Ce super capteur ferait ainsi l'acquisition de TROIS fois plus d'informations que notre capteur banal filtré et il aboutirait à un fichier contenant trois couches RVB sur 12 bits. Je vois mal comment la capture "monochrome" sur 12 bits de trois fois moins d'information pourrait aboutir au même résultat...
Qu'en pensez vous ?
Que la quantité d'information dans une image n'a rien à voir avec les nombre total de bits stockés dans ses différents pixels. Elle est beaucoup plus faible; d'une certaine façon, c'est ce qui permettra de comprimer le poids du fichier dans des proportions considérables (jusqu'à 1/100 sans trop de dommages, en général, avec les ondelettes)
Mais je suis là totalement hors de mes pompes; Saint Shannon, pardonnez-moi!
Simplement, j'avancerai qu'il est très probable que les RVB qui ont été interpolés dans le dématriçage ne sont pas probablement pas toujours exacts jusqu'au 12ème bit, mais que ça a peu d'importance.
Charles
Sansame wrote:
Autre façon d'aborder le paradoxe : imaginons un "super-capteur" qui,
pour le même nombre de pixels que notre capteur à matrice de Bayer,
capturerait sur 12 bits TROIS valeurs de luminance RVB pour chaque pixel
(plus besoin de dématriçage !). Ce super capteur ferait ainsi
l'acquisition de TROIS fois plus d'informations que notre capteur banal
filtré et il aboutirait à un fichier contenant trois couches RVB sur 12
bits. Je vois mal comment la capture "monochrome" sur 12 bits de trois
fois moins d'information pourrait aboutir au même résultat...
Qu'en pensez vous ?
Que la quantité d'information dans une image n'a rien à voir avec les
nombre total de bits stockés dans ses différents pixels. Elle est
beaucoup plus faible; d'une certaine façon, c'est ce qui permettra de
comprimer le poids du fichier dans des proportions considérables
(jusqu'à 1/100 sans trop de dommages, en général, avec les ondelettes)
Mais je suis là totalement hors de mes pompes; Saint Shannon, pardonnez-moi!
Simplement, j'avancerai qu'il est très probable que les RVB qui ont été
interpolés dans le dématriçage ne sont pas probablement pas toujours
exacts jusqu'au 12ème bit, mais que ça a peu d'importance.
Autre façon d'aborder le paradoxe : imaginons un "super-capteur" qui, pour le même nombre de pixels que notre capteur à matrice de Bayer, capturerait sur 12 bits TROIS valeurs de luminance RVB pour chaque pixel (plus besoin de dématriçage !). Ce super capteur ferait ainsi l'acquisition de TROIS fois plus d'informations que notre capteur banal filtré et il aboutirait à un fichier contenant trois couches RVB sur 12 bits. Je vois mal comment la capture "monochrome" sur 12 bits de trois fois moins d'information pourrait aboutir au même résultat...
Qu'en pensez vous ?
Que la quantité d'information dans une image n'a rien à voir avec les nombre total de bits stockés dans ses différents pixels. Elle est beaucoup plus faible; d'une certaine façon, c'est ce qui permettra de comprimer le poids du fichier dans des proportions considérables (jusqu'à 1/100 sans trop de dommages, en général, avec les ondelettes)
Mais je suis là totalement hors de mes pompes; Saint Shannon, pardonnez-moi!
Simplement, j'avancerai qu'il est très probable que les RVB qui ont été interpolés dans le dématriçage ne sont pas probablement pas toujours exacts jusqu'au 12ème bit, mais que ça a peu d'importance.
Charles
Sansame
Que la quantité d'information dans une image n'a rien à voir avec les nombre total de bits stockés dans ses différents pixels. Elle est beaucoup plus faible; d'une certaine façon, c'est ce qui permettra de comprimer le poids du fichier dans des proportions considérables (jusqu'à 1/100 sans trop de dommages, en général, avec les ondelettes)
La quantité d'information contenue dans un fichier photo non compressé est directement liée au nombre de bits significatifs qui constituent son fichier. Elle est d'ailleurs la même que celle contenue dans un rectangle monochrome de même nombre de pixels car c'est une analyse de l'image monochrome par le logiciel de compression qui permet d'y découvrir une singularité, sa monochromie et d'exploiter sa singularité pour faire un tout petit fichier sans perte. En revanche, la compression avec perte diminue la quantité d'information.
Simplement, j'avancerai qu'il est très probable que les RVB qui ont été interpolés dans le dématriçage ne sont pas probablement pas toujours exacts jusqu'au 12ème bit, mais que ça a peu d'importance.
La profondeur de couleur des couches RGB résultant du dématriçage est obligatoirement inférieure à celle de la couche monochrome captée. Il ne doit pas être trop difficile de calculer la profondeur résultante malgré le biais apporté par le fait que les RAW sont tous compressés. Faudrait interroger les éditeurs de dématriçeurs.
-- Sansame
Que la quantité d'information dans une image n'a rien à voir avec les nombre
total de bits stockés dans ses différents pixels. Elle est beaucoup plus
faible; d'une certaine façon, c'est ce qui permettra de comprimer le poids du
fichier dans des proportions considérables (jusqu'à 1/100 sans trop de
dommages, en général, avec les ondelettes)
La quantité d'information contenue dans un fichier photo non compressé
est directement liée au nombre de bits significatifs qui constituent
son fichier. Elle est d'ailleurs la même que celle contenue dans un
rectangle monochrome de même nombre de pixels car c'est une analyse de
l'image monochrome par le logiciel de compression qui permet d'y
découvrir une singularité, sa monochromie et d'exploiter sa singularité
pour faire un tout petit fichier sans perte. En revanche, la
compression avec perte diminue la quantité d'information.
Simplement, j'avancerai qu'il est très probable que les RVB qui ont été
interpolés dans le dématriçage ne sont pas probablement pas toujours exacts
jusqu'au 12ème bit, mais que ça a peu d'importance.
La profondeur de couleur des couches RGB résultant du dématriçage est
obligatoirement inférieure à celle de la couche monochrome captée. Il
ne doit pas être trop difficile de calculer la profondeur résultante
malgré le biais apporté par le fait que les RAW sont tous compressés.
Faudrait interroger les éditeurs de dématriçeurs.
Que la quantité d'information dans une image n'a rien à voir avec les nombre total de bits stockés dans ses différents pixels. Elle est beaucoup plus faible; d'une certaine façon, c'est ce qui permettra de comprimer le poids du fichier dans des proportions considérables (jusqu'à 1/100 sans trop de dommages, en général, avec les ondelettes)
La quantité d'information contenue dans un fichier photo non compressé est directement liée au nombre de bits significatifs qui constituent son fichier. Elle est d'ailleurs la même que celle contenue dans un rectangle monochrome de même nombre de pixels car c'est une analyse de l'image monochrome par le logiciel de compression qui permet d'y découvrir une singularité, sa monochromie et d'exploiter sa singularité pour faire un tout petit fichier sans perte. En revanche, la compression avec perte diminue la quantité d'information.
Simplement, j'avancerai qu'il est très probable que les RVB qui ont été interpolés dans le dématriçage ne sont pas probablement pas toujours exacts jusqu'au 12ème bit, mais que ça a peu d'importance.
La profondeur de couleur des couches RGB résultant du dématriçage est obligatoirement inférieure à celle de la couche monochrome captée. Il ne doit pas être trop difficile de calculer la profondeur résultante malgré le biais apporté par le fait que les RAW sont tous compressés. Faudrait interroger les éditeurs de dématriçeurs.
-- Sansame
Charles VASSALLO
Sansame wrote:
La quantité d'information contenue dans un fichier photo non compressé est directement liée au nombre de bits significatifs qui constituent son fichier. Elle est d'ailleurs la même que celle contenue dans un rectangle monochrome de même nombre de pixels car c'est une analyse de l'image monochrome par le logiciel de compression qui permet d'y découvrir une singularité, sa monochromie et d'exploiter sa singularité pour faire un tout petit fichier sans perte. En revanche, la compression avec perte diminue la quantité d'information.
Ah ! Nous ne parlons pas de la même chose. Tu parles du poids du fichier et moi de la «quantité d'information» au sens des émules de Shannon, même si je ne sais pas très bien ce que c'est.
J'ai quand même l'idée naïve que «l'information» contenue dans une image, hors de toute mesure d'icelle, est ce qui permettrait de la reconstruire ; pour faire la part des choses, ajoutons «à un niveau d'approximation donné», correspondant à ce que le medium de sortie sait faire ou à ce que l'observateur peut capter.
En ce sens, on n'ajoute donc aucune information quand on multiplie le nombre des pixels dans un rectangle monochrome, et également quand on ajoute des pixels interpolés lors du dématriçage d'une image RAW. Dans ce dernier cas, on suppose une certaine régularité des couleurs dans l'image, et on n'ajoute aucune information tant que cette régularité est vérifiée. Cette hypothèse de régularité est incluse dans le medium de sortie de l'image. De temps en temps on se plante (au voisinage des contours), et on fait des erreurs ; ces erreurs correspondent précisément à de l'information qu'on aurait dû rajouter et qui manque.
Charles
Sansame wrote:
La quantité d'information contenue dans un fichier photo non compressé
est directement liée au nombre de bits significatifs qui constituent son
fichier. Elle est d'ailleurs la même que celle contenue dans un
rectangle monochrome de même nombre de pixels car c'est une analyse de
l'image monochrome par le logiciel de compression qui permet d'y
découvrir une singularité, sa monochromie et d'exploiter sa singularité
pour faire un tout petit fichier sans perte. En revanche, la compression
avec perte diminue la quantité d'information.
Ah ! Nous ne parlons pas de la même chose. Tu parles du poids du fichier
et moi de la «quantité d'information» au sens des émules de Shannon,
même si je ne sais pas très bien ce que c'est.
J'ai quand même l'idée naïve que «l'information» contenue dans une
image, hors de toute mesure d'icelle, est ce qui permettrait de la
reconstruire ; pour faire la part des choses, ajoutons «à un niveau
d'approximation donné», correspondant à ce que le medium de sortie sait
faire ou à ce que l'observateur peut capter.
En ce sens, on n'ajoute donc aucune information quand on multiplie le
nombre des pixels dans un rectangle monochrome, et également quand on
ajoute des pixels interpolés lors du dématriçage d'une image RAW. Dans
ce dernier cas, on suppose une certaine régularité des couleurs dans
l'image, et on n'ajoute aucune information tant que cette régularité est
vérifiée. Cette hypothèse de régularité est incluse dans le medium de
sortie de l'image. De temps en temps on se plante (au voisinage des
contours), et on fait des erreurs ; ces erreurs correspondent
précisément à de l'information qu'on aurait dû rajouter et qui manque.
La quantité d'information contenue dans un fichier photo non compressé est directement liée au nombre de bits significatifs qui constituent son fichier. Elle est d'ailleurs la même que celle contenue dans un rectangle monochrome de même nombre de pixels car c'est une analyse de l'image monochrome par le logiciel de compression qui permet d'y découvrir une singularité, sa monochromie et d'exploiter sa singularité pour faire un tout petit fichier sans perte. En revanche, la compression avec perte diminue la quantité d'information.
Ah ! Nous ne parlons pas de la même chose. Tu parles du poids du fichier et moi de la «quantité d'information» au sens des émules de Shannon, même si je ne sais pas très bien ce que c'est.
J'ai quand même l'idée naïve que «l'information» contenue dans une image, hors de toute mesure d'icelle, est ce qui permettrait de la reconstruire ; pour faire la part des choses, ajoutons «à un niveau d'approximation donné», correspondant à ce que le medium de sortie sait faire ou à ce que l'observateur peut capter.
En ce sens, on n'ajoute donc aucune information quand on multiplie le nombre des pixels dans un rectangle monochrome, et également quand on ajoute des pixels interpolés lors du dématriçage d'une image RAW. Dans ce dernier cas, on suppose une certaine régularité des couleurs dans l'image, et on n'ajoute aucune information tant que cette régularité est vérifiée. Cette hypothèse de régularité est incluse dans le medium de sortie de l'image. De temps en temps on se plante (au voisinage des contours), et on fait des erreurs ; ces erreurs correspondent précisément à de l'information qu'on aurait dû rajouter et qui manque.
Charles
Noëlle Adam
Sansame wrote:
Que la quantité d'information dans une image n'a rien à voir avec les nombre total de bits stockés dans ses différents pixels. Elle est beaucoup plus faible; d'une certaine façon, c'est ce qui permettra de comprimer le poids du fichier dans des proportions considérables (jusqu'à 1/100 sans trop de dommages, en général, avec les ondelettes)
La quantité d'information contenue dans un fichier photo non compressé est directement liée au nombre de bits significatifs qui constituent son fichier.
Non, ça c'est la quantité d'informations :) ou plus exactement, celle de données. La quantité d'information est une fonction inverse de la probabilité.
Pour la même quantité de données, on peut avoir peu ou beaucoup d'information :
«Aujourd'hui il pleut sur Brest» contient beaucoup moins d'information que « Aujourd'hui il neige à Marseille ».
Noëlle.
Sansame wrote:
Que la quantité d'information dans une image n'a rien à voir avec les
nombre total de bits stockés dans ses différents pixels. Elle est
beaucoup plus faible; d'une certaine façon, c'est ce qui permettra de
comprimer le poids du fichier dans des proportions considérables
(jusqu'à 1/100 sans trop de dommages, en général, avec les ondelettes)
La quantité d'information contenue dans un fichier photo non compressé
est directement liée au nombre de bits significatifs qui constituent son
fichier.
Non, ça c'est la quantité d'informations :) ou plus exactement, celle de
données. La quantité d'information est une fonction inverse de la
probabilité.
Pour la même quantité de données, on peut avoir peu ou beaucoup
d'information :
«Aujourd'hui il pleut sur Brest» contient beaucoup moins d'information
que « Aujourd'hui il neige à Marseille ».
Que la quantité d'information dans une image n'a rien à voir avec les nombre total de bits stockés dans ses différents pixels. Elle est beaucoup plus faible; d'une certaine façon, c'est ce qui permettra de comprimer le poids du fichier dans des proportions considérables (jusqu'à 1/100 sans trop de dommages, en général, avec les ondelettes)
La quantité d'information contenue dans un fichier photo non compressé est directement liée au nombre de bits significatifs qui constituent son fichier.
Non, ça c'est la quantité d'informations :) ou plus exactement, celle de données. La quantité d'information est une fonction inverse de la probabilité.
Pour la même quantité de données, on peut avoir peu ou beaucoup d'information :
«Aujourd'hui il pleut sur Brest» contient beaucoup moins d'information que « Aujourd'hui il neige à Marseille ».
Noëlle.
Sansame
«Aujourd'hui il pleut sur Brest» contient beaucoup moins d'information que « Aujourd'hui il neige à Marseille ».
Trés juste, ça met en valeur le fait que c'est le couple message + contexte qui porte véritablement l'information.
Sur la relation entre la longueur d'une donnée et la quantité d'information qu'elle apporte, remarquons aussi que "Lucie est un mammifère au cou plus long que la moyenne" est plus long mais apporte moins d'info que "Lucie est une girafe"...
-- Sansame
«Aujourd'hui il pleut sur Brest» contient beaucoup moins d'information que «
Aujourd'hui il neige à Marseille ».
Trés juste, ça met en valeur le fait que c'est le couple message +
contexte qui porte véritablement l'information.
Sur la relation entre la longueur d'une donnée et la quantité
d'information qu'elle apporte, remarquons aussi que "Lucie est un
mammifère au cou plus long que la moyenne" est plus long mais apporte
moins d'info que "Lucie est une girafe"...
«Aujourd'hui il pleut sur Brest» contient beaucoup moins d'information que « Aujourd'hui il neige à Marseille ».
Trés juste, ça met en valeur le fait que c'est le couple message + contexte qui porte véritablement l'information.
Sur la relation entre la longueur d'une donnée et la quantité d'information qu'elle apporte, remarquons aussi que "Lucie est un mammifère au cou plus long que la moyenne" est plus long mais apporte moins d'info que "Lucie est une girafe"...
