Compression

Services de tlinformatique 23
CHAPITRE 2 Compression de donnes

sans pertes
Ce chapitre est en partie loeuvre de MM. S.Maadi, Y. Peneveyre, et
C. Lambercy, tudiants en tlcommunications de dernire anne. Mes cha-
leureux remerciements ces tudiants pour leur remarquable travail.
eivd Tlcommunications mjn
24 Services de tlinformatique
2.1 Introduction
La compression est l'action utilise pour rduire la taille physique d'un bloc d'informa-
tion. En compressant des donnes, on peut placer plus d'informations dans le mme espace
de stockage, ou utiliser moins de temps pour le transfert au travers dun rseau tlinformati-
que. Parce que gnralement les images requirent une place importante, la compression est
devenue part intgrante des donnes graphiques. Presque tous les formats de fichiers graphi-
ques utilisent l'une ou l'autre mthode de compression.
On rencontre souvent la compression de donnes comme tant une partie de l'encodage
de donnes au mme titre que le cryptage de donnes (cryptographie) et la transmission de
donnes. Les modems actuels utilisent systmatiquement la compression pour atteindre des
performances qui, autrement, se limiteraient du ct de 14 kbit/s.
Presque chaque format de fichier incorpore l'une ou l'autre mthode de compression.
Parmi les plus connues de ces mthodes, on peut citer :
Pixel Packing : Ce n'est pas rellement une mthode de compression mais une manire
efficace d'enregistrer des donnes de manire contigus en mmoire. Cette mthode est
utilise par le format PICT de Macintosh et par d'autres formats qui sont capable d'enre-
gistrer plusieurs pixels (1, 2 ou 4) par byte en mmoire ou sur le disque.
Run Length Encoding (RLE) : C'est un algorithme de compression extrmement rpandu
utilis par des formats bitmaps tels que BMP, TIFF et PCX dans le but de rduire le taux
de donnes graphiques redondantes.
CCITT encoding : C'est une forme de compression de donnes utilise pour la transmis-
sion de fax et standardise par le CCITT (International Telegraph Telephone Consultative
Committee). Ce standard est bas sur le schma de compression statique introduit par
David Huffman et plus largement connu sous l'appellation de codage de Huffman.
Lempel-Ziv (LZ77, LZ78), Lempel-Ziv-Welch (LZW) : Utilis par des formats de
fichiers tels que GIF et TIFF . Cet algorithme est une partie du standard de compression
pour modem V42bis et de Postscript niveau 2. Cet algorithme est aussi la base, du moins
en partie, de tous les algorithmes de compactage modernes.
Joint Photographic Experts Group (JPEG) : Un standard de compression de donnes uti-
lis particulirement pour des images de hautes dfinitions et du multimdia. Le standard
utilise un algorithme de compression bas sur la Transforme Discrte en Cosinus (DCT),
ainsi que des compressions secondaires bases sur Huffmann, principalement.
Fractal Image Format (FIF) : Procd dvelopp par Iterated System qui consiste stocker
une image sous forme non pas de points mais de formules mathmatiques. Ainsi, l'appa-
rence d'une image dpendra uniquement du priphrique de sortie et sera indpendante de
la rsolution.
Mis part ces algorithmes de compression largement utiliss et qui ont fait leurs preu-
ves, ils en existe toute une srie qui apparaissent sous l'initiative de jeunes entreprises inno-
vatrices. On peut mentionner la trs prometteuse mthode de compression par ondelettes ou
la compression par logique floue.
2.2 Terminologie
Les termes donnes brutes (raw data) et donnes non codes (unencoded data) dsi-
gnent les donnes avant qu'elles ne soient compresses et les termes donnes codes (enco-
ded data) ou donnes compresses (compressed data) dsignent les donnes aprs qu'elles
aient t compresses.
Le terme taux de compression (compression ratio) est utilis pour se rfrer aux rap-
port entre la taille des donnes non compresses sur taille des donnes compresses. Si on
peut compresser un fichier 10 x , on parlera alors d'un taux de 10:1 ce qui signifie trs logi-
quement que sa taille a t divise par 10. Ce sera galement un critre d'efficacit entre dif-
frents algorithmes : Un algorithme ayant un taux de 10:1 sera 5 fois plus efficace qu'un
algorithme n'ayant qu'un taux de compression de 2:1.
A noter qu'il ne sera fait aucune distinction dans la suite de l'expos entre "codage" et
"compression", ce dernier terme tant un cas particulier du premier, d'une part et entre dco-
dage et dcompression d'autres part, pour les mme raisons que prcdemment.
2.2.1 Compression physique et compression logique
On considre gnralement la compression comme un algorithme capable de compri-
mer normment de donnes dans un minimum de place (compression physique), mais on
peut galement adopter une autre approche et considrer qu'en premier lieu un algorithme de
compression a pour but de recoder les donnes dans une reprsentation diffrente plus com-
pacte contenant la mme information (compression logique).
La distinction entre compression physique et logique est faite sur la base de comment
les donnes sont compresses ou plus prcisment comment est-ce que les donnes sont rar-
ranges dans une forme plus compacte.
La compression physique est excute exclusivement sur les informations contenues
dans les donnes. Cette mthode produit typiquement des rsultats incomprhensibles qui
apparemment n'ont aucun sens. Le rsultat d'un bloc de donnes compresses est plus petit
que l'original car l'algorithme de compression physique a retir la redondance qui existait
entre les donnes elles-mmes. Toutes les mthodes de compression dont nous allons traiter
sont des mthodes physiques.
La compression logique est accomplie travers le processus de substitution logique qui
consiste remplacer un symbole alphabtique, numrique ou binaire en un autre. Changer
"United State of America" en "USA" est un bon exemple de substitution logique car "USA"
est driv directement de l'information contenue dans la chane "United State of America" et
garde la mme signification. La substitution logique ne fonctionne qu'au niveau du caractre
ou plus haut et est base exclusivement sur l'information contenue l'intrieur mme des
donnes. Un autre exemple, moins heureux, de substitution logique est de remplacer 1999
par 99...
2.2.2 Compression symtrique et asymtrique
Les algorithmes de compression peuvent tre diviss en deux catgories distinctes :
symtrique et asymtrique.
Une mthode de compression symtrique utilise le mme algorithme, et demande la
mme capacit de calcul, aussi bien pour la compression que pour la dcompression. Par
exemple, une application de transmission de donnes o la compression et la dcompression
sont les deux faits en temps rels sera gnralement implmente avec un algorithme sym-
trique si l'on veut atteindre la plus grande efficacit.
Les mthodes de compression asymtriques demandent plus de travail dans une direc-
tion que dans l'autre. Normalement, l'tape de compression demande beaucoup plus de temps
et de ressources systmes que l'tape de dcompression. Dans la pratique, cela prend tout son
sens : par exemple, imaginons que nous ayons une base de donnes o les donnes seront
compresses une seule fois mais dcompresses un grand nombre de fois pour la consulta-
tion, alors on pourra certainement tolrer un temps beaucoup plus grand pour la compression,
dans le but de trouver le taux de compression le plus lev, que pour la dcompression, o l,
la vitesse est prdominante. Un algorithme asymtrique qui utilise beaucoup plus de temps
CPU pour la compression mais qui est beaucoup plus rapide la dcompression serait un bon
choix dans ce cas l. Un exemple classique est lencyclopdie Encarta de Microsoft.
Les algorithmes qui sont asymtriques dans l'autre sens sont beaucoup moins courants
mais ont quelques applications. En faisant des routines de backups de fichiers, par exemple,
on espre que la plupart des fichiers sauvegards ne seront jamais lus. Un algorithme trs
rapide la compression mais trs lent la dcompression peut tre utile dans ce cas.
2.2.3 Codage adaptatif, semi-adaptatif et non-adaptatif
Certains codeurs statiques comme le codage de Huffmann sont conus pour compres-
ser seulement des types spcifiques de donnes. Ces codages non-adaptatifs contiennent un
dictionnaire statique de chanes de caractres prdfinies qui sont connues comme apparais-
sant de grandes frquences dans les donnes encoder. Par exemple, un codeur non-adap-
tatif conu spcifiquement pour compresser la langue franaise contiendra un dictionnaire
avec des chanes de caractres telles que "et", "mais", "de", "le", car ces chanes apparaissent
trs frquemment dans les textes en franais.
Un codeur adaptatif, l'inverse n'intgrera pas de donnes relatives la frquence
d'apparitions des donnes compresser. Des compresseurs adaptatifs comme LZW ou Huff-
mann dynamique dterminent la dpendance des donnes en construisant leur dictionnaire
la vole. Ils n'ont pas de listes prdfinies de chanes de caractres par exemples mais les
construisent dynamiquement l'encodage.
La compression adaptative est capable de s'adapter n'importe quelles donnes
d'entres et de retourner une sortie avec le taux de compression le meilleur possible. C'est
une des principales diffrences avec les compressions non-adaptatives qui sont capable
d'avoir des codages efficaces uniquement avec un type de donnes d'entres trs restreint
pour lequel ils ont ts conus.
Un mlange de ces deux mthodes d'encodage l'aide de dictionnaires est la mthode
d'encodage semi-adaptative. Un encodage semi-adaptatif fait un premier passage sur les don-
nes pour construire le dictionnaire et un second passage pour effectuer l'encodage. En utili-
sant cette mthode, un dictionnaire optimal est construit avant qu'un quelconque encodage
soit effectu.
2.2.4 Compression avec et sans pertes
C'est peut-tre le critre de comparaison le plus important pour les algorithmes de com-
pression et c'est d'ailleurs pour cette raison que nous allons sparer la suite de l'expos en
fonction de celui-ci.
Une bonne partie des schmas de compression utiliss sont appels sans pertes, cela
signifie que lorsque des donnes sont compresses et ensuite dcompresses, l'information
originale contenue dans les donnes a t prserve. Aucune donne n'a t perdue ou
oublie. Les donnes n'ont pas t modifies.
La mthode de compression avec pertes quant elle "jette", de faon slective, quel-
ques donnes d'une image dans le but d'effectuer la compression avec un taux de compres-
sion meilleur que la plupart des mthodes de compression sans pertes. Les algorithmes avec
pertes sappliquent gnralement aux donnes ayant de forts taux de redondance, comme les
images, ou les sons. Certaines mthodes tirent partis d'algorithmes heuristiques labors qui
s'ajustent eux-mmes pour trouver le rapport de compression maximum possible en chan-
geant aussi peu que possible les dtails visibles d'une image. Autrement, d'autres algorithmes
moins lgants suppriment carrment la portion la moins significative de chaque pixel.
L'il humain est limit dans le nombre de couleurs qu'il est capable de percevoir
simultanment particulirement si ces couleurs ne sont pas adjacentes dans l'image ou sont
trs contrastes. Un algorithme de compression intelligent peut tenir compte de ces limita-
tions, analyser une image sur ces bases, et effectuer une rduction significative de la taille
des donnes base sur la suppression de l'information de certaines couleurs difficilement per-
ceptibles par la plupart des gens.
Dans les images en noir et blanc, chaque pixel ne peut prendre que l'une des deux cou-
leurs : noir ou blanc; mme dans ces images l, si l'on ne change que quelques pixels, la dif-
frence l'il nu sera minime.
Les termes "avec pertes" et "sans pertes" sont parfois utiliss de manire errone pour
dcrire la qualit avec laquelle une image a t compresse.
2.2.5 Rappels thoriques
On dfinit la quantit dinformation (information content, Informationsgehalt)
vhicule par un message i dune source discrte par rapport la probabilit qua chaque
symbole dapparatre dans ce message. Lunit est le Shannon (dimension fictive).
H
i
La notation lb dfinit le logarithme en base deux. Cette utilisation du logarithme en
base deux est due des raisons de commodit.
En moyenne, la source produit une quantit dinformation H gale lesprance
mathmatique des quantits dinformation convoyes par les divers messages quelle est
susceptible de gnrer :
[2.1]
La moyenne porte sur lensemble des messages, chaque message tant constitu dune
combinaison priori arbitraire de symboles choisis parmi les n disponibles.
On appelle H entropie de la source. Lentropie est maximale lorsque tous les symboles
mis par la source sont quiprobables :
[2.2]
La relation [2.1] devient alors :
[2.3]
La quantit de dcision D (decision content, Entscheidungsgehalt) est lie au nombre
de symboles n parmi lesquels la source choisit ceux quelle va mettre :
[2.4]
Lorsque n = 2, D = 1 bit. L encore, il sagit dune unit fictive, reprsentant le choix
lmentaire minimum entre deux caractres. En comparant [2.2] et [2.3], on remarquera que
lentropie maximale dune source est gale au dbit de dcision.
La redondance mesure la quantit dinformation non significative dans le dbit de
dcision gnr par une source, et est donc logiquement dfini par :
[2.5]
H
i
lb
1
Prob i ( )
-------------------

