"Philippe LAGARDE" a écrit dans le message de news:1t2ntjpg8ls88.1ix963c0ggzbl$
Le JPEG travaille sur des matrices 8x8. Donc si tu changes un pixel, une seule matrice sera recalculée, et le reste ne sera pas changé (si tu restes
à la même compression bien évidemment).
Oui, le changement d'une matrice 8x8 n'affecte pas les autres.
De plus, dans cette matrice, l'apparition d'un pixel mal corrélé avec ses voisins ne peut provoquer qu'une amélioration de la qualité de compression (car le calcul adaptatif attribuera le même nombre de bits ou plus aux éléments de la matrice).
Et effectivement, c'est un pb que de retrouver l'exact taux de compression de l'appareil photo avec un logiciel de retouche. C'est pour cela qu'il faut garder les originaux et utiliser les softs de capture (par ex zoom-browser) qui permettent de redresser les images sans en changer la compression.
"Philippe LAGARDE" <philippeNOSPAM@mise-en-lumiere.org.invalid> a écrit dans
le message de news:1t2ntjpg8ls88.1ix963c0ggzbl$.dlg@40tude.net...
Le JPEG travaille sur des matrices 8x8. Donc si tu changes un pixel, une
seule matrice sera recalculée, et le reste ne sera pas changé (si tu
restes
à la même compression bien évidemment).
Oui, le changement d'une matrice 8x8 n'affecte pas les autres.
De plus, dans cette matrice, l'apparition d'un pixel mal corrélé avec ses
voisins ne peut provoquer qu'une amélioration de la qualité de compression
(car le calcul adaptatif attribuera le même nombre de bits ou plus aux
éléments de la matrice).
Et effectivement, c'est un pb que de retrouver l'exact taux de compression
de l'appareil photo avec un logiciel de retouche.
C'est pour cela qu'il faut garder les originaux et utiliser les softs de
capture (par ex zoom-browser) qui permettent de redresser les images sans en
changer la compression.
"Philippe LAGARDE" a écrit dans le message de news:1t2ntjpg8ls88.1ix963c0ggzbl$
Le JPEG travaille sur des matrices 8x8. Donc si tu changes un pixel, une seule matrice sera recalculée, et le reste ne sera pas changé (si tu restes
à la même compression bien évidemment).
Oui, le changement d'une matrice 8x8 n'affecte pas les autres.
De plus, dans cette matrice, l'apparition d'un pixel mal corrélé avec ses voisins ne peut provoquer qu'une amélioration de la qualité de compression (car le calcul adaptatif attribuera le même nombre de bits ou plus aux éléments de la matrice).
Et effectivement, c'est un pb que de retrouver l'exact taux de compression de l'appareil photo avec un logiciel de retouche. C'est pour cela qu'il faut garder les originaux et utiliser les softs de capture (par ex zoom-browser) qui permettent de redresser les images sans en changer la compression.
Peter Pan
A mon avis, pour traiter ce genre de cas, il y a un changement d'algorithme car la transformée en cosinus discrête est à l'ouest.
Ce que l'aiguille de la boussole est au nord. Huh ! Clair !
-- Pierre ;-) http://www.ppan.net http://www.pasbanal.com
A mon avis, pour traiter ce genre de cas, il y a un changement
d'algorithme car la transformée en cosinus discrête est à l'ouest.
Ce que l'aiguille de la boussole est au nord. Huh ! Clair !
--
Pierre ;-)
http://www.ppan.net
http://www.pasbanal.com
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:4087fe6b$0$17619$
ai je parlé de révolution ? non. la seule chose remarquable est que cette technique est associée à un soft de
traitement des pixels dits "morts", "véritable cauchemard" pour le photographe maniaque... (que je ne suis pas).
bof, j'ai cru lire ici et la qu'il y avait d'autres maniaques qui ne souffraient pourtant pas cette maladie la.
Alf92
arkanode a exposé ceci :
C'est pour cela qu'il faut garder les originaux et utiliser les softs de capture (par ex zoom-browser) qui permettent de redresser les images sans en changer la compression.
des "basiques" comme ACDSee le permettent. -- Cordialement, Alf92
arkanode a exposé ceci :
C'est pour cela qu'il faut garder les originaux et utiliser les softs
de capture (par ex zoom-browser) qui permettent de redresser les
images sans en changer la compression.
des "basiques" comme ACDSee le permettent.
--
Cordialement,
Alf92
C'est pour cela qu'il faut garder les originaux et utiliser les softs de capture (par ex zoom-browser) qui permettent de redresser les images sans en changer la compression.
des "basiques" comme ACDSee le permettent. -- Cordialement, Alf92
arkanode
"arkanode" a écrit dans le message de news:c69an0$h6i$
De plus, dans cette matrice, l'apparition d'un pixel mal corrélé avec ses voisins ne peut provoquer qu'une amélioration de la qualité de compression (car le calcul adaptatif attribuera le même nombre de bits ou plus aux éléments de la matrice).
Attention au paradoxe suivant:
La qualité de compression s'améliore (moins de pertes), mais effectivement, les pixels voisins peuvent être pollués...
"arkanode" <nospam@please.fr> a écrit dans le message de
news:c69an0$h6i$1@news-reader2.wanadoo.fr...
De plus, dans cette matrice, l'apparition d'un pixel mal corrélé avec ses
voisins ne peut provoquer qu'une amélioration de la qualité de compression
(car le calcul adaptatif attribuera le même nombre de bits ou plus aux
éléments de la matrice).
Attention au paradoxe suivant:
La qualité de compression s'améliore (moins de pertes), mais effectivement,
les pixels voisins peuvent être pollués...
"arkanode" a écrit dans le message de news:c69an0$h6i$
De plus, dans cette matrice, l'apparition d'un pixel mal corrélé avec ses voisins ne peut provoquer qu'une amélioration de la qualité de compression (car le calcul adaptatif attribuera le même nombre de bits ou plus aux éléments de la matrice).
Attention au paradoxe suivant:
La qualité de compression s'améliore (moins de pertes), mais effectivement, les pixels voisins peuvent être pollués...
Alf92
arkanode a exposé ceci :
bof, j'ai cru lire ici et la qu'il y avait d'autres maniaques qui ne souffraient pourtant pas cette maladie la.
bin oui. bien triste... c'est plus marrant les matrices 4x4 recalculées par cosinus inversé, la lune entrant dans le sagittaire début juillet. ;o) sans dec tes explications j'ai rien bité... t'es super calé ou c'est du flan ? de toute manière tu peux me faire gober n'importe quoi (ou presque), les maths c'est pas mon domaine. -- Cordialement, Alf92
arkanode a exposé ceci :
bof, j'ai cru lire ici et la qu'il y avait d'autres maniaques qui ne
souffraient pourtant pas cette maladie la.
bin oui.
bien triste... c'est plus marrant les matrices 4x4 recalculées par cosinus
inversé, la lune entrant dans le sagittaire début juillet. ;o)
sans dec tes explications j'ai rien bité... t'es super calé ou c'est du flan
?
de toute manière tu peux me faire gober n'importe quoi (ou presque), les
maths c'est pas mon domaine.
--
Cordialement,
Alf92
bof, j'ai cru lire ici et la qu'il y avait d'autres maniaques qui ne souffraient pourtant pas cette maladie la.
bin oui. bien triste... c'est plus marrant les matrices 4x4 recalculées par cosinus inversé, la lune entrant dans le sagittaire début juillet. ;o) sans dec tes explications j'ai rien bité... t'es super calé ou c'est du flan ? de toute manière tu peux me faire gober n'importe quoi (ou presque), les maths c'est pas mon domaine. -- Cordialement, Alf92
Alf92
arkanode a exposé ceci :
Attention au paradoxe suivant:
La qualité de compression s'améliore (moins de pertes), mais effectivement, les pixels voisins peuvent être pollués...
il fallait le rappeler en effet... -- Cordialement, Alf92
arkanode a exposé ceci :
Attention au paradoxe suivant:
La qualité de compression s'améliore (moins de pertes), mais
effectivement, les pixels voisins peuvent être pollués...
il fallait le rappeler en effet...
--
Cordialement,
Alf92
La qualité de compression s'améliore (moins de pertes), mais effectivement, les pixels voisins peuvent être pollués...
il fallait le rappeler en effet... -- Cordialement, Alf92
arkanode
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:40882fcd$0$17619$
arkanode a exposé ceci : bien triste... c'est plus marrant les matrices 4x4 recalculées par cosinus inversé, la lune entrant dans le sagittaire début juillet. ;o) sans dec tes explications j'ai rien bité... t'es super calé ou c'est du flan
? de toute manière tu peux me faire gober n'importe quoi (ou presque), les maths c'est pas mon domaine.
Je suis en train de chercher des liens sur google pour indiquer de la littérature mais visiblement, il faut passer à l'Anglais:
http://www.charithmetic.org/abstracts/finalpcs03dct.pdf dans celui ci, on trouve une référence à la représentation en diagrammes papillons...
http://www.faqs.org/faqs/compression-faq/part1/section-19.html dans ce dernier, on trouve ceci, qui est aussi intéressant:
Lossless JPEG:
The separate lossless mode does not use DCT, since roundoff errors prevent a DCT calculation from being lossless. For the same reason, one would not normally use colorspace conversion or downsampling, although these are permitted by the standard. The lossless mode simply codes the difference between each pixel and the "predicted" value for the pixel. The predicted value is a simple function of the already-transmitted pixels just above and to the left of the current one (for example, their average; 8 different predictor functions are permitted). The sequence of differences is encoded using the same back end (Huffman or arithmetic) used in the lossy mode.
Lossless JPEG with the Huffman back end is certainly not a state-of-the-art lossless compression method, and wasn't even when it was introduced. The arithmetic-coding back end may make it competitive, but you're probably best off looking at other methods if you need only lossless compression.
The main reason for providing a lossless option is that it makes a good adjunct to the hierarchical mode: the final scan in a hierarchical sequence can be a lossless coding of the remaining differences, to achieve overall losslessness. This isn't quite as useful as it may at first appear, because exact losslessness is not guaranteed unless the encoder and decoder have identical IDCT implementations (ie, identical roundoff errors). And you can't use downsampling or colorspace conversion either if you want true losslessness. But in some applications the combination is useful.
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de
news:40882fcd$0$17619$636a15ce@news.free.fr...
arkanode a exposé ceci :
bien triste... c'est plus marrant les matrices 4x4 recalculées par cosinus
inversé, la lune entrant dans le sagittaire début juillet. ;o)
sans dec tes explications j'ai rien bité... t'es super calé ou c'est du
flan
?
de toute manière tu peux me faire gober n'importe quoi (ou presque), les
maths c'est pas mon domaine.
Je suis en train de chercher des liens sur google pour indiquer de la
littérature mais visiblement, il faut passer à l'Anglais:
http://www.charithmetic.org/abstracts/finalpcs03dct.pdf
dans celui ci, on trouve une référence à la représentation en diagrammes
papillons...
http://www.faqs.org/faqs/compression-faq/part1/section-19.html
dans ce dernier, on trouve ceci, qui est aussi intéressant:
Lossless JPEG:
The separate lossless mode does not use DCT, since roundoff errors prevent a
DCT calculation from being lossless. For the same reason, one would not
normally use colorspace conversion or downsampling, although these are
permitted by the standard. The lossless mode simply codes the difference
between each pixel and the "predicted" value for the pixel. The predicted
value is a simple function of the already-transmitted pixels just above and
to the left of the current one (for example, their average; 8 different
predictor functions are permitted). The sequence of differences is encoded
using the same back end (Huffman or arithmetic) used in the lossy mode.
Lossless JPEG with the Huffman back end is certainly not a state-of-the-art
lossless compression method, and wasn't even when it was introduced. The
arithmetic-coding back end may make it competitive, but you're probably best
off looking at other methods if you need only lossless compression.
The main reason for providing a lossless option is that it makes a good
adjunct to the hierarchical mode: the final scan in a hierarchical sequence
can be a lossless coding of the remaining differences, to achieve overall
losslessness. This isn't quite as useful as it may at first appear, because
exact losslessness is not guaranteed unless the encoder and decoder have
identical IDCT implementations (ie, identical roundoff errors). And you
can't use downsampling or colorspace conversion either if you want true
losslessness. But in some applications the combination is useful.
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:40882fcd$0$17619$
arkanode a exposé ceci : bien triste... c'est plus marrant les matrices 4x4 recalculées par cosinus inversé, la lune entrant dans le sagittaire début juillet. ;o) sans dec tes explications j'ai rien bité... t'es super calé ou c'est du flan
? de toute manière tu peux me faire gober n'importe quoi (ou presque), les maths c'est pas mon domaine.
Je suis en train de chercher des liens sur google pour indiquer de la littérature mais visiblement, il faut passer à l'Anglais:
http://www.charithmetic.org/abstracts/finalpcs03dct.pdf dans celui ci, on trouve une référence à la représentation en diagrammes papillons...
http://www.faqs.org/faqs/compression-faq/part1/section-19.html dans ce dernier, on trouve ceci, qui est aussi intéressant:
Lossless JPEG:
The separate lossless mode does not use DCT, since roundoff errors prevent a DCT calculation from being lossless. For the same reason, one would not normally use colorspace conversion or downsampling, although these are permitted by the standard. The lossless mode simply codes the difference between each pixel and the "predicted" value for the pixel. The predicted value is a simple function of the already-transmitted pixels just above and to the left of the current one (for example, their average; 8 different predictor functions are permitted). The sequence of differences is encoded using the same back end (Huffman or arithmetic) used in the lossy mode.
Lossless JPEG with the Huffman back end is certainly not a state-of-the-art lossless compression method, and wasn't even when it was introduced. The arithmetic-coding back end may make it competitive, but you're probably best off looking at other methods if you need only lossless compression.
The main reason for providing a lossless option is that it makes a good adjunct to the hierarchical mode: the final scan in a hierarchical sequence can be a lossless coding of the remaining differences, to achieve overall losslessness. This isn't quite as useful as it may at first appear, because exact losslessness is not guaranteed unless the encoder and decoder have identical IDCT implementations (ie, identical roundoff errors). And you can't use downsampling or colorspace conversion either if you want true losslessness. But in some applications the combination is useful.
arkanode
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:40882b48$0$17623$
arkanode a exposé ceci :
[...]
Fichtre... -- Cordialement, Alf92
Attention, l'exemple que j'ai donné était démonstratif mais pas tout à fait exact, en l'occurrence, je pense que ceci est plus vrai:
ex: transormée en cosinus: 5 3 3 1 ->transformée en cos suivant les x 4 1 2 1 puis suivant les y 3 1 1 0
On voit aussi que l'on peut faire des erreurs en choisissant une matrice de quantification (compression) mais aussi des erreurs de quantification à chaque calcul car on peut avoir des coefficients des cosinus non entiers...
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de
news:40882b48$0$17623$636a15ce@news.free.fr...
arkanode a exposé ceci :
[...]
Fichtre...
--
Cordialement,
Alf92
Attention, l'exemple que j'ai donné était démonstratif mais pas tout à fait
exact, en l'occurrence, je pense que ceci est plus vrai:
ex: transormée en cosinus:
5 3
3 1
->transformée en cos suivant les x
4 1
2 1
puis suivant les y
3 1
1 0
On voit aussi que l'on peut faire des erreurs en choisissant une matrice de
quantification (compression) mais aussi des erreurs de quantification à
chaque calcul car on peut avoir des coefficients des cosinus non entiers...
"Alf92" <alf92[NO-SPAM]@freesurf.fr> a écrit dans le message de news:40882b48$0$17623$
arkanode a exposé ceci :
[...]
Fichtre... -- Cordialement, Alf92
Attention, l'exemple que j'ai donné était démonstratif mais pas tout à fait exact, en l'occurrence, je pense que ceci est plus vrai:
ex: transormée en cosinus: 5 3 3 1 ->transformée en cos suivant les x 4 1 2 1 puis suivant les y 3 1 1 0
On voit aussi que l'on peut faire des erreurs en choisissant une matrice de quantification (compression) mais aussi des erreurs de quantification à chaque calcul car on peut avoir des coefficients des cosinus non entiers...
