Je me suis aperçu qu'un trop grand nombre de fichiers sur le bureau
pouvait ralentir considérablement l'ordinateur, voire le planter.
D'où ma question : serait-il possible d'envoyer directement dans un
dossier plutôt que sur le bureau (comportement par défaut) les fichiers
"Capture d'écran" ?
Non, c'est impossible, la "première phase" (DCT + quantification) n'est pas optionnelle et n'est pas totalement sans perte, quelque soit les paramètres.
Oui, c'est ce que je viens de comprendre. Reste à faire comprendre à un ignare en maths (terminale littéraire, c'est dire !) mais malgré tout très intéressé (voir ma signature) ce qu'est une transformée de Fourier (je me rappelle qu'il y avait ça aussi dans l'économiseur d'écran du projet SETI).
-- Tardigradus e^iπ=-1 c'est magnifique
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Non, c'est impossible, la "première phase" (DCT + quantification) n'est
pas optionnelle et n'est pas totalement sans perte, quelque soit les
paramètres.
Oui, c'est ce que je viens de comprendre. Reste à faire comprendre à un
ignare en maths (terminale littéraire, c'est dire !) mais malgré tout
très intéressé (voir ma signature) ce qu'est une transformée de Fourier
(je me rappelle qu'il y avait ça aussi dans l'économiseur d'écran du
projet SETI).
Non, c'est impossible, la "première phase" (DCT + quantification) n'est pas optionnelle et n'est pas totalement sans perte, quelque soit les paramètres.
Oui, c'est ce que je viens de comprendre. Reste à faire comprendre à un ignare en maths (terminale littéraire, c'est dire !) mais malgré tout très intéressé (voir ma signature) ce qu'est une transformée de Fourier (je me rappelle qu'il y avait ça aussi dans l'économiseur d'écran du projet SETI).
-- Tardigradus e^iπ=-1 c'est magnifique
patrick.1200RTcazaux
Patrick Stadelmann wrote:
Ca n'est absolument pas garanti, un TIFF peut très bien par exemple ne contenir que l'image compressée avec... JPEG !
Un peu tordu, là, non ? Même si techniquement c'est possible, quel est l'intérêt ? Pourquoi ne pas mettre tout ça dans un EPS en plus ? :) C'est le principe matriochka ? :)
-- Tardigradus e^iπ=-1 c'est magnifique
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Ca n'est absolument pas garanti, un TIFF peut très bien par exemple ne
contenir que l'image compressée avec... JPEG !
Un peu tordu, là, non ? Même si techniquement c'est possible, quel est
l'intérêt ?
Pourquoi ne pas mettre tout ça dans un EPS en plus ? :) C'est le
principe matriochka ? :)
Ca n'est absolument pas garanti, un TIFF peut très bien par exemple ne contenir que l'image compressée avec... JPEG !
Un peu tordu, là, non ? Même si techniquement c'est possible, quel est l'intérêt ? Pourquoi ne pas mettre tout ça dans un EPS en plus ? :) C'est le principe matriochka ? :)
-- Tardigradus e^iπ=-1 c'est magnifique
pdorange
Patrick Stadelmann wrote:
> Notamment lors de la transformation de couleur (passage de RGB à YUV > sous-échantillonné, même principe qu le MPEG), puis en DCT et en > Quntification.
La transformation de couleur est optionnelle, on peut tout à fait utiliser JPEG sur chacune des composantes d'origine (RGB, CMYK, ...).
C'est bien possible, je ne connais pas en détail la spécification.
En pratique, ce que l'on appelle fichier JPEG, c'est dans l'immense majorité des cas un fichier JFIF, qui encode l'image en YCbCr 4:2:0.
Donc avec transformation de couleurs en 4:2:0 on perd 33% de l'information (avant les autres opérations), c'est un sous-échantillonnage sur les couleurs. <http://www.garage-video.com/spec/YUV.html>
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> Notamment lors de la transformation de couleur (passage de RGB à YUV
> sous-échantillonné, même principe qu le MPEG), puis en DCT et en
> Quntification.
La transformation de couleur est optionnelle, on peut tout à fait
utiliser JPEG sur chacune des composantes d'origine (RGB, CMYK, ...).
C'est bien possible, je ne connais pas en détail la spécification.
En pratique, ce que l'on appelle fichier JPEG, c'est dans l'immense
majorité des cas un fichier JFIF, qui encode l'image en YCbCr 4:2:0.
Donc avec transformation de couleurs en 4:2:0 on perd 33% de
l'information (avant les autres opérations), c'est un
sous-échantillonnage sur les couleurs.
<http://www.garage-video.com/spec/YUV.html>
> Notamment lors de la transformation de couleur (passage de RGB à YUV > sous-échantillonné, même principe qu le MPEG), puis en DCT et en > Quntification.
La transformation de couleur est optionnelle, on peut tout à fait utiliser JPEG sur chacune des composantes d'origine (RGB, CMYK, ...).
C'est bien possible, je ne connais pas en détail la spécification.
En pratique, ce que l'on appelle fichier JPEG, c'est dans l'immense majorité des cas un fichier JFIF, qui encode l'image en YCbCr 4:2:0.
Donc avec transformation de couleurs en 4:2:0 on perd 33% de l'information (avant les autres opérations), c'est un sous-échantillonnage sur les couleurs. <http://www.garage-video.com/spec/YUV.html>
Oui, c'est ce que je viens de comprendre. Reste à faire comprendre à un ignare en maths (terminale littéraire, c'est dire !)
"J'a eu" un prof de physique en secondaire scientifique qui avait passé un bac littéraire... Mais c'est vrai, "ça est pas" la majorité... -- Barnabé
Patrick Stadelmann
In article <1jr2xfz.x8cq991cxjv09N%, (Tardigradus) wrote:
Patrick Stadelmann wrote:
> Ca n'est absolument pas garanti, un TIFF peut très bien par exemple ne > contenir que l'image compressée avec... JPEG !
Un peu tordu, là, non ? Même si techniquement c'est possible, quel est l'intérêt ?
C'est pas juste techniquement possible, c'est l'une des 3 options de compression proposées par Photoshop CS3 pour l'export en TIFF ! C'est juste que comme déjà dit, TIFF est un conteneur, dedans on met ce que l'on veut, donc pourquoi pas du JPEG !
Patrick -- Patrick Stadelmann
In article
<1jr2xfz.x8cq991cxjv09N%patrick.1200RTcazaux@cadratin.fr.invalid>,
patrick.1200RTcazaux@cadratin.fr.invalid (Tardigradus) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> Ca n'est absolument pas garanti, un TIFF peut très bien par exemple ne
> contenir que l'image compressée avec... JPEG !
Un peu tordu, là, non ? Même si techniquement c'est possible, quel est
l'intérêt ?
C'est pas juste techniquement possible, c'est l'une des 3 options de
compression proposées par Photoshop CS3 pour l'export en TIFF ! C'est
juste que comme déjà dit, TIFF est un conteneur, dedans on met ce que
l'on veut, donc pourquoi pas du JPEG !
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jr2xfz.x8cq991cxjv09N%, (Tardigradus) wrote:
Patrick Stadelmann wrote:
> Ca n'est absolument pas garanti, un TIFF peut très bien par exemple ne > contenir que l'image compressée avec... JPEG !
Un peu tordu, là, non ? Même si techniquement c'est possible, quel est l'intérêt ?
C'est pas juste techniquement possible, c'est l'une des 3 options de compression proposées par Photoshop CS3 pour l'export en TIFF ! C'est juste que comme déjà dit, TIFF est un conteneur, dedans on met ce que l'on veut, donc pourquoi pas du JPEG !
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1jr2xb5.1wvare117a86icN%, (Tardigradus) wrote:
Patrick Stadelmann wrote:
> Non, c'est impossible, la "première phase" (DCT + quantification) n'est > pas optionnelle et n'est pas totalement sans perte, quelque soit les > paramètres.
Oui, c'est ce que je viens de comprendre. Reste à faire comprendre à un ignare en maths (terminale littéraire, c'est dire !) mais malgré tout très intéressé (voir ma signature) ce qu'est une transformée de Fourier (je me rappelle qu'il y avait ça aussi dans l'économiseur d'écran du projet SETI).
C'est une DCT (transformée en cosinus discrète) dans JPEG. Le principe est assez simple. Dans une photo, la plupart du temps, les valeurs des pixels proches est très proche. En théorie de l'information, on dit que les pixels sont corrélés : une partie de l'information est présente de manière redondante dans tous les pixels. La DCT transforme les pixels en coefficients qui sont nettement moins corrélés. Pour des raisons de complexité, on effectue l'opération non pas sur toute l'image, mais sur des blocs de 8x8 pixels. Après transformation, on obtient 8x8 coefficients, dont la plupart ont une valeur quasi nulle : l'information n'est plus "diluée" dans les pixels, elle est regroupée avec peu de redondance dans un petit nombre de pixels.
Patrick -- Patrick Stadelmann
In article
<1jr2xb5.1wvare117a86icN%patrick.1200RTcazaux@cadratin.fr.invalid>,
patrick.1200RTcazaux@cadratin.fr.invalid (Tardigradus) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> Non, c'est impossible, la "première phase" (DCT + quantification) n'est
> pas optionnelle et n'est pas totalement sans perte, quelque soit les
> paramètres.
Oui, c'est ce que je viens de comprendre. Reste à faire comprendre à un
ignare en maths (terminale littéraire, c'est dire !) mais malgré tout
très intéressé (voir ma signature) ce qu'est une transformée de Fourier
(je me rappelle qu'il y avait ça aussi dans l'économiseur d'écran du
projet SETI).
C'est une DCT (transformée en cosinus discrète) dans JPEG. Le principe
est assez simple. Dans une photo, la plupart du temps, les valeurs des
pixels proches est très proche. En théorie de l'information, on dit que
les pixels sont corrélés : une partie de l'information est présente de
manière redondante dans tous les pixels. La DCT transforme les pixels en
coefficients qui sont nettement moins corrélés. Pour des raisons de
complexité, on effectue l'opération non pas sur toute l'image, mais sur
des blocs de 8x8 pixels. Après transformation, on obtient 8x8
coefficients, dont la plupart ont une valeur quasi nulle : l'information
n'est plus "diluée" dans les pixels, elle est regroupée avec peu de
redondance dans un petit nombre de pixels.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jr2xb5.1wvare117a86icN%, (Tardigradus) wrote:
Patrick Stadelmann wrote:
> Non, c'est impossible, la "première phase" (DCT + quantification) n'est > pas optionnelle et n'est pas totalement sans perte, quelque soit les > paramètres.
Oui, c'est ce que je viens de comprendre. Reste à faire comprendre à un ignare en maths (terminale littéraire, c'est dire !) mais malgré tout très intéressé (voir ma signature) ce qu'est une transformée de Fourier (je me rappelle qu'il y avait ça aussi dans l'économiseur d'écran du projet SETI).
C'est une DCT (transformée en cosinus discrète) dans JPEG. Le principe est assez simple. Dans une photo, la plupart du temps, les valeurs des pixels proches est très proche. En théorie de l'information, on dit que les pixels sont corrélés : une partie de l'information est présente de manière redondante dans tous les pixels. La DCT transforme les pixels en coefficients qui sont nettement moins corrélés. Pour des raisons de complexité, on effectue l'opération non pas sur toute l'image, mais sur des blocs de 8x8 pixels. Après transformation, on obtient 8x8 coefficients, dont la plupart ont une valeur quasi nulle : l'information n'est plus "diluée" dans les pixels, elle est regroupée avec peu de redondance dans un petit nombre de pixels.
Patrick -- Patrick Stadelmann
patrick.1200RTcazaux
Patrick Stadelmann wrote:
une partie de l'information est présente de manière redondante dans tous les pixels
Comme quoi ? Si tous les pixels concernés dans le bloc de 8 par 8 ont le même niveau de rouge, par exemple, ou du moins un niveau minimum commun ? Et la DCT ne leur laisserait que la différence entre eux ? Un truc dans ce goût là ?
-- Tardigradus e^iπ=-1 c'est magnifique
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
une partie de l'information est présente de
manière redondante dans tous les pixels
Comme quoi ? Si tous les pixels concernés dans le bloc de 8 par 8 ont le
même niveau de rouge, par exemple, ou du moins un niveau minimum commun
? Et la DCT ne leur laisserait que la différence entre eux ? Un truc
dans ce goût là ?
une partie de l'information est présente de manière redondante dans tous les pixels
Comme quoi ? Si tous les pixels concernés dans le bloc de 8 par 8 ont le même niveau de rouge, par exemple, ou du moins un niveau minimum commun ? Et la DCT ne leur laisserait que la différence entre eux ? Un truc dans ce goût là ?
-- Tardigradus e^iπ=-1 c'est magnifique
Patrick Stadelmann
In article <1jr2xjt.1x3wfa21ou8u41N%, (Pierre-Alain Dorange) wrote:
Patrick Stadelmann wrote:
> > Notamment lors de la transformation de couleur (passage de RGB à YUV > > sous-échantillonné, même principe qu le MPEG), puis en DCT et en > > Quntification. > > La transformation de couleur est optionnelle, on peut tout à fait > utiliser JPEG sur chacune des composantes d'origine (RGB, CMYK, ...).
C'est bien possible, je ne connais pas en détail la spécification.
C'est peu utilisé en pratique, car la compression est moins bonne. On voit clairement en regardant les composantes R, G et B qu'il y a beaucoup de redondance entre-elles. Il est donc avantageux de passer dans une représentation luminance / chrominance. Ainsi, un fichier JPEG standard travaille sur une image Y Cb Cr (c'est imposé par le format JFIF), et utilise deux tables de quantification différentes, un pour Y, et une pour Cb et Cr.
Mais l'algorithme lui-même est "color blind", il fonctionne de la même manière sur tous les types de composantes. J'ai a une époque travaillé sur un implémentation qui traitait directement les composantes R, G e B.
> En pratique, ce que l'on appelle fichier JPEG, c'est dans l'immense > majorité des cas un fichier JFIF, qui encode l'image en YCbCr 4:2:0.
Donc avec transformation de couleurs en 4:2:0 on perd 33% de l'information (avant les autres opérations), c'est un sous-échantillonnage sur les couleurs. <http://www.garage-video.com/spec/YUV.html>
On perd 50 %. Si on a N pixels, on a N pixels dans chaque composante R, G et B, donc 3N pixels. Après la conversion, on aura N pixels Y, N/4 pixels Cb et N/4 pixels Cr, donc 1.5 N pixels en tout, soit la moitié.
Patrick -- Patrick Stadelmann
In article <1jr2xjt.1x3wfa21ou8u41N%pdorange@pas-de-pub-merci.mac.com>,
pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> > Notamment lors de la transformation de couleur (passage de RGB à YUV
> > sous-échantillonné, même principe qu le MPEG), puis en DCT et en
> > Quntification.
>
> La transformation de couleur est optionnelle, on peut tout à fait
> utiliser JPEG sur chacune des composantes d'origine (RGB, CMYK, ...).
C'est bien possible, je ne connais pas en détail la spécification.
C'est peu utilisé en pratique, car la compression est moins bonne. On
voit clairement en regardant les composantes R, G et B qu'il y a
beaucoup de redondance entre-elles. Il est donc avantageux de passer
dans une représentation luminance / chrominance. Ainsi, un fichier JPEG
standard travaille sur une image Y Cb Cr (c'est imposé par le format
JFIF), et utilise deux tables de quantification différentes, un pour Y,
et une pour Cb et Cr.
Mais l'algorithme lui-même est "color blind", il fonctionne de la même
manière sur tous les types de composantes. J'ai a une époque travaillé
sur un implémentation qui traitait directement les composantes R, G e B.
> En pratique, ce que l'on appelle fichier JPEG, c'est dans l'immense
> majorité des cas un fichier JFIF, qui encode l'image en YCbCr 4:2:0.
Donc avec transformation de couleurs en 4:2:0 on perd 33% de
l'information (avant les autres opérations), c'est un
sous-échantillonnage sur les couleurs.
<http://www.garage-video.com/spec/YUV.html>
On perd 50 %. Si on a N pixels, on a N pixels dans chaque composante R,
G et B, donc 3N pixels. Après la conversion, on aura N pixels Y, N/4
pixels Cb et N/4 pixels Cr, donc 1.5 N pixels en tout, soit la moitié.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jr2xjt.1x3wfa21ou8u41N%, (Pierre-Alain Dorange) wrote:
Patrick Stadelmann wrote:
> > Notamment lors de la transformation de couleur (passage de RGB à YUV > > sous-échantillonné, même principe qu le MPEG), puis en DCT et en > > Quntification. > > La transformation de couleur est optionnelle, on peut tout à fait > utiliser JPEG sur chacune des composantes d'origine (RGB, CMYK, ...).
C'est bien possible, je ne connais pas en détail la spécification.
C'est peu utilisé en pratique, car la compression est moins bonne. On voit clairement en regardant les composantes R, G et B qu'il y a beaucoup de redondance entre-elles. Il est donc avantageux de passer dans une représentation luminance / chrominance. Ainsi, un fichier JPEG standard travaille sur une image Y Cb Cr (c'est imposé par le format JFIF), et utilise deux tables de quantification différentes, un pour Y, et une pour Cb et Cr.
Mais l'algorithme lui-même est "color blind", il fonctionne de la même manière sur tous les types de composantes. J'ai a une époque travaillé sur un implémentation qui traitait directement les composantes R, G e B.
> En pratique, ce que l'on appelle fichier JPEG, c'est dans l'immense > majorité des cas un fichier JFIF, qui encode l'image en YCbCr 4:2:0.
Donc avec transformation de couleurs en 4:2:0 on perd 33% de l'information (avant les autres opérations), c'est un sous-échantillonnage sur les couleurs. <http://www.garage-video.com/spec/YUV.html>
On perd 50 %. Si on a N pixels, on a N pixels dans chaque composante R, G et B, donc 3N pixels. Après la conversion, on aura N pixels Y, N/4 pixels Cb et N/4 pixels Cr, donc 1.5 N pixels en tout, soit la moitié.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1jr2yy2.6aofhd17lc9vdN%, (Tardigradus) wrote:
Patrick Stadelmann wrote:
> une partie de l'information est présente de > manière redondante dans tous les pixels
Comme quoi ? Si tous les pixels concernés dans le bloc de 8 par 8 ont le même niveau de rouge, par exemple, ou du moins un niveau minimum commun.
L'hypothèse est que dans une image "naturelle", en effet les valeurs des 8x8 pixels sera souvent proche. Cela veut entre autre dire que la valeur moyenne est d'une manière présente dans tous les pixels. Après la transformation, elle se retrouve uniquement dans le premier coefficient. Ainsi, en diminuant (par exemple) uniquement ce coefficient avant de faire la transformée inverse, on aura la même image mais plus sombre, i.e. on aura modifié les 64 coefficients.
? Et la DCT ne leur laisserait que la différence entre eux ? Un truc dans ce goût là ?
Oui, il y a ça. En fait, on peu voir la DCT comme une représentation de l'image selon ses composante en fréquence. Le premier coefficient, la composante continue, donne la valeur moyenne. Les coefficients suivants indique comment l'image change à une fréquence spatiale donnée.
Ainsi, un bloc de gris uniforme aura 1 coefficient non nul dépendant de l'intensité, et 63 coefficient nul.
Un bloc avec une variation lente aura quelques coefficients non nuls (basse fréquence).
Une bloc avec des changements rapide (pixels adjacent passant de gris très foncé à gris très clair) aura des valeurs importantes dans les coefficients de rang plus élevés. En théorie, si l'intensité évolue selon une fonction sinusoïdale, alors un seul coefficient sera non nul, celui correspondant à la fréquence du sinus.
A noter aussi qu'en travaillant sur ces blocs de 8x8, il reste de la redondance entre les blocs (leur premier coefficient aura une valeur proche). Pour ces coefficient, seule la différence est codée. On a ainsi des nombres plus petits à encoder. Par exemple, au lieu de 12 13 16 15, on aura 12 1 3 -1.
Patrick -- Patrick Stadelmann
In article
<1jr2yy2.6aofhd17lc9vdN%patrick.1200RTcazaux@cadratin.fr.invalid>,
patrick.1200RTcazaux@cadratin.fr.invalid (Tardigradus) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> une partie de l'information est présente de
> manière redondante dans tous les pixels
Comme quoi ? Si tous les pixels concernés dans le bloc de 8 par 8 ont le
même niveau de rouge, par exemple, ou du moins un niveau minimum commun.
L'hypothèse est que dans une image "naturelle", en effet les valeurs des
8x8 pixels sera souvent proche. Cela veut entre autre dire que la valeur
moyenne est d'une manière présente dans tous les pixels. Après la
transformation, elle se retrouve uniquement dans le premier coefficient.
Ainsi, en diminuant (par exemple) uniquement ce coefficient avant de
faire la transformée inverse, on aura la même image mais plus sombre,
i.e. on aura modifié les 64 coefficients.
? Et la DCT ne leur laisserait que la différence entre eux ? Un truc
dans ce goût là ?
Oui, il y a ça. En fait, on peu voir la DCT comme une représentation de
l'image selon ses composante en fréquence. Le premier coefficient, la
composante continue, donne la valeur moyenne. Les coefficients suivants
indique comment l'image change à une fréquence spatiale donnée.
Ainsi, un bloc de gris uniforme aura 1 coefficient non nul dépendant de
l'intensité, et 63 coefficient nul.
Un bloc avec une variation lente aura quelques coefficients non nuls
(basse fréquence).
Une bloc avec des changements rapide (pixels adjacent passant de gris
très foncé à gris très clair) aura des valeurs importantes dans les
coefficients de rang plus élevés. En théorie, si l'intensité évolue
selon une fonction sinusoïdale, alors un seul coefficient sera non nul,
celui correspondant à la fréquence du sinus.
A noter aussi qu'en travaillant sur ces blocs de 8x8, il reste de la
redondance entre les blocs (leur premier coefficient aura une valeur
proche). Pour ces coefficient, seule la différence est codée. On a ainsi
des nombres plus petits à encoder. Par exemple, au lieu de 12 13 16 15,
on aura 12 1 3 -1.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jr2yy2.6aofhd17lc9vdN%, (Tardigradus) wrote:
Patrick Stadelmann wrote:
> une partie de l'information est présente de > manière redondante dans tous les pixels
Comme quoi ? Si tous les pixels concernés dans le bloc de 8 par 8 ont le même niveau de rouge, par exemple, ou du moins un niveau minimum commun.
L'hypothèse est que dans une image "naturelle", en effet les valeurs des 8x8 pixels sera souvent proche. Cela veut entre autre dire que la valeur moyenne est d'une manière présente dans tous les pixels. Après la transformation, elle se retrouve uniquement dans le premier coefficient. Ainsi, en diminuant (par exemple) uniquement ce coefficient avant de faire la transformée inverse, on aura la même image mais plus sombre, i.e. on aura modifié les 64 coefficients.
? Et la DCT ne leur laisserait que la différence entre eux ? Un truc dans ce goût là ?
Oui, il y a ça. En fait, on peu voir la DCT comme une représentation de l'image selon ses composante en fréquence. Le premier coefficient, la composante continue, donne la valeur moyenne. Les coefficients suivants indique comment l'image change à une fréquence spatiale donnée.
Ainsi, un bloc de gris uniforme aura 1 coefficient non nul dépendant de l'intensité, et 63 coefficient nul.
Un bloc avec une variation lente aura quelques coefficients non nuls (basse fréquence).
Une bloc avec des changements rapide (pixels adjacent passant de gris très foncé à gris très clair) aura des valeurs importantes dans les coefficients de rang plus élevés. En théorie, si l'intensité évolue selon une fonction sinusoïdale, alors un seul coefficient sera non nul, celui correspondant à la fréquence du sinus.
A noter aussi qu'en travaillant sur ces blocs de 8x8, il reste de la redondance entre les blocs (leur premier coefficient aura une valeur proche). Pour ces coefficient, seule la différence est codée. On a ainsi des nombres plus petits à encoder. Par exemple, au lieu de 12 13 16 15, on aura 12 1 3 -1.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <1jr2yy2.6aofhd17lc9vdN%, (Tardigradus) wrote:
Patrick Stadelmann wrote:
> une partie de l'information est présente de > manière redondante dans tous les pixels
Comme quoi ? Si tous les pixels concernés dans le bloc de 8 par 8 ont le même niveau de rouge, par exemple, ou du moins un niveau minimum commun.
L'hypothèse est que dans une image "naturelle", en effet les valeurs des 8x8 pixels sera souvent proche. Cela veut entre autre dire que la valeur moyenne est d'une manière présente dans tous les pixels. Après la transformation, elle se retrouve uniquement dans le premier coefficient. Ainsi, en diminuant (par exemple) uniquement ce coefficient avant de faire la transformée inverse, on aura la même image mais plus sombre, i.e. on aura modifié les 64 pixels.
? Et la DCT ne leur laisserait que la différence entre eux ? Un truc dans ce goût là ?
Oui, il y a ça. En fait, on peu voir la DCT comme une représentation de l'image selon ses composante en fréquence. Le premier coefficient, la composante continue, donne la valeur moyenne. Les coefficients suivants indique comment l'image change à une fréquence spatiale donnée.
Ainsi, un bloc de gris uniforme aura 1 coefficient non nul dépendant de l'intensité, et 63 coefficient nul.
Un bloc avec une variation lente aura quelques coefficients non nuls (basse fréquence).
Une bloc avec des changements rapide (pixels adjacent passant de gris très foncé à gris très clair) aura des valeurs importantes dans les coefficients de rang plus élevés. En théorie, si l'intensité évolue selon une fonction sinusoïdale, alors un seul coefficient sera non nul, celui correspondant à la fréquence du sinus.
A noter aussi qu'en travaillant sur ces blocs de 8x8, il reste de la redondance entre les blocs (leur premier coefficient aura une valeur proche). Pour ces coefficient, seule la différence est codée. On a ainsi des nombres plus petits à encoder. Par exemple, au lieu de 12 13 16 15, on aura 12 1 3 -1.
Patrick -- Patrick Stadelmann
In article
<1jr2yy2.6aofhd17lc9vdN%patrick.1200RTcazaux@cadratin.fr.invalid>,
patrick.1200RTcazaux@cadratin.fr.invalid (Tardigradus) wrote:
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
> une partie de l'information est présente de
> manière redondante dans tous les pixels
Comme quoi ? Si tous les pixels concernés dans le bloc de 8 par 8 ont le
même niveau de rouge, par exemple, ou du moins un niveau minimum commun.
L'hypothèse est que dans une image "naturelle", en effet les valeurs des
8x8 pixels sera souvent proche. Cela veut entre autre dire que la valeur
moyenne est d'une manière présente dans tous les pixels. Après la
transformation, elle se retrouve uniquement dans le premier coefficient.
Ainsi, en diminuant (par exemple) uniquement ce coefficient avant de
faire la transformée inverse, on aura la même image mais plus sombre,
i.e. on aura modifié les 64 pixels.
? Et la DCT ne leur laisserait que la différence entre eux ? Un truc
dans ce goût là ?
Oui, il y a ça. En fait, on peu voir la DCT comme une représentation de
l'image selon ses composante en fréquence. Le premier coefficient, la
composante continue, donne la valeur moyenne. Les coefficients suivants
indique comment l'image change à une fréquence spatiale donnée.
Ainsi, un bloc de gris uniforme aura 1 coefficient non nul dépendant de
l'intensité, et 63 coefficient nul.
Un bloc avec une variation lente aura quelques coefficients non nuls
(basse fréquence).
Une bloc avec des changements rapide (pixels adjacent passant de gris
très foncé à gris très clair) aura des valeurs importantes dans les
coefficients de rang plus élevés. En théorie, si l'intensité évolue
selon une fonction sinusoïdale, alors un seul coefficient sera non nul,
celui correspondant à la fréquence du sinus.
A noter aussi qu'en travaillant sur ces blocs de 8x8, il reste de la
redondance entre les blocs (leur premier coefficient aura une valeur
proche). Pour ces coefficient, seule la différence est codée. On a ainsi
des nombres plus petits à encoder. Par exemple, au lieu de 12 13 16 15,
on aura 12 1 3 -1.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1jr2yy2.6aofhd17lc9vdN%, (Tardigradus) wrote:
Patrick Stadelmann wrote:
> une partie de l'information est présente de > manière redondante dans tous les pixels
Comme quoi ? Si tous les pixels concernés dans le bloc de 8 par 8 ont le même niveau de rouge, par exemple, ou du moins un niveau minimum commun.
L'hypothèse est que dans une image "naturelle", en effet les valeurs des 8x8 pixels sera souvent proche. Cela veut entre autre dire que la valeur moyenne est d'une manière présente dans tous les pixels. Après la transformation, elle se retrouve uniquement dans le premier coefficient. Ainsi, en diminuant (par exemple) uniquement ce coefficient avant de faire la transformée inverse, on aura la même image mais plus sombre, i.e. on aura modifié les 64 pixels.
? Et la DCT ne leur laisserait que la différence entre eux ? Un truc dans ce goût là ?
Oui, il y a ça. En fait, on peu voir la DCT comme une représentation de l'image selon ses composante en fréquence. Le premier coefficient, la composante continue, donne la valeur moyenne. Les coefficients suivants indique comment l'image change à une fréquence spatiale donnée.
Ainsi, un bloc de gris uniforme aura 1 coefficient non nul dépendant de l'intensité, et 63 coefficient nul.
Un bloc avec une variation lente aura quelques coefficients non nuls (basse fréquence).
Une bloc avec des changements rapide (pixels adjacent passant de gris très foncé à gris très clair) aura des valeurs importantes dans les coefficients de rang plus élevés. En théorie, si l'intensité évolue selon une fonction sinusoïdale, alors un seul coefficient sera non nul, celui correspondant à la fréquence du sinus.
A noter aussi qu'en travaillant sur ces blocs de 8x8, il reste de la redondance entre les blocs (leur premier coefficient aura une valeur proche). Pour ces coefficient, seule la différence est codée. On a ainsi des nombres plus petits à encoder. Par exemple, au lieu de 12 13 16 15, on aura 12 1 3 -1.
