Portable Network Graphics

PNG est particulièrement approprié lorsqu’il s’agit d’enregistrer des images synthétiques destinées au Web comme des graphiques, des icônes, des images représentant du texte (bonne conservation de la lisibilité), ou des images avec des dégradés. Le PNG surpasse régulièrement le format GIF en ce qui concerne la réduction de la taille des fichiers (avec une palette de couleurs bien choisie) ou la qualité (puisqu’il n’est pas limité à 256 couleurs).

Les caractéristiques de PNG lui permettent d’enregistrer des photographies sans perte de données, au détriment de la taille du fichier qui reste logiquement très supérieure à celle de formats avec perte de données destinés aux photographies, comme JPEG ou JPEG 2000.

La présence d’un canal alpha définissant différents niveaux de transparence le rend idéal pour la composition sur les pages web. Cette caractéristique est bien implémentée par la majorité des navigateurs web.

Lorsque l’image PNG utilise une palette de 256 couleurs maximum, il est possible d’utiliser une des couleurs pour la transparence.

C’est le même comportement qu’avec le format GIF et cela fonctionne même avec Internet Explorer 6. Par conséquent, les images Web au format GIF peuvent être converties en cette version de PNG sans crainte d’incompatibilité avec la majorité des navigateurs web actuels (premier trimestre 2006), et sans souci de brevet (le brevet GIF est entré en 2006 dans le domaine public).

Le PNG, d’ailleurs parfois appelé par récursivité PNG’s Not GIF (PNG n’est pas GIF), peut faire tout ce que le format GIF peut faire et même plus, comme la translucidité. Il n’a cependant pas été prévu pour faire des images animées, mais le format dérivé MNG a été créé par ses auteurs à cet effet (voir également le format APNG).

Les deux formats peuvent être entrelacés, mais PNG utilise l'algorithme Adam7 tandis que GIF affiche dans ce cas l'image ligne par ligne.

1. signature PNG - 8 octets
2. chunk IHDR pour l'en-tête - 25 octets
3. chunk IDAT pour les données - longueur variable
4. chunk IEND pour la fin de fichier - 12 octets

Un « chunk » est un gros morceau du fichier, un fragment d'information constituant une entité. Ce terme anglais est utilisé dans de nombreux formats multimédias.

Un fichier peut contenir plusieurs chunks de données IDAT ainsi qu'un chunk PLTE pour la palette à utiliser s'il s'agit d'une image dont les couleurs sont indexées.

Un fichier peut également contenir d'autres chunks secondaires, dont des informations textuelles.

Un fichier PNG commence par une signature de 8 octets représenté par les valeurs décimales suivantes : 137 80 78 71 13 10 26 10, ou en hexadécimal: 89 50 4E 47 0D 0A 1A 0A.

La suite du fichier est décomposée en plusieurs parties de longueurs variables, appelées chunk.

Il existe 18 chunks officiels, dont 4 principaux et 14 secondaires[1].

Les chunks sont étiquetés (nommés). La casse est importante dans les noms des chunks. Chaque étiquette est définie par quatre caractères successifs, définissant un code mnémonique, sous forme de fourCC. Pour chaque chunk, si la première lettre de son nom est en capitale il s'agit d'un chunk critique, sinon c'est un chunk auxiliaire[2].

Voici un tableau regroupant les chunks les plus utilisés (les quatre principaux en tête) :

Les autres dix chunks secondaires sont :

D'autres chunks peuvent également être définis. Ils sont soit publics, soit privés, mais doivent répondre au règles de nommage[2]. Un chunk public doit avoir été enregistré auprès du W3C, l'autorité désignée par l'ISO/IEC[3].

Voici les chunks publics en usage[4] :

Un chunk est composé de 4 parties:

LENGTH : La taille en octets du chunk, seulement ses datas. On ne prend pas en compte la taille, le type, ni le CRC.

