The Metadata in PNG files » History » Revision 7
« Previous |
Revision 7/16
(diff)
| Next »
Tuan Nhu, 13 Aug 2013 07:09
The Metadata in PNG files¶
The Portable Network Graphics (PNG) is a raster graphics file format that supports a portable, legally unencumbered, well-compressed, well-specified standard for lossless bitmapped image files.
A PNG always starts with an 8-byte signature: 137 80 78 71 13 10 26 10 (decimal values). The remainder of the file consists a series of chunks beginning with an IHDR chunk and ending with an IEND chunk.
1. Chunks¶
Each chunk consists of four parts:
| Length | 4 bytes | An unsigned integer giving the number of bytes in the chunk's data field. The length counts only the data field, not itself, the chunk type code, or the CRC. Zero is a valid length. Although encoders and decoders should treat the length as unsigned, its value must not exceed 231-1 bytes. |
|---|---|---|
| Chunk type | 4 bytes | Type codes are restricted to consist of uppercase and lowercase ASCII letters and they are case sensitive. + The case of the first letter indicates whether the chunk is critical or not. If the first letter is uppercase, the chunk is critical; if not, the chunk is ancillary (more details are mentioned below). + The case of the second letter indicates whether the chunk is "public" (either in the specification or the registry of special-purpose public chunks) or "private" (not standardised). Uppercase is public and lowercase is private. + The third letter must be uppercase to conform to the PNG specification. It is reserved for future expansion. + The case of the fourth letter indicates whether the chunk is safe to copy by editors that do not recognize it. |
| Chunk data | Length bytes | The data bytes appropriate to the chunk type, if any. This field can be of zero length. |
| CRC | 4 bytes | A CRC (Cyclic Redundancy Check) calculated on the preceding bytes in the chunk, including the chunk type code and chunk data fields, but not including the length field. The CRC is always present, even for chunks containing no data. |
Fig.1. The chunk layout.
Chunks declare themselves as critical or ancillary.
Chunks that are necessary for successful display of the file's contents are called critical chunks. If a decoder encounters a critical chunk it does not recognize, it must abort reading the file or supply the user with an appropriate warning.
| Name | Multiple | Ordering constraints | Contain |
|---|---|---|---|
| IHDR | No | Must be the first | the image's width, height, and bit depth |
| PLTE | No | Before IDAT | the palette; list of colors. |
| IDAT | Yes | Multiple IDATs must be consecutive | the actual image data, which may be split among multiple IDAT chunks. Such splitting increases filesize slightly, but makes it possible to generate a PNG in a streaming manner. |
| IEND | No | Must be the last | it just marks the image end. The chunk's data field is empty. |
Fig.2. Some standard critical chunks.
Chunks that are not strictly necessary in order to meaningfully display the contents of the file are known as ancillary chunks. It includes gamma values, background color, and textual metadata information, ect... If a decoder encourters an ancillary chunk that it does not understand can safely ignore it.
| Name | Multiple | Ordering constraints | Contain |
|---|---|---|---|
| cHRM | No | Before PLTE and IDAT | the chromaticity coordinates of the display primaries and white point. |
| gAMA | No | Before PLTE and IDAT | gamma values. |
| iCCP | No | Before PLTE and IDAT | an ICC color profile. |
| sBIT | No | Before PLTE and IDAT | indicates the color-accuracy of the source data. |
| sRGB | No | Before PLTE and IDAT | indicates that the standard sRGB color space is used. |
| bKGD | No | After PLTE; before IDAT | gives the default background color. It is intended for use when there is no better choice available, such as in standalone image viewers. |
| hIST | No | After PLTE; before IDAT | the histogram, or total amount of each color in the image. |
| tRNS | No | After PLTE; before IDAT | transparency information.For indexed images, it stores alpha channel values for one or more palette entries. For truecolor and grayscale images, it stores a single pixel value that is to be regarded as fully transparent. |
| pHYs | No | Before IDAT | the intended pixel size and/or aspect ratio of the image. |
| sPLT | Yes | Before IDAT | a palette to use if the full range of colors is unavailable. |
| tIME | No | None | the time that the image was last changed. |
| iTXt | Yes | None | UTF-8 text, compressed or not, with an optional language tag. iTXt chunk with the keyword 'XML:com.adobe.xmp' can contain Extensible Metadata Platform (XMP) |
| tEXt | Yes | None | text that can be represented in ISO/IEC 8859-1, with one name=value pair for each chunk. |
| zTXt | Yes | None | compressed text with the same limits as tEXt. |
Fig.3. Some standard ancillary chunks.
2. Textual information chunks - the metadata in PNG¶
Updated by Tuan Nhu over 8 years ago · 7 revisions