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

4. Spécifications des blocs

Ce chapitre définit les blocs PNG prédéfinis.

4.1. Blocs critiques

Toute implémentation doit être en mesure de comprendre et correctement afficher les blocs critiques standard. Une image PNG valide doit contenir un bloc IHDR, au moins un bloc IDAT, et enfin un bloc IEND.

4.1.1. En tête image IHDR

Le bloc IHDR doit apparaître EN PREMIER. Il contient :

La largeur et la hauteur donnent les dimensions de l'image exprimées en pixels. Elles sont représentées chacune par un entier non signé sur 4 octets. La valeur zéro est invalide. La dimension maximum est (2^31)-1 pixels dans les deux directions, de manière à s'accommoder aux langages ayant des difficultés à traiter les entiers non signés de 4 octets.

La valeur de profondeur d'échantillonnage est un entier sur un octet donnant le nombre de bits par échantillon ou par entrée de la palette (et non par pixel dans ce cas). Les valeurs valides sont 1, 2, 4, 8, et 16, toutes ces valeurs n'étant pas autorisées selon le type de codage couleur. Le type couleur est codée sur un octet et décrit le type de modèle colorimétrique utilisé pour l'image. Le code de type couleur est une somme des commutateurs suivants: 1 (palette utilisée), 2 (couleur utilisée), et 4 (canal alpha utilisé). Les valeurs valides sont 0, 2, 3, 4, et 6.

Des restrictions en profondeur de bit sont imposées pour chaque modèle de couleurs afin de simplifier l'implémentation et pour interdire des combinaisons qui pourraient poser des problèmes de compression. Les décodeurs doivent supporter toutes les combinaisons "légales" de profondeur d'échantillonnage et de type de modèle de couleur. Ces combinaisons autorisées sont :

La profondeur d'échantillonnage est toujours identique au nombre de bits par échantillon (d'un canal de couleur élémentaire) sauf dans le cas du type 3, pour laquelle l'échantillonnage est toujours sur 8 bits. La méthode de compression est donnée sous forme d'un entier sur un octet qui indique quelle méthode est utilisée pour compresser les données image. A ce jour, seule la méthode de compression 0 (déflation/inflation avec fenêtre glissante de 32K) est définie. Toutes les images standard PNG doivent être compressées par cette méthode. Ce champ n'est implanté que pour des développements futurs ou pour son utilisation par des implémentations propriétaires. Les décodeurs doivent vérifier cet octet et afficher une erreur si un code non valide est détecté. Cf. Compression par Déflation/Inflation (Chapitre 5).

La méthode de filtrage est représentée par un entier sur un octet et indique la méthode de pré-traitement appliquée à l'image image avant la compression. A l'heure actuelle, seule la méthode de filtrage 0 (filtrage adaptatif par cinq filtres prédéfinis) est définie. Tout comme pour la méthode de compression, les décodeurs devront afficher une erreur en cas de code non valide. Cf. Algorithmes de Filtrage (Chapitre 6).