TYPE : Le nom du chunk (ex : IHDR, IDAT, IEND, etc.).

DATAS : Les informations relatives au chunk sur n octets (relatif à LENGTH).

CRC : 4 octets de contrôle généré en utilisant l'algorithme suivant :

fonction maj_crc((entier positif 4 octets) crc, (entier positif 1 octet) bloc(), (entier positif 4 octets) taille)
 //le premier argument, crc, lors du premier appel de cette fonction pour un chunk donné, doit être 0xffffffff (tous les bits à 1)
 //sinon, il doit s'agir de la valeur retournée par le précédent appel de cette fonction
 //le deuxième argument, bloc(), est une liste d'éléments d'un octet. Il s'agit de tout ou partie du chunk
 //le troisième argument, taille, est le nombre d'éléments de la liste bloc()
 (entier positif 4 octets) c, n, v
 c=crc
 pour n de 0 à (taille-1)
  //normalement, cette boucle ne contient qu'une seule instruction mais, ici, elle est subdivisée en quatre instructions. C'est plus lisible ainsi
 //il y a une itération de cette boucle pour chacun des octets de la partie DATA du chunk, dans l'ordre de leurs positions dans le chunk
  //xb=ou exclusif bit à bit
  v=c xb bloc(n)
  //eb=et bit à bit; tout nombre préfixé par 0x est en base 16
  //on met à 0 les bits des trois premiers octets, vu que leur valeur ne dépend pas de celle de bloc(n)
  v=v eb 0xff
  //table_crc() est une liste de 256 constantes, des entiers codés sur quatre octets (voir ci-dessous)
  v=table_crc(v)
  //div=division entière
  c=v xb (c div 256)
 fin pour
 retourner c
fin fonction

Une fois tout le chunk parcouru, la valeur renvoyée par le dernier appel de maj_crc() n'est pas celle du crc. il faut encore inverser la valeur de chaque bit :

fonction validation_crc((entier positif 4 octets) crc)
 retourner (crc xb 0xffffffff)
fin fonction

La liste table_crc() se trouvant dans maj_crc() est constituée de valeurs arbitraires mais calculables. certaines implémentations listent ces valeurs (alors calculées à l'avance) et les stockent directement dans la variable tandis que d'autres contiennent l'algorithme (généralement une fonction) permettant de les calculer :

fonction calcul_table_crc()
 (entier positif 4 octets) c, i, j
 pour i de 0 à 255
  c=i
  //8 itérations
  pour j de 0 à 7
   //retourne 0 (faux) si c est pair et 1 (vrai) si c est impair (en dehors du dernier,tous les bits du résultat sont à 0)
   si (c eb 1)
    //la valeur 0xedb88320 (11101101 10111000 10001100 00100000 en binaire et 3 988 292 384 en décimal) est arbitraire
    //c étant, dans ce cas, nécessairement impair, c div 2 équivaut à (c-1)/2
    c=0xedb88320 xb (c div 2)
   sinon
    c=c/2
   fin si
  fin pour
  table_crc(i)=c
 fin pour
fin fonction

L'exemple du chunk IHDR est constitué des données binaires, représentées ici en hexadécimal, suivantes :

00 00 00 0D 49 48 44 52 00 00 03
20 00 00 02 58 10 06 00 00 00 15
14 15 27

Ces données sont à interpréter selon le tableau.

La compression peut être effectuée grâce à la bibliothèque zlib (C/C++). Il est aussi possible de générer le CRC grâce à cette bibliothèque.

• Format ouvert
• Image numérique
• Image matricielle

Autres formats :

• GIF
• JPEG
• WebP
• TIFF
• BMP
• APNG
• JNG
• MNG

• (fr) La page francophone du format PNG
• (en) Page du PNG - Sur le W3C
• (en) Page officielle du format PNG
• (fr) Page d’explication de Microsoft - Sur la manière d'utiliser le PNG dans un site pour qu’il soit lu par Internet Explorer