La compression de données

Pour obtenir un stockage plus compact, la première solution envisagée est la compression de données. Une telle fonctionnalité peut être requise par manque de mémoire ou pour archiver une partie des données qui doivent être conservées durant une période assez longue. Différents algorithmes de compression sont disponibles mais tous ne sont pas adaptés pas aux RSCF. L’objectif visé n’est pas uniquement de minimiser la mémoire utilisée. Il consiste également à réduire l’énergie consommée soit en limitant le nombre de programmations de la mémoire Flash soit en diminuant les quantités d’informations transmises.

Pour pouvoir être utilisé dans une application de RCSF, un algorithme de compression doit respecter un ensemble de contraintes associées aux ressources disponibles. La principale source de limitation est, a priori, la puissance et le temps de calcul nécessaire pour exécuter correctement l’algorithme [Sadler 2006]. Cependant, la mémoire requise pour stocker les calculs intermédiaires, ainsi que l’énergie consommée durant l’exécution de l’algorithme, sont également à prendre en considération [Puthenpurayil 2007].

Le choix de l’algorithme est également conditionné à la qualité des données compressées recherchées c’est-à-dire à l’utilisation d’une compression avec ou sans perte.

Cette qualité dépend généralement du format des informations échangées. Pour des images, du son, voire des vidéos, la compression avec perte est, dans la plupart des cas, utilisée. En revanche, pour les flux ou les fichiers de données classiques, une compression sans perte est quasi obligatoire. Des exemples de techniques de compression avec perte sont :

• Compression d’images

o JPEG (Joint Photographic Experts Group)

• Compression vidéo

o MPEG (Moving Picture Experts Group)

• Compression audio

o MP3 (MPEG-1 Audio Layer 3)

Quant aux techniques de compression sans perte, on peut citer :

• Compression d’images

o PNG (Portable Network Graphics)

• Compression de flux de données

o GZIP (GNU Zip) [Deutsch 1996a]

Ces dernières font appel à des algorithmes de compression sans perte tels que Huffman [Huffman 1952], LZW (Lempel-Ziv-Welch) [Welch 1984] ou DEFLATE [Deutsch 1996b]

Le système LiveFile a été développé pour répondre aux deux grandes catégories d’applications de RCSF :

• les applications d’acquisition de données ;

• les applications de substitution d’une infrastructure fixe de réseau.

CemOA : archive ouverte d'Irstea / Cemagref

Les applications de cette deuxième catégorie peuvent impliquer la transmission de flux audio et vidéo. Cependant, dans ce cas, le RCSF sert de support à la communication. Toute compression de données avec perte ne peut avoir lieu qu’au niveau des entités faisant appel au RCSF. Par conséquent, une étude a été menée pour équiper le système LiveFile d’un algorithme de compression sans perte.

3.3.1.1 Le codage par plages RLE

L’une des premières solutions envisagée est l’utilisation du codage par plages ou

« run-length encoding » (RLE). Le principe de fonctionnement de ce codage consiste à considérer les séquences de « n » caractères identiques successifs. Plus ces séquences sont longues, plus le taux de compression est important (voir Figure 3.21). Il est généralement utilisé pour compresser des images. L’intérêt d’une telle méthode de compression pour les RCSF existe pour des applications de surveillance de grandeurs peu variables. Par exemple, pour détecter les incendies de forêt, des capteurs de température peuvent être utilisés et effectuer des relevés à des fréquences très élevées (toutes les minutes). Le nombre de valeurs successives identiques est, dans cette situation, très important.

Figure 3.21 – Illustration du codage RLE

Cependant, certaines applications nécessitent de stocker, en plus de la valeur acquise, un ensemble de renseignements sur la date et le lieu de prélèvement. Pour ce faire, dans le système LiveFile, le type « RECORD » est, la plupart du temps, associé à une structure de données complète listant les différents attributs associés à la donnée acquise. La répétition de valeurs identiques successives en est donc assez limitée. Cette solution a l’avantage d’être l’une des moins consommatrice de ressources et de permettre de compresser, sans conversion, différents formats de données (caractères, chiffres, pixels, etc.).

CemOA : archive ouverte d'Irstea / Cemagref

3.3.1.2 Le codage d’Huffman

Le codage d’Huffman est une méthode de compression de type statistique. Son fonctionnement repose sur le principe suivant : plus un symbole est fréquent, plus son codage doit être court. Inversement, un symbole rare a un codage plus long. Par exemple, si l’on considère un texte en français, la lettre « e » aura un codage plus petit que la lettre « z ».