La méthode d'entrelacement est donnée sous forme d'un entier sur un octet indiquant l'ordre de transmission des données de l'image. Deux valeurs sont possibles actuellement: 0 (pas d'entrelacement) ou 1 (méthode Adam7). Cf. Entrelacement des données (Section 2.6).

4.1.2. Palette : bloc PLTE

Le bloc PLTE contient de 1 à 256 entrées de palette, chacune codée par trois octets donnant la valeur des canaux :

Le nombre total d'entrées est déterminé à partir de la taille du bloc palette. Une longueur des données de ce bloc qui ne serait pas divisible par 3 indique une erreur. Ce bloc apparaît dans le cas d'un modèle de couleur de type 3, peut apparaître pour les modèles 2 et 6, et est absent dans le cas des modèles 0 et 4. En cas de présence, il doit précéder le premier bloc IDAT. Il ne peut y avoir qu'un bloc PLTE dans un ficher.

Pour le modèle de couleur 3 (couleurs indexées), le bloc PLTE est indispensable. La première entrée de la palette PLTE code la valeur notée 0 de pixel, la seconde entrée la valeur notée 1, etc. Le nombre d'entrées de palette ne peut excéder la profondeur bit définie pour les pixels (par exemple, 2^4 = 16 pour une profondeur bit de 4). Le cas où moins d'entrées de palette que ce que la profondeur bit permet est admis. Dans ce cas, tout pixel dont l'index sort de la plage définie par la palette indique une erreur.

Pour les modèles de couleur 2 et 6 (couleur vraie avec ou sans alpha), le bloc PLTE est facultatif. S'il est présent, il définit l'ensemble de 1 à 256 couleurs le plus convenable dans le cas où l'utilisateur de l'image ne peut afficher celle-ci en vraies couleurs (palette préférentielle). Si PLTE n'est pas présente, le client devra choisir ces couleurs de lui-même, mais il sera largement préférable que ce choix ait été fait auparavant par l'encodeur. Cf. Recommandations pour les Encodeurs: Palettes Préférentielles, Section 9.5.

Notez que la palette utilise des couleurs codées en 8 bits (1 octet) par canal chromatique indépendamment de la profondeur bit de chaque pixel. En particulier, la palette a toujours une profondeur de 8 bits même s'il s'agit d'une quantification suggérée d'une image en vraies couleurs sur 16-bits. Il n'y a aucune obligation que toutes les couleurs soient définies, ni utilisées dans l'image. Il n'y en a pas plus que toutes les couleurs y soient différentes.

4.1.3. Données image: bloc IDAT

Le bloc IDAT contient les données de l'image contenue dans le fichier. Pour créer ces données :

• Commencer par les lignes de pixels représentés par la description donnée dans le chapitre Codage de l'image (Section 2.3); la disposition et la taille totale de ces données brutes sont déterminées par les champs du bloc IHDR.
• Filtrer l'image selon la méthode spécifiée dans le bloc IHDR. (Notez qu'avec la méthode 0, la seule actuellement définie, il est nécessaire de faire précéder chaque ligne d'un octet indiquant le type de filtrage).
• Compresser l'image filtrée avec la méthode spécifiée dans le bloc IHDR.

Les blocs IDAT contiennent les données obtenues en sortie de l'algorithme de compression. Pour lire l'image, il suffit d'inverser le processus.

Il peut exister plusieurs blocs IDAT; si c'est le cas, ils devront apparaître consécutivement sans autre blocs intermédiaires. Les données compressées seront alors la concaténation du contenu de tous les blocs IDAT. L'encodeur pourra diviser les données compressées en plusieurs blocs IDAT à sa convenance. (Cette multiplicité des blocs IDAT est permise pour que les encodeurs puissent travailler avec une quantité de mémoire fixée; typiquement, la taille de chaque bloc IDAT dépendra de la taille mémoire du tampon d'image attribué à l'encodeur). Il est important de noter que les limites des blocs IDAT n'ont aucune signification d'un point de vue sémantique et peuvent découper les données compressées à n'importe quel endroit du flux. A la limite, un fichier PNG dont les blocs IDAT ne contiendraient qu'un seul octet est parfaitement valide, bien qu'extrêmement dispendieux en place. (A ce sujet, même des blocs IDAT à zéro octets sont admis, la perte de place étant encore plus grande).Cf. Algorithmes de Filtrage (Chapitre 6) et Compression par Inflation/Déflation (Chapitre 5).

4.1.4. Bloc de fin d'image IEND

Le bloc IEND doit apparaître EN DERNIER. Il marque la fin du flux de données transportée par le PNG. La partie données de ce bloc est vide.

4.2. Blocs auxiliaires

Tous les blocs auxiliaires sont optionnels, en ce sens que certains encodeurs pourront les omettre, et les décodeurs pourront les ignorer. Cependant, nous encourageons le développement d'encodeurs qui écriront les blocs auxiliaires standards dans la mesure où l'information est disponible, et des décodeurs qui interprètent ces blocs dès que possible ou approprié.

Les blocs auxiliaires sont listés ci-après par ordre alphabétique. L'ordre dans lequel ils apparaissent dans un fichier est sans importance.

4.2.1. Couleur de fond : bKGD

Le bloc bKGD définit une couleur de fond "par défaut" pour l'affichage de l'image. Notez que les navigateurs ne sont aucunement tenus de respecter cette couleur; un navigateur pourra utiliser une couleur de son choix.

Pour le modèle de couleur 3 (couleurs indexées), le bloc bKGD contient:

La valeur donnée est l'index de la couleur dans la palette contenue dans le fichier. Pour les modèles de couleur 0 et 4 (niveaux de gris, avec ou sans canal alpha), le bloc bKGD contient :

(Par mesure de simplification, 2 octets sont utilisés quelle que soit la définition de l'image). La valeur donnée est le niveau de gris utilisée pour afficher le fond. Pour les modèles 2 et 6 (vraies couleurs, avec ou sans canal alpha), le bloc bKGD contient :

(Par mesure de simplification, 2 octets sont utilisés quelle que soit la définition de l'image). La valeur codée est la couleur RVB utilisée pour le fond.

Lorsqu'il est présent, le bloc bKGD devra précéder le premier bloc IDAT, et devra passer après le bloc PLTE, s'il existe.Cf Recommendations pour les Décodeurs: Couleur de Fond (Section 10.7).

4.2.2. Chromatisme primaire et point blanc : cHRM

Certaines applications d'affichage dépendant du matériel, et nécessitant une définition explicite des couleurs primaires pourront la trouver dans un fichier PNG. Il s'agira d'un bloc cHRM qui spécifie les coordonnées x,y du modèle chromatique CIE 1931 pour les couleurs rouge, vert, et bleu primaires, ainsi que la référence du point blanc. Cf. Modèles colorimétriques (Chapitre 14).

Le bloc cHRM contient :

Chaque valeur est codée selon un entier de 4 octets non signé, représentant les coordonnées x ou y multipliées par un facteur 100000. Par exemple, une coordonnée de 0,3127 sera enregistrée comme un entier de valeur 31270. Le bloc cHRM est autorisé dans tout fichier PNG, bien qu'il n'ait pas d'utilité pour les images en niveaux de gris. Si l'encodeur ne connaît pas ou ne peut obtenir les données chromatiques du système source, le bloc cHRM ne devra pas être écrit dans le fichier; l'absence d'un bloc cHRM au décodage indique que les couleurs primaires de l'image dépendent du système utilisé.

Si le bloc cHRM est présent, il devra précéder le premier bloc IDAT, et devra précéder un bloc PLTE s'il existe.Cf. Recommandations pour les Encodeurs: Gestion des Couleurs (Section 9.3), et Recommandations pour les Décodeurs: Gestion des couleurs (Section 10.6).

4.2.3. Gamma de l'image : gAMA

Le bloc gAMA code le gamma de la caméra (réelle ou virtuelle) qui a produit l'image, et donc le gamme de l'image originale. Plus précisément, le bloc gAMA code la valeur file_gamma, selon la définition du codage Gamma (Chapitre 13).

Le bloc gAMA contient :

La valeur est codée selon un entier non signé sur 4 octets, représentant la valeur gamma multipliée par 100000. Par exemple, un gamma de 0.45 sera enregistré comme un entier valant 45000.

Si l'encodeur est incapable de connaître le gamma de l'image originale, il ne devra pas écrire le bloc gAMA; l'absence d'un tel bloc au décodage indique que le gamma est inconnu.

Si le bloc gAMA est présent, il devra précéder le premier bloc IDAT, ainsi que le bloc PLTE s'il existe. Cf. Correction de Gamma (Section 2.7), Recommandations pour les Encodeurs: Gestion du gamma (Section 9.2), et Recommandations pour les Décodeurs: Gestion du Gamma (Section 10.5).

4.2.4. Histogramme de l'image : hIST

Le bloc hIST donne la fréquence approximative d'utilisation de chaque couleur de la palette. Un tel bloc ne peut être présent que si un bloc palette PLTE est défini. Si un client est incapable de reproduire toutes les couleurs listées dans la palette, l'histogramme peut alors aider à déterminer quel sous ensemble de couleurs rendra l'image au mieux.

Le bloc hIST contient une série d'entiers non signés sur deux octets (16 bits). On devra trouver autant d'entrées d'histogramme que de couleurs définies dans le bloc PLTE. Chaque entrée code de façon proportionnelle le nombre de pixels de l'image qui sont de la couleur associée. Le facteur d'échelle est choisi par l'encodeur.

La valeur de la fréquence de couleur est approximative, sauf pour la valeur zéro qui indique avec certitude que la couleur correspondante de la palette n'est jamais utilisée dans l'ensemble de l'image. Si au moins un pixel de l'image est d'une couleur donnée, il est important que sa fréquence associée ne soit pas nulle (au moins 1).

Lorsque la palette représente la quantification suggérée d'une image enregistrée en vraies couleurs, l'histogramme est d'autant plus approximatif, dans la mesure où il n'est pas garanti que l'encodeur et le décodeur attribuent des pixels à des entrées de palette de la même manière. Dans ce cas, aucune entrée ne doit être nulle.

Si un bloc hIST est présent, il devra suivre un bloc PLTE, et devra précéder le premier bloc IDAT. Cf. Motivation: Histogramme de palette (Section 12.14), et Recommandations pour les Décodeurs: Palettes suggérées et utilisation des histogrammes (Section 10.10).

4.2.5. Dimensions physiques de pixel : pHYs

Le bloc pHYs spécifie la taille du pixel et son rapport dimensionnel. Il contient :

Les valeurs suivantes sont valides pour l'unité :

Lorsque le code d'unité est 0, le bloc pHYs ne définit que le rapport dimensionnel du pixel. La taille effective du pixel reste non spécifiée.

Note: un pouce vaut 0,0254 m.

Si ce bloc auxiliaire est absent, on considérera que l'on a affaire a des pixels carrés, de taille inconnue. S'il est présent, ce bloc doit précéder le premier bloc IDAT.Cf. Recommandations pour les Décodeurs: Dimensions des Pixels (Section 10.2).

4.2.6. Bits significatifs : sBIT

Pour simplifier les décodeurs, le format PNG spécifie les profondeurs de bits qui peuvent être utilisées, et demande que les échantillons soient recalibrés pour utiliser la plage complète définie par cette profondeur de bits. Le bloc sBIT est défini pour garder une trace du nombre de bits significatifs d'origine. Ceci permet aux décodeurs de pouvoir retrouver les données originales de l'image, sans pertes, même si l'échantillonnage initial n'est pas supporté par le format PNG. Nous recommandons l'émission d'un bloc sBIT dans le cas où les données ont été calibrées à partir d'une définition inférieure. Pour le modèle de couleurs 0 (niveaux de gris), le bloc sBIT contiendra un octet unique, indiquant le nombre de bits significatifs par pixel de l'image originale.

Pour le modèle de couleurs 2 (vraies couleurs), le bloc sBIT contiendra trois octets, indiquant le nombre de bits significatifs pour chaque canal primaire de l'image originale (R, V, B).

Pour le modèle 3 (couleurs indexées), le bloc sBIT contient trois octets, indiquant le nombre de bits significatifs utilisés dans le codage des couleurs désignées dans la palette, et ce, pour chaque couleur primaire. Pour le modèle 4 (niveaux de gris avec canal alpha), le bloc sBIT contient deux octets, indiquant le nombre de bits significatifs pour chaque canal de l'image originale (luminosité et transparence). Pour le modèle 6 (vraies couleurs avec canal alpha), le bloc sBIT contiendra 4 octets, indiquant les valeurs du modèle 2, plus le nombre de bits significatifs du canal de transparence.

Chacune des profondeurs explicitées dans le bloc sBIT doit être supérieure à zéro et inférieure ou égale à la profondeur en bits définie dans le fichier PNG (8 pour des images en couleurs indexées, la valeur mentionnée dans le bloc IHDR pour les autres modèles de couleurs).

Un décodeur pourra ignorer un bloc sBIT: l'image enregistrée après calibrage reste un fichier PNG valide de profondeur bit indiquée dans le bloc IHDR. Cependant, si le décodeur souhaite pouvoir reproduire l'image dans sa définition originale, ceci pourra être fait en décalant vers la droite les échantillons (ou les entrées de palette, pour les images en couleurs indexées). Le calibrage fait par l'encodeur "poussera" vers les poids forts les valeurs originales des échantillons.

Si un bloc sBIT est présent, il doit précéder le premier bloc IDAT, ainsi que le bloc PLTE s'il existe. Cf. Recommandations pour les Encodeurs: Calibrage des échantillons (Section 9.1) et Recommandations pour les Décodeurs: Restitution de définition (Section 10.4).

4.2.7. Texte : tEXt

Des information textuelles que l'encodeur souhaîte enregistrer avec l'image pourront l'être dans des blocs tEXt. Chaque bloc tEXt contiendra un mot-clef et une chaîne de caractères, selon le format :

Le mot-clef et la chaîne de caractères sont séparés par un caractère nul (octet de valeur 0). Par conséquent, ni le mot-clef, ni la chaîne de caractères ne peuvent contenir un caractère nul. Notez que la chaîne de caractère n'est pas terminée par un Null (la longueur de bloc est une information suffisante pour déterminer la fin de la chaîne). Le mot-clef doit au moins contenir un caractère, et au plus 80. La taille de la chaîne peut être quelconque, de 0 caractères à la taille maximale admissible par le bloc, moins la taille du mot-clef moins un (le séparateur).

Un nombre quelconque de blocs tEXt peuvent être présents, et plusieurs blocs de même mot-clef sont admis.

Le mot-clef définit la nature de l'information contenue dans la chaîne qui suit. Les mot-clef suivant ont été prédéfinis et pourront être utilisés si le besoin l'exige :

Pour renseigner le mot-clef Creation Time, le format de date défini dans le paragraphe 5.2.14 de la RFC 1123 est suggéré, mais non imposé [RFC-1123]. Les décodeurs devront pouvoir assumer n'importe quel format libre d'information, pour tous les champs textes.

D'autres mots-clefs pourront être "inventés" à d'autre fins. Les mots-clef ayant un intérêt général pourront être "enregistrés" par l'équipe de maintenance de la spécification PNG. Cependant, l'usage de mots-clefs propriétaires non enregistrés reste permis (nous recommandons simplement de choisir des mots-clefs suffisamment explicites, afin de minimiser les risques de voir le même mot utilisé par deux opérateurs distincts avec une signification divergente).

Les mots-clefs et le texte seront interprétés selon la table de caractères définie par l'ISO 8859-1 (Latin-1) [ISO-8859]. La chaîne de caractères pourra contenir tout caractère Latin-1. Un saut de ligne sera représenté par un caractère 'linefeed' unique (10 en décimal, ou \n en notation C); l'utilisation d'autres caractères de contrôle dans cette chaîne est déconseillé.

Les mots-clefs ne peuvent être constitués que de caractères imprimables Latin-1 ou espaces; soient les caractères de code 32 à 126 et 161 à 255. Pour réduire toute erreur de lecture (humaine) des mots-clefs, il est interdit déplacer des espaces au début et à la fin du mot-clef. De même, plusieurs espaces consécutifs sont illégaux. Notez aussi que l'espace non sécable (code 160) n'est pas permis dans les mots-clef, car on ne peut le distinguer visuellement d'un espace normal.

Les mots-clefs doivent être écrits tels qu'ils ont été enregistrés, permettant ainsi aux décodeurs de procéder par comparaison numérique pour leur reconnaissance. En particulier, les mots-clefs sont considérés comme sensibles à la casse. Cf. Recommandations pour Encodeurs: Association de textes (Section 9.7) et Recommandations pour les Décodeurs: Association de textes (Section 10.11).

4.2.8. Dernière modification le : tIME

Le bloc tIME donne la date et l'heure de la dernière édition (et non celles de la création originale). Il contient :

On préférera le Temps Universel (UTC, ou encore GMT) plutôt que l'heure locale. Le bloc tIME est prévu pour être utilisé en tant qu'étiquette temporelle automatique, remise à jour chaque fois que l'image a changé. Il est recommandé que ce bloc ne soit pas édité par des éditeurs PNG qui n'auront apporté aucune modification à l'image. Cf. mot-clef Creation Time du bloc tEXt pouvant servir de marqueur temporel utilisateur.

4.2.9. Transparence : tRNS

Le bloc tRNS spécifie su l'image utilise la transparence simple : soit des valeurs alpha associées à chaque entrée de palette (pour des images en couleurs indexées) ou une couleur transparente unique (pour les images en niveaux de gris ou vraies couleurs). Bien que la transparence simple ne soit pas aussi élégante qu'un canal alpha complet, elle nécessite beaucoup moins d'espace et suffit dans la grande majorité des cas. Pour le modèle de couleurs 3 (couleurs indexées), le bloc tRNS contient une série de valeurs alpha sur un octet, correspondant aux entrées du bloc PLTE :

Chaque entrée indique que tout pixel telle couleur devra être traité avec la valeur de transparence spécifiée. Les valeurs Alpha ont alors la même interprétation que dans un canal alpha complet classique sur 8 bits : 0 indique une transparence totale, 255 une opacité totale, quelle que soit la profondeur bit du codage de l'image. Le bloc tRNS ne peut comporter plus d'entrées alpha que d'entrées de palette, l'inverse est par contre possible. Dans un tel cas, les valeurs alpha de toutes les couleurs restantes seront considérées comme valant 255. Ceci permet, par exemple, dans le cas où une seule couleur de palette (l'entrée 0) est donnée comme couleur transparente, de pouvoir réduire le bloc tRNS à un octet (nul), et ainsi gagner de la place.

Dans le modèle 0 (niveaux de gris), le bloc tRNS contient une seule valeur indiquant un niveau de gris, enregistrées sous le format :

(Par mesure de simplification, 2 octets sont utilisés quelle que soit la définition de l'image). Les pixels de ce niveau de gris seront traités comme des pixels transparents (équivalents à une valeur alpha de 0); tous les autres pixels sont traités comme totalement opaques (valeur alpha (2^profondeur_bit)-1). Dans le modèle de couleur 2 (vraies couleurs), le bloc tRNS contient une couleur RVB, enregistrée sous le format :

(Par mesure de simplification, 2 octets sont utilisés quelle que soit la définition de l'image). Les pixels de couleur égale à la couleur spécifiée dans le bloc tRNS sont traités comme totalement transparents (valeur alpha à 0); tous les autres pixels sont traités comme totalement opaques (valeur alpha (2^profondeur_bit)-1).

Un bloc tRNS est interdit dans les modèles de couleur 4 et 6, car ces modes supposent l'existence d'un véritable canal alpha. Note: lorsque l'on travaille en niveaux de gris 16 bits ou en vraies couleurs, il est important de comparer les deux octets de l'échantillon pour déterminer si un pixel est transparent ou non. Lorsque que certains décodeurs éliminent certains bits des poids faibles pour générer l'affichage, il faudra prendre la précaution de tester auparavant la transparence. Par exemple, si le niveau de gris 0x0001 est assigné à la fonction de transparence, il serait incorrect de ne comparer que les poids forts des échantillons et déduire qu'une valeur 0x0002 est aussi transparente.

Lorsqu'un bloc tRNS est présent, il doit précéder le premier bloc IDAT, et passer après le bloc PLTE, s'il existe.

4.2.10. Données texte compressées : zTXt

Un bloc zTXt contient des données textuelles, tout comme un bloc tEXt mais en tirant le bénéfice de la compression. Les blocs zTXt et tEXt sont équivalents d'un point de vue sémantique, mais le type zTXt est recommandé pour enregistrer des textes longs.

Un bloc zTXt contient :

Le mot-clef et le séparateur nul sont à l'identique du bloc tEXt. Notez que le mot-clef n'est pas compressé. L'octet méthode de compression permet de dissocier plusieurs méthodes de compression du texte. Actuellement, seule la valeur 0 est définie (compression par déflation/inflation). L'octet indiquant la méthode de compression est suivi de la chaîne compressée. Avec la méthode 0, le flux compressé adhère à la spécification zlib (Cf. Compression par déflation/inflation, Chapitre 5). La décompression de ce flux produit un texte en Latin-1 identique au texte qui aurait été enregistré dans un bloc tEXt.

Un nombre quelconque de blocs zTXt et tEXt pet être présent dans un fichier PNG. Cf. la définition précédente du bloc tEXt pour les mots-clefs prédéfinis et les conseils sur le format du texte. Cf. Recommandations pour les Encodeurs: Traitement des blocs texte (Section 9.7), et Recommandations pour les Décodeurs: Traitement des blocs texte (Section 10.11).

4.3. Résumé à propos des blocs prédéfinis

La table suivante résume les caractéristiques des principaux blocs standards :

Blocs critiques (ordre indispensable, PLTE est optionnel) :

Blocs auxiliaires (ordre non significatif, excepté spécifications) :

Mots clefs standards pour les blocs tEXt et zTXt :

4.4. Autres types de blocs

D'autres blocs PNG publics sont définis dans le document "PNG Special-Purpose Public Chunks" [PNG-EXTENSIONS]. Les blocs qui y sont décrits sont d'un usage moins fréquent que ceux définis dans cette spécification. Malgré cela, nous demandons aux auteurs d'applications utilisant le format PNG de vérifier si ces blocs additionnels ne peuvent suffire à leurs besoins, avant de créer un nouveau type de bloc. De nouveaux blocs peuvent être ajoutés à cette liste sur simple proposition en contactant l'équipe de maintenance de la spécification PNG à l'adresse png-info@uunet.uu.net ou png-group@w3.org.

Des nouveaux types de blocs ne seront enregistrés que s'ils peuvent avoir une utilité pour d'autres développeurs et s'ils ne violent pas la philosophie générale de construction des PNGs. La validation de ces nouveaux blocs n'est pas systématique, mais nous sommes conscients de l'intérêt de diffuser une nouvelle spécification de type lorsque nous sentons que son usage peut être généralisé. Notez cependant que la création de nouveaux types de blocs critiques est déconseillée, sauf en cas de nécessité absolue. Des applications pourront mettre en œuvre des blocs de type privés pour un usage propriétaire. Cf. Recommandations pour les Encodeurs: Usage des blocs privés (Section 9.8).

Les décodeurs doivent être prêts à recevoir des codes de types privés ou publics inconnus. Ces blocs devront être traités comme spécifié dans la section Conventions d'appellation des blocs (Section 3.3).