RFC: 2083
Statut : Proposition
Retour à l'index des normes : INDEX FRANCAIS

5. Compression par déflation/inflation

La méthode de compression 0, supportée par PNG (la seule actuellement disponible) définit une compression par déflation/inflation utilisant une fenêtre glissante de 32K. La compression par déflation est un dérivé du LZ77 utilisé dans les programmes zip, gzip, pkzip et assimilés. Notre groupe de travail a mené des recherches exhaustives pour garantir la liberté de droits du procédé. Des implémentations en langage C entièrement portables sont disponibles gratuitement.

Des flux compressés par déflation sont enregistrés sous le format "zlib", selon la structure suivante :

Les détails de ce codage sont donnés dans la spécification zlib [RFC-1950].

Dans la méthode de compression PNG 0, le code méthode de compression/flags doit préciser la méthode 8 ("déflation") et une taille de fenêtre LZ77 au plus de 32K. Notez que le code de méthode "zlib" et le code compression PNG n'ont pas de relation. La position des flags additionnels ne doivent pas spécifier un quelconque dictionnaire.

Les données compressées dans les données zlib sont organisées sous forme d'une série de segments, chacun pouvant représenter des données brutes (non compressées), des données compressées selon un LZ77 encodé par codes Huffman standards, ou compressées selon un LZ77 encodé par codes Huffman personnalisés. Un bit marqueur dans le dernier segment signale la fin du flux à l'intention du décodeur. Les détails du processus de compression et d'encodage sont donnés par la spécification RFC-1951.

La valeur de vérification enregistré à la fin du flux zlib est calculé sur les données non compressées incluses dans le flux. Notez que cette valeur n'est pas calculé selon l'algorithme de CRC utilisé pour la vérification de blocs PNG. Cette valeur de vérification zlib est surtout utilisée pour vérifier que les implémentations de la déflation et de l'inflation sont compatibles et cohérentes. Le CRC de bloc PNG, quant à lui, permet de s'assurer que le bloc PNG a été transmis correctement. Dans un fichier PNG, la concaténation de tous les segments de données transportés par la série de blocs IDAT donne le flux zlib décrit ci-dessus. Ce flux, décompressé, produit l'image filtrée selon le procédé décrit dans ce document.

Il est important d'insister sur le fait que les blocs IDAT "découpent" ce flux tout à fait arbitrairement, et que la fin des données d'un bloc IDAT peut intervenir n'importe où dans le flux zlib. Il y aura peu de chance d'avoir une quelconque corrélation entre le découpage en blocs IDAT et le découpage selon les blocs "déflatés". Par exemple, il sera possible que la valeur de vérification d'un segment zlib se retrouve à cheval entre deux blocs IDAT.

Dans le même ordre d'idées, il n'y a aucune corrélation entre la structure de l'image (c'est à dire, les limites des lignes) et les limites de segments de données compressées ni de blocs IDAT. L'image est représentée par l'intégralité du flux zlib enregistré sous forme d'un certain nombre de blocs IDAT; un décodeur qui prendrait toute considération autre serait incorrect. (Bien sûr, certaines implémentations d'encodeurs pourraient introduire ce genre de corrélation. Mais les décodeurs ne doivent pas compter dessus).

Le format PNG utilise aussi la technique zlib dans les blocs zTXt. Dans un tel bloc, la fin du bloc qui suit l'octet codant le type de compression est un flux zlib tel que spécifié ci-dessus. Ce flux, une fois décompressé, contient le texte en clair associé au mot-clef. Contrairement aux données de l'image, le texte ne peut être partagé entre plusieurs blocs zTXt; chaque bloc zTXt contient un flux zlib autonome et indissociable. Une documentation complémentaire et une implémentation source en C pour la déflation et l'inflation sont disponibles dans les archives Info-zip.