LinuxDig.com Request For Comments

RFC Number : 2083 Title : PNG (Portable Network Graphics) Specification Version 1. Network Working Group T. Boutell, et. al. Request for Comments: 2083 Boutell.Com, Inc. Category: Informational March 1997 PNG (Portable Network Graphics) Specification Version 1.0 Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. IESG Note: The IESG takes no position on the validity of any Intellectual Property Rights statements contained in this document. Abstract This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. PNG provides a patent-free replacement for GIF and can also replace many common uses of TIFF. Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits. PNG is designed to work well in online viewing applications, such as the World Wide Web, so it is fully streamable with a progressive display option. PNG is robust, providing both full file integrity checking and simple detection of common transmission errors. Also, PNG can store gamma and chromaticity data for improved color matching on heterogeneous platforms. This specification defines the Internet Media Type image/png. Table of Contents 1. Introduction .................................................. 4 2. Data Representation ........................................... 5 2.1. Integers and byte order .................................. 5 2.2. Color values ............................................. 6 2.3. Image layout ............................................. 6 2.4. Alpha channel ............................................ 7 2.5. Filtering ................................................ 8 2.6. Interlaced data order .................................... 8 2.7. Gamma correction ......................................... 10 Boutell, et. al. Informational [Page 1]  RFC 2083 PNG: Portable Network Graphics March 1997 2.8. Text strings ............................................. 10 3. File Structure ................................................ 11 3.1. PNG file signature ....................................... 11 3.2. Chunk layout ............................................. 11 3.3. Chunk naming conventions ................................. 12 3.4. CRC algorithm ............................................ 15 4. Chunk Specifications .......................................... 15 4.1. Critical chunks .......................................... 15 4.1.1. IHDR Image header .................................. 15 4.1.2. PLTE Palette ....................................... 17 4.1.3. IDAT Image data .................................... 18 4.1.4. IEND Image trailer ................................. 19 4.2. Ancillary chunks ......................................... 19 4.2.1. bKGD Background color .............................. 19 4.2.2. cHRM Primary chromaticities and white point ........ 20 4.2.3. gAMA Image gamma ................................... 21 4.2.4. hIST Image histogram ............................... 21 4.2.5. pHYs Physical pixel dimensions ..................... 22 4.2.6. sBIT Significant bits .............................. 22 4.2.7. tEXt Textual data .................................. 24 4.2.8. tIME Image last-modification time .................. 25 4.2.9. tRNS Transparency .................................. 26 4.2.10. zTXt Compressed textual data ...................... 27 4.3. Summary of standard chunks ............................... 28 4.4. Additional chunk types ................................... 29 5. Deflate/Inflate Compression ................................... 29 6. Filter Algorithms ............................................. 31 6.1. Filter types ............................................. 31 6.2. Filter type 0: None ...................................... 32 6.3. Filter type 1: Sub ....................................... 33 6.4. Filter type 2: Up ........................................ 33 6.5. Filter type 3: Average ................................... 34 6.6. Filter type 4: Paeth...................................... 35 7. Chunk Ordering Rules .......................................... 36 7.1. Behavior of PNG editors .................................. 37 7.2. Ordering of ancillary chunks ............................. 38 7.3. Ordering of critical chunks .............................. 38 8. Miscellaneous Topics .......................................... 39 8.1. File name extension ...................................... 39 8.2. Internet media type ...................................... 39 8.3. Macintosh file layout .................................... 39 8.4. Multiple-image extension ................................. 39 8.5. Security considerations .................................. 40 9. Recommendations for Encoders .................................. 41 9.1. Sample depth scaling ..................................... 41 9.2. Encoder gamma handling ................................... 42 9.3. Encoder color handling ................................... 45 9.4. Alpha channel creation ................................... 47 Boutell, et. al. Informational [Page 2]  RFC 2083 PNG: Portable Network Graphics March 1997 9.5. Suggested palettes ....................................... 48 9.6. Filter selection ......................................... 49 9.7. Text chunk processing .................................... 49 9.8. Use of private chunks .................................... 50 9.9. Private type and method codes ............................ 51 10. Recommendations for Decoders ................................. 51 10.1. Error checking .......................................... 52 10.2. Pixel dimensions ........................................ 52 10.3. Truecolor image handling ................................ 52 10.4. Sample depth rescaling .................................. 53 10.5. Decoder gamma handling .................................. 54 10.6. Decoder color handling .................................. 56 10.7. Background color ........................................ 57 10.8. Alpha channel processing ................................ 58 10.9. Progressive display ..................................... 62 10.10. Suggested-palette and histogram usage .................. 63 10.11. Text chunk processing .................................. 64 11. Glossary ..................................................... 65 12. Appendix: Rationale .......................................... 69 12.1. Why a new file format? .................................. 69 12.2. Why these features? ..................................... 70 12.3. Why not these features? ................................. 70 12.4. Why not use format X? ................................... 72 12.5. Byte order .............................................. 73 12.6. Interlacing ............................................. 73 12.7. Why gamma? .............................................. 73 12.8. Non-premultiplied alpha ................................. 75 12.9. Filtering ............................................... 75 12.10. Text strings ........................................... 76 12.11. PNG file signature ..................................... 77 12.12. Chunk layout ........................................... 77 12.13. Chunk naming conventions ............................... 78 12.14. Palette histograms ..................................... 80 13. Appendix: Gamma Tutorial ..................................... 81 14. Appendix: Color Tutorial ..................................... 89 15. Appendix: Sample CRC Code .................................... 94 16. Appendix: Online Resources ................................... 96 17. Appendix: Revision History ................................... 96 18. References ................................................... 97 19. Credits ......................................................100 Boutell, et. al. Informational [Page 3]  RFC 2083 PNG: Portable Network Graphics March 1997 1. Introduction The PNG format provides a portable, legally unencumbered, well- compressed, well-specified standard for lossless bitmapped image files. Although the initial motivation for developing PNG was to replace GIF, the design provides some useful new features not available in GIF, with minimal cost to developers. GIF features retained in PNG include: * Indexed-color images of up to 256 colors. * Streamability: files can be read and written serially, thus allowing the file format to be used as a communications protocol for on-the-fly generation and display of images. * Progressive display: a suitably prepared image file can be displayed as it is received over a communications link, yielding a low-resolution image very quickly followed by gradual improvement of detail. * Transparency: portions of the image can be marked as transparent, creating the effect of a non-rectangular image. * Ancillary information: textual comments and other data can be stored within the image file. * Complete hardware and platform independence. * Effective, 100% lossless compression. Important new features of PNG, not available in GIF, include: * Truecolor images of up to 48 bits per pixel. * Grayscale images of up to 16 bits per pixel. * Full alpha channel (general transparency masks). * Image gamma information, which supports automatic display of images with correct brightness/contrast regardless of the machines used to originate and display the image. * Reliable, straightforward detection of file corruption. * Faster initial presentation in progressive display mode. PNG is designed to be: * Simple and portable: developers should be able to implement PNG easily. * Legally unencumbered: to the best knowledge of the PNG authors, no algorithms under legal challenge are used. (Some considerable effort has been spent to verify this.) * Well compressed: both indexed-color and truecolor images are compressed as effectively as in any other widely used lossless format, and in most cases more effectively. Boutell, et. al. Informational [Page 4]  RFC 2083 PNG: Portable Network Graphics March 1997 * Interchangeable: any standard-conforming PNG decoder must read all conforming PNG files. * Flexible: the format allows for future extensions and private add-ons, without compromising interchangeability of basic PNG. * Robust: the design supports full file integrity checking as well as simple, quick detection of common transmission errors. The main part of this specification gives the definition of the file format and recommendations for encoder and decoder behavior. An appendix gives the rationale for many design decisions. Although the rationale is not part of the formal specification, reading it can help implementors understand the design. Cross-references in the main text point to relevant parts of the rationale. Additional appendixes, also not part of the formal specification, provide tutorials on gamma and color theory as well as other supporting material. In this specification, the word 'must' indicates a mandatory requirement, while 'should' indicates recommended behavior. See Rationale: Why a new file format? (Section 12.1), Why these features? (Section 12.2), Why not these features? (Section 12.3), Why not use format X? (Section 12.4). Pronunciation PNG is pronounced 'ping'. 2. Data Representation This chapter discusses basic data representations used in PNG files, as well as the expected representation of the image data. 2.1. Integers and byte order All integers that require more than one byte must be in network byte order: the most significant byte comes first, then the less significant bytes in descending order of significance (MSB LSB for two-byte integers, B3 B2 B1 B0 for four-byte integers). The highest bit (value 128) of a byte is numbered bit 7; the lowest bit (value 1) is numbered bit 0. Values are unsigned unless otherwise noted. Values explicitly noted as signed are represented in two's complement notation. See Rationale: Byte order (Section 12.5). Boutell, et. al. Informational [Page 5]  RFC 2083 PNG: Portable Network Graphics March 1997 2.2. Color values Colors can be represented by either grayscale or RGB (red, green, blue) sample data. Grayscale data represents luminance; RGB data represents calibrated color information (if the cHRM chunk is present) or uncalibrated device-dependent color (if cHRM is absent). All color values range from zero (representing black) to most intense at the maximum value for the sample depth. Note that the maximum value at a given sample depth is (2^sampledepth)-1, not 2^sampledepth. Sample values are not necessarily linear; the gAMA chunk specifies the gamma characteristic of the source device, and viewers are strongly encouraged to compensate properly. See Gamma correction (Section 2.7). Source data with a precision not directly supported in PNG (for example, 5 bit/sample truecolor) must be scaled up to the next higher supported bit depth. This scaling is reversible with no loss of data, and it reduces the number of cases that decoders have to cope with. See Recommendations for Encoders: Sample depth scaling (Section 9.1) and Recommendations for Decoders: Sample depth rescaling (Section 10.4). 2.3. Image layout Conceptually, a PNG image is a rectangular pixel array, with pixels appearing left-to-right within each scanline, and scanlines appearing top-to-bottom. (For progressive display purposes, the data may actually be transmitted in a different order; see Interlaced data order, Section 2.6.) The size of each pixel is determined by the bit depth, which is the number of bits per sample in the image data. Three types of pixel are supported: * An indexed-color pixel is represented by a single sample that is an index into a supplied palette. The image bit depth determines the maximum number of palette entries, but not the color precision within the palette. * A grayscale pixel is represented by a single sample that is a grayscale level, where zero is black and the largest value for the bit depth is white. * A truecolor pixel is represented by three samples: red (zero = black, max = red) appears first, then green (zero = black, max = green), then blue (zero = black, max = blue). The bit depth specifies the size of each sample, not the total pixel size. Boutell, et. al. Informational [Page 6]  RFC 2083 PNG: Portable Network Graphics March 1997 Optionally, grayscale and truecolor pixels can also include an alpha sample, as described in the next section. Pixels are always packed into scanlines with no wasted bits between pixels. Pixels smaller than a byte never cross byte boundaries; they are packed into bytes with the leftmost pixel in the high-order bits of a byte, the rightmost in the low-order bits. Permitted bit depths and pixel types are restricted so that in all cases the packing is simple and efficient. PNG permits multi-sample pixels only with 8- and 16-bit samples, so multiple samples of a single pixel are never packed into one byte. 16-bit samples are stored in network byte order (MSB first). Scanlines always begin on byte boundaries. When pixels have fewer than 8 bits and the scanline width is not evenly divisible by the number of pixels per byte, the low-order bits in the last byte of each scanline are wasted. The contents of these wasted bits are unspecified. An additional 'filter type' byte is added to the beginning of every scanline (see Filtering, Section 2.5). The filter type byte is not considered part of the image data, but it is included in the datastream sent to the compression step. 2.4. Alpha channel An alpha channel, representing transparency information on a per- pixel basis, can be included in grayscale and truecolor PNG images. An alpha value of zero represents full transparency, and a value of (2^bitdepth)-1 represents a fully opaque pixel. Intermediate values indicate partially transparent pixels that can be combined with a background image to yield a composite image. (Thus, alpha is really the degree of opacity of the pixel. But most people refer to alpha as providing transparency information, not opacity information, and we continue that custom here.) Alpha channels can be included with images that have either 8 or 16 bits per sample, but not with images that have fewer than 8 bits per sample. Alpha samples are represented with the same bit depth used for the image samples. The alpha sample for each pixel is stored immediately following the grayscale or RGB samples of the pixel. Boutell, et. al. Informational [Page 7]  RFC 2083 PNG: Portable Network Graphics March 1997 The color values stored for a pixel are not affected by the alpha value assigned to the pixel. This rule is sometimes called 'unassociated' or 'non-premultiplied' alpha. (Another common technique is to store sample values premultiplied by the alpha fraction; in effect, such an image is already composited against a black background. PNG does not use premultiplied alpha.) Transparency control is also possible without the storage cost of a full alpha channel. In an indexed-color image, an alpha value can be defined for each palette entry. In grayscale and truecolor images, a single pixel value can be identified as being 'transparent'. These techniques are controlled by the tRNS ancillary chunk type. If no alpha channel nor tRNS chunk is present, all pixels in the image are to be treated as fully opaque. Viewers can support transparency control partially, or not at all. See Rationale: Non-premultiplied alpha (Section 12.8), Recommendations for Encoders: Alpha channel creation (Section 9.4), and Recommendations for Decoders: Alpha channel processing (Section 10.8). 2.5. Filtering PNG allows the image data to be filtered before it is compressed. Filtering can improve the compressibility of the data. The filter step itself does not reduce the size of the data. All PNG filters are strictly lossless. PNG defines several different filter algorithms, including 'None' which indicates no filtering. The filter algorithm is specified for each scanline by a filter type byte that precedes the filtered scanline in the precompression datastream. An intelligent encoder can switch filters from one scanline to the next. The method for choosing which filter to employ is up to the encoder. See Filter Algorithms (Chapter 6) and Rationale: Filtering (Section 12.9). 2.6. Interlaced data order A PNG image can be stored in interlaced order to allow progressive display. The purpose of this feature is to allow images to 'fade in' when they are being displayed on-the-fly. Interlacing slightly expands the file size on average, but it gives the user a meaningful display much more rapidly. Note that decoders are Boutell, et. al. Informational [Page 8]  RFC 2083 PNG: Portable Network Graphics March 1997 required to be able to read interlaced images, whether or not they actually perform progressive display. With interlace method 0, pixels are stored sequentially from left to right, and scanlines sequentially from top to bottom (no interlacing). Interlace method 1, known as Adam7 after its author, Adam M. Costello, consists of seven distinct passes over the image. Each pass transmits a subset of the pixels in the image. The pass in which each pixel is transmitted is defined by replicating the following 8-by-8 pattern over the entire image, starting at the upper left corner: 1 6 4 6 2 6 4 6 7 7 7 7 7 7 7 7 5 6 5 6 5 6 5 6 7 7 7 7 7 7 7 7 3 6 4 6 3 6 4 6 7 7 7 7 7 7 7 7 5 6 5 6 5 6 5 6 7 7 7 7 7 7 7 7 Within each pass, the selected pixels are transmitted left to right within a scanline, and selected scanlines sequentially from top to bottom. For example, pass 2 contains pixels 4, 12, 20, etc. of scanlines 0, 8, 16, etc. (numbering from 0,0 at the upper left corner). The last pass contains the entirety of scanlines 1, 3, 5, etc. The data within each pass is laid out as though it were a complete image of the appropriate dimensions. For example, if the complete image is 16 by 16 pixels, then pass 3 will contain two scanlines, each containing four pixels. When pixels have fewer than 8 bits, each such scanline is padded as needed to fill an integral number of bytes (see Image layout, Section 2.3). Filtering is done on this reduced image in the usual way, and a filter type byte is transmitted before each of its scanlines (see Filter Algorithms, Chapter 6). Notice that the transmission order is defined so that all the scanlines transmitted in a pass will have the same number of pixels; this is necessary for proper application of some of the filters. Caution: If the image contains fewer than five columns or fewer than five rows, some passes will be entirely empty. Encoders and decoders must handle this case correctly. In particular, filter type bytes are only associated with nonempty scanlines; no filter type bytes are present in an empty pass. Boutell, et. al. Informational [Page 9]  RFC 2083 PNG: Portable Network Graphics March 1997 See Rationale: Interlacing (Section 12.6) and Recommendations for Decoders: Progressive display (Section 10.9). 2.7. Gamma correction PNG images can specify, via the gAMA chunk, the gamma characteristic of the image with respect to the original scene. Display programs are strongly encouraged to use this information, plus information about the display device they are using and room lighting, to present the image to the viewer in a way that reproduces what the image's original author saw as closely as possible. See Gamma Tutorial (Chapter 13) if you aren't already familiar with gamma issues. Gamma correction is not applied to the alpha channel, if any. Alpha samples always represent a linear fraction of full opacity. For high-precision applications, the exact chromaticity of the RGB data in a PNG image can be specified via the cHRM chunk, allowing more accurate color matching than gamma correction alone will provide. See Color Tutorial (Chapter 14) if you aren't already familiar with color representation issues. See Rationale: Why gamma? (Section 12.7), Recommendations for Encoders: Encoder gamma handling (Section 9.2), and Recommendations for Decoders: Decoder gamma handling (Section 10.5). 2.8. Text strings A PNG file can store text associated with the image, such as an image description or copyright notice. Keywords are used to indicate what each text string represents. ISO 8859-1 (Latin-1) is the character set recommended for use in text strings [ISO-8859]. This character set is a superset of 7- bit ASCII. Character codes not defined in Latin-1 should not be used, because they have no platform-independent meaning. If a non-Latin-1 code does appear in a PNG text string, its interpretation will vary across platforms and decoders. Some systems might not even be able to display all the characters in Latin-1, but most modern systems can. Provision is also made for the storage of compressed text. See Rationale: Text strings (Section 12.10). Boutell, et. al. Informational [Page 10]  RFC 2083 PNG: Portable Network Graphics March 1997 3. File Structure A PNG file consists of a PNG signature followed by a series of chunks. This chapter defines the signature and the basic properties of chunks. Individual chunk types are discussed in the next chapter. 3.1. PNG file signature The first eight bytes of a PNG file always contain the following (decimal) values: 137 80 78 71 13 10 26 10 This signature indicates that the remainder of the file contains a single PNG image, consisting of a series of chunks beginning with an IHDR chunk and ending with an IEND chunk. See Rationale: PNG file signature (Section 12.11). 3.2. Chunk layout Each chunk consists of four parts: Length A 4-byte 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 (2^31)-1 bytes. Chunk Type A 4-byte chunk type code. For convenience in description and in examining PNG files, type codes are restricted to consist of uppercase and lowercase ASCII letters (A-Z and a-z, or 65-90 and 97-122 decimal). However, encoders and decoders must treat the codes as fixed binary values, not character strings. For example, it would not be correct to represent the type code IDAT by the EBCDIC equivalents of those letters. Additional naming conventions for chunk types are discussed in the next section. Chunk Data The data bytes appropriate to the chunk type, if any. This field can be of zero length. Boutell, et. al. Informational [Page 11]  RFC 2083 PNG: Portable Network Graphics March 1997 CRC A 4-byte 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. See CRC algorithm (Section 3.4). The chunk data length can be any number of bytes up to the maximum; therefore, implementors cannot assume that chunks are aligned on any boundaries larger than bytes. Chunks can appear in any order, subject to the restrictions placed on each chunk type. (One notable restriction is that IHDR must appear first and IEND must appear last; thus the IEND chunk serves as an end-of-file marker.) Multiple chunks of the same type can appear, but only if specifically permitted for that type. See Rationale: Chunk layout (Section 12.12). 3.3. Chunk naming conventions Chunk type codes are assigned so that a decoder can determine some properties of a chunk even when it does not recognize the type code. These rules are intended to allow safe, flexible extension of the PNG format, by allowing a decoder to decide what to do when it encounters an unknown chunk. The naming rules are not normally of interest when the decoder does recognize the chunk's type. Four bits of the type code, namely bit 5 (value 32) of each byte, are used to convey chunk properties. This choice means that a human can read off the assigned properties according to whether each letter of the type code is uppercase (bit 5 is 0) or lowercase (bit 5 is 1). However, decoders should test the properties of an unknown chunk by numerically testing the specified bits; testing whether a character is uppercase or lowercase is inefficient, and even incorrect if a locale-specific case definition is used. It is worth noting that the property bits are an inherent part of the chunk name, and hence are fixed for any chunk type. Thus, TEXT and Text would be unrelated chunk type codes, not the same chunk with different properties. Decoders must recognize type codes by a simple four-byte literal comparison; it is incorrect to perform case conversion on type codes. Boutell, et. al. Informational [Page 12]  RFC 2083 PNG: Portable Network Graphics March 1997 The semantics of the property bits are: Ancillary bit: bit 5 of first byte 0 (uppercase) = critical, 1 (lowercase) = ancillary. Chunks that are not strictly necessary in order to meaningfully display the contents of the file are known as 'ancillary' chunks. A decoder encountering an unknown chunk in which the ancillary bit is 1 can safely ignore the chunk and proceed to display the image. The time chunk (tIME) is an example of an ancillary chunk. Chunks that are necessary for successful display of the file's contents are called 'critical' chunks. A decoder encountering an unknown chunk in which the ancillary bit is 0 must indicate to the user that the image contains information it cannot safely interpret. The image header chunk (IHDR) is an example of a critical chunk. Private bit: bit 5 of second byte 0 (uppercase) = public, 1 (lowercase) = private. A public chunk is one that is part of the PNG specification or is registered in the list of PNG special-purpose public chunk types. Applications can also define private (unregistered) chunks for their own purposes. The names of private chunks must have a lowercase second letter, while public chunks will always be assigned names with uppercase second letters. Note that decoders do not need to test the private-chunk property bit, since it has no functional significance; it is simply an administrative convenience to ensure that public and private chunk names will not conflict. See Additional chunk types (Section 4.4) and Recommendations for Encoders: Use of private chunks (Section 9.8). Reserved bit: bit 5 of third byte Must be 0 (uppercase) in files conforming to this version of PNG. The significance of the case of the third letter of the chunk name is reserved for possible future expansion. At the present time all chunk names must have uppercase third letters. (Decoders should not complain about a lowercase third letter, however, as some future version of the PNG specification could define a meaning for this bit. It is sufficient to treat a chunk with a lowercase third letter in the same way as any other unknown chunk type.) Boutell, et. al. Informational [Page 13]  RFC 2083 PNG: Portable Network Graphics March 1997 Safe-to-copy bit: bit 5 of fourth byte 0 (uppercase) = unsafe to copy, 1 (lowercase) = safe to copy. This property bit is not of interest to pure decoders, but it is needed by PNG editors (programs that modify PNG files). This bit defines the proper handling of unrecognized chunks in a file that is being modified. If a chunk's safe-to-copy bit is 1, the chunk may be copied to a modified PNG file whether or not the software recognizes the chunk type, and regardless of the extent of the file modifications. If a chunk's safe-to-copy bit is 0, it indicates that the chunk depends on the image data. If the program has made any changes to critical chunks, including addition, modification, deletion, or reordering of critical chunks, then unrecognized unsafe chunks must not be copied to the output PNG file. (Of course, if the program does recognize the chunk, it can choose to output an appropriately modified version.) A PNG editor is always allowed to copy all unrecognized chunks if it has only added, deleted, modified, or reordered ancillary chunks. This implies that it is not permissible for ancillary chunks to depend on other ancillary chunks. PNG editors that do not recognize a critical chunk must report an error and refuse to process that PNG file at all. The safe/unsafe mechanism is intended for use with ancillary chunks. The safe-to-copy bit will always be 0 for critical chunks. Rules for PNG editors are discussed further in Chunk Ordering Rules (Chapter 7). For example, the hypothetical chunk type name 'bLOb' has the property bits: bLOb <-- 32 bit chunk type code represented in text form |||| |||+- Safe-to-copy bit is 1 (lower case letter; bit 5 is 1) ||+-- Reserved bit is 0 (upper case letter; bit 5 is 0) |+--- Private bit is 0 (upper case letter; bit 5 is 0) +---- Ancillary bit is 1 (lower case letter; bit 5 is 1) Therefore, this name represents an ancillary, public, safe-to-copy chunk. Boutell, et. al. Informational [Page 14]  RFC 2083 PNG: Portable Network Graphics March 1997 See Rationale: Chunk naming conventions (Section 12.13). 3.4. CRC algorithm Chunk CRCs are calculated using standard CRC methods with pre and post conditioning, as defined by ISO 3309 [ISO-3309] or ITU-T V.42 [ITU-V42]. The CRC polynomial employed is 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 The 32-bit CRC register is initialized to all 1's, and then the data from each byte is processed from the least significant bit (1) to the most significant bit (128). After all the data bytes are processed, the CRC register is inverted (its ones complement is taken). This value is transmitted (stored in the file) MSB first. For the purpose of separating into bytes and ordering, the least significant bit of the 32-bit CRC is defined to be the coefficient of the x^31 term. Practical calculation of the CRC always employs a precalculated table to greatly accelerate the computation. See Sample CRC Code (Chapter 15). 4. Chunk Specifications This chapter defines the standard types of PNG chunks. 4.1. Critical chunks All implementations must understand and successfully render the standard critical chunks. A valid PNG image must contain an IHDR chunk, one or more IDAT chunks, and an IEND chunk. 4.1.1. IHDR Image header The IHDR chunk must appear FIRST. It contains: Width: 4 bytes Height: 4 bytes Bit depth: 1 byte Color type: 1 byte Compression method: 1 byte Filter method: 1 byte Interlace method: 1 byte Boutell, et. al. Informational [Page 15]  RFC 2083 PNG: Portable Network Graphics March 1997 Width and height give the image dimensions in pixels. They are 4-byte integers. Zero is an invalid value. The maximum for each is (2^31)-1 in order to accommodate languages that have difficulty with unsigned 4-byte values. Bit depth is a single-byte integer giving the number of bits per sample or per palette index (not per pixel). Valid values are 1, 2, 4, 8, and 16, although not all values are allowed for all color types. Color type is a single-byte integer that describes the interpretation of the image data. Color type codes represent sums of the following values: 1 (palette used), 2 (color used), and 4 (alpha channel used). Valid values are 0, 2, 3, 4, and 6. Bit depth restrictions for each color type are imposed to simplify implementations and to prohibit combinations that do not compress well. Decoders must support all legal combinations of bit depth and color type. The allowed combinations are: Color Allowed Interpretation Type Bit Depths 0 1,2,4,8,16 Each pixel is a grayscale sample. 2 8,16 Each pixel is an R,G,B triple. 3 1,2,4,8 Each pixel is a palette index; a PLTE chunk must appear. 4 8,16 Each pixel is a grayscale sample, followed by an alpha sample. 6 8,16 Each pixel is an R,G,B triple, followed by an alpha sample. The sample depth is the same as the bit depth except in the case of color type 3, in which the sample depth is always 8 bits. Compression method is a single-byte integer that indicates the method used to compress the image data. At present, only compression method 0 (deflate/inflate compression with a 32K sliding window) is defined. All standard PNG images must be compressed with this scheme. The compression method field is provided for possible future expansion or proprietary variants. Decoders must check this byte and report an error if it holds Boutell, et. al. Informational [Page 16]  RFC 2083 PNG: Portable Network Graphics March 1997 an unrecognized code. See Deflate/Inflate Compression (Chapter 5) for details. Filter method is a single-byte integer that indicates the preprocessing method applied to the image data before compression. At present, only filter method 0 (adaptive filtering with five basic filter types) is defined. As with the compression method field, decoders must check this byte and report an error if it holds an unrecognized code. See Filter Algorithms (Chapter 6) for details. Interlace method is a single-byte integer that indicates the transmission order of the image data. Two values are currently defined: 0 (no interlace) or 1 (Adam7 interlace). See Interlaced data order (Section 2.6) for details. 4.1.2. PLTE Palette The PLTE chunk contains from 1 to 256 palette entries, each a three-byte series of the form: Red: 1 byte (0 = black, 255 = red) Green: 1 byte (0 = black, 255 = green) Blue: 1 byte (0 = black, 255 = blue) The number of entries is determined from the chunk length. A chunk length not divisible by 3 is an error. This chunk must appear for color type 3, and can appear for color types 2 and 6; it must not appear for color types 0 and 4. If this chunk does appear, it must precede the first IDAT chunk. There must not be more than one PLTE chunk. For color type 3 (indexed color), the PLTE chunk is required. The first entry in PLTE is referenced by pixel value 0, the second by pixel value 1, etc. The number of palette entries must not exceed the range that can be represented in the image bit depth (for example, 2^4 = 16 for a bit depth of 4). It is permissible to have fewer entries than the bit depth would allow. In that case, any out-of-range pixel value found in the image data is an error. For color types 2 and 6 (truecolor and truecolor with alpha), the PLTE chunk is optional. If present, it provides a suggested set of from 1 to 256 colors to which the truecolor image can be quantized if the viewer cannot display truecolor directly. If PLTE is not present, such a viewer will need to select colors on its own, but it is often preferable for this Boutell, et. al. Informational [Page 17]  RFC 2083 PNG: Portable Network Graphics March 1997 to be done once by the encoder. (See Recommendations for Encoders: Suggested palettes, Section 9.5.) Note that the palette uses 8 bits (1 byte) per sample regardless of the image bit depth specification. In particular, the palette is 8 bits deep even when it is a suggested quantization of a 16-bit truecolor image. There is no requirement that the palette entries all be used by the image, nor that they all be different. 4.1.3. IDAT Image data The IDAT chunk contains the actual image data. To create this data: * Begin with image scanlines represented as described in Image layout (Section 2.3); the layout and total size of this raw data are determined by the fields of IHDR. * Filter the image data according to the filtering method specified by the IHDR chunk. (Note that with filter method 0, the only one currently defined, this implies prepending a filter type byte to each scanline.) * Compress the filtered data using the compression method specified by the IHDR chunk. The IDAT chunk contains the output datastream of the compression algorithm. To read the image data, reverse this process. There can be multiple IDAT chunks; if so, they must appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of all the IDAT chunks. The encoder can divide the compressed datastream into IDAT chunks however it wishes. (Multiple IDAT chunks are allowed so that encoders can work in a fixed amount of memory; typically the chunk size will correspond to the encoder's buffer size.) It is important to emphasize that IDAT chunk boundaries have no semantic significance and can occur at any point in the compressed datastream. A PNG file in which each IDAT chunk contains only one data byte is legal, though remarkably wasteful of space. (For that matter, zero-length IDAT chunks are legal, though even more wasteful.) See Filter Algorithms (Chapter 6) and Deflate/Inflate Compression (Chapter 5) for details. Boutell, et. al. Informational [Page 18]  RFC 2083 PNG: Portable Network Graphics March 1997 4.1.4. IEND Image trailer The IEND chunk must appear LAST. It marks the end of the PNG datastream. The chunk's data field is empty. 4.2. Ancillary chunks All ancillary chunks are optional, in the sense that encoders need not write them and decoders can ignore them. However, encoders are encouraged to write the standard ancillary chunks when the information is available, and decoders are encouraged to interpret these chunks when appropriate and feasible. The standard ancillary chunks are listed in alphabetical order. This is not necessarily the order in which they would appear in a file. 4.2.1. bKGD Background color The bKGD chunk specifies a default background color to present the image against. Note that viewers are not bound to honor this chunk; a viewer can choose to use a different background. For color type 3 (indexed color), the bKGD chunk contains: Palette index: 1 byte The value is the palette index of the color to be used as background. For color types 0 and 4 (grayscale, with or without alpha), bKGD contains: Gray: 2 bytes, range 0 .. (2^bitdepth)-1 (For consistency, 2 bytes are used regardless of the image bit depth.) The value is the gray level to be used as background. For color types 2 and 6 (truecolor, with or without alpha), bKGD contains: Red: 2 bytes, range 0 .. (2^bitdepth)-1 Green: 2 bytes, range 0 .. (2^bitdepth)-1 Blue: 2 bytes, range 0 .. (2^bitdepth)-1 (For consistency, 2 bytes per sample are used regardless of the image bit depth.) This is the RGB color to be used as background. Boutell, et. al. Informational [Page 19]  RFC 2083 PNG: Portable Network Graphics March 1997 When present, the bKGD chunk must precede the first IDAT chunk, and must follow the PLTE chunk, if any. See Recommendations for Decoders: Background color (Section 10.7). 4.2.2. cHRM Primary chromaticities and white point Applications that need device-independent specification of colors in a PNG file can use the cHRM chunk to specify the 1931 CIE x,y chromaticities of the red, green, and blue primaries used in the image, and the referenced white point. See Color Tutorial (Chapter 14) for more information. The cHRM chunk contains: White Point x: 4 bytes White Point y: 4 bytes Red x: 4 bytes Red y: 4 bytes Green x: 4 bytes Green y: 4 bytes Blue x: 4 bytes Blue y: 4 bytes Each value is encoded as a 4-byte unsigned integer, representing the x or y value times 100000. For example, a value of 0.3127 would be stored as the integer 31270. cHRM is allowed in all PNG files, although it is of little value for grayscale images. If the encoder does not know the chromaticity values, it should not write a cHRM chunk; the absence of a cHRM chunk indicates that the image's primary colors are device-dependent. If the cHRM chunk appears, it must precede the first IDAT chunk, and it must also precede the PLTE chunk if present. See Recommendations for Encoders: Encoder color handling (Section 9.3), and Recommendations for Decoders: Decoder color handling (Section 10.6). Boutell, et. al. Informational [Page 20]  RFC 2083 PNG: Portable Network Graphics March 1997 4.2.3. gAMA Image gamma The gAMA chunk specifies the gamma of the camera (or simulated camera) that produced the image, and thus the gamma of the image with respect to the original scene. More precisely, the gAMA chunk encodes the file_gamma value, as defined in Gamma Tutorial (Chapter 13). The gAMA chunk contains: Image gamma: 4 bytes The value is encoded as a 4-byte unsigned integer, representing gamma times 100000. For example, a gamma of 0.45 would be stored as the integer 45000. If the encoder does not know the image's gamma value, it should not write a gAMA chunk; the absence of a gAMA chunk indicates that the gamma is unknown. If the gAMA chunk appears, it must precede the first IDAT chunk, and it must also precede the PLTE chunk if present. See Gamma correction (Section 2.7), Recommendations for Encoders: Encoder gamma handling (Section 9.2), and Recommendations for Decoders: Decoder gamma handling (Section 10.5). 4.2.4. hIST Image histogram The hIST chunk gives the approximate usage frequency of each color in the color palette. A histogram chunk can appear only when a palette chunk appears. If a viewer is unable to provide all the colors listed in the palette, the histogram may help it decide how to choose a subset of the colors for display. The hIST chunk contains a series of 2-byte (16 bit) unsigned integers. There must be exactly one entry for each entry in the PLTE chunk. Each entry is proportional to the fraction of pixels in the image that have that palette index; the exact scale factor is chosen by the encoder. Histogram entries are approximate, with the exception that a zero entry specifies that the corresponding palette entry is not used at all in the image. It is required that a histogram entry be nonzero if there are any pixels of that color. Boutell, et. al. Informational [Page 21]  RFC 2083 PNG: Portable Network Graphics March 1997 When the palette is a suggested quantization of a truecolor image, the histogram is necessarily approximate, since a decoder may map pixels to palette entries differently than the encoder did. In this situation, zero entries should not appear. The hIST chunk, if it appears, must follow the PLTE chunk, and must precede the first IDAT chunk. See Rationale: Palette histograms (Section 12.14), and Recommendations for Decoders: Suggested-palette and histogram usage (Section 10.10). 4.2.5. pHYs Physical pixel dimensions The pHYs chunk specifies the intended pixel size or aspect ratio for display of the image. It contains: Pixels per unit, X axis: 4 bytes (unsigned integer) Pixels per unit, Y axis: 4 bytes (unsigned integer) Unit specifier: 1 byte The following values are legal for the unit specifier: 0: unit is unknown 1: unit is the meter When the unit specifier is 0, the pHYs chunk defines pixel aspect ratio only; the actual size of the pixels remains unspecified. Conversion note: one inch is equal to exactly 0.0254 meters. If this ancillary chunk is not present, pixels are assumed to be square, and the physical size of each pixel is unknown. If present, this chunk must precede the first IDAT chunk. See Recommendations for Decoders: Pixel dimensions (Section 10.2). 4.2.6. sBIT Significant bits To simplify decoders, PNG specifies that only certain sample depths can be used, and further specifies that sample values should be scaled to the full range of possible values at the sample depth. However, the sBIT chunk is provided in order to store the original number of significant bits. This allows Boutell, et. al. Informational [Page 22]  RFC 2083 PNG: Portable Network Graphics March 1997 decoders to recover the original data losslessly even if the data had a sample depth not directly supported by PNG. We recommend that an encoder emit an sBIT chunk if it has converted the data from a lower sample depth. For color type 0 (grayscale), the sBIT chunk contains a single byte, indicating the number of bits that were significant in the source data. For color type 2 (truecolor), the sBIT chunk contains three bytes, indicating the number of bits that were significant in the source data for the red, green, and blue channels, respectively. For color type 3 (indexed color), the sBIT chunk contains three bytes, indicating the number of bits that were significant in the source data for the red, green, and blue components of the palette entries, respectively. For color type 4 (grayscale with alpha channel), the sBIT chunk contains two bytes, indicating the number of bits that were significant in the source grayscale data and the source alpha data, respectively. For color type 6 (truecolor with alpha channel), the sBIT chunk contains four bytes, indicating the number of bits that were significant in the source data for the red, green, blue and alpha channels, respectively. Each depth specified in sBIT must be greater than zero and less than or equal to the sample depth (which is 8 for indexed-color images, and the bit depth given in IHDR for other color types). A decoder need not pay attention to sBIT: the stored image is a valid PNG file of the sample depth indicated by IHDR. However, if the decoder wishes to recover the original data at its original precision, this can be done by right-shifting the stored samples (the stored palette entries, for an indexed- color image). The encoder must scale the data in such a way that the high-order bits match the original data. If the sBIT chunk appears, it must precede the first IDAT chunk, and it must also precede the PLTE chunk if present. See Recommendations for Encoders: Sample depth scaling (Section 9.1) and Recommendations for Decoders: Sample depth rescaling (Section 10.4). Boutell, et. al. Informational [Page 23]  RFC 2083 PNG: Portable Network Graphics March 1997 4.2.7. tEXt Textual data Textual information that the encoder wishes to record with the image can be stored in tEXt chunks. Each tEXt chunk contains a keyword and a text string, in the format: Keyword: 1-79 bytes (character string) Null separator: 1 byte Text: n bytes (character string) The keyword and text string are separated by a zero byte (null character). Neither the keyword nor the text string can contain a null character. Note that the text string is not null-terminated (the length of the chunk is sufficient information to locate the ending). The keyword must be at least one character and less than 80 characters long. The text string can be of any length from zero bytes up to the maximum permissible chunk size less the length of the keyword and separator. Any number of tEXt chunks can appear, and more than one with the same keyword is permissible. The keyword indicates the type of information represented by the text string. The following keywords are predefined and should be used where appropriate: Title Short (one line) title or caption for image Author Name of image's creator Description Description of image (possibly long) Copyright Copyright notice Creation Time Time of original image creation Software Software used to create the image Disclaimer Legal disclaimer Warning Warning of nature of content Source Device used to create the image Comment Miscellaneous comment; conversion from GIF comment For the Creation Time keyword, the date format defined in section 5.2.14 of RFC 1123 is suggested, but not required [RFC-1123]. Decoders should allow for free-format text associated with this or any other keyword. Other keywords may be invented for other purposes. Keywords of general interest can be registered with the maintainers of the PNG specification. However, it is also permitted to use private unregistered keywords. (Private keywords should be Boutell, et. al. Informational [Page 24]  RFC 2083 PNG: Portable Network Graphics March 1997 reasonably self-explanatory, in order to minimize the chance that the same keyword will be used for incompatible purposes by different people.) Both keyword and text are interpreted according to the ISO 8859-1 (Latin-1) character set [ISO-8859]. The text string can contain any Latin-1 character. Newlines in the text string should be represented by a single linefeed character (decimal 10); use of other control characters in the text is discouraged. Keywords must contain only printable Latin-1 characters and spaces; that is, only character codes 32-126 and 161-255 decimal are allowed. To reduce the chances for human misreading of a keyword, leading and trailing spaces are forbidden, as are consecutive spaces. Note also that the non- breaking space (code 160) is not permitted in keywords, since it is visually indistinguishable from an ordinary space. Keywords must be spelled exactly as registered, so that decoders can use simple literal comparisons when looking for particular keywords. In particular, keywords are considered case-sensitive. See Recommendations for Encoders: Text chunk processing (Section 9.7) and Recommendations for Decoders: Text chunk processing (Section 10.11). 4.2.8. tIME Image last-modification time The tIME chunk gives the time of the last image modification (not the time of initial image creation). It contains: Year: 2 bytes (complete; for example, 1995, not 95) Month: 1 byte (1-12) Day: 1 byte (1-31) Hour: 1 byte (0-23) Minute: 1 byte (0-59) Second: 1 byte (0-60) (yes, 60, for leap seconds; not 61, a common error) Universal Time (UTC, also called GMT) should be specified rather than local time. Boutell, et. al. Informational [Page 25]  RFC 2083 PNG: Portable Network Graphics March 1997 The tIME chunk is intended for use as an automatically-applied time stamp that is updated whenever the image data is changed. It is recommended that tIME not be changed by PNG editors that do not change the image data. See also the Creation Time tEXt keyword, which can be used for a user-supplied time. 4.2.9. tRNS Transparency The tRNS chunk specifies that the image uses simple transparency: either alpha values associated with palette entries (for indexed-color images) or a single transparent color (for grayscale and truecolor images). Although simple transparency is not as elegant as the full alpha channel, it requires less storage space and is sufficient for many common cases. For color type 3 (indexed color), the tRNS chunk contains a series of one-byte alpha values, corresponding to entries in the PLTE chunk: Alpha for palette index 0: 1 byte Alpha for palette index 1: 1 byte ... etc ... Each entry indicates that pixels of the corresponding palette index must be treated as having the specified alpha value. Alpha values have the same interpretation as in an 8-bit full alpha channel: 0 is fully transparent, 255 is fully opaque, regardless of image bit depth. The tRNS chunk must not contain more alpha values than there are palette entries, but tRNS can contain fewer values than there are palette entries. In this case, the alpha value for all remaining palette entries is assumed to be 255. In the common case in which only palette index 0 need be made transparent, only a one-byte tRNS chunk is needed. For color type 0 (grayscale), the tRNS chunk contains a single gray level value, stored in the format: Gray: 2 bytes, range 0 .. (2^bitdepth)-1 (For consistency, 2 bytes are used regardless of the image bit depth.) Pixels of the specified gray level are to be treated as transparent (equivalent to alpha value 0); all other pixels are to be treated as fully opaque (alpha value (2^bitdepth)-1). Boutell, et. al. Informational [Page 26]  RFC 2083 PNG: Portable Network Graphics March 1997 For color type 2 (truecolor), the tRNS chunk contains a single RGB color value, stored in the format: Red: 2 bytes, range 0 .. (2^bitdepth)-1 Green: 2 bytes, range 0 .. (2^bitdepth)-1 Blue: 2 bytes, range 0 .. (2^bitdepth)-1 (For consistency, 2 bytes per sample are used regardless of the image bit depth.) Pixels of the specified color value are to be treated as transparent (equivalent to alpha value 0); all other pixels are to be treated as fully opaque (alpha value (2^bitdepth)-1). tRNS is prohibited for color types 4 and 6, since a full alpha channel is already present in those cases. Note: when dealing with 16-bit grayscale or truecolor data, it is important to compare both bytes of the sample values to determine whether a pixel is transparent. Although decoders may drop the low-order byte of the samples for display, this must not occur until after the data has been tested for transparency. For example, if the grayscale level 0x0001 is specified to be transparent, it would be incorrect to compare only the high-order byte and decide that 0x0002 is also transparent. When present, the tRNS chunk must precede the first IDAT chunk, and must follow the PLTE chunk, if any. 4.2.10. zTXt Compressed textual data The zTXt chunk contains textual data, just as tEXt does; however, zTXt takes advantage of compression. zTXt and tEXt chunks are semantically equivalent, but zTXt is recommended for storing large blocks of text. A zTXt chunk contains: Keyword: 1-79 bytes (character string) Null separator: 1 byte Compression method: 1 byte Compressed text: n bytes The keyword and null separator are exactly the same as in the tEXt chunk. Note that the keyword is not compressed. The compression method byte identifies the compression method used in this zTXt chunk. The only value presently defined for it is 0 (deflate/inflate compression). The compression method byte is Boutell, et. al. Informational [Page 27]  RFC 2083 PNG: Portable Network Graphics March 1997 followed by a compressed datastream that makes up the remainder of the chunk. For compression method 0, this datastream adheres to the zlib datastream format (see Deflate/Inflate Compression, Chapter 5). Decompression of this datastream yields Latin-1 text that is identical to the text that would be stored in an equivalent tEXt chunk. Any number of zTXt and tEXt chunks can appear in the same file. See the preceding definition of the tEXt chunk for the predefined keywords and the recommended format of the text. See Recommendations for Encoders: Text chunk processing (Section 9.7), and Recommendations for Decoders: Text chunk processing (Section 10.11). 4.3. Summary of standard chunks This table summarizes some properties of the standard chunk types. Critical chunks (must appear in this order, except PLTE is optional): Name Multiple Ordering constraints OK? IHDR No Must be first PLTE No Before IDAT IDAT Yes Multiple IDATs must be consecutive IEND No Must be last Ancillary chunks (need not appear in this order): Name Multiple Ordering constraints OK? cHRM No Before PLTE and IDAT gAMA No Before PLTE and IDAT sBIT No Before PLTE and IDAT bKGD No After PLTE; before IDAT hIST No After PLTE; before IDAT tRNS No After PLTE; before IDAT pHYs No Before IDAT tIME No None tEXt Yes None zTXt Yes None Boutell, et. al. Informational [Page 28]  RFC 2083 PNG: Portable Network Graphics March 1997 Standard keywords for tEXt and zTXt chunks: Title Short (one line) title or caption for image Author Name of image's creator Description Description of image (possibly long) Copyright Copyright notice Creation Time Time of original image creation Software Software used to create the image Disclaimer Legal disclaimer Warning Warning of nature of content Source Device used to create the image Comment Miscellaneous comment; conversion from GIF comment 4.4. Additional chunk types Additional public PNG chunk types are defined in the document 'PNG Special-Purpose Public Chunks' [PNG-EXTENSIONS]. Chunks described there are expected to be less widely supported than those defined in this specification. However, application authors are encouraged to use those chunk types whenever appropriate for their applications. Additional chunk types can be proposed for inclusion in that list by contacting the PNG specification maintainers at png-info@uunet.uu.net or at png-group@w3.org. New public chunks will only be registered if they are of use to others and do not violate the design philosophy of PNG. Chunk registration is not automatic, although it is the intent of the authors that it be straightforward when a new chunk of potentially wide application is needed. Note that the creation of new critical chunk types is discouraged unless absolutely necessary. Applications can also use private chunk types to carry data that is not of interest to other applications. See Recommendations for Encoders: Use of private chunks (Section 9.8). Decoders must be prepared to encounter unrecognized public or private chunk type codes. Unrecognized chunk types must be handled as described in Chunk naming conventions (Section 3.3). 5. Deflate/Inflate Compression PNG compression method 0 (the only compression method presently defined for PNG) specifies deflate/inflate compression with a 32K sliding window. Deflate compression is an LZ77 derivative used in zip, gzip, pkzip and related programs. Extensive research has been done supporting its patent-free status. Portable C implementations are freely available. Boutell, et. al. Informational [Page 29]  RFC 2083 PNG: Portable Network Graphics March 1997 Deflate-compressed datastreams within PNG are stored in the 'zlib' format, which has the structure: Compression method/flags code: 1 byte Additional flags/check bits: 1 byte Compressed data blocks: n bytes Check value: 4 bytes Further details on this format are given in the zlib specification [RFC-1950]. For PNG compression method 0, the zlib compression method/flags code must specify method code 8 ('deflate' compression) and an LZ77 window size of not more than 32K. Note that the zlib compression method number is not the same as the PNG compression method number. The additional flags must not specify a preset dictionary. The compressed data within the zlib datastream is stored as a series of blocks, each of which can represent raw (uncompressed) data, LZ77-compressed data encoded with fixed Huffman codes, or LZ77- compressed data encoded with custom Huffman codes. A marker bit in the final block identifies it as the last block, allowing the decoder to recognize the end of the compressed datastream. Further details on the compression algorithm and the encoding are given in the deflate specification [RFC-1951]. The check value stored at the end of the zlib datastream is calculated on the uncompressed data represented by the datastream. Note that the algorithm used is not the same as the CRC calculation used for PNG chunk check values. The zlib check value is useful mainly as a cross-check that the deflate and inflate algorithms are implemented correctly. Verifying the chunk CRCs provides adequate confidence that the PNG file has been transmitted undamaged. In a PNG file, the concatenation of the contents of all the IDAT chunks makes up a zlib datastream as specified above. This datastream decompresses to filtered image data as described elsewhere in this document. It is important to emphasize that the boundaries between IDAT chunks are arbitrary and can fall anywhere in the zlib datastream. There is not necessarily any correlation between IDAT chunk boundaries and deflate block boundaries or any other feature of the zlib data. For example, it is entirely possible for the terminating zlib check value to be split across IDAT chunks. Boutell, et. al. Informational [Page 30]  RFC 2083 PNG: Portable Network Graphics March 1997 In the same vein, there is no required correlation between the structure of the image data (i.e., scanline boundaries) and deflate block boundaries or IDAT chunk boundaries. The complete image data is represented by a single zlib datastream that is stored in some number of IDAT chunks; a decoder that assumes any more than this is incorrect. (Of course, some encoder implementations may emit files in which some of these structures are indeed related. But decoders cannot rely on this.) PNG also uses zlib datastreams in zTXt chunks. In a zTXt chunk, the remainder of the chunk following the compression method byte is a zlib datastream as specified above. This datastream decompresses to the user-readable text described by the chunk's keyword. Unlike the image data, such datastreams are not split across chunks; each zTXt chunk contains an independent zlib datastream. Additional documentation and portable C code for deflate and inflate are available from the Info-ZIP archives at . 6. Filter Algorithms This chapter describes the filter algorithms that can be applied before compression. The purpose of these filters is to prepare the image data for optimum compression. 6.1. Filter types PNG filter method 0 defines five basic filter types: Type Name 0 None 1 Sub 2 Up 3 Average 4 Paeth (Note that filter method 0 in IHDR specifies exactly this set of five filter types. If the set of filter types is ever extended, a different filter method number will be assigned to the extended set, so that decoders need not decompress the data to discover that it contains unsupported filter types.) The encoder can choose which of these filter algorithms to apply on a scanline-by-scanline basis. In the image data sent to the compression step, each scanline is preceded by a filter type byte that specifies the filter algorithm used for that scanline. Boutell, et. al. Informational [Page 31]  RFC 2083 PNG: Portable Network Graphics March 1997 Filtering algorithms are applied to bytes, not to pixels, regardless of the bit depth or color type of the image. The filtering algorithms work on the byte sequence formed by a scanline that has been represented as described in Image layout (Section 2.3). If the image includes an alpha channel, the alpha data is filtered in the same way as the image data. When the image is interlaced, each pass of the interlace pattern is treated as an independent image for filtering purposes. The filters work on the byte sequences formed by the pixels actually transmitted during a pass, and the 'previous scanline' is the one previously transmitted in the same pass, not the one adjacent in the complete image. Note that the subimage transmitted in any one pass is always rectangular, but is of smaller width and/or height than the complete image. Filtering is not applied when this subimage is empty. For all filters, the bytes 'to the left of' the first pixel in a scanline must be treated as being zero. For filters that refer to the prior scanline, the entire prior scanline must be treated as being zeroes for the first scanline of an image (or of a pass of an interlaced image). To reverse the effect of a filter, the decoder must use the decoded values of the prior pixel on the same line, the pixel immediately above the current pixel on the prior line, and the pixel just to the left of the pixel above. This implies that at least one scanline's worth of image data will have to be stored by the decoder at all times. Even though some filter types do not refer to the prior scanline, the decoder will always need to store each scanline as it is decoded, since the next scanline might use a filter that refers to it. PNG imposes no restriction on which filter types can be applied to an image. However, the filters are not equally effective on all types of data. See Recommendations for Encoders: Filter selection (Section 9.6). See also Rationale: Filtering (Section 12.9). 6.2. Filter type 0: None With the None filter, the scanline is transmitted unmodified; it is only necessary to insert a filter type byte before the data. Boutell, et. al. Informational [Page 32]  RFC 2083 PNG: Portable Network Graphics March 1997 6.3. Filter type 1: Sub The Sub filter transmits the difference between each byte and the value of the corresponding byte of the prior pixel. To compute the Sub filter, apply the following formula to each byte of the scanline: Sub(x) = Raw(x) - Raw(x-bpp) where x ranges from zero to the number of bytes representing the scanline minus one, Raw(x) refers to the raw data byte at that byte position in the scanline, and bpp is defined as the number of bytes per complete pixel, rounding up to one. For example, for color type 2 with a bit depth of 16, bpp is equal to 6 (three samples, two bytes per sample); for color type 0 with a bit depth of 2, bpp is equal to 1 (rounding up); for color type 4 with a bit depth of 16, bpp is equal to 4 (two-byte grayscale sample, plus two-byte alpha sample). Note this computation is done for each byte, regardless of bit depth. In a 16-bit image, each MSB is predicted from the preceding MSB and each LSB from the preceding LSB, because of the way that bpp is defined. Unsigned arithmetic modulo 256 is used, so that both the inputs and outputs fit into bytes. The sequence of Sub values is transmitted as the filtered scanline. For all x < 0, assume Raw(x) = 0. To reverse the effect of the Sub filter after decompression, output the following value: Sub(x) + Raw(x-bpp) (computed mod 256), where Raw refers to the bytes already decoded. 6.4. Filter type 2: Up The Up filter is just like the Sub filter except that the pixel immediately above the current pixel, rather than just to its left, is used as the predictor. To compute the Up filter, apply the following formula to each byte of the scanline: Up(x) = Raw(x) - Prior(x) Boutell, et. al. Informational [Page 33]  RFC 2083 PNG: Portable Network Graphics March 1997 where x ranges from zero to the number of bytes representing the scanline minus one, Raw(x) refers to the raw data byte at that byte position in the scanline, and Prior(x) refers to the unfiltered bytes of the prior scanline. Note this is done for each byte, regardless of bit depth. Unsigned arithmetic modulo 256 is used, so that both the inputs and outputs fit into bytes. The sequence of Up values is transmitted as the filtered scanline. On the first scanline of an image (or of a pass of an interlaced image), assume Prior(x) = 0 for all x. To reverse the effect of the Up filter after decompression, output the following value: Up(x) + Prior(x) (computed mod 256), where Prior refers to the decoded bytes of the prior scanline. 6.5. Filter type 3: Average The Average filter uses the average of the two neighboring pixels (left and above) to predict the value of a pixel. To compute the Average filter, apply the following formula to each byte of the scanline: Average(x) = Raw(x) - floor((Raw(x-bpp)+Prior(x))/2) where x ranges from zero to the number of bytes representing the scanline minus one, Raw(x) refers to the raw data byte at that byte position in the scanline, Prior(x) refers to the unfiltered bytes of the prior scanline, and bpp is defined as for the Sub filter. Note this is done for each byte, regardless of bit depth. The sequence of Average values is transmitted as the filtered scanline. The subtraction of the predicted value from the raw byte must be done modulo 256, so that both the inputs and outputs fit into bytes. However, the sum Raw(x-bpp)+Prior(x) must be formed without overflow (using at least nine-bit arithmetic). floor() indicates that the result of the division is rounded to the next lower integer if fractional; in other words, it is an integer division or right shift operation. Boutell, et. al. Informational [Page 34]  RFC 2083 PNG: Portable Network Graphics March 1997 For all x < 0, assume Raw(x) = 0. On the first scanline of an image (or of a pass of an interlaced image), assume Prior(x) = 0 for all x. To reverse the effect of the Average filter after decompression, output the following value: Average(x) + floor((Raw(x-bpp)+Prior(x))/2) where the result is computed mod 256, but the prediction is calculated in the same way as for encoding. Raw refers to the bytes already decoded, and Prior refers to the decoded bytes of the prior scanline. 6.6. Filter type 4: Paeth The Paeth filter computes a simple linear function of the three neighboring pixels (left, above, upper left), then chooses as predictor the neighboring pixel closest to the computed value. This technique is due to Alan W. Paeth [PAETH]. To compute the Paeth filter, apply the following formula to each byte of the scanline: Paeth(x) = Raw(x) - PaethPredictor(Raw(x-bpp), Prior(x), Prior(x-bpp)) where x ranges from zero to the number of bytes representing the scanline minus one, Raw(x) refers to the raw data byte at that byte position in the scanline, Prior(x) refers to the unfiltered bytes of the prior scanline, and bpp is defined as for the Sub filter. Note this is done for each byte, regardless of bit depth. Unsigned arithmetic modulo 256 is used, so that both the inputs and outputs fit into bytes. The sequence of Paeth values is transmitted as the filtered scanline. Boutell, et. al. Informational [Page 35]  RFC 2083 PNG: Portable Network Graphics March 1997 The PaethPredictor function is defined by the following pseudocode: function PaethPredictor (a, b, c) begin ; a = left, b = above, c = upper left p := a + b - c ; initial estimate pa := abs(p - a) ; distances to a, b, c pb := abs(p - b) pc := abs(p - c) ; return nearest of a,b,c, ; breaking ties in order a,b,c. if pa <= pb AND pa <= pc then return a else if pb <= pc then return b else return c end The calculations within the PaethPredictor function must be performed exactly, without overflow. Arithmetic modulo 256 is to be used only for the final step of subtracting the function result from the target byte value. Note that the order in which ties are broken is critical and must not be altered. The tie break order is: pixel to the left, pixel above, pixel to the upper left. (This order differs from that given in Paeth's article.) For all x < 0, assume Raw(x) = 0 and Prior(x) = 0. On the first scanline of an image (or of a pass of an interlaced image), assume Prior(x) = 0 for all x. To reverse the effect of the Paeth filter after decompression, output the following value: Paeth(x) + PaethPredictor(Raw(x-bpp), Prior(x), Prior(x-bpp)) (computed mod 256), where Raw and Prior refer to bytes already decoded. Exactly the same PaethPredictor function is used by both encoder and decoder. 7. Chunk Ordering Rules To allow new chunk types to be added to PNG, it is necessary to establish rules about the ordering requirements for all chunk types. Otherwise a PNG editing program cannot know what to do when it encounters an unknown chunk. Boutell, et. al. Informational [Page 36]  RFC 2083 PNG: Portable Network Graphics March 1997 We define a 'PNG editor' as a program that modifies a PNG file and wishes to preserve as much as possible of the ancillary information in the file. Two examples of PNG editors are a program that adds or modifies text chunks, and a program that adds a suggested palette to a truecolor PNG file. Ordinary image editors are not PNG editors in this sense, because they usually discard all unrecognized information while reading in an image. (Note: we strongly encourage programs handling PNG files to preserve ancillary information whenever possible.) As an example of possible problems, consider a hypothetical new ancillary chunk type that is safe-to-copy and is required to appear after PLTE if PLTE is present. If our program to add a suggested PLTE does not recognize this new chunk, it may insert PLTE in the wrong place, namely after the new chunk. We could prevent such problems by requiring PNG editors to discard all unknown chunks, but that is a very unattractive solution. Instead, PNG requires ancillary chunks not to have ordering restrictions like this. To prevent this type of problem while allowing for future extension, we put some constraints on both the behavior of PNG editors and the allowed ordering requirements for chunks. 7.1. Behavior of PNG editors The rules for PNG editors are: * When copying an unknown unsafe-to-copy ancillary chunk, a PNG editor must not move the chunk relative to any critical chunk. It can relocate the chunk freely relative to other ancillary chunks that occur between the same pair of critical chunks. (This is well defined since the editor must not add, delete, modify, or reorder critical chunks if it is preserving unknown unsafe-to-copy chunks.) * When copying an unknown safe-to-copy ancillary chunk, a PNG editor must not move the chunk from before IDAT to after IDAT or vice versa. (This is well defined because IDAT is always present.) Any other reordering is permitted. * When copying a known ancillary chunk type, an editor need only honor the specific chunk ordering rules that exist for that chunk type. However, it can always choose to apply the above general rules instead. * PNG editors must give up on encountering an unknown critical chunk type, because there is no way to be certain that a valid file will result from modifying a file containing such a chunk. (Note that simply discarding the chunk is not good enough, because it might have unknown implications for the interpretation of other chunks.) Boutell, et. al. Informational [Page 37]  RFC 2083 PNG: Portable Network Graphics March 1997 These rules are expressed in terms of copying chunks from an input file to an output file, but they apply in the obvious way if a PNG file is modified in place. See also Chunk naming conventions (Section 3.3). 7.2. Ordering of ancillary chunks The ordering rules for an ancillary chunk type cannot be any stricter than this: * Unsafe-to-copy chunks can have ordering requirements relative to critical chunks. * Safe-to-copy chunks can have ordering requirements relative to IDAT. The actual ordering rules for any particular ancillary chunk type may be weaker. See for example the ordering rules for the standard ancillary chunk types (Summary of standard chunks, Section 4.3). Decoders must not assume more about the positioning of any ancillary chunk than is specified by the chunk ordering rules. In particular, it is never valid to assume that a specific ancillary chunk type occurs with any particular positioning relative to other ancillary chunks. (For example, it is unsafe to assume that your private ancillary chunk occurs immediately before IEND. Even if your application always writes it there, a PNG editor might have inserted some other ancillary chunk after it. But you can safely assume that your chunk will remain somewhere between IDAT and IEND.) 7.3. Ordering of critical chunks Critical chunks can have arbitrary ordering requirements, because PNG editors are required to give up if they encounter unknown critical chunks. For example, IHDR has the special ordering rule that it must always appear first. A PNG editor, or indeed any PNG-writing program, must know and follow the ordering rules for any critical chunk type that it can emit. Boutell, et. al. Informational [Page 38]  RFC 2083 PNG: Portable Network Graphics March 1997 8. Miscellaneous Topics 8.1. File name extension On systems where file names customarily include an extension signifying file type, the extension '.png' is recommended for PNG files. Lower case '.png' is preferred if file names are case- sensitive. 8.2. Internet media type The Internet Assigned Numbers Authority (IANA) has registered 'image/png' as the Internet Media Type for PNG [RFC-2045, RFC- 2048]. For robustness, decoders may choose to also support the interim media type 'image/x-png' which was in use before registration was complete. 8.3. Macintosh file layout In the Apple Macintosh system, the following conventions are recommended: * The four-byte file type code for PNG files is 'PNGf'. (This code has been registered with Apple for PNG files.) The creator code will vary depending on the creating application. * The contents of the data fork must be a PNG file exactly as described in the rest of this specification. * The contents of the resource fork are unspecified. It may be empty or may contain application-dependent resources. * When transferring a Macintosh PNG file to a non-Macintosh system, only the data fork should be transferred. 8.4. Multiple-image extension PNG itself is strictly a single-image format. However, it may be necessary to store multiple images within one file; for example, this is needed to convert some GIF files. In the future, a multiple-image format based on PNG may be defined. Such a format will be considered a separate file format and will have a different signature. PNG-supporting applications may or may not choose to support the multiple-image format. See Rationale: Why not these features? (Section 12.3). Boutell, et. al. Informational [Page 39]  RFC 2083 PNG: Portable Network Graphics March 1997 8.5. Security considerations A PNG file or datastream is composed of a collection of explicitly typed 'chunks'. Chunks whose contents are defined by the specification could actually contain anything, including malicious code. But there is no known risk that such malicious code could be executed on the recipient's computer as a result of decoding the PNG image. The possible security risks associated with future chunk types cannot be specified at this time. Security issues will be considered when evaluating chunks proposed for registration as public chunks. There is no additional security risk associated with unknown or unimplemented chunk types, because such chunks will be ignored, or at most be copied into another PNG file. The tEXt and zTXt chunks contain data that is meant to be displayed as plain text. It is possible that if the decoder displays such text without filtering out control characters, especially the ESC (escape) character, certain systems or terminals could behave in undesirable and insecure ways. We recommend that decoders filter out control characters to avoid this risk; see Recommendations for Decoders: Text chunk processing (Section 10.11). Because every chunk's length is available at its beginning, and because every chunk has a CRC trailer, there is a very robust defense against corrupted data and against fraudulent chunks that attempt to overflow the decoder's buffers. Also, the PNG signature bytes provide early detection of common file transmission errors. A decoder that fails to check CRCs could be subject to data corruption. The only likely consequence of such corruption is incorrectly displayed pixels within the image. Worse things might happen if the CRC of the IHDR chunk is not checked and the width or height fields are corrupted. See Recommendations for Decoders: Error checking (Section 10.1). A poorly written decoder might be subject to buffer overflow, because chunks can be extremely large, up to (2^31)-1 bytes long. But properly written decoders will handle large chunks without difficulty. Boutell, et. al. Informational [Page 40]  RFC 2083 PNG: Portable Network Graphics March 1997 9. Recommendations for Encoders This chapter gives some recommendations for encoder behavior. The only absolute requirement on a PNG encoder is that it produce files that conform to the format specified in the preceding chapters. However, best results will usually be achieved by following these recommendations. 9.1. Sample depth scaling When encoding input samples that have a sample depth that cannot be directly represented in PNG, the encoder must scale the samples up to a sample depth that is allowed by PNG. The most accurate scaling method is the linear equation output = ROUND(input * MAXOUTSAMPLE / MAXINSAMPLE) where the input samples range from 0 to MAXINSAMPLE and the outputs range from 0 to MAXOUTSAMPLE (which is (2^sampledepth)-1). A close approximation to the linear scaling method can be achieved by 'left bit replication', which is shifting the valid bits to begin in the most significant bit and repeating the most significant bits into the open bits. This method is often faster to compute than linear scaling. As an example, assume that 5-bit samples are being scaled up to 8 bits. If the source sample value is 27 (in the range from 0-31), then the original bits are: 4 3 2 1 0 --------- 1 1 0 1 1 Left bit replication gives a value of 222: 7 6 5 4 3 2 1 0 ---------------- 1 1 0 1 1 1 1 0 |=======| |===| | Leftmost Bits Repeated to Fill Open Bits | Original Bits which matches the value computed by the linear equation. Left bit replication usually gives the same value as linear scaling, and is never off by more than one. Boutell, et. al. Informational [Page 41]  RFC 2083 PNG: Portable Network Graphics March 1997 A distinctly less accurate approximation is obtained by simply left-shifting the input value and filling the low order bits with zeroes. This scheme cannot reproduce white exactly, since it does not generate an all-ones maximum value; the net effect is to darken the image slightly. This method is not recommended in general, but it does have the effect of improving compression, particularly when dealing with greater-than-eight-bit sample depths. Since the relative error introduced by zero-fill scaling is small at high sample depths, some encoders may choose to use it. Zero-fill must not be used for alpha channel data, however, since many decoders will special-case alpha values of all zeroes and all ones. It is important to represent both those values exactly in the scaled data. When the encoder writes an sBIT chunk, it is required to do the scaling in such a way that the high-order bits of the stored samples match the original data. That is, if the sBIT chunk specifies a sample depth of S, the high-order S bits of the stored data must agree with the original S-bit data values. This allows decoders to recover the original data by shifting right. The added low-order bits are not constrained. Note that all the above scaling methods meet this restriction. When scaling up source data, it is recommended that the low-order bits be filled consistently for all samples; that is, the same source value should generate the same sample value at any pixel position. This improves compression by reducing the number of distinct sample values. However, this is not a requirement, and some encoders may choose not to follow it. For example, an encoder might instead dither the low-order bits, improving displayed image quality at the price of increasing file size. In some applications the original source data may have a range that is not a power of 2. The linear scaling equation still works for this case, although the shifting methods do not. It is recommended that an sBIT chunk not be written for such images, since sBIT suggests that the original data range was exactly 0..2^S-1. 9.2. Encoder gamma handling See Gamma Tutorial (Chapter 13) if you aren't already familiar with gamma issues. Proper handling of gamma encoding and the gAMA chunk in an encoder depends on the prior history of the sample values and on whether these values have already been quantized to integers. Boutell, et. al. Informational [Page 42]  RFC 2083 PNG: Portable Network Graphics March 1997 If the encoder has access to sample intensity values in floating- point or high-precision integer form (perhaps from a computer image renderer), then it is recommended that the encoder perform its own gamma encoding before quantizing the data to integer values for storage in the file. Applying gamma encoding at this stage results in images with fewer banding artifacts at a given sample depth, or allows smaller samples while retaining the same visual quality. A linear intensity level, expressed as a floating-point value in the range 0 to 1, can be converted to a gamma-encoded sample value by sample = ROUND((intensity ^ encoder_gamma) * MAXSAMPLE) The file_gamma value to be written in the PNG gAMA chunk is the same as encoder_gamma in this equation, since we are assuming the initial intensity value is linear (in effect, camera_gamma is 1.0). If the image is being written to a file only, the encoder_gamma value can be selected somewhat arbitrarily. Values of 0.45 or 0.5 are generally good choices because they are common in video systems, and so most PNG decoders should do a good job displaying such images. Some image renderers may simultaneously write the image to a PNG file and display it on-screen. The displayed pixels should be gamma corrected for the display system and viewing conditions in use, so that the user sees a proper representation of the intended scene. An appropriate gamma correction value is screen_gc = viewing_gamma / display_gamma If the renderer wants to write the same gamma-corrected sample values to the PNG file, avoiding a separate gamma-encoding step for file output, then this screen_gc value should be written in the gAMA chunk. This will allow a PNG decoder to reproduce what the file's originator saw on screen during rendering (provided the decoder properly supports arbitrary values in a gAMA chunk). However, it is equally reasonable for a renderer to apply gamma correction for screen display using a gamma appropriate to the viewing conditions, and to separately gamma-encode the sample values for file storage using a standard value of gamma such as 0.5. In fact, this is preferable, since some PNG decoders may not accurately display images with unusual gAMA values. Boutell, et. al. Informational [Page 43]  RFC 2083 PNG: Portable Network Graphics March 1997 Computer graphics renderers often do not perform gamma encoding, instead making sample values directly proportional to scene light intensity. If the PNG encoder receives sample values that have already been quantized into linear-light integer values, there is no point in doing gamma encoding on them; that would just result in further loss of information. The encoder should just write the sample values to the PNG file. This 'linear' sample encoding is equivalent to gamma encoding with a gamma of 1.0, so graphics programs that produce linear samples should always emit a gAMA chunk specifying a gamma of 1.0. When the sample values come directly from a piece of hardware, the correct gAMA value is determined by the gamma characteristic of the hardware. In the case of video digitizers ('frame grabbers'), gAMA should be 0.45 or 0.5 for NTSC (possibly less for PAL or SECAM) since video camera transfer functions are standardized. Image scanners are less predictable. Their output samples may be linear (gamma 1.0) since CCD sensors themselves are linear, or the scanner hardware may have already applied gamma correction designed to compensate for dot gain in subsequent printing (gamma of about 0.57), or the scanner may have corrected the samples for display on a CRT (gamma of 0.4-0.5). You will need to refer to the scanner's manual, or even scan a calibrated gray wedge, to determine what a particular scanner does. File format converters generally should not attempt to convert supplied images to a different gamma. Store the data in the PNG file without conversion, and record the source gamma if it is known. Gamma alteration at file conversion time causes re- quantization of the set of intensity levels that are represented, introducing further roundoff error with little benefit. It's almost always better to just copy the sample values intact from the input to the output file. In some cases, the supplied image may be in an image format (e.g., TIFF) that can describe the gamma characteristic of the image. In such cases, a file format converter is strongly encouraged to write a PNG gAMA chunk that corresponds to the known gamma of the source image. Note that some file formats specify the gamma of the display system, not the camera. If the input file's gamma value is greater than 1.0, it is almost certainly a display system gamma, and you should use its reciprocal for the PNG gAMA. Boutell, et. al. Informational [Page 44]  RFC 2083 PNG: Portable Network Graphics March 1997 If the encoder or file format converter does not know how an image was originally created, but does know that the image has been displayed satisfactorily on a display with gamma display_gamma under lighting conditions where a particular viewing_gamma is appropriate, then the image can be marked as having the file_gamma: file_gamma = viewing_gamma / display_gamma This will allow viewers of the PNG file to see the same image that the person running the file format converter saw. Although this may not be precisely the correct value of the image gamma, it's better to write a gAMA chunk with an approximately right value than to omit the chunk and force PNG decoders to guess at an appropriate gamma. On the other hand, if the image file is being converted as part of a 'bulk' conversion, with no one looking at each image, then it is better to omit the gAMA chunk entirely. If the image gamma has to be guessed at, leave it to the decoder to do the guessing. Gamma does not apply to alpha samples; alpha is always represented linearly. See also Recommendations for Decoders: Decoder gamma handling (Section 10.5). 9.3. Encoder color handling See Color Tutorial (Chapter 14) if you aren't already familiar with color issues. If it is possible for the encoder to determine the chromaticities of the source display primaries, or to make a strong guess based on the origin of the image or the hardware running it, then the encoder is strongly encouraged to output the cHRM chunk. If it does so, the gAMA chunk should also be written; decoders can do little with cHRM if gAMA is missing. Boutell, et. al. Informational [Page 45]  RFC 2083 PNG: Portable Network Graphics March 1997 Video created with recent video equipment probably uses the CCIR 709 primaries and D65 white point [ITU-BT709], which are: R G B White x 0.640 0.300 0.150 0.3127 y 0.330 0.600 0.060 0.3290 An older but still very popular video standard is SMPTE-C [SMPTE- 170M]: R G B White x 0.630 0.310 0.155 0.3127 y 0.340 0.595 0.070 0.3290 The original NTSC color primaries have not been used in decades. Although you may still find the NTSC numbers listed in standards documents, you won't find any images that actually use them. Scanners that produce PNG files as output should insert the filter chromaticities into a cHRM chunk and the camera_gamma into a gAMA chunk. In the case of hand-drawn or digitally edited images, you have to determine what monitor they were viewed on when being produced. Many image editing programs allow you to specify what type of monitor you are using. This is often because they are working in some device-independent space internally. Such programs have enough information to write valid cHRM and gAMA chunks, and should do so automatically. If the encoder is compiled as a portion of a computer image renderer that performs full-spectral rendering, the monitor values that were used to convert from the internal device-independent color space to RGB should be written into the cHRM chunk. Any colors that are outside the gamut of the chosen RGB device should be clipped or otherwise constrained to be within the gamut; PNG does not store out of gamut colors. If the computer image renderer performs calculations directly in device-dependent RGB space, a cHRM chunk should not be written unless the scene description and rendering parameters have been adjusted to look good on a particular monitor. In that case, the data for that monitor (if known) should be used to construct a cHRM chunk. Boutell, et. al. Informational [Page 46]  RFC 2083 PNG: Portable Network Graphics March 1997 There are often cases where an image's exact origins are unknown, particularly if it began life in some other format. A few image formats store calibration information, which can be used to fill in the cHRM chunk. For example, all PhotoCD images use the CCIR 709 primaries and D65 whitepoint, so these values can be written into the cHRM chunk when converting a PhotoCD file. PhotoCD also uses the SMPTE-170M transfer function, which is closely approximated by a gAMA of 0.5. (PhotoCD can store colors outside the RGB gamut, so the image data will require gamut mapping before writing to PNG format.) TIFF 6.0 files can optionally store calibration information, which if present should be used to construct the cHRM chunk. GIF and most other formats do not store any calibration information. It is not recommended that file format converters attempt to convert supplied images to a different RGB color space. Store the data in the PNG file without conversion, and record the source primary chromaticities if they are known. Color space transformation at file conversion time is a bad idea because of gamut mismatches and rounding errors. As with gamma conversions, it's better to store the data losslessly and incur at most one conversion when the image is finally displayed. See also Recommendations for Decoders: Decoder color handling (Section 10.6). 9.4. Alpha channel creation The alpha channel can be regarded either as a mask that temporarily hides transparent parts of the image, or as a means for constructing a non-rectangular image. In the first case, the color values of fully transparent pixels should be preserved for future use. In the second case, the transparent pixels carry no useful data and are simply there to fill out the rectangular image area required by PNG. In this case, fully transparent pixels should all be assigned the same color value for best compression. Image authors should keep in mind the possibility that a decoder will ignore transparency control. Hence, the colors assigned to