RFC: 2083
Retour à l'index des normes : INDEX FRANÇAIS
Statut : Proposition
Un fichier PNG consiste en une signature PNG suivi d'une série de blocs. Ce chapitre définit la signature ainsi que les propriétés générales des blocs. Le détail de chaque bloc est précisé dans les chapitres suivants.
Les huit premiers bits d'un fichier PNG contiennent toujours les valeurs suivantes (en décimal) :
137 80 78 71 13 10 26 10
Cette signature indique que le reste du fichier contient une seule image codée selon en PNG, consistant en une série de blocs dont le premier est un bloc IHDR et le dernier un bloc IEND. Cf Motivations: Signature de fichier PNG (Section 12.11).
Chaque bloc est constitué de quatre parties:
Un entier non-signé sur 4 octets donnant le nombre d'octets de la partie données du bloc. Cette longueur n'est calculée que sur la partie "données", ne se compte pas elle-même, ni les parties "type", ni le CRC. Zéro est donc une longueur possible. Bien que les encodeurs et décodeurs soient sensés interpréter ce paramètre comme un entier non signé, on limitera sa valeur à (2^31)-1.
Un code de type de bloc sur 4 octets. Pour faciliter l'implémentation et l'examen de fichiers PNG, ces codes se présenteront sous forme d'un groupe de lettres ASCII (A-Z et a-z, ou 65-90 et 97-122 en décimal). Cependant, les encodeurs et décodeurs devront toujours interpréter ces lettres en tant que valeurs numériques, et jamais sous forme d'une chaîne de caractères. Par exemple, le code de type IDAT n'est pas équivalent à celui formé par les quatre lettres équivalentes en EBCDIC. Les conventions nommant les divers types de blocs sont exposées dans les chapitres suivants.
Les octets de données, s'il y en a, et selon le type de bloc. Cette partie peut être vide.
Un CRC (Cyclic Redundancy Check) sur 4 octets, calculé à partir des octets précédents du même bloc, tenant compte du type et des données, mais pas de la longueur. Le CRC est tout le temps présent, même pour des blocs ne contenant aucune données. Voir l'algorithme du CRC (Section 3.4). Le nombre d'octets de données peut être quelconque tant qu'il reste inférieure à la limite supérieure; de ce fait, les programmeurs ne pourront être assurés qu'un bloc sera aligné au delà de l'octet.
Les blocs peuvent apparaître dans un ordre quelconque, hormis certaines restrictions définies pour chacun des types spécifiés. (Une restriction notable est qu'un bloc IHDR doit toujours apparaître en premier, et un bloc IEND en dernier; ainsi, le bloc IEND sert de marqueur de fin de fichier). On pourra trouver plusieurs blocs d'un type donné, mais seulement si ce type le permet. Cf Motivations: Structure des blocs (Section 12.12).
Les codes de type sont nommés de telle sorte qu'un décodeur peut déduire certaines propriétés d'un bloc même lorsque le code de type n'est pas reconnu. Ces règles sont instituées pour permettre une extension sure et souple du format PNG, en permettant a un décodeur de décider du traitement à effectuer lorsqu'un bloc de type inconnu est rencontré. Ces règles d'appellation n'ont que peu d'intérêt lorsque le décodeur reconnaît le type de bloc.
Quatre bits particuliers dans le type (le bit 5 - valeur 32- dans chacun des 4 octets) sont utilisés pour transmettre des propriétés du bloc. Ce choix permet une lecture facile des propriétés "à vue" selon si chaque lettre composant le type est majuscule (bit 5 à 0) ou minuscule (bit 5 à 1). Un décodeur devra quant à lui tester numériquement la valeur de ces bits pour déduire les propriétés d'un bloc inconnu; le test de la casse sur une interprétation caractère est insuffisant, et peut même conduire à une interprétation erronée, suivant l'implémentation locale des tables de caractères.
Il est important de noter que les bits de propriétés des blocs sont une partie indissociable du nom du bloc, et de ce fait sont fixés pour un type de bloc prédéfini. De ce fait, deux blocs TEXT et Text sont des blocs entièrement différents, et non le même bloc doté de propriétés différentes. Les décodeurs devront reconnaître les types de blocs par une comparaison littérale numérique des quatre octets du code de type; il est donc tout à fait illicite d'opérer des changements de casse sur les types de blocs.
La sémantique des bits de propriétés est la suivante :
Les blocs qui ne sont pas absolument nécessaires à un affichage significatif de l'image sont appelés blocs "auxiliaires". Un décodeur rencontrant un bloc de type inconnu marqué du caractère "auxiliaire" (bit 5, octet 1 à 1) peut sans risque ignorer le bloc et accepter d'afficher l'image. Le bloc temps (tIME) en est un exemple.
Les blocs contenant des données indispensables à l'affichage correct de l'image sont appelés "critiques". Un décodeur rencontrant un bloc de nature inconnue avec la propriété "critique" marquée (bit 5, octet 1 à 0) doit indiquer au client que l'image contient des informations qu'il ne peut correctement interpréter. Le bloc d'en-tête (IHDR) est un exemple de bloc "critique".
Un bloc est public s'il est conforme à la spécification PNG ou s'il fait partie de la liste des blocs publics spéciaux définis par le PNG. Des applications peuvent quant à elles créer et exploiter des blocs privés (non standards) pour leur usage propre. Le nom des blocs privés doivent impérativement avoir une minuscule en deuxième lettre, tandis qu'une deuxième lettre majuscule sera réservée aux blocs publics. Notez qu'un décodeur n'a pas besoin de tester ce bit, dans la mesure où il n'a pas de signification fonctionnelle; Il s'agit surtout d'une facilité "administrative" pour éviter tout conflit entre noms privés et publics. Cf. Types Additionnels (Section 4.4) et Recommandations pour les Encodeurs: Utilisation de blocs privés (Section 9.8).
La signification du troisième bit de propriétés n'est pas encore défini et est réservé pour des développements futurs. A l'heure actuelle, tous les noms devront avoir une troisième lettre majuscule. (Les décodeurs ne devront pas nécessairement générer une faute sur réception d'un troisième caractère minuscule; cependant, comme des futures versions de la spécification PNG pourraient donner une signification à ce bit, la meilleure position à adopter lorsqu'un bloc est reçu avec une troisième lettre minuscule est de considérer ce bloc comme inconnu).
Ce bit n'a pas d'intérêt pour les simples décodeurs, mais pourra être utilisé par des éditeurs PNG (programmes modifiant les fichiers PNG). Ce bit définit le comportement à adopter lorsque des blocs inconnus sont détectés dans un fichiers à modifier.
Si le marqueur de sécurité à la copie vaut 1, le bloc pourra être copié dans un fichier PNG modifié que le bloc soit reconnu ou non par le programme applicatif, et quelque soit l'étendue des modifications.
Si le marqueur de sécurité à la copie vaut 0, cela indique que le bloc considéré a une influence sur l'image contenue dans le fichier. Si le programme a procédé à des modifications de blocs "critiques", du type addition, modification, suppression, ou réordonnancement de blocs critiques, alors des blocs non reconnus ne doivent pas être copiés dans le fichier PNG. (Bien sûr, si le programme reconnaît le bloc, il pourra décider d'en copier une version modifiée en conséquence).
Un éditeur PNG aura toujours la permission de copier tous les blocs non reconnus si les modifications, suppressions, ajouts ou réordonnancements ne concernent que des blocs auxiliaires. Ceci à une conséquence sur les blocs auxiliaires : ils leur est interdit de dépendre d'autre blocs auxiliaires.
Un éditeur PNG incapable de reconnaître un bloc critique doit afficher une erreur et refuser globalement de traiter ce fichier PNG. Le mécanisme sûr/non sûr est essentiellement dédié au traitement de blocs auxiliaires. Le marqueur de sécurité à la copie sera donc toujours 0 dans des blocs critiques.
Les règles à appliquer par des éditeurs PNG sont décrites par la suite dans la section Règles d'Ordonnancement des Blocs (Chapitre 7).
Par exemple, le nom de bloc hypothétique "bLOb" présente les propriétés suivantes :
bLOb <-- code "de.class" tppabs="http://www.eisti.fr/eistiweb/docs/normes/rfc2083/de.class" type sur 32 bits sous forme texte
||||
|||+- marqueur de copie à 1 (minuscule; bit 5 à 1)
||+-- marqueur réservé 0 (majuscule; bit 5 à 0)
|+--- marqueur privé à 0 (majuscule; bit 5 à 0)
+---- marqueur auxiliaire à 1 (minuscule; bit 5 à 1)
Dans cet exemple, le nom représente un bloc auxiliaire, public, sûr en copie. Cf. Motivations: Conventions d'appellation des blocs (Section 12.13).
Les CRC des blocs sont calculés selon une méthode standard de calcul des CRC, avec pre et post conditionnement, définie dans la norme ISO 3309 [ISO-3309] ou ITU-T V.42 [ITU-V42]. La fonction polynomiale
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1
est employée.
Le registre 32-bits de calcul est initialisé avec des 1. Les données de chaque octet sont traitées depuis le bit de poids faible (1) jusqu'au bit de poids fort (128). Une fois tous les octets de données traités, le registre CRC est inversé (on prend son complément à un). Cette valeur est transmise (enregistrée dans le fichier) les poids forts en tête. Pour achever la séparation en octets et leur ordonnancement, le bit de poids faible du CRC sur 32-bit est pris comme le coefficient du terme x^31.
En pratique, le calcul du CRC se base sur une table calculée à l'avance afin d'en accélérer le traitement. Cf. CRC des Echantillons (Chapitre 15).