La première étape du codage d’Huffman consiste à déterminer la distribution des différents symboles présents dans l’élément à compresser. Elle implique la construction d’un arbre binaire dit d’Huffman. Chaque feuille de celui-ci contient un symbole avec son nombre d’occurrences faisant office de poids. Les nœuds de l’arbre sont ensuite créés, de manière itérative, par la réunion des feuilles de poids les plus faibles restantes (voir Figure 3.22). A chaque niveau de l’arbre, l’ordre d’assemblage est propre à l’alphabet considéré.

Figure 3.22 – Illustration du codage d’Huffman

Le codage d’Huffman existe sous 3 formes différentes suivant le mode de création de l’arbre choisi :

• création statique de l’arbre ;

• création semi-adaptative de l’arbre ;

• création adaptative de l’arbre.

Dans le premier cas, le codage de chaque symbole est connu dès le départ et est issu d’un arbre élaboré préalablement. Pour réaliser la compression et la décompression des données, il faut posséder la table de conversion dérivée de cet arbre. Pour la création semi-adaptative, un ensemble de données ou un fichier est pris comme référentiel pour construire l’arbre utilisé. Chaque nouveau flux de données reçues par la suite sera compressé à l’aide des informations issues de cet arbre. Le dernier mode implique la construction d’un arbre pour chaque ensemble de données à compresser.

CemOA : archive ouverte d'Irstea / Cemagref

3.3.1.3 L’algorithme LZW

L’algorithme LZW est une méthode de compression utilisant un dictionnaire qui est totalement ou en partie construit dynamiquement. Généralement, le dictionnaire contient au départ le code des symboles simples. Il est ensuite progressivement enrichi à partir des codes créés pour compresser des mots composés de plusieurs symboles simples.

L’exemple le plus souvent utilisé pour présenter l’algorithme LZW est la compression d’une chaîne de caractères. Le dictionnaire possède au départ le code ASCII de tous les caractères simples allant de 0 à 255. Par conséquent, le prochain élément rencontré constitué d’un couple de caractères sera codé avec le nombre 256 (voir Figure 3.23). Un caractère au format ASCII étant codé sur 8 bits, avec cette méthode, deux caractères voire plus le seront sur 9 bits au lieu de 16. Au fur et à mesure de la rencontre de nouveaux mots, le codage sur 9 bits peut ne pas suffire. Ce problème requiert soit un bon dimensionnement du codage au préalable soit des mécanismes pour indiquer un changement de format au niveau du codage.

Figure 3.23 – Illustration de l’algorithme LZW

3.3.1.4 Bilan sur la compression de données

Les méthodes étudiées font appel à des techniques de compression de données sans perte assez différentes. En effet, par exemple, le codage de Shannon-Fano n’a pas été présenté car son principe de fonctionnement est proche de celui du codage d’Huffman. Chacun des algorithmes présentés dispose d’avantages et d’inconvénients par rapport à une utilisation dans un RSCF.

Pour comparer ces 3 méthodes, des tests de compression sur différents types de fichiers sont envisageables. Cependant, la méthode qui affichera les meilleures performances globalement, pourrait être pénalisée sur certains jeux de données. La notion d’entropie peut être utilisée pour déterminer l’algorithme avec potentiellement le taux de compression le plus performant [Shannon 1948]. Cette notion tend à estimer la quantité d’informations contenues dans un texte. Elle donne donc des indications sur la limite théorique de compression. De par son mode de fonctionnement statistique, le codage d’Huffman est celui qui se rapproche le plus de l’entropie.

Cependant, le critère du taux de compression n’est pas le seul à prendre en considération au niveau des RSCF. A ce titre, les inconvénients de la méthode d’Huffman sont l’utilisation d’un codage de taille variable, la nécessité dans certains cas de la

CemOA : archive ouverte d'Irstea / Cemagref

construction d’un arbre assez volumineux. De plus, l’arbre doit être transmis pour effectuer la décompression ce qui n’est pas le cas si l’on utilise le code ASCII pour initier l’algorithme LZW. Le code RLE ne nécessite, quant à lui, aucune transmission de dictionnaire ou de table de conversion (voir Table 3.2).

Algorithmes Avantages Inconvénients

Codage par plages Puissance de calcul nécessaire Faible niveau de performance Codage d’Huffman Niveau de performance élevé Construction de l’arbre

Diffusion du codage Algorithme LZW Niveau de performance élevé Construction du code

Table 3.2 – Comparaison des différentes méthodes de compression de données

Toutes ces méthodes ont été développées dans un cadre général. Or, dans les applications d’acquisition de données, les grandeurs observées sont connues avant le déploiement du RCSF. Cette connaissance ainsi que certaines des caractéristiques des grandeurs observées sont utilisables pour optimiser la méthode de compression. Le contexte d’application peut donc intervenir dans l’élaboration du dictionnaire de codage.