lb Prob i ( ) ( ) = = Sh
H
i
H E H
i
( ) H
i
Prob i ( )
i
Prob i ( )lb Prob i ( ) ( )

i
= = = Sh
Prob i ( )
1
n
---
= i 1n =
H H
max
lb n ( ) = = Sh
D lb n ( ) = bit
R D H =
2.3 Algorithmes sans pertes
2.3.1 Pixel Packing
Ce n'est pas exactement une mthode de compression de donnes mais plutt une
manire d'enregistrer des informations de manire contigus en mmoire. Beaucoup de for-
mats bitmaps utilisent le Pixel Packing pour conserver la quantit de mmoire ou de place
disque dont ils ont besoin pour stocker une image. Si vous travaillez avec des images dont les
pixels contiennent 4 bits dans un byte de mmoire, on trouvera commode d'enregistrer cha-
que pixel dans un byte de mmoire, car un byte est typiquement la plus petite portion de
mmoire adressable sur la plupart des systmes informatiques. Toutefois, on s'apercevra vite
qu'en procdant de la sorte, la moiti de chaque byte ne sera pas utilise par les donnes du
pixel (cf. Fig. 1-a). Une image contenant 4096 pixels contenant 4 bit par pixels prendra donc
4096 bytes de mmoire de stockage dont la moiti sera irrmdiablement perdue.
Pour sauvegarder de la mmoire on peut alors faire appel au Pixel Packing. Au lieu de
sauver une seule fois 4 bit par byte, on peut sauver 2 fois 4 bits par byte. La taille alors utili-
se pour contenir notre image passera de 4096 2048 bytes puisque cette fois-ci la totalit de
la mmoire sera utilise sans pertes. On a donc 2 fois moins de mmoire utilise qu'aupara-
vant. (cf. Fig. 1-b)
Le Pixel Packing n'est pourtant pas la panace. Ce gain de mmoire un cot en ce qui
concerne la vitesse d'excution. En effet, il faut savoir que la plupart des systmes organisent
leurs donnes concernant les images en tableaux de bytes contenant chacun un pixel au
moins. Si c'est le cas, il serait en effet plus rapide d'enregistrer qu'une fois 4 bits/pixels par
byte et de lire directement ces donnes en mmoire dans l'ordre prtabli que d'enregistrer
deux fois 4 bits/pixels par byte ce qui demanderait de masquer et dcaler chaque byte de don-
ne pour extraire et crire la valeur du pixel appropri. Soit on a un gain de vitesse en matire
de lecture/criture, soit on a un gain en matire de place utilise, mais pas les deux la fois.
C'est un bon exemple du cot engendr par la compression de donnes.
A un moment donn de l'histoire de l'informatique il n'y avait pas tergiverser ; le cot
des disques tait prohibitif, et leurs capacits n'taient pas aussi importantes que maintenant
donc on tait oblig de compresser les fichiers. Lvolution du prix des disques durs ainsi
que celui des autres mdias (CD-ROM, DVD par exemple) fait qu'normment d'applica-
tions stockent des donnes non compresses par dfaut. Paralllement, la qualit des images,
le besoin en informations multimdia (musique, voix, images animes) fait que les besoins
en capacit croissent galement. Dautre part, les performances des CPU actuels font quil
est parfois avantageux, du point de vue de la performance de limiter la taille des fichiers,
quitte devoir dcomprimer linformation avant de la traiter...
FIGURE 2.1 Pixel Packing
2.3.2 Run-length Encoding (RLE)
RLE est un algorithme de compression de donnes qui est utilis par la plupart des for-
mats de fichiers bitmaps tels que TIFF, BMP et PCX. Il a t cr pour compresser n'importe
quel type de donnes sans tenir compte de l'information qu'elle contient. Toutefois le contenu
des donnes va affecter le taux de compression qu'il pourra atteindre. Bien que la plupart des
algorithmes RLE ne puissent pas atteindre les forts taux de compression d'autres mthodes de
compression plus avances, RLE est la fois simple implmenter et rapide d'excution ce
qui fait de lui une bonne alternative entre utilis un algorithme de compression plus com-
plexe ou laisser l'image sans compression.
RLE est l'une des mthodes les plus anciennes, les plus simples et la plus utilise. Tout
son secret consiste identifier et supprimer des redondances d'informations en les codant
sous une forme plus compacte. RLE s'emploie rduire la taille physique d'une rptition de
chane de caractre. Cette chane rpte est appele un passage (run) et est typiquement
code avec 2 bytes. Le premier byte reprsente le nombre de caractres dans le passage et est
appel le compteur de passage (run count). Il peut prendre une valeur comprise entre 0h et
128h ou 256h. Le second byte est la valeur du caractre dans le passage qui peut prendre la
valeur 0h FFh. Ce dernier byte est appel la valeur du passage (run value).
Non compress, le passage comprenant 15 caractres "A" devrait normalement prendre
15 bytes stocker.
AAAAAAAAAAAAAAA
Fig. 1 : Exemple de Pixel Packing
a) 4 bits/Pixels non-empaquets
Byte 2
Byte 0
Byte 1
Byte 0
Byte 0
Byte 0
Pixel 1 Pixel 2 Pixel 0
b) 4 bits/Pixels empaquets
Byte 0 Byte 1 Byte 2
Pixel 0 Pixel 2 Pixel 4 Pixel 3 Pixel 1 Pixel 5
La mme chane aprs codage ne prend plus que 2 bytes.
15A
Le "15A" gnr pour reprsenter la chane de caractre est appel un paquet RLE
(RLE packet). Ici, le compteur de passage contient le nombre de rptitions soit 15. Le
deuxime byte "A", la valeur du passage, contient la valeur rpte dans le passage.
Un nouveau paquet est gnr chaque fois que le caractre change ou chaque fois que
le nombre de caractre dans le passage excde la valeur maximum que peut prendre le comp-
teur. Si l'on suppose que notre chane de 15 caractres contient maintenant 4 passages diff-
rents :
En utilisant le codage RLE, cette chane pourra tre compresse en 4 paquets de 2
bytes.
Ainsi, aprs le codage, la chane de 15 bytes de dpart prendra seulement 8 bytes de
donnes pour reprsenter la chane. Dans ce cas, RLE permet d'atteindre un taux de compres-
sion de 2:1.
De longs passages sont rares dans certains types de donnes. Par exemple le texte
ASCII (comme celui contenu sur cette page) contient rarement de longs passages mais plutt
des passages de 1 ou 2 caractres identiques, rarement plus. Or il s'avre que pour coder un
passage en RLE, on a besoin de 2 caractres, par consquent, il s'avre que si l'on code des
chanes de caractres en RLE constitues de passages composs uniquement de 2 caractres
on n'aura aucun gain et la taille du fichier aprs compression sera exactement la mme. Pire,
si les passages sont composs uniquement de 1 caractre, la taille du fichier aprs compres-
sion sera le double de celle de dpart.
Dans l'exemple prcdent le fait d'avoir en codant doubl la taille du dernier caractre
n'a pas dgrad de manire notable notre taux de compression car on avait suffisamment
d'autres longs passages. Mais regardons maintenant ce qui se passe sur l'exemple suivant
constitu principalement de caractres uniques :
Cannibalisation
Aprs le codage RLE :
1C1a2n1i1b1a1l1i1s1a1t1i1o1n
AAAAAAbbbXXXXXt
6A3b5X1t
On peut dduire de tout cela que le codage RLE est simple et efficace mais que l'effica-
cit de la compression dpend fortement du type de donnes encoder. Une image en noir et
blanc constitue d'une grande partie de blanc s'encodera trs facilement en raison de la
grande quantit contigu de donnes identiques. A l'inverse, une image photographique cons-
titue de beaucoup de couleurs diffrentes s'encodera trs difficilement. (C'est l'une des rai-
sons pour laquelle on exprime la complexit d'une image en fonction du nombre de couleurs
diffrentes qu'elle contient).
2.3.3 Variantes de RLE
Il y a plusieurs variantes du codage RLE. Les donnes sont normalement traites dans
un processus squentiel qui prend des flots de donnes unidimensionnels plutt que bi-
dimensionnel. Dans un processus squentiel, un bitmap est cod en commenant dans le coin
en haut gauche et en continuant de gauche droite travers chaque ligne jusqu'au coin inf-
rieur droit de l'image (figure2.2, page32, a). Mais des schmas alternatifs de RLE peuvent
tre crits de telles manires qu'ils encodent les donnes de manire verticale, colonne par
colonne (figure2.2, page32, b) ou bien par flots de 4 x 4 pixels (figure2.2, page32, c) ou
encore en zigzag (figure2.2, page32, d). De singulires variantes comme cette dernire sont
utilises dans des applications trs spcialises mais sont relativement rares.
FIGURE 2.2 Codage RLE
Une autre variante que l'on peut rencontrer (trs rarement), est un algorithme RLE avec
perte. Normalement RLE est sans perte mais certaines moutures implmentent la possibilit
que des donnes puissent tre ignores par exemple en ne tenant pas compte d'un ou deux
LSB (Less Significant Bit) pour chaque pixel. Cette manire de faire peut amliorer le taux
de compression sans affecter l'apparence d'image relativement complexe. Cette variante ne
c) Codage 4 x 4
d) Codage en zigzag
b) Codage verticale a) Codage horizontale
fonctionne correctement qu'avec des images de qualits photographiques qui contiennent
normment de variations subtiles que l'il n'est pas ou peu capable de percevoir.
Quand le codeur RLE encode, il faudrait s'assurer qu'il traite des paquets constants
dont la taille serait gale celle occupe par une ligne (ou colonne ou diagonale) de l'image
bitmap. Il y a plusieurs bnfices encoder les donnes de cette manire. Premirement, on
peut s'assurer qu'on aura toujours besoin de la mme taille minimale de buffer. Mais surtout
on prviendra tout problme de codage crois (cross-coding).
Le codage crois est un problme qui survient lorsque le processus d'encodage com-
mence confondre les diffrentes lignes et qu'il n'est plus capable de faire la distinction entre
elles. Les points o les lignes commencent et o elles finissent sont perdus si bien qu'elles
finissent par tre compltement mlanges.
Le codage crois est parfois utilis bien qu'il soit totalement dconseill de le faire. Le
seul avantage qu'on peut en retirer est de gagner quelques bytes lors de la compression, mais
au prix d'un processus de dcodage beaucoup plus complexe donc d'une perte de temps plus
importante.
Lors de problmes avec une image code en RLE que lon peut lire avec une applica-
tion mais pas avec une autre, il sagit gnralement dun problme de codage crois.
Une programmation correcte consisterait poser des marqueurs de fin de lignes pour
indiquer au programme charg de dcoder les donnes que la fin de la ligne est atteinte ou
encore de construire une table qui contiendrait pour chaque ligne de l'image la position o
elle se trouve. Cette faon de faire (encoder des lignes individuellement) a un avantage cer-
tain si une application n'a juste besoin que d'une partie d'une image. Elle n'a plus besoin de
perdre son temps a dcoder toute l'image mais juste la partie qui l'intresse.
2.3.4 Codage RLE par Bit, Byte ou niveau de pixel
Le codage l'aide de RLE utilise toujours un ou deux dtails prs le mme schma.
Les diffrences de codages qui existent entre les diffrents algorithmes concernent
l'atomicit (la plus petite partie) des donnes que l'on va encoder. En fonction de cette notion,
on retient trois classes diffrentes : bit, byte ou niveau-pixel.
Le niveau Bit
Le niveau Bit s'intresse une succession de bits similaires tout en ne tenant absolu-
ment pas compte du niveau byte ou du niveau pixel. Seule les images noires et blancs (code
sur 1 bit) contiennent suffisamment de passages de bits pour que cette mthode soit efficace.
Un codage typique de RLE au niveau Bit code le tout sur un byte ; Soit la valeur du passage
sur le MSB (Most Significant Bit) et la valeur du compteur de passage sur les 7 derniers bits.
S'il devait s'avrer qu'il y avait des passages de plus de 128 (7 bits) caractres, la chane serait
simplement coupe en plusieurs paquets. (cf. figure2.3, page34)
FIGURE 2.3 Paquet RLE au niveau bit
Le niveau Byte
Le niveau Byte s'intresse quant lui des valeurs de bytes identiques en ne tenant pas
compte du niveau bit ou du niveau pixel. Le plus courant de ces types de codage code les
informations sur 2 bytes: Le premier byte contient la valeur du compteur de passage (0 255)
et le second byte la valeur du passage. (figure2.4, page34).
FIGURE 2.4 Paquet RLE au niveau Byte
Nous avons vu tout l'heure que l'un des problmes de RLE est qu'il fallait au moins
avoir des passages de longueurs plus grand que 2 si l'on voulait avoir une chance de pouvoir
comprimer nos donnes. Un codage au niveau byte rsout d'une certaine manire ce pro-
blme en identifiant dans les donnes sources celles qui pourront tre compresses et celles
qui ne le pourront pas. S'il voit qu'il peut les compresser, il va le faire comme vu prcdem-
ment sinon il ne va pas les toucher et les rcrire tel quelles de manire ce qu'elles ne pren-
nent pas plus de place lors de la compression.
Mais lors de la dcompression ? Comment fera-t-il pour reconnatre les donnes qui
ont t compresses et celles qui ne l'ont pas t ? Trs simplement, car lors de la compres-
sion, au lieu d'utiliser le byte rserv au compteur de passage sur 8 bits, il va l'utiliser seule-
ment sur 7 bits (donc 128 caractres au lieu de 256), par contre le bit ainsi libr va lui servir
dterminer si oui ou non les donnes on t compresses. (cf. figure2.5, page35). Si lors
de la dcompression ce premier bit est 1, on va dcoder le passage en recopiant la valeur du
passage "compteur de passage" fois, sinon si le premier bit est 0 cela signifie que les
"compteurs de messages" valeurs qui suivent le compteur de messages sont lues directement
0-127
Valeur de passage
0 ou 1
Compteur de passage
Compteur de passage
Compteur de passage
Valeur de passage
0-255 0-255
depuis le fichier source sans avoir t compress. En gnral on utilise un codage RLE par
byte pour les images qui stockent leurs donnes comme un byte par pixel.
FIGURE 2.5 Codage au niveau byte
Il existe une autre mthode qui consiste rajouter carrment un byte au dbut qui fera
office de flag. Toutefois, on signalera 2 inconvnients: Premirement la limite d'efficacit est
remonte de 3 4 caractres identiques si l'on veut un taux de compression positif. Deuxi-
mement si les donnes contiennent un caractre identique au flag il faut de toute faon les
compresser et en tenir compte lors de la dcompression, avec le risque d'avoir un trs faible
taux si l'on a beaucoup de ces caractres flags qui apparaissent. C'est la raison pour laquelle,
si l'on utilise un caractre flag, ce doit tre un caractre rare (en gnral de 0x0 0x20 ou
0xFF).
Le niveau Pixel
Le niveau Pixel est utilis quand un ou plusieurs bytes conscutifs de donnes sont uti-
liss pour stocker un pixel. Ici, on ne tient pas compte du niveau bit et le niveau byte sert
juste dterminer la valeur d'un pixel. La taille des paquets de codage dpend du nombre de
byte par pixel. Admettons qu'un passage soit tel qu'il soit cod avec 3 bytes par pixel ; La
valeur code sera un paquet de 4 bytes soit un byte de comptage suivi de trois bytes de
valeurs de passages (cf. figure2.6, page35). Le codage est donc trs similaire au codage par
byte, la diffrence tant que le compteur indique cette fois-ci un nombre de pixels et non le
nombre de bytes dans le passage.
FIGURE 2.6 Paquet RLE au niveau Pixel
Compteur de passage Valeur de passage
0-127
0-255
Indicateur de
Passage 0 ou 1
Compteur de passage Valeur de passage
0-255 0-255 0-255 0-255
Pixel
Red
Pixel
Green
Pixel
Blue
2.3.5 Rplication verticale de paquets
Certaines moutures de RLE utilisent une autre faon pour augmenter l'efficacit de la
compression. Dans cette faon de faire, on n'enregistre pas rellement les informations conte-
nues dans une ligne mais on indique seulement une rptition de la ligne prcdente. Un petit
exemple pour claircir les ides :
Imaginons que l'on a une image qui fait 640 bytes de large et que tous les pixels sur
cette ligne soient de la mme couleur. On aura donc besoin de 10 bytes pour coder une ligne
sachant que l'on peut coder 128 bytes par paquets et que la taille d'un paquet est de 2 bytes.
Admettons maintenant que les premires 100 lignes sont toutes identiques donc de la mme
couleur. A 10 bytes par ligne, on arrive une taille de 1000 bytes pour les 100 premires
lignes.
Si maintenant on utilise des bits de rplications qui ne font qu'un byte (par exemple des
bits 0), on aura donc de toute faon la premire ligne coder normalement (10 bytes) mais
qu'on fera suivre de 99 paquets de rplications verticaux (99 bytes), donc le rsultat ne pren-
dra que 109 bytes. (figure2.7, page36, a)
FIGURE 2.7 Rplication verticale de paquets
On pourrait mme imaginer d'aller plus loin. On coderait de toute manire la premire
ligne (10 bytes), ensuite on aurait un byte 0 pour indiquer une rptition de lignes, puis on
aurait qu' indiquer dans un troisime byte le nombre de rptitions faire, 99 (figure2.7,
page36, b). Ce qui voudrait dire que pour coder les 100 premires lignes contenant 64'000
bytes on aurait juste besoin de 12 bytes !
Malheureusement la dfinition des paquets de rplication verticales est dpendante de
l'application qui les utilise. Toutefois 2 formats propritaires utilisent cette mthode verti-
cale. WordPerfect Graphics mtafile (WPG) et GEM Raster (IMG) ont chacun dfini un
algorithme de ce type pour amliorer leur efficacit de compression. WPG utilise un paquet
de 2 bytes comme vu prcdemment. Le format GEM est un peu plus compliqu. La
Compteur
de passage
Valeur de
passage
127 132 0 0 0
1 2 99
Compteur
de passage
Valeur de
passage
Valeur
rpter
Nombre de
fois rpter
a) avec 1 byte
127 132 0 99
b) avec 2 bytes
squence 00h 00h FFh doit apparatre au dbut d'une ligne pour indiquer un paquet rpliqu
verticalement. Le byte qui suit cette squence indique le nombre de fois qu'il faut rpter
cette squence moins une.
Beaucoup des concepts vus prcdemment ne sont pas limits RLE. Tous les algo-
rithmes de compression bitmaps doivent considrer les concepts de codage crois, efficacit
de compression, dtection de compression ngative, rplication verticale, etc...
2.4 Codages base statistique
2.4.1 La mthode probabiliste
La compression probabiliste est souvent employe aprs un codage RLE. Elle repose
sur le fait qu'un flux de donnes peut tre compact en utilisant un nombre variable de bit
pour reprsenter les diffrents octets ou squences d'octets. Les symboles les plus frquents
sont cods sur de courtes squences de bits tandis que les symboles les plus rares sont cods
sur davantage de bits. Avec cette mthode de stockage le taux avoisine les 50%.
Dans la ralit, on devrait nuancer quelque peu notre enthousiasme. En effet, on doit
prendre en compte la cration d'une table de frquence, laquelle rduit quelque peu le gain
(puisqu'il faut l'insrer dans le fichier). De plus la compression est ralentie par le fait qu'on
doit lire deux fois le fichier, une premire fois pour crer la table et dterminer la squence
binaire de chaque octet et une deuxime fois pour effectuer le codage.
Quelques procds permettent de se rapprocher d'un codage optimal. Certains utilitai-
res assignent des squences de bits de longueurs variables non seulement aux caractres sim-
ples mais aussi aux squences de caractres de longueur variables. Par exemple PKZIP se
base sur le fait que les occurrences de la chane "ne" seront bien plus nombreuses que celles
de la chane "qx".
2.4.2 Le codage de Shannon
Le principe du codage statistique remonte la fin des annes quarante et repose sur les
travaux du mathmaticien Claude Shannon (laboratoires Bell), qui dmontrait l'existence
d'une mthode permettant de compacter les flux d'information sans rien perdre de leur signi-
fication. On peut par exemple dformer des syllabes par des lettres ("elle" par "l") et com-
prendre la phrase sans dformer son contenu informatif. L'ide directrice tait donc que tout
message est porteur d'une certaine densit d'information ou entropie dont le calcul peut
s'effectuer au prorata de leur frquence probable d'apparition. Cette entropie ne correspond
pas forcment la taille du message, dans la mesure o la plupart des messages contiennent
de nombreuses redondances, ce qui permet d'en prvoir les squences rptitives. Si l'on par-
venait calculer la frquence probable d'apparitions des informations d'un message, il
deviendrait du coup tout aussi simple d'en liminer les redondances et de les encoder de
manire efficace. (figure2.8, page39)
Toute langue comprend de nombreuses squences rptitives. Sur un PC chaque carac-
tre est cod sur 8 bits (ASCII). Le but est de dcrire un caractre par son entropie, sa fr-
quence d'apparition dans un message, cette frquence devant tre reprsente par un certain
nombre de bits. La plupart des compresseurs consomment une moyenne de 2,5 bits par carac-
tre soit un peu plus de 3 fois moins que les 8 bits par dfaut.
Plus un symbole est courant, plus il est ais d'en prvoir l'apparition. Moins il ncessite
d'informations pour l'identifier, plus son entropie est leve. Donc s'il tait cod en fonction
de cette dernire, il pourrait occuper moins d'espace qu'un caractre plus rare dont la prvi-
sion est plus dlicate.
FIGURE 2.8 Frquence dapparition des lettres en franais
Alors plutt que de lui allouer 8 bits, il serait plus conomique de ne lui rserver que le
nombre de bits ncessaires sa reconnaissance. Du fait de la plus grande frquence du E, un
message compress tendra tre cod sur moins de bits que le message original. Si sur une
courte squence d'une trentaine de bits le gain avoisine les 10%, il ne manquera pas d'tre
beaucoup plus intressant sur un texte plus long, beaucoup plus riche en redondances. En
vrit, il est trs simple de parcourir un texte pour dnombrer les apparitions de chacun de
ses caractres ; il est plus ardu, en revanche, de dduire un codage vraiment optimal de ces
calculs des probabilits.
On peut nanmoins se baser, pour un message donn, sur la thorie de linformation
pour dterminer les probabilits et en dduire un codage appropri. Nous utiliserons comme
exemple, dans la suite, le message "BANANES ET ANANAS" (pourquoi pas ?). Les pro-
prits statistiques de ce message sont donnes la figure 2.9, page 40. Selon cette figure, on
peut constater quun codage optimal selon Shannon doit permettre de coder le message en
exactement 43.945 bit, contre 136 en ASCII. Dautre part, on doit tre en mesure de coder le
symbole A avec moins de 2 bit (1.765 bit trs exactement), condition de coder le symbole T
avec 4.08 bit.
Plusieurs mthodes ont t dveloppes pour utiliser les proprits statistiques des
messages. Nous allons tudier dans la suite les deux plus classiques.
e 11 n 6,6 m 3 f 1,22 j 0,17 0,04
s 9,27 o 6,04 p 2,79 v 1,01 z 0,12 w 0,03
i 8,61 4,87 d 2,23 q 0,88 k 0,12 0,03
a 7,8 l 4,75 g 1,91 y 0,65 0,08 0,03
r 7,42 u 4,49 h 1,67 x 0,41 0,08 0,03
t 6,8 c 3,87 b 1,64 0,3 0,06 0,01
Les lettres '', '' et '', n'apparaissent pas car l'arrondi 2 chiffres aprs la virgule les fait disparatre.
Cette rpartition a t faite partir d'un dictionnaire mais il est clair qu'elle peut varier en fonction du texte
analys (texte littraire, texte commercial).
FIGURE 2.9 Caractristiques statistiques de "BANANES ET ANANAS"
2.4.3 Le codage Shannon-Fano
En mme temps que Shannon, R.F Fano poursuivait au MIT (Massachusetts Institute
of Technology) des recherches similaires. Dans la mthode connue sous le nom de "Shan-
non-Fano", l' ide est de rpartir les symboles en deux groupes de valeur peu prs quiva-
lente, cette valeur tant la somme, dans chaque groupe, des probabilits d'apparition des
symboles qu'il contient. Le groupe de gauche est appel 0, celui de droite 1 (ce choix est arbi-
traire). Les groupes sont nouveau subdiviss et nomms 0 ou 1 jusqu' ce que la subdivi-
sion ne contienne plus qu'un symbole. L'arbre binaire ainsi obtenu est form de segments ou
branches et de feuilles. Chaque branche reprsente un bit d'informations (0 ou 1), Chaque
feuille contient un caractre simple. Pour dterminer le code numrique d'un caractre donn,
il faut partir du sommet de l'arbre et suivre les branches jusqu' atteindre la feuille qui le
reprsente. Les caractres les plus frquents se trouvent le plus prs du sommet et requirent
donc moins de bits dans leurs transcriptions compresses.
2.4.4 Un exemple de codage selon Shannon-Fano
Nous allons effectuer la compression de notre message-tmoin en utilisant lalgorithme
de Shannon-Fano. La premire subdivision est indique la figure2.10, page 41. On remar-
que que, dans larbre de codage rsultant, on inscrit un "0" en regard de la branche de gauche,
et un "1" en regard de la branche de droite. Ce codage est sans effet sur lefficacit du rsul-
tat, et est donc arbitraire.
s : symbole
f(s) : frquences dapparition du symbole
p(s) : probabilit dapparition du symbole
H(s) : quantit dinformation convoye par le symbole
H : quantit dinformation cumule par ce symbole (f(s) * H(s))
ASCII : quantit de dcision selon un code ASCII
La subdivision dfinit deux symboles (qui sont en fait des groupes de symboles), "AN"
et ES<space>BT. Cette subdivision est ainsi faite pour que les frquences des deux subdivi-
sions soient aussi quilibres que possible.
FIGURE 2.10 Premire subdivision selon Shannon-Fano
La deuxime tape va isoler les symboles A et N, et dfinir une nouvelle subdivision
des symboles restants.
FIGURE 2.11 Deuxime subdivision
FIGURE 2.12 Troisime partition
La troisime partition ne laisse plus que le couple BT non rsolu, et le rsultat final est
indiqu la figure2.13, page43:
FIGURE 2.13 Partition finale
Pour connatre le code associ chaque lettre, on parcourt larbre final de haut en bas,
et lon obtient :
On peut sassurer que le rsultat correspond une quantit de dcision trs proche de la
quantit dinformation, soit 44 bit. La redondance rsultante est pratiquement nulle.
La mthode serait lumineuse s'il n'existait plusieurs manire de subdiviser une liste de
symboles et s'il n'tait dlicat de dcouvrir la mthode optimale. En pratique le codage Shan-
non-Fano s'approche de l'optimisation idale mais le risque existe de produire un code plus
long que ncessaire.
A 00
N 01
E 100
S 101
<space> 110
B 1110
T 1111
2.4.5 Le codage de Huffman
C'est l qu'intervient David Huffman qui en 1952 publie le rsultat de ses recherches.
Son tude se fonde sur l'ide que certains caractres sont susceptibles d'apparatre plus sou-
vent que d'autres dans un fichier, laissant la possibilit de les coder sur un nombre de bits
plus restreint. Mais il inverse le raisonnement de Shannon et Fano. Ainsi plutt que de subdi-
viser une liste indfiniment avec pour effet de dvelopper un arbre partir de son sommet,
pourquoi ne pas le construire en partant d'en bas ?
Il eut l'ide d'examiner la liste des caractres pour trouver les deux moins frquents, de
crer un nouveau symbole parent des deux premiers et somme de leurs comptes de frquen-
ces, et de l'ajouter la liste. Les symboles enfants prennent alors respectivement les valeurs 0
et 1 et sont retirs de la liste. Le processus est rpt sur l'ensemble des caractres jusqu' ce
qu'il ne reste plus qu'un seul parent formant la racine de l'arbre.
Pour dcoder un symbole, il suffit de descendre dans cette arborescence. Cette
mthode garantit en gnral un gain de 40 % d'autant plus intressant que le processus
s'effectue rapidement, ne ncessite que trs peu de mmoire et ne peut en aucun cas crer de
situation dsespre, ni de perte d'espace, malgr le petit en-tte report dans la table de sor-
tie.
2.4.6 Exemple de codage selon Huffmann
Reprenons notre exemple prcdent, savoir
"BANANES ET ANANAS". On peut voir ci-contre la
table de frquences des lettres de ce message, bien sr
identique celle que nous avions obtenue pour le codage
selon Shannon-Fano. On va commencer le partitionnage
par les lettres les moins frquentes, savoir dans ce cas,
B et T, pour former un symbole combin BT, qui aura en
toute logique une frquence dapparition de f(B) + f(T),
cest--dire 2. Cette frquence pourra son tour se com-
parer la frquence dapparition de E, S et <space>, et
ainsi de suite jusqu ce que lon obtienne un symbole
combin contenant le total du message, soit f(s) = 17. A
mesure de la construction de larbre, on notera avec un
"0" la branche de gauche, et un "1" la branche de droite
(choix arbitraire).
La premire partition est prsente la figure 2.14, page45
FIGURE 2.14 Premire partition
On groupe ensuite les symboles ayant un poids (frquence dapparition) de 2 ensemble,
pour aboutir larbre partiel de la figure2.15, page45.
FIGURE 2.15 Deuxime partition
Ensuite, les lments restant sont regroups. Les frquences dapparition ne sont pas
identiques, et nont en principe pas besoin de ltre: ce qui est important, cest que lquilibre
reste aussi bon que possible. On remarque ce niveau quil peut y avoir plusieurs groupages
quivalents un instant donn (ce nest pas le cas dans notre exemple trs simple). Ceci ne
pose en principe pas de problme : le code rsultant va bien sr changer, mais pas lefficacit
de ce codage.
Les figure2.16, page46 et figure2.17, page46 donnent les deux dernires tapes du
codage selon Huffmann. On constate facilement que lon parvient un codage quivalent
celui de Shannon-Fano.
FIGURE 2.16 Troisime partition
FIGURE 2.17 Partition finale
2.4.7 Efficacit des codages de Shannon-Fano et de Huffmann
Dans notre exemple trs simple, nous avons vu que les deux mthodes taient quiva-
lentes; en ralit Huffmann est en principe lgrement meilleur que Shannon-Fano. Leffica-
cit reste remarquable dans les deux cas, puisque lon sapproche aussi prs que possible de
loptimum thorique.
En ralit, le codage nest pas aussi bon quon pourrait le croire : dans les deux cas, il
faut encore transmettre une table donnant la correspondance entre les symboles et leur
codage. Ceci peut se faire par une transmission explicite de la table de correspondance, par
une transmission de la table de frquences, suivie dune reconstitution par le rcepteur de
larbre de codage, ou encore par divers procds de codage dun arbre binaire.
Cette transmission fait bien sr baisser considrablement lefficacit de notre codage
dans le cas du message considr: on peut estimer que lon parvient, au mieux, transmettre
un message de 120 bit environ, contre 136 pour un codage ASCII sans compression.
Quel travail pour gagner quelques malheureux bit ! En ralit, la situation nest pas si
dfavorable quelle nen a lair. Notre message est extrmement court, si bien que la table de
correspondance est de taille comparable au message comprim, et reprsente pratiquement
50% du message rsultant. Si le message augmente, la table de correspondance ne va pas
augmenter en proportion (il ny a que 256 symboles lorsque lon code des bytes), si bien que
plus le message est grand, plus la compression est efficace.
2.5 Le codage CCITT pour fax
Le CCITT (International Telegraph and Telephone Consultative Committee) est une
organisation de standardisation qui a dvelopp une srie de protocoles de transmissions
pour la transmission d'images et de donnes en noir et blanc sur des lignes tlphoniques
(fax). Ces protocoles sont officiellement connus en tant que standard CCITT T.4 et T.6 mais
y sont plus souvent rfr comme standard de compression CCITT Groupe 3 et Groupe 4 res-
pectivement.
Le codage CCITT 1-dimension, dcrit plus bas, descend en droite ligne du codage de
Huffman vu plus haut, alors que les autres codages CCITT ne sont pas des implmentations
du codage de Huffman.
Les codes des groupes 3 et 4 sont des algorithmes de compressions spcifiquement
dsigns pour le codage d'images en noir et blanc. Tous les fax modernes supportent la
norme de compression Groupe 3. Elle est rapide, a un bon taux de compression et contient
des informations de corrections d'erreurs.
Le groupe 4 est une forme de compression plus efficace capable d'encoder un docu-
ment la mme vitesse que le groupe 3 mais en prenant 2 fois moins de place malgr le fait
qu'il soit un tout petit peu plus difficile implmenter. Il t conu pour fonctionner sur un
rseau local c'est pourquoi il ne contient pas de code de dtection d'erreurs. On confond sou-
vent le groupe 4 avec la mthode de compression IBM MMR (Modified Modified Read). En
fait se sont exactement les mme et ils ont exactement les mme rsultats la compression.
IBM a simplement sorti son algorithme avant que le groupe 4 ne soit standardis.
Les algorithmes du CCITT sont non adaptatifs ce qui signifie qu'ils n'adaptent pas leurs
algorithmes pour encoder chaque bitmap avec la meilleure efficacit possible. Tout comme
l'algorithme de Huffman, les algorithmes CCITT sont des algorithmes statiques en rfrence
l'utilisation d'une table d'encodage de taille fixe pour l'ensemble d'un fichier. Le calcul des
frquences peut s'effectuer dynamiquement au fur et mesure du traitement du fichier. Au
dmarrage du traitement toutes les probabilits seront de valeurs gales mais en mme temps
qu'un caractre sera encod ou dcrypt, sa probabilit d'apparition sera incrmente.
La compression dynamique montre de meilleurs rsultats et montre quelques avantages
sur la compression statique. Elle peut tre ralise en un seul passage, la vole et ne se
limite donc pas la compression des seuls fichiers. On peut y recourir pour compacter
n'importe quel flux de donnes. Le protocole MNP5 utilis par les modems en est un driv.
De plus en pratique, cette mthode atteint des taux de compression suprieurs puisque dans
un fichier, les probabilits d'occurrences voluent sans cesse et qu'un modle dynamique
peut s'adapter aux variations de frquences. Si la compression dynamique est un peu plus
dlicate programmer que la compression statique, elle offre nanmoins nombre d'avanta-
ges.
Le groupe 3 atteint des taux de compression de 5:1 8:1 sur un document A4. En tant
approximativement 2 fois meilleurs, le groupe 4 peut atteindre des taux de compression
allant jusqu' 15:1. Toutefois il faut savoir que les algorithmes du CCITT ont t optimiss
pour des fax, donc pour des documents cris la main ou taps la machine (par exemple, la
table statique a t conue de telle manire qu'elle soit reprsentative d'un document standard
envoy par fax comportant la fois du texte et des images).
Le CCITT dfinit actuellement trois algorithmes pour le codage d'images en deux
dimensions :
Groupe 3 1-dimensions (G31D)
G31D est le plus simple des algorithmes et le plus facile implmenter. G32D et G42D
sont beaucoup plus complexes aussi bien dans leur conception que dans leurs oprations.
2.5.1 Groupe 3 1-dimension (G31D)
Comme dit plus haut, c'est une variation du codage de Huffman. Un codeur de groupe
3 dtermine la longueur d'un passage de pixels sur une ligne (le nombre de bit 1 ou 0 dans
une image en noir et blanc) et en dduit un code de frquence reprsentant la longueur et la
couleur du passage. Ces codes sont pris d'une table prdfinies de valeurs reprsentant des
passages de pixels en noir et blanc. On distingue 2 types de codes diffrents : les terminating
codes pour les passages courts (0 63 pixels) et les makeup code pour les longs passages (de
63 2623 pixels). Les passages plus grands que 2623 pixels sont cods avec plusieurs codes.
La frquence est la somme des frquences de chaque code.
Il existe certains codes spciaux dfinit dans le groupe 3. Par exemple des codes de
synchronisation pour les transmissions comme le code EOL (End Of Line) qui commence
chaque nouvelle ligne et est utilis pour se resynchroniser sur le flot de donnes lorsqu'il y a
eu un problme de transmission.
Un autre code spcial est le code de terminaison RTC (Return To Control) qui apparat
la fin de chaque image transmise pour signaler la fin de la transmission et indiquer au
rcepteur de couper la porteuse utilise pour le transfert de donnes rapide et couter la fr-
quence de la porteuse lente utilise pour le transfert d'informations de contrles. Ainsi met-
teurs et rcepteurs pourront changer les informations de fin de session. Un code RTC est
simplement constitu de 6 codes EOL mis bout bout.
2.5.2 TIFF Compression Type 2
TIFF est labrviation de Tagged Image File Format. C'est une variation du codage
CCITT G31D. La diffrence tant qu'il n'implmente pas les codes EOL ou RTC (ce qui est
comprhensible vu qu'ici la compression est destine une image fixe stocke sur disque et
non une image transmise sur une voie de communication). On appelle galement ce code le
"Groupe 3 sans EOL". Les compressions TIFF type 3 et TIFF type 4 implmentent exacte-
ment les codages CCITT Group 3 et CCITT Group 4.
2.5.3 Groupe 3 2-dimensions (G32D)
Dans le codage G31D, lors du codage on ne code qu'une ligne la fois en ne se sou-
ciant que de ce que l'on est entrain de coder. Les donnes qui sont avant ou aprs notre pas-
sage nous importent peu. On peut parler de codage dans une seule dimension.
En codage G32D, comme son nom l'indique, on code en deux dimensions. La faon
dont on va coder une ligne dpendra directement de la ligne prcdente. Beaucoup d'images
ont de la redondance verticale, donc en dcrivant uniquement les diffrences entre deux
lignes qui se suivent au lieu de dcrire compltement la ligne, on peut atteindre des taux de
compression plus levs.
Les codes utiliss pour dcrire les diffrences entres pixels de la mme ligne (codage
horizontal) ou de deux lignes successives (codages verticaux) sont appels des Relative Ele-
ment Address Designate (READ).
Les plus petits codes sont utiliss pour dcrire des transitions plus petites que 4 pixels
alors que les codes les plus longs sont utiliss pour dcrire de plus grandes diffrences.
Le problme de cette mthode est qu' cause de la rptition des lignes, il suffit que la
ligne qui est situe au dbut soit corrompue pour une raison quelconque pour que toutes les
lignes suivantes le soient galement. Pour minimiser ce problme, G32D utilise une variable
appele facteur K qui lui permet de ne recopier qu'un nombre maximum de K-1 lignes. Ainsi
si un problme survient, il n'y aura que K-1 lignes corrompues puisque aprs on aura recod
les informations compltement. Une valeur typique de K est de 4 ce qui signifie que notre
image va tre code par bloc de 4 lignes constitu par une ligne de base et trois lignes reco-
pies dessus.
2.5.4 Groupe 4 2-dimensions (G42D)
G42D a t dvelopp partir de G32D. Le codage est le mme quelques dtails prs
: On n'a pas de code EOL et la variable K est mise une valeur infinie. Et surtout le codage
de la compression est plus complexe que le groupe trois, ce qui permet d'avoir un gain 2 fois
plus important mais une perte de vitesse galement plus grande. Toutefois dans une impl-
mentation hardware, la diffrence de vitesse est insignifiante ce qui fait de G42D un excel-
lent compromis.
2.6 Les versions adaptatives de Huffmann et
Shannon-Fano
Les codages base statistique requirent malheureusement un examen pralable du
fichier de manire tablir la table des probabilits dapparition, et donc la quantit dinfor-
mation associe chaque symbole. Ceci est souvent impossible raliser en tlcommunica-
tions, o lon dsire implmenter, idalement, la compression dans un modem. Or, un
modem ne peut gure se permettre dexaminer au pralable le fichier transfrer, tant
entendu que le modem nest pas cens savoir que les informations quil transmet sont conte-
nues dans un fichier.
De plus, sans parler de la perte de temps associe la lecture pralable du fichier pour
en dterminer les probabilits dapparition des symboles, cette manire de faire nest claire-
ment pas optimale. En effet, prenons un document dune certaine longueur, comportant plu-
sieurs sujets, chacun de ces sujets tant li des thmes diffrents. Ainsi, un document
technique peut comporter des chapitres en anglais, des chapitres en franais, et des listing de
segments de code en un langage de programmation quelconque. Un tel document peut aussi
comporter des images. Lanalyse pralable du document va nous fournir un codage optimal
pour la moyenne du document. Ce codage ne sera en revanche certainement pas optimal pour
les divers segments, pris individuellement.
Tant les algorithmes de Huffmann que de Shannon-Fano se prtent des version adap-
tatives, permettant le codage en temps rel de linformation transmettre. Nous ne nous pen-
cherons ici que sur le codage selon Huffmann.
2.6.1 Codage de Huffmann adaptatif
Lide est de reconstruire larbre de codage chaque nouveau caractre reu. Lincon-
vnient est que lon ne peut pas savoir au pralable de quels symboles va se composer le
message, et quil est donc ncessaire de pouvoir ajouter en cours de compression de nou-
veaux symboles, et donc de nouveaux codes, larbre de codage. On dbutera lalgorithme
avec une table de symboles pratiquement vide, lexception de deux symboles particuliers
qui sont <NEW> et <EOF>. Le premier sera utilis pour la dfinition dynamique de nou-
veaux symboles, le second pour marquer la fin du message. Ces deux symboles reoivent
arbitrairement, au dpart, un poids de 1. A chaque fois que lon rencontre un symbole non
encore prsent dans larbre, on va le signaler en mettant un symbole <NEW> suivi de la
dfinition du symbole (par exemple, sa reprsentation non compresse en code ASCII ou
UNICODE). Ce nouveau symbole sera ensuite insr dans larbre de codage.
FIGURE 2.18 Arbre de codage originel
Un inconvnient majeur de cette manire de faire est quil faut en principe recrer
compltement larbre de codage chaque nouveau symbole. Fort heureusement, larbre de
codage de Huffmann (ainsi que celui de Shannon-Fano, dailleurs) fait partie dune famille
particulire darbres dits quilibrs. Ces arbres ont des proprits intressantes qui permet-
tent leur modification selon des rgles trs strictes; il sensuit quil nest pas ncessaire de
reconstruire larbre chaque symbole, mais que lon peut se contenter gnralement de per-
muter les branches incrimines pour dduire le nouvel arbre de lactuel. Ces algorithmes sont
hlas gnralement rcursifs, donc excessivement lents; dautre part, il existe des cas particu-
liers o le rarrangement implique les permutations de toutes les branches de larbre, ce qui a
parfois pour effet de produire, temporairement, une situation o la reconstruction pure et
simple de larbre serait plus rapide.
Les versions adaptatives des algorithmes bass sur la statistique sont presque toujours
meilleures que les versions statiques. Mme si lon a besoin dun symbole supplmentaire
pour transmettre de nouveaux symboles, il nest plus ncessaire de transmettre la table de
frquences, ou larbre de codage : codeur et dcodeur peuvent commencer leur opration
avec une table vide. Dautre part, le code va sadapter automatiquement linformation
transmettre, ce qui aura pour effet, surtout sur de longs documents relativement htrognes,
doptimiser localement la compression.
Un effet pouvant surprendre est que le codage de chaque symbole peut (et doit) varier
au cours du document : il ny a donc pas de reprsentation constante dun symbole lint-
rieur du message.
2.6.2 Exemple (partiel)
Reprenons notre message favori, et comprimons quelques symboles du message :
FIGURE 2.19 Codage de la lettre B de BANANES
FIGURE 2.20 Codage du A
On remarque que le code correspondant <NEW> a chang entre la transmission du B
et du A. Le codage du N va avoir un effet similaire, avec nouveau une transmission de
<NEW>. Le A subsquent naura par contre pas pour effet de transmettre un <NEW>
puisquil a dj t transmis prcdemment : la situation sera celle illustre la figure 2.21,
page54.
FIGURE 2.21 Transmission de N puis A
2.6.3 Huffmann et Shannon-Fano, contre-exemple
Dans les cas prcdents, nous avons chaque fois obtenu une bonne correspondance
entre la quantit dinformation thorique et la quantit de dcision effectivement ncessaire
avce un codage compression. On peut aussi trouver des exemples qui ne sont pas aussi
favorables.
Soit un fichier comportant 9999 caractres <NUL> (byte 0) et un caractre non nul (par
exemple, un caractre <EOT>, fin de texte). Si nous essayons de le coder selon Huffmann
(ou Shannon-Fano, peu importe), nous obtiendrons le codage reprsent la figure 2.22,
page55.
FIGURE 2.22 Contre exemple
Soit une quantit de dcision de 10 kbit pour une quantit dinformation de moins de
15 bit. Ceci est un cas particulier o lalgorithme de compression choue lamentablement.
La raison en est que, daprs la figure 2.22, page55, il faudrait exactement 0.00014427 bit
pour coder le caracre <NUL>, alors que nous en avons utilis 1 ! Nous navons pas de
moyens de dfinir des fractions de bit.
2.6.4 Codages sur plus dun caractre
On peut utiliser Huffmann pour coder non plus des caractres individuels, mais des
paires, ou plus gnralement des combinaisons de caractres. La combinaison "es" est vrai-
semblablement beaucoup plus probable que "qw", si bien que lon peut vraisemblablement
amliorer lefficacit du codage selon Huffmann.
En fait, on parvient effectivement lamliorer quelque peu, au prix dune complexit
plus grande, et de la ncessit de transmettre une table de correspondance nettement plus
volumineuse comme en-tte de dcodage. Cette technique nest que peu utilise en pratique.
2.7 La compression arithmtique.
La technique d'encodage arithmtique due P. Elsa n'a pas, contrairement celle de
Huffman, pour restriction de ne devoir traduire les probabilits que par des nombres entiers
de bits. Elle peut encore rduire l'espace occup en encodant un caractre sur une fraction de
bit. Pratiquement, les diffrences constates entre le rsultat atteint par Huffman et celui de
code arithmtique restent assez minces, se traduisant par un gain de place de l'ordre de 4% ou
5% au plus, sauf cas trs particuliers.
Ce genre de cas se rencontre en particulier quand les probabilits dapparition des
divers symboles sont trs dsquilibres; imaginons en effet une source ne produisant que
deux symboles, lun avec une probabilit de 98%, lautre avec la probabilit complmen-
taire: un codage selon Huffmann ou Shannon-Fano ne peut attribuer quun bit chaque sym-
bole, indpendemment de la quantit dinformation contenue dans le symbole incrimin,
simplement parcequil nest pas possible de transmettre des fractions de bit. Cest dans ce
genre de cas que le codage arithmtique se montre plus favorable que les codages statisti-
ques.
L'encodage arithmtique traite l'ensemble d'un message comme une seule entit. Il
fonctionne par la reprsentation d'un nombre par un intervalle de nombres rels compris
entre 0 et 1. A mesure que le message s'allonge, l'intervalle requis pour le reprsenter dimi-
nue, et le nombre de bits qui servent prciser cet intervalle s'accrot.
Les symboles successifs du message rduisent cet intervalle en concordance avec la
probabilit d'apparition du symbole. Sous sa forme la plus simple, on parle de compression
arithmtique dordre zro.
2.7.1 Compression arithmtique dordre zro
Soit, par exemple, coder le message BILL GATES. Sa distribution de probabilits
a lallure suivante :
FIGURE 2.23 Probabilits dapparition des symboles dans le message BILL GATES
SPACE 0.1
A 0.1
B 0.1
E 0.1
G 0.1
I 0.1
L 0.2
S 0.1
T 0.1
On va maintenant associer chaque symbole un domaine r lintrieur de lespace des
probabilits compris entre 0 et 1. Lassociation de chaque symbole avec un domaine particu-
lier nest pas critique, mais il est vital que le dcodeur et lencodeur utilisent la mme table
dassociations.
FIGURE 2.24 Association de domaines de probabilits aux symboles
Le premier caractre, B, se voit assigner un domaine entre 0.20 et 0.30. Le message
final aura donc une valeur comprise entre 0.2 et 0.3, ce qui devient notre nouvel espace de
probabilits pour le message. Le caractre I, qui obtient le domaine de 0.5 0.6, va utiliser le
domaine compris entre 50% et 60% du nouvel espace de probabilits, ce qui amne le mes-
sage un nouveau domaine compris entre 0.25 et 0.26. Lalgorithme permettant dencoder
un message de longueur arbitraire ressemblera au code suivant (code approximatif, bas sur
la syntaxe de C) :
int num_chars; // Nombre de symboles diffrents dans
// le message (= 9 dans le message
// BILL GATES
// Noter que les lignes suivantes sont interdites en C,
// il faudrait utiliser des pointeurs
float low_range[num_chars]; // Tableau des bornes infrieures
// des domaines de probabilit de
// chaque symbole
float high_range[num_chars]; // Tableau des bornes suprieures
// des domaines de probabilit de
// chaque symbole
low = 0.0;
high = 1.0;
char c;
while ((c = getc(stdin)) != EOF) {
range = high - low;
high = low + range * high_range(c);
low = low + range * low_range(c);
}
// low contient le message transmettre !
On peut appliquer cet algorithme notre message exemple, et on obtiendra lvolution
suivante :
SPACE 0.1 0.00 <= r < 0.10
A 0.1 0.10 <= r < 0.20
B 0.1 0.20 <= r < 0.30
E 0.1 0.30 <= r < 0.40
G 0.1 0.40 <= r < 0.50
I 0.1 0.50 <= r < 0.60
L 0.2 0.60 <= r < 0.80
S 0.1 0.80 <= r < 0.90
T 0.1 0.90 <= r < 1.00
FIGURE 2.25 Evolution du codage arithmtique de BILL GATES
0.2572167752 est la reprsentation arithmtique du message BILL GATES. En fait,
nimporte quelle quantit telle que 0.2572167752 <= x < 0.2572167756 peut en principe
reprsenter le message dsir. Le dcodage est relativement simple : sachant que le message
encod se trouve entre les bornes 0.2 et 0.3, on voit immdiatement que le premier caractre
est B. On soustrait ensuite 0.2 (la borne infrieure) au message, ce qui donne 0.0572167752,
ce que lon divise par lintervalle de probabilit du symbole B, soit 0.1 : le rsultat est
0.572167752, ce qui correspond lintervalle du symbole I, et ainsi de suite.
On utilise souvent un symbole spcial (EOF) pour encoder la fin du message, de
manire savoir quand le processus doit sinterrompre.
2.7.2 Considrations pratiques
Il nest gnralement pas pratique dutiliser des fractions dcimales avec un nombre
trs grand de digits; un message raisonnablement complexe peut facilement comprendre plu-
sieurs milliers de digits aprs la virgule, ce qui rend son traitement par des librairies de vir-
gule flottante tout fait illusoire. En pratique, plutt que de travailler avec des nombres
fractionnaires, on va travailler avec des entiers, en reprsentant 0 comme 0x00000.... et 1
comme 0xFFFFFFF...., ces deux quantits ntant pas limites vers la droite.
Ainsi, le travail avec des quantits fractionnaires infiniment longues se rduit un trai-
tement dentiers de longueur arbitraire, le rsultat tant systmatiquement considr comme
compris entre 0 et 1. Cette approche nest pas triviale, et a t rendue possible par les travaux
de P. Elsa.
Symbole low high
0.0 1.00
B 0.2 0.3
I 0.25 0.26
L 0.256 0.258
L 0.2572 0.2576
<Space> 0.25720 0.25724
G 0.257216 0.257220
A 0.2572164 0.2572168
T 0.25721676 0.2572168
E 0.257216772 0.257216776
S 0.2572167752 0.2572167756
2.8 Codage dordre suprieur
Au lieu de se borner coder des symboles isols, il peut tre avantageux de coder des
groupes de symbole. Ainsi, dans un texte en langue franaise, la probabilit dapparition de
la lettre Q est faible, mais la probabilit dapparition de la lettre U sachant que la lettre prc-
dente tait un Q est trs grande. On dira que U a une forte probabilit dapparition dans le
contexte Q. Inversment, sachant que lon a rencontr un W, la probabilit de voir un X ou
un K est pratiquement nulle. Ainsi, on devrait tre en mesure dobtenir de meilleurs taux de
compression en utilisant des groupes de symboles plutt que des symboles isols. Cette am-
lioration devrait tre valable pour tous les types de codage base statistique, soit Huffmann,
Shannon-Fano, et arithmtique.
En principe, il est possible dagir dune faon totalement identique dans un codage
dordre N que dans un codage dorde 0. Le problme est que les tables de probabilit des
combinaisons de symboles croissent avec la puissance de lordre du codage; si pour un
codage dordre 2, on obtient pour des symboles cods sur des bytes une table de 256*256
encore peu prs raisonnable, la situation se gte trs vite pour les codages dordre sup-
rieur. Lordre 3 requiert dj 16*10
6
valeurs, ce qui est prohibitif; dans un tel schma, mieux
vaut ne mme pas voquer des ordres suprieurs 3 !
2.8.1 Codage statique dordre 1
Gnralement, le codage de paires de symboles est effectu par des moyens trs sim-
ples : on associe chaque symbole une table de symboles comprenant tous les symboles pos-
sibles, obtenant ainsi une table carre de N*N positions. Ces positions vont mmoriser les
frquences dapparition des combinaisons de symboles.
Le codage dordre 1, quelle que soit la mthode permet dobtenir un lger gain, sans
que ce gain puisse tre qualifi de dterminant : la lourdeur de la table de frquences, et
lexamen pralable du message ncessaire linitialisation de la table font que le jeu nen
vaut pratiquement pas la chandelle.
2.8.2 Codage dynamique dordre 1
La solution, ici encore, est de recourir un codage dynamique. On dbute avec une
table vide, que lon complte progressivement lors de lapparition de nouvelles paires de
symboles. Comme nous lavons vu, cette opration implique la dfinition dun symbole sup-
plmentaire, <NEW> permettant la dfinition de nouveaux symboles en cours de compres-
sion.
Cette faon de faire permet, entre autres, dliminer la necessit de stocker des paires
de symboles extrmement peu probables, comme WX, QK, et autres squences gure usites
dans la langue franaise, lexception de certaines bandes dessines.
2.8.3 Codage dynamique dordre N
Il est possible, sur le principe du codage adaptatif, de tenir compte de contextes sup-
rieurs 1. Cette mthode est appele codage dynamique dordre N. Bien quutilisable aussi
bien dans le cadre dun codage de Huffmann que de Shannon-Fano, on la surtout utilise
dans le cadre du codage arithmtique.
Intressant sur un plan purement thorique, les avantages obtenus par un codage dyna-
mique dordre N ne suffisent gnralement pas justifier son utilisation en pratique. Il existe
de nombreuses variantes de ce type de codage, certaines amliorant leur efficacit en mainte-
nant un hit-parade des combinaisons les plus frquemment rencontres par-del les limites
dun document. Ces techniques permettent une convergence plus rapide de lalgorithme pour
des messages standard. Gnralement, ceci ne suffit toutefois pas pour battre des mthodes
de compression plus modernes, comme celles prsentes au chapitre suivant.
2.9 La compression Lempel-Ziv-Welch (LZW)
Un des algorithmes de compression les plus utilis en matire de compression d'infor-
mations en informatique est sans conteste le LZW. Cette mthode d'encodage sans perte est
trouve dans plusieurs formats tels que GIF ou TIFF et fait galement partie du standard de
compression de modem V.42bis et de PostScript niveau 2.
Entrevoyons les diffrentes tapes qui ont permis l'laboration de cet algorithme.
2.9.1 La mthode Lempel-Ziv
A la fin des annes septante, deux chercheurs israliens, Jacob Ziv et Abraham Lem-
pel, mettent au point une technique de compression encore plus sophistique, appele com-
pression LZ (d'aprs leurs initiales). Ils inauguraient la compression moderne, exploitant un
dictionnaire mobile sur le mme principe que la compression arithmtique. Ctait, depuis
Huffmann, la premire fois que lon mettait srieusement en doute lefficacit des mthodes
statistiques. Le principe est assez simple comprendre: pour coder un mot, comme "anti-
constitutionnellement", on peut effectivement le transmettre, ou ne transmettre que sa posi-
tion dans un dictionnaire contenant tous les mots possibles de la langue franaise. Dans le
deuxime cas, il ny a quun entier transmettre. Linconvnient est quil faut disposer dun
dictionnaire exhaustif. Lide matresse de LZ et des algorithmes dictionnaire est de crer
ce dictionnaire pendant le processus de compression.
Deux procds en drivent, connus sous les noms de LZ77 et LZ78, tablis d'aprs
leurs annes de cration. Ils reposent sur l'enregistrement de squences de caractres dans
une sorte de dictionnaires de "phrases", difi partir des donnes en entre, au fur et
mesure de la lecture du fichier compacter. Le texte qui reste compresser est compar au
contenu du dictionnaire. Ds qu'il rencontre une nouvelle squence, le moteur de compres-
sion vrifie sa prsence dans le dictionnaire. Si elle ne s'y trouve pas, il l'ajoute dans le dic-
tionnaire et place en sortie un symbole marqueur qui en identifie l'adresse dans une table
rserve cet usage. Si la table a dj t enregistre, le compresseur se contente de mettre la
table jour, en y reportant l'identifiant.
LZ77 est gnralement trouv dans la compression de texte et de programmes d'archi-
vage tels que compress, zoo, lha, pkzip, et arj. LZ78 quant lui est plus facilement utilis
pour compresser des donnes binaires tels que dans des bitmaps.
2.9.2 La mthode LZ78
Elle construit son dictionnaire comme un "arbre de phrases" ou chanes auquel un
caractre spcial est ajout pour chaque squence rencontre en cours de compression. Cette
dernire se fonde donc sur le remplacement d'une chane de texte longue par une rfrence
chiffre plus courte. Il faut partir d'un dictionnaire vide puis, pour compacter une squence,
rechercher la phrase la plus longue trouve dans le dictionnaire, encoder en sortie la rf-
rence chiffre trouve dans le dictionnaire ainsi que le caractre qui la suit, ajouter au dic-
tionnaire une nouvelle phrase constitue de la chane de caractre vrifie combine avec le
caractre et continuer jusqu' la fin du fichier.
2.9.3 La mthode LZ77
La compression LZ77 part d'une ide plus simple. L, le dictionnaire n'est autre que la
suite linaire et non filtre du texte prcdemment trait. La rfrence d'une de ces entres se
rsume au rappel de l'emplacement de la chane et du nombre de caractre qu'elle comprend.
En commenant au dbut d'un texte pour les traiter squentiellement jusqu' sa fin, on trou-
vera fatalement des squences de caractres ou des mots qui se rptent. Plutt que de
retranscrire intgralement un mot dj enregistr plus haut, mieux vaut lui rserver deux
octets. Le premier est destin indiquer l'emplacement de sa prcdente occurrence, sous la
forme d'une distance chiffre en nombre de caractres "remonter", le second contenant sa
longueur exprime galement en nombre de caractres : 16 bits, soit 2 octets suffisent alors
pour stocker un mot de 10 lettres qui non compress, occuperait 10 octets. Le gain de place
est remarquable pour un taux de compression quivalent 5 pour 1.
Imaginons le fichier compacter comme une immense chane de caractre se droulant
de gauche droite. Sur la gauche du tout premier caractre, nous plaons une fentre d'une
taille de 4096 caractres, adresss sur 12 bits, qui pour l'heure est encore vide. Cette fentre
(le dictionnaire du compresseur) glisse de gauche droite le long du texte, les caractres de
droite n'tant pas encore compresss. A chaque tape, l'enregistrement que le compresseur
crit en sortie comprend trois champs : la distance sparant la chane considre de sa prc-
dente occurrence, le nombre de caractres semblables entre les deux occurrences et, enfin le
premier caractre diffrent suivant la chane. S'il n'existe pas de correspondance dans le texte
dj trait, l'enregistrement reoit une distance de 0, une longueur de 0 et le caractre suivant.
La compression LZ77 n'est pas proprement parler optimise : Chaque enregistrement en
sortie comprend forcment trois champs renseigner qui, pourtant, ne sont pas toujours
ncessaires.
2.9.4 LZSS
La mthode LZSS (SS correspond aux inventeurs Storer et Szymanski) est une amlio-
ration sensible : elle simplifie les enregistrements crire en sortie en reportant soit une dou-
ble rfrence compose de l'adresse et de la longueur de la chane, soit un simple caractre.
Pour distinguer le type de l'enregistrement, il lui suffit de prfixer une rfrence par un bit 1
et un caractre par un bit 0.
2.9.5 La compression LZW
En 1984, pendant qu'il travaillait chez Unisys, Terry Welch modifia l'algorithme de
compression LZ78 pour implmenter des contrleurs de disques hautes performances. Il
observa que le caractre littral suivant le numro de "phrase" en sortie pouvait tre limin
et la compression amliore. L'ide tait de placer d'office dans le dictionnaire 256 phrases
initiales d'un caractre chacune. Tout ce qui resterait faire serait, en sortie, d'crire la rf-
rence de la phrase sans l'accompagner d'un littral. Ce dernier serait simplement considr
comme le premier caractre de la phrase suivante, et le dictionnaire serait incrment d'une
manire naturelle (avec limination, quand le dictionnaire est satur, des mots les moins uti-
liss)
Ce principe forme la base de la compression LZW (Lempel-Ziv-Welch). La mthode
est semblable la mthode RLE, mais appliques des suites d'octets. Elle connut un succs
immdiat et fut largement suivie aussi bien dans le monde UNIX que dans le monde DOS.
La force de LZW tant que c'est un algorithme de compression capable de travailler sur pres-
que n'importe quel type de donnes. Il est gnralement rapide aussi bien en phase de com-
pression que de dcompression et ne require pas l'utilisation d'instructions en virgule
flottante.
Le dcodage de donnes compresses l'aide de LZW est l'inverse du codage. Le
dcompresseur lit un code du flot de donnes compresses et ajoute le code au dictionnaire
s'il n'est pas encore prsent. Le code est ensuite traduit dans la chane de caractre qu'il repr-
sente et est crit dans le fichier de sortie non compress.
LZW va plus loin que les autres algorithmes de compression bas sur des dictionnaires
dans ce sens o il n'est pas ncessaire de conserver le dictionnaire pour la dcompression.
Nous avons vu que pour compresser des fichiers textes, LZW initialise les 256 premires
entres du dictionnaire avec les 256 caractres ASCII 8 bits (00h FFh) comme phrases.
Comme aussi bien le codeur que le dcodeur commencent avec un dictionnaire initialis
ces valeurs, le dcodeur n'a pas besoin d'avoir le dictionnaire original mais peut le recons-
truire lui-mme.
Le format TIFF comme d'autres formats graphiques utilise LZW. Dans TIFF, les don-
nes pixels sont empaquetes en deux bytes avant d'tre prsente au compresseur LZW.
Comme le format GIF permet des profondeurs d'images allant de 1 8 bits, il y a entre
2 et 256 valeurs de codes d'entres possibles pour le dictionnaire de LZW, donc le diction-
naire est initialis en consquence.
2.9.6 Retrait du bruit et diffrentiation.
LZW est un remarquable compresseur d'images pour des images dont les profondeurs
peuvent varier de 1, 8 ou 24 bits, ralisant des taux de compression commenant au mini-
mum avec les taux de RLE. Toutefois, du bruit dans une image peut dgrader le taux de com-
pression de manire significative. Enlever le bruit d'une image, gnralement en forant
zro le ou les deux bits de poids le plus faible de l'image, est recommand pour accrotre
l'efficacit de la compression.
Une autre mthode pour augmenter la "compressibilit" des donnes est de rduire la
quantit d'informations d'une image. Cette mthode est appele diffrenciation. L'ide est de
transformer des donnes de manire quelle soit plus facilement compressible. On utilise le
fait que des pixels adjacents dans une partie de tons continus ne varieront que trs peu entre
eux en valeurs. Si nous remplaons la valeur d'un pixel par la diffrence de valeurs entre ce
pixel et le pixel prcdent, on pourra rduire la quantit d'information enregistre sans perdre
de donnes.
2.9.7 Variation d'implmentation de l'algorithme LZW
Ces variations utilises dans diffrentes applications sont utilises pour accrotre l'effi-
cacit de LZW. Car un des points faible de LZW serait la longueur de chaque identifiant en
sortie (en bits) qui son tour dtermine la taille finale du dictionnaire. Ces identifiants font
en gnral de 9 15 bits de longueur. Les plus grands conviennent mieux aux fichiers impor-
tants mais, pour peu que les fichiers soient de petites taille, des identificateurs de taille plus
rduite donnent de meilleurs taux de compression.
Pour pallier cet inconvnient, PKZIP utilise une mthode dynamique de redimension-
nement des identifiants qui, de 9 bits au dbut, augmentent, dans une limite de 15 bits au fur
et mesure que le dictionnaire prend plus d'ampleur : le dictionnaire est remis zro quand
l'opration devient ncessaire.
Une autre variante de LZW s'engage observer constamment le processus de compres-
sion pour relever le moindre trou dans l'efficacit. Si un trou est dcouvert, le code du dic-
tionnaire le moins souvent utilis (Algorithme LRU) est cras au profit d'un nouveau code.
La variante LZMW construit des phrases en concatnant 2 phrases ensemble plutt
qu'en concatnant une phrase avec le prochain caractre des donnes. Ce qui implique un
dictionnaire plus complexe.
Paradoxalement, la difficult avec LZW est qu'il est simple implmenter... Ce qui
implique qu'on a le choix de dcider quand craser des phrases et la manire de procder
pour trouver de nouvelles phrases.
Les formats TIFF et GIF utilisent l'algorithme LZW dans sa mouture standard. Toute-
fois le format GIF traite chaque pixel comme tant une valeur spare en tenant compte de la
profondeur de chaque pixel alors que le format TIFF lira toujours des symboles d'entres de 8
bits sans regarder la profondeur des pixels. Dans ce dernier cas, chaque symbole peut conte-
nir un, moins que un, ou plus que un pixel suivant sa profondeur.

Compression

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Compression

Transféré par

Droits d'auteur :

Formats disponibles

Services de tlinformatique 23

CHAPITRE 2 Compression de donnes

Prob i ( )lb Prob i ( ) ( )

Vous aimerez peut-être aussi