Introduction
publicité
Projet d’algorithmique Master 2 ISV 2005-2006 Par Sébastien Vaie Projet d’algorithmique Compression de données Rapport Introduction ............................................................................................................................. 4 RLE ou Run Lenght Encoding ............................................................................................... 5 Introduction ......................................................................................................................... 5 Principe ................................................................................................................................. 5 Exemple :............................................................................................................................ 6 Performances et limitations ............................................................................................... 6 Exemple :............................................................................................................................ 6 Variantes ............................................................................................................................... 7 Conclusion RLE ................................................................................................................... 7 LZW ou Lempel-Ziv-Welch .................................................................................................... 8 Introduction ......................................................................................................................... 8 Principe ................................................................................................................................. 8 Exemple :............................................................................................................................ 9 Performances et limitations ............................................................................................... 9 Variantes ............................................................................................................................. 10 Conclusion .......................................................................................................................... 10 Huffman ou statistique ......................................................................................................... 11 Introduction ....................................................................................................................... 11 Principe ............................................................................................................................... 11 Exemple :.......................................................................................................................... 12 Exemple 2 :....................................................................................................................... 13 Performances et limitations ............................................................................................. 13 Variantes ............................................................................................................................. 14 Exemple :.......................................................................................................................... 15 Conclusion .............................................................................................................................. 16 Référence ............................................................................................................................ 17 Sébastien Vaie 2005-2006 page 3 Projet d’algorithmique Compression de données Rapport Introduction L’augmentation de la taille des données à stocker et les limitations matérielles de l’informatique ainsi que la démocratisation des transferts d’informations via les voies téléphoniques a forcé l’apparition de la compression. Afin de permettre le transfert de manière plus rapide sur les réseaux de l’information ainsi que le stockage plus important de données sur un même espace. La compression de données est comme son nom l’indique le fait de compacter des données afin qu’elles prennent moins de place. Ainsi, elles peuvent être transférées via le réseau plus facilement. Elle est utilisée dans tous les domaines qui sont en rapport de proche ou de loin avec l’informatique que ce soit la photo, la vidéo, le son, les programmes…. Elle comprend 2 grandes classes que l’on nomme la compression sans perte, qui ne détruit aucune donnée, et la compression avec perte qui permet la suppression de données qui sont moins importantes, ou comme pour les données destinées à une appréciation humaine qui peuvent être limitées par la perception humaine. Nous n’allons parler que des algorithmes de compression de données sans perte et plus précisément des 3 types d’algorithme les plus utilisés à savoir RLE, LZW, et hauffman. Sébastien Vaie 2005-2006 page 4 Projet d’algorithmique Compression de données Rapport RLE ou Run Lenght Encoding Introduction Le RLE est l’un des algorithmes de compression les plus anciens, il a été fait pour compresser tous types de données sans tenir compte de ce denier. Il est très utilisé car est relativement simple à implémenter. En contrepartie, le contenu de ces données va conditionner l’efficacité de la compression. En effet, cet algorithme fonctionne de telle manière qu’il va supprimer les redondances continues de bytes. Donc pour des données qui ont de nombreuses suites de bytes identiques la compression sera optimale mais pour des données de type texte où il y a peu de répétition continue du même caractère, il sera nettement moins performant. Principe Son principe est relativement simple. Il va parcourir le fichier en regardant les caractères un par un, si le suivant est le même il passe dans une boucle jusqu’à ce qu’il soit différent en même temps dans cette boucle pour chaque caractère identique il incrémente un compteur. Une fois sorti de cette boucle, il retourne en arrière du nombre de ce compteur, il remplace le premier caractère par un identificateur de compression, le deuxième par le compteur et le troisième par le caractère répété. Ensuite, il supprime les caractères répétés en plus (compteur – 3). Il est généralement prévu de mettre une contrainte sur les répétitions. En effet, l’algorithme ne va pas compresser des caractères qui ne sont répétés que 2 fois car cela augmenterait la taille de la chaîne de caractère. S’il y a une répétition de 2 caractères par la compression elle sera remplacée par 3 caractères ce qui fait un caractère de plus et donc cela sera sous performant. Sébastien Vaie 2005-2006 page 5 Projet d’algorithmique Compression de données Rapport Exemple : Chaîne à compresser : AAAAARRRRRROLLLLBBBBBUUTTTTTT On choisit comme caractère spécial : @ et comme seuil de répétition : 3 Après compression : @5A@6RO@4L@5BUU@6T Gain : 11 caractères soit 38%, Ce qui fait un gain relativement faible. Performances et limitations On peut donc dire que cet algorithme est relativement simple. En effet, puisque de manière générale il consiste en une simple boucle. Il est donc relativement aisé de le programmer. Il est également relativement simple à comprendre, il a également l’avantage qu’il peut coder n’importe quel type de données. Ce sont là ses points forts. Il a généralement un taux de compression d’environ 40% selon le type de données. Nous avons vu précédemment que le RLE pouvait compresser n’importe quel type de données. Il y a tout de même une limitation sur ce point qui n’est pas de l’ordre de l’algorithme mais surtout de l’efficacité. En effet, étant basé sur la répétition de caractères ou de bytes, le type de données modifiera considérablement le taux de compression. Car si les données à compresser ne présentent pas de répétition le fichier de sortie sera plus gros que l’original ce qui est donc problématique pour un système de compression. Ceci peut arriver avec des données de type texte ASCII. Exemple : Cannibalisation => 15 caractères Après le codage RLE : 1C1a2n1i1b1a1l1i1s1a1t1i1o1n => 28 caractères Ce qui nous donne un fichier de sortie de quasiment le double. Donc, le type de données ne conditionnera pas le succès ou l’échec de l’exécution de l’algorithme mais conditionnera plutôt le taux de compression. En revanche, il pourrait très bien marcher sur des types de données biologiques notamment les fichiers de génome qui sont représentés sous forme de texte mais dont leurs structures peuvent représenter beaucoup de répétition. Mais pour pallier un minimum à ces problèmes, il existe plusieurs variantes du RLE. Sébastien Vaie 2005-2006 page 6 Projet d’algorithmique Compression de données Rapport Variantes Il a donc été imaginé des méthodes de parcours différentes afin de pouvoir en quelque sorte augmenter le nombre de répétitions. En effet, au lieu de parcourir le fichier de gauche à droite les variantes peuvent le parcourir en colonne ou encore en ligne mais en prenant 4 bytes par 4 bytes à la place de toute ligne ou encore en zigzag ces différents types de parcours peuvent considérablement augmenter le taux de compression sur des types de données où la méthode standard est inefficace. Si on prend l’exemple d’un texte en français on a beaucoup plus de chance d’avoir des répétitions de caractères identiques en colonne que dans le sens de lecture. Figure 1- variantes de parcours Conclusion RLE On peut dire que cet algorithme est facile à comprendre et à utiliser et qu’il marche très bien sur certain type de données : tel que les images synthétiques, fichiers binaires, etc. Mais cette simplicité a un prix à savoir : l’utilisateur doit connaître le type de données qu’il va compresser sinon il risque d’avoir la mauvaise surprise que le résultat de sa compression prenne plus de place que l’originale et on peut imaginer que sur des systèmes critiques cela peut poser de gros problème. Sébastien Vaie 2005-2006 page 7 Projet d’algorithmique Compression de données Rapport LZW ou Lempel-Ziv-Welch Introduction On a pu remarquer que la principale orientation de recherche de codage sur les fichiers pour les compresser était axée en majorité sur les répétitions. Que ce soit les compressions avec ou sans perte. Le LZW ne déroge donc pas à cette règle. Il a donc pour but de trouver, de coder et de remplacer ces dernières. Cet algorithme est dit adaptatif car il n’est pas possible de connaître la taille du fichier de sortie. Car il est basé sur un système de dictionnaire que est modifié tout au long du codage du fichier. L’idée est qu’il est possible de coder une chaîne de caractères en formant systématiquement une nouvelle chaîne de caractères basée sur celle déjà rencontrée plus le nouveau caractère. Ces chaînes sont stockées et dans le fichier nous n’avons plus que l’adresse de la chaîne dans le dictionnaire. Cet algorithme est une modification de l’algorithme LZ 78. Principe La différence principale entre les méthodes LZ77 et 78 est l’implémentation initiale, dans le dictionnaire, d’une table comprenant 256 « phrases » initiale d’un caractère chacune ce qui augmente l’efficacité de la compression. Cet algorithme va donc fonctionner de la manière suivante: Il va lire le ficher et dès qu’il va rencontrer un « mot » qu’il ne connaît pas il va créer une nouvelle entrée dans le dictionnaire. Lorsqu’il va rencontrer une suite de caractères qu’il a déjà rencontré il va la parcourir jusqu’à la fin de cette « répétition ». Ainsi, quand un des caractères sera différent, il va remplacer la partie qu’il connaît déjà par la référence et ajouter à la fin le caractère en plus et entre ce nouveau mot dans le dictionnaire donc de proche en proche l’algorithme va apprendre de plus en plus de mot et sera de plus en plus performant. aaababbbaaabaaaaaaabaabb Division : |a|aa|b|ab|bb|aaa|ba|aaaa|aab|aabb index 01 2 3 4 5 6 7 8 9 10 Codage 0a|1a|0b|1b|3b|2a|3a| 6a | 2b | 9b Figure 2 LZ W Mais commencant par le mot vide (LZ78) Sébastien Vaie 2005-2006 page 8 Projet d’algorithmique Compression de données Rapport Exemple : Chaîne à coder: /WED/WE/WEE/WEB/WET Caractère lu /W E D / WE / WEE / WEB / WET Code ressorti / W E D 256 E 260 261 257 B 260 Nouveau code 256 257 258 259 260 261 262 263 264 265 266 /W WE ED /D /WE E/ /WEE E/W WEB B/ /WET Chaîne compressée ou encodée: /WED 256 257 256 260 261 257 B 260 T On dit donc de cet algorithme qu’il est adaptatif car il créé son dictionnaire au fur et à mesure de l’encodage du fichier. De plus, avec le fait le dictionnaire contient d’office les 256 chaînes les plus courtes cela évite d’avoir besoin de donner le dictionnaire avec le fichier compressé car lors de la décompression il aura la table initiale et donc comme les entrées se font en même temps que la lecture l’ordre d’entrée permettra lors de la décompression de pouvoir « reconstruire le dictionnaire » afin de retrouver le fichier originale. Performances et limitations Ce type de compression est relativement performant. En effet, cet algorithme a un taux de compression minimum proche du maximum des algorithmes de type RLE (40%) pour arriver, selon le type de données et le type de fichiers, à près de 50% de compression ce qui est très acceptable pour de la compression sans perte. Les performances sont d’autant plus acceptables si le fichier à compresser a une certaine taille. Effectivement, le fait que le dictionnaire se fasse au fur et à mesure implique une certaine longueur. La dernière amélioration apporter par Welsh permet de ne plus avoir besoin de fournir le dictionnaire pour la décompression. On sait également que ce type de compression n’est pas très performant sur les images de type photographique car il y a peu de succession de même enchaînement de pixel. Sébastien Vaie 2005-2006 page 9 Projet d’algorithmique Compression de données Rapport La deuxième limitation est plutôt d’ordre technique. Ce type d’algorithme est un peu plus compliqué à implémenter dû au mouvement de pointeur sur les fichiers. Et la dernière limitation est plus d’ordre légal. Ces algorithmes sont sous couvert de 2 brevets et donc ne sont pas libres de droit Variantes Il existe plusieurs variantes du LZW qui s’attaquent toutes plus ou moins au point faible de cet algorithme. Il est nécessaire que le fichier ait une certaine taille afin que l’algorithme soit optimal. La taille des identifiants du dictionnaire varie de 9 à 15 bites. La variante PKZIP va faire en sorte de redimensionner la taille de l’identifiant de sortie pour qu’il ne dépasse pas une certaine taille quand le dictionnaire prend de l’ampleur. La variante LZMW construit des phrases en concaténant 2 phrases ensemble plutôt qu’en concaténant une phrase avec le prochain caractère des données. Ce qui implique un dictionnaire plus complexe. Mais donne une progression plus rapide du dictionnaire et donc peut permettre de compresser des fichiers de plus petites tailles. Conclusion En conclusion, on a pu voir que cet algorithme est relativement performant pour presque tous les types de données et que son taux de compression est proche des 50%. Il va plus loin que les autres algorithmes à base de dictionnaire car il n’est pas nécessaire de fournir celui-ci pour la décompression. Sébastien Vaie 2005-2006 page 10 Projet d’algorithmique Compression de données Rapport Huffman ou statistique Introduction Le codage de Huffman a pour but de transformer une suite de caractères en suite de 0 et de 1 (préfixe) qui sont tous différents. De manière à ce que le code d’un caractère ne soit pas le préfixe d’un autre Exemple : 110 et 1101 problème de différenciation car 110 est contenu dans 1101 et donc lors de la décompression le système ne saurait pas de quel caractère il s’agit. La compression va donc se faire par transformation des caractères et non plus par réduction des occurrences (RLE ou LZW). Il va diminuer le nombre de bits occupés par les caractères qui ont une fréquence d’apparition élevée et augmenter celle des caractères qui ont une fréquence basse. Pour générer le code de chaque lettre cet algorithme va donc utiliser un arbre binaire. Principe Son principe est relativement simple. L’algorithme va parcourir tout le fichier à compresser et il va calculer la fréquence d’apparition de chaque caractère. Il les classe en fonction de cette fréquence de manière décroissante. Ensuite, pour chaque caractère il créé un arbre (une feuille), donc tant que le nombre d’arbre est supérieur à 1, il va fusionner les arbres qui ont la plus petite fréquence. Figure 3-exemple de codage Huffman Sébastien Vaie 2005-2006 page 11 Projet d’algorithmique Compression de données Rapport Dans le nœud ainsi créé il va mettre la somme des fréquences des feuilles ainsi que la concaténation des 2 caractères des feuilles. Une fois qu’il ne reste plus qu’un arbre il va associer chaque branche issu de chaque noeud avec la valeur de 0 ou 1. Si cette branche est GAUCHE elle aura comme valeur 0 sinon elle aura 1. Donc en partant de la racine on peut trouver le code de chaque caractère en étant assuré de l’unicité de celui-ci. Car par définition un arbre de Huffman est un arbre qui minimise : Σ f(i)D(i) De toute les feuilles i ou f() est la fréquence et D() la distance de la racine à la feuille i. Exemple : Texte : axabataaxbc 1 011 A5 010 X2 001 000 B2 T1 C1 0 1 Calculs des fréquences : 1 A→5 X→2 B→2 T→1 C→1 4 XB 0 2 TC 1 0 1 6 XBTC 0 11 AXBTC Résultat du codage : 1 Sébastien Vaie 2005-2006 001 1 010 1 001 1 1 011 010 000 page 12 Projet d’algorithmique Compression de données Rapport Exemple 2 : Résultat : 101010000111111110110111011000001101001100110111001000011100101100010111110 00011110100 ; Performances et limitations Au niveau des performances cet algorithme est proche du RLE: il compresse de 40% à 50% en moyenne, mais est applicable à quasiment tous les type de données (aussi bien texte que image) car il ne se base pas sur les répétitions successives de caractères. Donc on peut dire qu’il est relativement performant. En effet, pour trouver le code d’un caractère, il suffit de descendre l’arbre jusqu’à ce caractère. Le processus est relativement rapide et n’engendre pas de perte d’espace (problème du RLE). On peut également remarquer qu’à certaine étape il peut y avoir 2 regroupements de même fréquence. Cela ne pose pas de problème car l’algorithme les traitera dans l’ordre qu’il veut donc le codage sera différent mais l’efficacité sera la même. Il suffit juste que lors de la décompression l’algorithme ait le bon arbre. Le problème principale est qu’il faut transmettre la table ou l’arbre avec le fichier compressé et donc cela fait considérablement baisser l’efficacité de la compression. En effet, la table de fréquence va grossir en fonction de la compression mais elle a l’avantage de ne pas pouvoir grossir indéfiniment en effet elle ne contient au maximum que 256 caractères (dans le cas des textes). Sébastien Vaie 2005-2006 page 13 Projet d’algorithmique Compression de données Rapport Mais il peut arriver que la somme du fichier compressé plus la table de fréquence soit de taille plus importante que le fichier non compressé. Donc on peut affirmer tout comme le LZW que le codage de Huffman est plus performant sur de grand fichier. Rapport taille de fichier, taille de fichier compressé, taille de la table de fréquence. Une autre limitation est que l’algorithme est extrêmement sensible à la perte d’un bit car cela peut complètement changer le fichier de sortie après décompression car le code ne sera plus valide. Variantes Comme toujours les variations d’algorithmes, basent leurs actions sur leurs défauts principaux des algorithmes dont ils sont issus. Pour Huffman le principal problème est la transmission de la table de fréquence ou de l’arbre. Donc pour palier à ce problème il existe des formes adaptatives de l’algorithme de Huffman: C’est-à-dire des formes qui créées leurs arbres au fur et à mesure de la compression et de la décompression. En effet, il part d’un arbre quasiment vide à l’exception de deux symboles qui sont <NEW>et <EOF> qui sont pondérés d’une fréquence de 1. Le symbole new permet l’addition de nouveau caractère dans l’arbre quand l’algorithme en rencontre. S’il rencontre un caractère qui est déjà présent dans l’arbre les règles strictes d’addition et de déplacement des arbres binaires équilibrés évitent d’avoir à reconstruire tout l’arbre. Donc l’arbre va ainsi pouvoir être créé au fur et à mesure de la compression ou de la décompression. Ce qui évite de devoir fournir la table de fréquence et ce qui augmente sensiblement la performance de la compression. Ainsi cette forme palie aux principaux désavantages de type d’algorithme. Sébastien Vaie 2005-2006 page 14 Projet d’algorithmique Compression de données Rapport Exemple : Codage de la chaîne BAN Insertion de B Insertion de A Ainsi, après 3 itérations on obtient le codage désiré. On peut remarquer que lors de l’insertion de nouveau caractère le code change. Ce type de compression permet un gain au niveau de la compression mais est un peu plus lent que la forme statique. En effet, étant généralement par récurrence, il demande un peu plus de temps machine Sébastien Vaie 2005-2006 page 15 Projet d’algorithmique Compression de données Rapport Conclusion En conclusion générale, on peut dire que les compressions sans perte ont un taux de compression maximum proche de 50%. On a pu voir également que ces algorithmes sont capables de traiter tous les types de données mais que les performances y étaient directement liées. A l’exception des algorithmes de type statistique (Huffman). Le principe des autres algorithmes est toujours sensiblement le même : il se base sur la suppression de répétition. On a pu voir également que la taille des fichiers à compresser influençait beaucoup les performances. Donc la chose primordiale avant d’utiliser un algorithme de compression c’est de connaître le type de données ainsi que leurs tailles. En résumé on peut dire que le RLE est parfait pour des fichiers de taille importante et ayant un grand nombre de répétitions successives tel que les fichiers de génome. Mais est très peu performant sur les données de type texte ou image photographique. Le Huffman est quant à lui parfait pour tous types de données même s’il est influencé par la taille de ces dernières. Il est plus efficace sur les gros fichiers dus à la présence de sa table de fréquence (voir Huffman adaptatif). Donc il est parfait pour les textes et les images de taille suffisante. Et en dernier le LZW est certainement le plus performant car il a des limitations mais elles influent moins sur les taux de compression. Parfait pour quasiment tous types de données, moins performant sur les images. Le seul problème est qu’il n’est pas libre de droit. Enfin, on peut dire que selon le type de données que l'on a traité il est facile de faire le bon choix et de ne pas utiliser des algorithmes très compliqués pour des types de données qui pourraient être compressés par des algorithmes relativement simples (RLE). Ne pas utiliser l’artillerie lourde pour écraser un moustique. Sébastien Vaie 2005-2006 page 16 Projet d’algorithmique Compression de données Rapport Référence section 6.1 de Folk, Zoellick & Riccardi, File Structures, An Object-Oriented Approach with C++ Compression de Données Sans Pertes, MM. S.Maadi, Y. Peneveyre, et C. Lambercy TIPE sur la compression de données informatiques, BENOIT Christophe DUSSON Alexandre Introduction à l’alguorithmique, Sébastien Vaie 2005-2006 page 17
