🚀 go-pugleaf

"METIS" a �crit :

> ===> Regarde ma r�ponse � Patrick Stadelmann...

Pour faire avancer le Smilili, le Ssmblili, le Schmilllilbli, le...
enfin le truc, je reposte un message de Gerard Guenin sur
fr.rec.photo.numerique :

J'explique le peu que je sais (et ne me demandez pas de d�tails
math�matiques, j'y suis allergique)

- La compression JPEG travaille sur des blocs de 8 x 8 pixels RVB.
(en fait, le travail s'effectue plut�t sur des blocs Y,Cb,Cr plut�t que
RVB qui permettent d�j� une diminution des infos de couleur pratiquement
invisible)

Phase 1:
- Les 3 x 64 �l�ments subissent une transformation math�matique (cosinus
discret) qui produit 3 x 64 coefficients.

Phase 2:
- Les 3 x 64 coefficients subissent alors une op�ration de seuillage +
quantification. C'est � ce stade que s'effectue la d�gradation de
l'image. Le but de l'op�ration est d'obtenir un maximum de coefficients
�gaux � 0.
L'image est donc d�grad�e mais occupe encore LA MEME place que les blocs
RVB d'origine !
Si, � partir de ces 3*64 coefficients ont applique la transformation
inverse, on retrouve les 64 pixels, mais d�grad�s.
Les phases de seuillage et quantification n'ont pas pour but de
compresser quoi que ce soit, mais de pr�parer la futur compression en
faisant appara�tre un maximum de coefficients nuls.
Lorqu'on choisit un taux de compression dans son logiciel de retouche,
ce sont en fait la valeur du seuil et la pr�cision de la quantification
que l'on choisit.

Phase 3:
- Suit alors une COMPRESSION de type RLC et un codage de Huffman. Ces
deux derni�res op�rations sont COMPLETEMENT r�versibles donc NON
destructrices.

La compression RLC fonctionne un peu comme �a :
origine : 120 34 18 0 0 0 0 0 0 0 0 0 0 0 0 3 4 0 0 0 0 0 0 0
compress�e : 252 120 34 18 12 253 3 4 7
D�compression :
252 octet de contr�le : 255-252 : lire directement les 3 octets suivant
12 : mettre 12 z�ro
253 octet de contr�le : 255-253 : lire les 2 octets suivants
7 : mettre 7 z�ro

De 24 octets ont est pass� � 9 sans perte.

(C'est un exemple, je ne connais pas le type exact du codage RLC retenu
pour le JPEG.)

Le codage de huffman sert � am�liorer la compression. C'est un codage
probabiliste � longueur variable. En gros on code sur un petit nombre de
bits les valeurs dont la probabilit� d'apparition est importante et sur
un grand nombre de bits celles dont la probabilit� d'apparition est la
plus faible. (un peu comme le morse qui code le E avec un seul point et
le Q avec une suite trait, trait, point, trait)

Conclusion :

La rotation JPEG sans perte s'explique alors tr�s bien. On remonte
jusqu'aux 3 * 64 coefficients quantifi�s (fin de phase 2), on d�place
les blocs, et
chaque bloc est "tourn�" . Ensuite recompression RLC.

Le paradoxe de tout �a est que l'algorithme de compression utilis�e dans
le JPEG est non destructeur, alors que l'ensemble du processus l'est.

Fin de citation.

> > Lors d'une pr�c�dente discussion sur le sujet et pour me convaincre
> > du bien fond� de la th�orie, j'ai r�alis� un petit script qui a
> > recharg� et resauv� 400 fois la m�me image (en JPEG Q "presque"
> > Max) et ben, la derni�re est toujours tr�s semblable � la
> > premi�re...
>
> ===> Refis-le en compression maximale en sauvant � chaque fois si tu
> peux, pour comparer l'�volution du mal... (si tu veux bien, hein...)

D'accord, je repars en "exp�rimentation"

> <|[:o|| saute... bin saute... aller, saute... ??? quand tu arraches
> > les pattes d'une puce, elle devient sourde !

Tortionnaire... En fait, j'aime pas les puces... Vas-y renouvelle
l'exp�rience !

Je l'ai pas dit, je l'ai pas dit, youpiiie, je suis gu�ri !

Aspirine.

Merde...

--
Jean-Claude Ghislain
www.grimart.com