====================================== PNG Changes from 1.0 to 1.1 revision 1 (1999-Jan-06) Adam M. Costello ====================================== This file shows all the substantive changes between the PNG 1.0 spec and the PNG 1.1 spec. It does not show minor changes in wording, formatting, punctuation, cross references, and RFC/W3C boilerplate. Minus signs (-) in the left margin indicate text that has been removed, while plus signs (+) indicate text that has been added. Sometimes, to provide context, text from PNG 1.1 that has not changed substantively since PNG 1.0 is included with nothing in the margin. 1. Introduction - In this specification, the word "must" indicates a mandatory - requirement, while "should" indicates recommended behavior. + The words "must", "required", "should", "recommended", "may", and + "optional" in this document are to be interpreted as described in + [RFC-2119], which is consistent with their plain English meanings. + The word "can" carries the same force as "may". 2.1. Integers and byte order + Unless otherwise stated, four-byte unsigned integers are limited + to the range 0 to (2^31)-1 to accommodate languages that have + difficulty with unsigned four-byte values. Similarly, four-byte + signed integers are limited to the range -((2^31)-1) to (2^31)-1 + to accommodate languages that have difficulty with the value + -2^31. 2.2. Color values - Sample values are not necessarily linear; the gAMA chunk specifies - the gamma characteristic of the source device, + Sample values are not necessarily proportional to light intensity; + the gAMA chunk specifies the relationship between sample values + and display output intensity, 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, + PNG images can specify, via the gAMA chunk, the power function + relating the desired display output with the image samples. + Display programs are strongly encouraged to use this information, + plus information about the display system they are using, + + If the RGB data conforms to the sRGB specification [sRGB], this + can be indicated with the sRGB chunk, enabling even more accurate + reproduction. Alternately, the iCCP chunk can be used to embed an + ICC profile [ICC] containing detailed color space information. 4.1.2. PLTE Palette - If PLTE is not present, such a viewer will need to select - colors on its own, + If neither PLTE nor sPLT is present, such a viewer will need to + select colors on its own, 4.2.2. cHRM Primary chromaticities and white point + An sRGB chunk or iCCP chunk, when present and recognized, + overrides the cHRM chunk. 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 specifies the relationship between the image + samples and the desired display output intensity as a power + function: + + sample = light_out ^ gamma + + Here sample and light_out are normalized to the range 0.0 + (minimum intensity) to 1.0 (maximum intensity). Therefore: + + sample = integer_sample / (2^bitdepth - 1) + The gamma value has no effect on alpha samples, which are + always a linear fraction of full opacity. + Technically, "desired display output intensity" is not specific + enough; one needs to specify the viewing conditions under + which the output is desired. For gAMA these are the reference + viewing conditions of the sRGB specification [sRGB], which are + based on ISO standards [ISO-3664]. Adjusting for different + viewing conditions is a complex process normally handled by + a Color Management System (CMS). If this adjustment is not + performed, the error is usually small. Applications desiring + high color fidelity may wish to use an sRGB chunk (see the sRGB + chunk specification, Paragraph 4.2.9) or an iCCP chunk (see the + iCCP chunk specification, Paragraph 4.2.5). + An sRGB chunk or iCCP chunk, when present and recognized, + overrides the gAMA chunk. + 4.2.5. iCCP Embedded ICC profile + If the iCCP chunk is present, the image samples conform to the + color space represented by the embedded ICC profile as defined + by the International Color Consortium [ICC]. The color space + of the ICC profile must be an RGB color space for color images + (PNG color types 2, 3, and 6), or a monochrome grayscale color + space for grayscale images (PNG color types 0 and 4). + + The iCCP chunk contains: + + Profile name: 1-79 bytes (character string) + Null separator: 1 byte + Compression method: 1 byte + Compressed profile: n bytes + + The format is like the zTXt chunk. The profile name can be any + convenient name for referring to the profile. It is case- + sensitive and subject to the same restrictions as a tEXt + keyword: it must contain only printable Latin-1 [ISO/IEC- + 8859-1] characters (33-126 and 161-255) and spaces (32), but no + leading, trailing, or consecutive spaces. The only value + presently defined for the compression method byte is 0, meaning + zlib datastream with deflate compression (see Deflate/Inflate + Compression, Chapter 5). Decompression of the remainder of the + chunk yields the ICC profile. + + An application that writes the iCCP chunk should also write + gAMA and cHRM chunks that approximate the ICC profile's + transfer function, for compatibility with applications that do + not use the iCCP chunk. + + When the iCCP chunk is present, applications that recognize it + and are capable of color management [ICC] should ignore the + gAMA and cHRM chunks and use the iCCP chunk instead, but + applications incapable of full-fledged color management should + use the gAMA and cHRM chunks if present. + + A file should contain at most one embedded profile, whether + explicit like iCCP or implicit like sRGB. + + If the iCCP chunk appears, it must precede the first IDAT + chunk, and it must also precede the PLTE chunk if present. + 4.2.8. sPLT Suggested palette + This chunk can be used to suggest a reduced palette to be used + when the display device is not capable of displaying the full + range of colors present in the image. If present, it provides + a recommended set of colors, with alpha and frequency + information, that can be used to construct a reduced palette to + which the PNG image can be quantized. + + This chunk contains a null-terminated text string that names + the palette and a one-byte sample depth, followed by a series + of palette entries, each a six-byte or ten-byte series + containing five unsigned integers: + + Palette name: 1-79 bytes (character string) + Null terminator: 1 byte + Sample depth: 1 byte + Red: 1 or 2 bytes + Green: 1 or 2 bytes + Blue: 1 or 2 bytes + Alpha: 1 or 2 bytes + Frequency: 2 bytes + ...etc... + + There can be any number of entries; a decoder determines the + number of entries from the remaining chunk length after the + sample depth byte. It is an error if this remaining length is + not divisible by 6 (if the sPLT sample depth is 8) or by 10 (if + the sPLT sample depth is 16). Entries must appear in + decreasing order of frequency. There is no requirement that + the entries all be used by the image, nor that they all be + different. + + The palette name can be any convenient name for referring to + the palette (for example, "256 color including Macintosh + default", "256 color including Windows-3.1 default", "Optimal + 512"). It may help applications or people to choose the + appropriate suggested palette when more than one appears in a + PNG file. The palette name is case-sensitive and subject to + the same restrictions as a tEXt keyword: it must contain only + printable Latin-1 [ISO/IEC-8859-1] characters (33-126 and 161- + 255) and spaces (32), but no leading, trailing, or consecutive + spaces. + + The sPLT sample depth must be 8 or 16. + + The red, green, blue, and alpha samples are either one or two + bytes each, depending on the sPLT sample depth, regardless of + the image bit depth. The color samples are not premultiplied + by alpha, nor are they precomposited against any background. + An alpha value of 0 means fully transparent, while an alpha + value of 255 (when the sPLT sample depth is 8) or 65535 (when + the sPLT sample depth is 16) means fully opaque. The palette + samples have the same gamma and chromaticity values as those of + the PNG image. + + Each frequency value is proportional to the fraction of pixels + in the image that are closest to that palette entry in RGBA + space, before the image has been composited against any + background. The exact scale factor is chosen by the encoder, + but should be chosen so that the range of individual values + reasonably fills the range 0 to 65535. It is acceptable to + artificially inflate the frequencies for "important" colors + such as those in a company logo or in the facial features of a + portrait. Zero is a valid frequency meaning the color is + "least important" or that it is rarely if ever used. But when + all of the frequencies are zero, they are meaningless (nothing + may be inferred about the actually frequencies of the colors). + + The sPLT chunk can appear for any PNG color type. Note that + entries in sPLT can fall outside the colorspace of the PNG + image; for example, in a grayscale PNG, sPLT entries would + typically satisfy R=G=B, but this is not required. Similarly, + sPLT entries can have nonopaque alpha values even when the PNG + image does not use transparency. + + If sPLT appears, it must precede the first IDAT chunk. There + can be multiple sPLT chunks, but if so they must have different + palette names. + 4.2.9. sRGB Standard RGB color space + If the sRGB chunk is present, the image samples conform to the + sRGB color space [sRGB], and should be displayed using the + specified rendering intent as defined by the International + Color Consortium [ICC]. + + The sRGB chunk contains: + + Rendering intent: 1 byte + + The following values are defined for the rendering intent: + + 0: Perceptual + 1: Relative colorimetric + 2: Saturation + 3: Absolute colorimetric + + Perceptual intent is for images preferring good adaptation to + the output device gamut at the expense of colorimetric + accuracy, like photographs. + + Relative colorimetric intent is for images requiring color + appearance matching (relative to the output device white + point), like logos. + + Saturation intent is for images preferring preservation of + saturation at the expense of hue and lightness, like charts and + graphs. + + Absolute colorimetric intent is for images requiring + preservation of absolute colorimetry, like proofs (previews of + images destined for a different output device). + + An application that writes the sRGB chunk should also write a + gAMA chunk (and perhaps a cHRM chunk) for compatibility with + applications that do not use the sRGB chunk. In this + situation, only the following values may be used: + + gAMA: + Gamma: 45455 + + cHRM: + White Point x: 31270 + White Point y: 32900 + Red x: 64000 + Red y: 33000 + Green x: 30000 + Green y: 60000 + Blue x: 15000 + Blue y: 6000 + + When the sRGB chunk is present, applications that recognize it + and are capable of color management [ICC] must ignore the gAMA + and cHRM chunks and use the sRGB chunk instead. + + Applications that recognize the sRGB chunk but are not capable + of full-fledged color management must also ignore the gAMA and + cHRM chunks, because the applications already know what values + those chunks should contain. The applications must therefore + use the values of gAMA and cHRM given above as if they had + appeared in gAMA and cHRM chunks. + + If the sRGB chunk appears, it must precede the first IDAT + chunk, and it must also precede the PLTE chunk if present. The + sRGB and iCCP chunks should not both appear. 4.3. Summary of standard chunks + iCCP No Before PLTE and IDAT + sRGB No Before PLTE and IDAT + sPLT Yes Before IDAT 5. Deflate/Inflate Compression + A PNG decoder must be able to decompress any valid zlib datastream + that satisfies these additional constraints. + + If the data to be compressed contains 16384 bytes or fewer, the + encoder can set the window size by rounding up to a power of 2 (256 + minimum). This decreases the memory required not only for encoding + but also for decoding, without adversely affecting the compression + ratio. - 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. + PNG also uses zlib datastreams in zTXt and iCCP chunks, where the + remainder of the chunk following the compression method byte is a + zlib datastream as specified above. Unlike the image data, such + datastreams are not split across chunks; each zTXt or iCCP chunk + contains an independent zlib datastream. - + ftp://ftp.cdrom.com/pub/infozip/ 8.5. Security considerations - The possible security risks associated with future chunk types - cannot be specified at this time. + The possible security risks associated with private chunk types + and future chunk types cannot be specified at this time. - The tEXt and zTXt chunks contain data that is meant to be - displayed as plain text. + The tEXt and zTXt chunks contain keywords and data that is meant + to be displayed as plain text. The iCCP, sPLT, and some public + "extension" chunks contain keywords meant to be displayed as plain + text. - 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. + Every chunk begins with a length field, making it easier to write + decoders invulnerable to fraudulent chunks that attempt to + overflow buffers. The CRC at the end of every chunk provides a + robust defense against accidentally corrupted data. 9.2. Encoder gamma handling See Gamma Tutorial (Chapter 15) if you aren't already familiar with gamma issues. + Encoders capable of full-fledged color management [ICC] will + perform more sophisticated calculations than those described here, + and they may choose to use the iCCP chunk. Encoders that know + that their image samples conform to the sRGB specification [sRGB] + should use the sRGB chunk and not perform gamma handling. + Otherwise, this section applies. + + The encoder has two gamma-related decisions to make. First, it + must decide how to transform whatever image samples it has into + the image samples that will go into the PNG file. Second, it must + decide what value to write into the gAMA chunk. + + The rule for the second decision is simply to write whatever value + will cause a decoder to do what you want. See Recommendations for + Decoders: Decoder gamma handling (Section 12.5). - 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. - - 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). + The first decision depends on the nature of the image samples and + their precision. If the samples represent light intensity in + floating-point or high-precision integer form (perhaps from a + computer image renderer), then the encoder may perform "gamma + encoding" (applying a power function with exponent less than 1) + before quantizing the data to integer values for output to the + file. This results in fewer banding artifacts at a given sample + depth, or allows smaller samples while retaining the same visual + quality. An intensity level expressed as a floating-point value + in the range 0 to 1 can be converted to a file image sample by + + sample = intensity ^ encoding_exponent + integer_sample = ROUND(sample * (2^bitdepth - 1)) + + If the intensity in the equation is the desired display output + intensity, then the encoding exponent is the gamma value to be + written to the file, by the definition of gAMA (See the gAMA + chunk specification, Paragraph 4.2.3). But if the intensity + available to the encoder is the original scene intensity, another + transformation may be needed. Sometimes the displayed image + should have higher contrast than the original image; in other + words, the end-to-end transfer function from original scene to + display output should have an exponent greater than 1. In this + case, + + gamma = encoding_exponent / end_to_end_exponent + + If you don't know whether the conditions under which the original + image was captured (or calculated) warrant such a contrast change, + you may assume that display intensities are proportional to + original scene intensities; in other words, the end-to-end + exponent is 1, so gamma and the encoding exponent are equal. - 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. + If the image is being written to a file only, the encoder is free + to choose the encoding exponent. Choosing a value that causes the + gamma value in the gAMA chunk to be 1/2.2 is often a reasonable + choice because it minimizes the work for a decoder displaying on a + typical video monitor. - 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). + Some image renderers may simultaneously write the image to a PNG + file and display it on-screen. The displayed pixels should be + appropriate for the display system, so that the user sees a proper + representation of the intended scene. + + If the renderer wants to write the displayed sample values to the + PNG file, avoiding a separate gamma encoding step for file output, + then the renderer should approximate the transfer function of the + display system by a power function, and write the reciprocal of + the exponent into the gAMA chunk. This will allow a PNG decoder + to reproduce what the file's originator saw on screen during + rendering. - 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. + However, it is equally reasonable for a renderer to compute + displayed pixels appropriate for the display device, and to + perform separate gamma encoding for file storage, arranging to + have a value in the gAMA chunk more appropriate to the future use + of the image. 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, + If the PNG encoder receives intensity samples that have already + been quantized into integers, 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. + This does not imply that the gAMA chunk should contain a + gamma value of 1.0, because the desired end-to-end transfer + function from scene intensity to display output intensity is not + necessarily linear. The desired gamma value is probably not far + from 1.0, however. It may depend on whether the scene being + rendered is a daylight scene or an indoor scene, etc. - 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 (rame 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. + When the sample values come directly from a piece of hardware, + the correct gamma value can in principle be inferred from the + transfer function of the hardware and the lighting conditions of + the scene. In the case of video digitizers ("frame grabbers"), + the samples are probably in the sRGB color space, because the sRGB + specification was designed to be compatible with video standards. + Image scanners are less predictable. Their output samples may + be proportional to the input light intensity because CCD (charge + coupled device) sensors themselves are linear, or the scanner + hardware may have already applied a power function designed to + compensate for dot gain in subsequent printing (an exponent of + about 0.57), or the scanner may have corrected the samples for + display on a monitor. The device documentation might describe the + transformation performed, or might describe the target display or + printer for the image data (which might be configurable). You + can also scan a calibrated target and use calibration software to + determine the behavior of the device. Remember that gamma relates + file samples to desired display output, not to scanner input. - 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. + 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 deduce the gamma value from + information in the source file if possible. 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. + If the source file format describes the gamma characteristic of + the image, a file format converter is strongly encouraged to + write a PNG gAMA chunk. Note that some file formats specify the + exponent of the function mapping file samples to display output + rather than the other direction. If the source file's gamma value + is greater than 1.0, it is probably a display system exponent, and + you should use its reciprocal for the PNG gamma. If the source + file format records the relationship between image samples and + something other than display output, then deducing the PNG gamma + value will be more complex. - 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 + Regardless of how an image was originally created, if an + encoder or file format converter knows that the image has been + displayed satisfactorily using a display system whose transfer + function can be approximated by a power function with exponent + display_exponent, then the image can be marked as having the gamma + value: + + gamma = 1 / display_exponent - 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, + On the other hand, if the encoder has no way to infer the gamma + value, 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. 9.3. Encoder color handling + Encoders capable of full-fledged color management [ICC] will + perform more sophisticated calculations than those described here, + and they may choose to use the iCCP chunk. Encoders that know + that their image samples conform to the sRGB specification [sRGB] + are strongly encouraged to use the sRGB chunk. Otherwise, this + section applies. Scanners that produce PNG files as output should insert the filter chromaticities into a cHRM chunk - and the camera_gamma into a gAMA chunk. PhotoCD also uses the SMPTE-170M transfer function, - which is closely approximated by a gAMA of 0.5. 9.5. Suggested palettes - A PLTE chunk can appear in truecolor PNG files. In such files, - the chunk is not an essential part of the image data, but simply - represents a suggested palette that viewers may use to present the - image on indexed-color display hardware. A suggested palette is - of no interest to viewers running on truecolor hardware. + Suggested palettes can appear as sPLT chunks in any PNG file, + or as a PLTE chunk in truecolor PNG files. In either case, the + suggested palette is not an essential part of the image data, + but it may be used to present the image on indexed-color display + hardware. Suggested palettes are of no interest to viewers + running on truecolor hardware. - If an encoder chooses to provide a suggested palette, it is - recommended that a hIST chunk also be written to indicate the - relative importance of the palette entries. The histogram values - are most easily computed as "nearest neighbor" counts, that is, - the approximate usage of each palette entry if no dithering is - applied. (These counts will often be available for free as a - consequence of developing the suggested palette.) + When sPLT is used to provide a suggested palette, it is + recommended that the encoder use the frequency fields to indicate + the relative importance of the palette entries, rather than leave + them all zero (meaning undefined). The frequency values are + most easily computed as "nearest neighbor" counts, that is, the + approximate usage of each RGBA palette entry if no dithering is + applied. (These counts will often be available for free as a + consequence of developing the suggested palette.) Because the + suggested palette includes transparency information, it should be + computed for the uncomposited image. + + Even for indexed-color images, sPLT can be used to define + alternative reduced palettes for viewers that are unable to + display all the colors present in the PLTE chunk. + + An older method for including a suggested palette in a truecolor + PNG file uses the PLTE chunk. If this method is used, the + histogram (frequencies) should appear in a separate hIST chunk. + Also, PLTE does not include transparency information, so for images of color type 2 (truecolor without alpha channel), it is recommended that the palette and histogram be computed with reference to the RGB data only, ignoring any transparent-color specification. If the file uses transparency (has a tRNS chunk), viewers can easily adapt the resulting palette for use with their intended background color. They need only replace the palette entry closest to the tRNS color with their background color (which may or may not match the file's bKGD color, if any). For images of color type 2 (truecolor without alpha channel), it is recommended that PLTE and hIST be computed with reference to the RGB data only, ignoring any transparent-color specification. If the file uses transparency (has a tRNS chunk), viewers can easily adapt the resulting palette for use with their intended background color. They need only replace the palette entry closest to the tRNS color with their background color (which may or may not match the file's bKGD color, if any). If PLTE appears without bKGD in an image of color type 6, the circumstances under which the palette was computed are unspecified. + For providing suggested palettes, sPLT is more flexible than PLTE + in the following ways: + + * With sPLT, there can be multiple suggested palettes. A + decoder may choose an appropriate palette based on name or + number of entries. + + * In an RGBA (color type 6) PNG, PLTE represents a palette + already composited against the bKGD color, so it is useful + only for display against that background color. The sPLT + chunk provides an uncomposited palette, which is useful for + display against backgrounds of the decoder's choice. + + * Since sPLT is a noncritical chunk, a PNG editor can add or + modify suggested palettes without being forced to discard + unknown unsafe-to-copy chunks. + + * Whereas sPLT is allowed in PNG files of color types 0, + 3, and 4 (grayscale and indexed), PLTE cannot be used to + provide reduced palettes in these cases. + + * More than 256 entries can appear in sPLT. + + An encoder that uses sPLT may choose to write a PLTE/hIST + suggested palette as well, for backward compatibility with + decoders that do not recognize sPLT. 10.3. Truecolor image handling - PNG allows the encoder to supply a suggested palette in a PLTE - chunk, but not all encoders will do so, and the suggested palette - may be unsuitable in any case (it may have too many or too few - colors). + PNG allows the encoder to supply suggested palettes, but not all + encoders will do so, and the suggested palettes may be unsuitable + in any case (they may have too many or too few colors). 10.5. Decoder gamma handling See Gamma Tutorial (Chapter 15) if you aren't already familiar with gamma issues. + Decoders capable of full-fledged color management [ICC] will + perform more sophisticated calculations than what is described + here. Otherwise, this section applies. - To produce correct tone reproduction, a good image display program - should take into account the gammas of the image file and the - display device, as well as the viewing_gamma appropriate to - the lighting conditions near the display. This can be done by - calculating - - gbright = insample / MAXINSAMPLE - bright = gbright ^ (1.0 / file_gamma) - vbright = bright ^ viewing_gamma - gcvideo = vbright ^ (1.0 / display_gamma) - fbval = ROUND(gcvideo * MAXFBVAL) - - where MAXINSAMPLE is the maximum sample value in the file (255 - for 8-bit, 65535 for 16-bit, etc), MAXFBVAL is the maximum value - of a frame buffer sample (255 for 8-bit, 31 for 5-bit, etc), - insample is the value of the sample in the PNG file, and fbval is - the value to write into the frame buffer. The first line converts - from integer samples into a normalized 0 to 1 floating point - value, the second undoes the gamma encoding of the image file - to produce a linear intensity value, the third adjusts for the - viewing conditions, the fourth corrects for the display system's - gamma value, and the fifth converts to an integer frame buffer - sample. In practice, the second through fourth lines can be - merged into - - gcvideo = gbright^(viewing_gamma / (file_gamma*display_gamma)) + For an image display program to produce correct tone reproduction, + it is necessary to take into account the relationship between + file samples and display output, and the transfer function of the + display system. This can be done by calculating + + sample = integer_sample / (2^bitdepth - 1.0) + display_output = sample ^ (1.0 / gamma) + display_input = inverse_display_transfer(display_output) + framebuf_sample = ROUND(display_input * MAX_FRAMEBUF_SAMPLE) + + where integer_sample is the sample value from the file, + framebuf_sample is the value to write into the frame buffer, and + MAX_FRAMEBUF_SAMPLE is the maximum value of a frame buffer sample + (255 for 8-bit, 31 for 5-bit, etc). The first line converts an + integer sample into a normalized 0-to-1 floating-point value, the + second converts to a value proportional to the desired display + output intensity, the third accounts for the display system's + transfer function, and the fourth converts to an integer frame + buffer sample. + + A step could be inserted between the second and third to adjust + display_output to account for the difference between the actual + viewing conditions and the reference viewing conditions. However, + this adjustment requires accounting for veiling glare, black + mapping, and color appearance models, none of which can be well + approximated by power functions. The calculations are not + described here. If viewing conditions are ignored, the error will + usually be small. + + Typically, the display transfer function can be approximated by a + power function with exponent display_exponent, in which case the + second and third lines can be merged into + + display_input = sample ^ (1.0 / (gamma * display_exponent)) + = sample ^ decoding_exponent so as to perform only one power calculation. For color images, the entire calculation is performed separately for R, G, and B values. + The value of gamma can be taken directly from the gAMA chunk. + Alternatively, an application may wish to allow the user to adjust + the appearance of the displayed image by influencing the value + of gamma. For example, the user could manually set a parameter + called user_exponent that defaults to 1.0, and the application + could set + + gamma = gamma_from_file / user_exponent + decoding_exponent = 1.0 / (gamma * display_exponent) + = user_exponent / (gamma_from_file * display_exponent) + + The user would set user_exponent greater than 1 to darken the + mid-level tones, or less than 1 to lighten them. It is not necessary to perform transcendental math for every pixel. Instead, compute a lookup table that gives the correct output value for every possible sample value. This requires only 256 calculations per image (for 8-bit accuracy), not one or three calculations per pixel. For an indexed-color image, a one-time correction of the palette is sufficient, unless the image uses transparency and is being displayed against a nonuniform background. - In some cases even the cost of computing a gamma lookup table - may be a concern. In these cases, viewers are encouraged to - have precomputed gamma correction tables for file_gamma values - of 1.0 and 0.5 with some reasonable choice of viewing_gamma and - display_gamma, and to use the table closest to the gamma indicated - in the file. This will produce acceptable results for the majority - of real files. + If floating-point calculations are not possible, gamma correction + tables can be computed using integer arithmetic and a precomputed + table of logarithms. Example code appears in the "Extensions to + the PNG Specification" document [PNG-EXTENSIONS]. When the incoming image has unknown gamma - (no gAMA chunk) + (gAMA, sRGB, and iCCP all absent), choose a likely default gamma value, but allow the user to select a new one if the result proves too dark or too light. + The default gamma can depend on other knowledge about the + image, like whether it came from the Internet or from the local + system. In practice, it is often difficult to determine what value of the display exponent should be used. In systems with no built-in gamma correction, the display exponent is determined entirely by the CRT (cathode ray tube). - Assuming a CRT_gamma of 2.5 is recommended, unless you have - detailed calibration measurements of this particular CRT - available. + Assume a CRT exponent of 2.2 unless detailed calibration + measurements of this particular CRT are available. Many modern frame buffers have lookup tables that are used to perform gamma correction, and on these systems the display exponent value should be the exponent of the lookup table and CRT combined. You may not be able to find out what the lookup table contains from within an image viewer application, so you may have to ask the user what the display system's exponent is. Unfortunately, different manufacturers use different ways of specifying what should go into the lookup table, so interpretation of the system gamma value is system-dependent. Gamma Tutorial (Chapter 13) gives some examples. The response of real displays is actually more complex than can be described by a single number (the display exponent). If actual measurements of the monitor's light output as a function of voltage input are available, the third and fourth lines of the computation above can be replaced by a lookup in these measurements, to find the actual frame buffer value that most nearly gives the desired brightness. - The value of viewing_gamma depends on lighting conditions; see - Gamma Tutorial (Chapter 13) for more detail. Ideally, a viewer - would allow the user to specify viewing_gamma, either directly - numerically, or via selecting from "bright surround", "dim - surround", and "dark surround" conditions. Viewers that don't - want to do this should just assume a value for viewing_gamma of - 1.0, since most computer displays live in brightly-lit rooms. - - When viewing images that are digitized from video, or that are - destined to become video frames, the user might want to set the - viewing_gamma to about 1.25 regardless of the actual level of room - lighting. This value of viewing_gamma is "built into" NTSC video - practice, and displaying an image with that viewing_gamma allows - the user to see what a TV set would show under the current room - lighting conditions. (This is not the same thing as trying to - obtain the most accurate rendition of the content of the scene, - which would require adjusting viewing_gamma to correspond to the - room lighting level.) This is another reason viewers might want - to allow users to adjust viewing_gamma directly. 10.8. Alpha channel processing - This computation should be performed with linear - (non-gamma-encoded) sample values. + This computation should be performed with intensity samples (not + gamma-encoded samples). - The code allows the sample depths and gamma values of foreground - image, background image, and frame buffer/CRT all to be different. - Don't assume they are the same without checking. + The code allows the sample depths and gamma values of foreground + and background images to be different, and not necessarily suited + to the display system. Don't assume everything is the same + without checking. - 21 gcvideo = pow(comppix,viewing_gamma/display_gamma); + 21 gcvideo = pow(comppix, 1.0/display_exponent); - 33 gcvideo = pow(comppix,viewing_gamma/display_gamma); + 33 gcvideo = pow(comppix, 1.0/display_exponent); - linbg = pow(gcvideo, display_gamma / viewing_gamma); + linbg = pow(gcvideo, display_exponent); - If a decoder contains only this much transparency capability, it - should deal with a full alpha channel by treating all nonzero - alpha values as fully opaque; that is, do not replace partially - transparent pixels by the background. This approach will not - yield very good results for images converted from associated-alpha - formats, but it's better than doing nothing. + If a decoder contains only this much transparency capability, it + should deal with a full alpha channel by converting it to a binary + alpha channel, either by treating all nonzero alpha values as + fully opaque or by dithering. Neither approach will yield very + good results for images converted from associated-alpha formats, + but it's better than doing nothing. Dithering full alpha to + binary alpha is very much like dithering grayscale to black-and- + white, except that all fully transparent and fully opaque pixels + should be left unchanged by the dither. 10.10. Suggested-palette and histogram usage - In truecolor PNG files, the encoder may have provided a suggested - PLTE chunk for use by viewers running on indexed-color hardware. + For viewers running on indexed-color hardware trying to display + a truecolor image, or an indexed-color image whose palette is + too large for the framebuffer, the encoder may have provided one + or more suggested palettes in sPLT chunks. If one of them is + found to be suitable, based on its size and perhaps its name, + the decoder can use that palette. Note that suggested palettes + with a sample depth different from what the decoder needs can be + converted using sample depth rescaling (See Recommendations for + Decoders: Sample depth rescaling, Section 12.4). + + When the background is a solid color, the decoder should composite + the image and the suggested palette against that color, then + quantize the resulting image to the resulting RGB palette. When + the image uses transparency and the background is not a solid + color, no suggested palette is likely to be useful. - If the image has a tRNS chunk, the viewer will need to adapt the - suggested palette for use with its desired background color. + For truecolor images, a suggested palette might also be provided + in a PLTE chunk. If the image has a tRNS chunk and the background + is a solid color, the viewer can adapt the suggested paletted for + use with this background color. For images of color type 6 (truecolor with alpha channel), any - suggested palette + PLTE chunk should have been designed for display of the image against a uniform background of the color specified by bKGD. If the viewer presents a transparent truecolor image against a background that is more complex than a single color, it is unlikely that the - suggested palette + PLTE chunk will be optimal for the composite image. + In truecolor PNG files, if both PLTE and sPLT appear, the decoder + can choose from among the palettes suggested by both, bearing in + mind the different transparency semantics mentioned above. - The histogram chunk is useful when the viewer cannot provide as - many colors as are used in the image's palette. + The frequencies in sPLT and hIST chunks are useful when the viewer + cannot provide as many colors as are used in the palette. - If no palette or histogram chunk is provided, + If no suggested palettes are provided, 11. Glossary - Note that in gamma-related calculations, zero raised to any power - is valid and must give a zero result. + Note that zero raised to any positive power is zero. Chromaticity A pair of values x,y that precisely specify - the hue, though not the absolute brightness, of a perceived color. + a color, except for the brightness information. + CIE + International Commission on Illumination (Commission + Internationale de l'Eclairage). + + CIE XYZ + A device-independent color space in which each component is the + sum of a weighted power distribution over the visible spectrum. + The Y component is luminence (see below). + + CIE LAB + A perceptually linear color space. Gamma - The brightness of mid-level tones in an image. More precisely, a - parameter that describes the shape of the transfer function for - one or more stages in an imaging pipeline. The transfer function - is given by the expression + Informally, a measure of the brightness of mid-level tones in an + image. Outside this specification, the term "gamma" is often used + as the exponent of a power function that is the transfer function + of any stage(s) of an imaging pipeline: output = input ^ gamma where both input and output are scaled to the range 0 to 1. + Within this specification, gamma refers specifically to the + function from display output to image samples. + Intensity + Power per unit area of light entering or leaving a surface. It is + often normalized to the range 0 to 1 by dividing by a maximum + intensity. 12.3. Why not these features? - Adding JPEG support to a PNG decoder might increase its - size by an order of magnitude. This would certainly cause - some decoders to omit support for the feature, which would - destroy our goal of interchangeability. + Adding JPEG support to a PNG decoder might significantly + increase its size, causing some decoders to omit + support for the feature, which would erode our goal of + interchangeability. 12.7. Why gamma? - It might seem natural to standardize on storing sample values that - are linearly proportional to light intensity + It might seem natural to standardize on storing sample values + proportional to display output intensity - * For reasons detailed in Gamma Tutorial (Chapter 13), all - video cameras apply a "gamma correction" function to the - intensity information. This causes the video signal to have - a gamma of about 0.5 relative to the light intensity in the - original scene. Thus, images obtained by frame-grabbing - video already have a gamma of about 0.5. + * CRTs have a transfer function with an exponent of 2.2, and + video signals are designed to be sent directly to CRTs. + Therefore, images obtained by frame-grabbing video already + have a gamma of 1/2.2. * Many images are created on PCs or workstations with no gamma correction hardware and no software willing to provide gamma correction either. In these cases, the images have had their lighting and color chosen to look best on this platform--they can be thought of as having "manual" gamma correction built in. To see what the image author intended, it is necessary to treat such images as having a - file_gamma value in the range 0.4-0.6, depending on the room - lighting level that the author was working in. + gamma value of 1/2.2 (assuming the author was using a CRT). - In practice, image gamma values around 1.0 and around 0.5 are both - widely found. Older image standards such as GIF often do not - account for this fact. The JFIF standard specifies that images - in that format should use linear samples, but many JFIF images - found on the Internet actually have a gamma somewhere near 0.4 or - 0.5. The variety of images found and the variety of systems that - people display them on have led to widespread problems with images - appearing "too dark" or "too light". + In practice, image gamma values around 1.0, 1/2.2, and 1/1.45 are + all widely found. Older image standards such as GIF and JFIF + often do not account for this fact. The exchange of images among + a variety of systems has led to widespread problems with images + appearing "too dark" or "too light". + Historical note: Version 1.0 of this specification used the gAMA + chunk to express the relationship between the file samples and the + "original scene intensity" (camera input) rather than the desired + display output intensity. This was changed in version 1.1 for the + following reasons: + + * The decoder needs to know the desired display output in + order to do its job, but there was not enough information + in the file to convert from the original scene to the + display output. The version 1.0 specification claimed + that the conversion depended only on viewing conditions + at the display, but that was an error; it also depends on + conditions at the camera. + + * Faithful reproduction of the original scene is not always + the goal. Sometimes deliberate distortion is desired. + + * For hand-drawn images there is no "original scene". + + Because the gamma-related recommendations in version 1.0 were + imprecise, it was not clear what value to put in a gAMA chunk in + common situations. For an image drawn on a CRT display with no + LUT under unknown viewing conditions, an argument could be made + for any value between 40000 and 50000. Real applications were + observed to write 45000 or 45455, and the latter is recommended by + the current specification. 13.1. Nonlinear transfer functions + But using the term "gamma" to refer to the exponents of transfer + functions of many different stages in imaging pipelines has led to + confusion. Therefore, this specification uses "gamma" to refer + specifically to the function from display output to image samples, + and simply uses "exponent" when referring to other functions. 13.3. End-to-end exponent If the end-to-end exponent of an imaging system is 1.0, its output is proportional to its input. This means that the ratio between the intensities of any two areas in the reproduced image will be the same as it was in the original scene. It might seem that this should always be the goal of an imaging system: to accurately reproduce the tones of the original scene. Alas, that is not the case. - When the reproduced image is to be viewed in "bright surround" - conditions, where other white objects nearby in the room have - about the same brightness as white in the image, then an overall - gamma of 1.0 does indeed give real-looking reproduction of a - natural scene. Photographic prints viewed under room light - and computer displays in bright room light are typical "bright - surround" viewing conditions. - - However, sometimes images are intended to be viewed in "dark - surround" conditions, where the room is substantially black - except for the image. This is typical of the way movies and - slides (transparencies) are viewed by projection. Under these - circumstances, an accurate reproduction of the original scene - results in an image that human viewers judge as "flat" and lacking - in contrast. It turns out that the projected image needs to have - a gamma of about 1.5 relative to the original scene for viewers to - judge it "natural". Thus, slide film is designed to have a gamma - of about 1.5, not 1.0. - - There is also an intermediate condition called "dim surround", - where the rest of the room is still visible to the viewer, but - is noticeably darker than the reproduced image itself. This is - typical of television viewing, at least in the evening, as well as - subdued-light computer work areas. In dim surround conditions, - the reproduced image needs to have a gamma of about 1.25 relative - to the original scene in order to look natural. - - The requirement for boosted contrast (gamma) in dark surround - conditions is due to the way the human visual system works, and - applies equally well to computer monitors. Thus, a PNG viewer - trying to achieve the maximum realism for the images it displays - really needs to know what the room lighting conditions are, and - adjust the gamma of the displayed image accordingly. - - If asking the user about room lighting conditions is inappropriate - or too difficult, just assume that the overall gamma - (viewing_gamma as defined below) should be 1.0 or 1.25. That's - all that most systems that implement gamma correction do. + One complication is that the response of the human visual system + to low light levels is not a scaled-down version of its response + to high light levels. Therefore, if the display device emits less + intense light than entered the capture device (as is usually the + case for television cameras and television sets, for example), an + end-to-end linear response will not produce an image that appears + correct. There are also other perceptual factors, like the affect + of the ambient light level and the field of view surrounding the + display, and physical factors, like reflectance of ambient light + off the display. + + Good end-to-end exponents are determined from experience. For + example, for photographic prints it's about 1.0; for slides + intended to be projected in a dark room it's about 1.5; for + television it's about 1.14. 13.4. CRT exponent - All CRT displays have a power-law transfer characteristic with - a gamma of about 2.5. This is due to the physical processes - involved in controlling the electron beam in the electron gun, and - has nothing to do with the phosphor. + All CRT displays have a power-law transfer characteristic with an + exponent of about 2.2. This is mainly due to the physical + processes involved in controlling the electron beam in the + electron gun. - assuming 2.5 is likely to be pretty accurate. + assuming 2.2 is likely to be pretty accurate. - you're usually better off just assuming gamma is 2.5 rather than - trying to measure it. + you're usually better off just assuming 2.2 rather than trying to + measure it. 13.5. Gamma correction - A CRT has a gamma of 2.5, and we can't change that. To get an - overall gamma of 1.0 (or somewhere near that) for an imaging - system, we need to have at least one other component of the - "image pipeline" that is nonlinear. If, in fact, there is only - one nonlinear stage in addition to the CRT, then it's traditional - to say that the CRT has a certain gamma, and that the other - nonlinear stage provides "gamma correction" to compensate for the - CRT. However, exactly where the "correction" is done depends on - circumstance. + A CRT has an exponent of 2.2, and we can't change that. To get + an end-to-end exponent closer to 1, we need to have at least one + other component of the "image pipeline" that is nonlinear. If, + in fact, there is only one nonlinear stage in addition to the + CRT, then it's traditional to say that the other nonlinear stage + provides "gamma correction" to compensate for the CRT. However, + exactly where the "correction" is done depends on circumstance. - In all broadcast video systems, gamma correction is done in - the camera. This choice was made in the days when television - electronics were all analog, and a good gamma-correction circuit - was expensive to build. The original NTSC video standard required - cameras to have a transfer function with a gamma of 1/2.2, or - about 0.45. Recently, a more complex two-part transfer function - has been adopted [SMPTE-170M], but its behavior can be well - approximated by a power function with a gamma of 0.5. When the - resulting image is displayed on a CRT with a gamma of 2.5, the - image on screen ends up with a gamma of about 1.25 relative to the - original scene, which is appropriate for "dim surround" viewing. + In all broadcast video systems, gamma correction is done in the + camera. This choice was made because it was more cost effective + to place the expensive processing in the small number of capture + devices (studio television cameras) than in the large number of + broadcast receivers. The original NTSC video standard required + cameras to have a transfer function with an exponent of 1/2.2, or + about 0.45. Recently, a more complex two-part transfer function + has been adopted [SMPTE-170M], but its behavior can be well + approximated by a power function with an exponent of 0.52. When + the resulting image is displayed on a CRT with an exponent of + 2.2, the end-to-end exponent is about 1.14, which has been found + to be appropriate for typical television studio conditions and + television viewing conditions. - These days, video signals are often digitized and stored in - computer frame buffers. This works fine, but remember that gamma - correction is "built into" the video signal, and so the digitized - video has a gamma of about 0.5 relative to the original scene. + These days, video signals are often digitized and stored in + computer frame buffers. The digital image is intended to be sent + through a CRT, which has exponent 2.2, so the image has a gamma of + 1/2.2. - Computer rendering programs often produce linear samples. To - display these correctly, intensity on the CRT needs to be directly - proportional to the sample values in the frame buffer. This can - be done with a special hardware lookup table between the frame - buffer and the CRT hardware. The lookup table (often called LUT) - is loaded with a mapping that implements a power function with a - gamma of 0.4, thus providing "gamma correction" for the CRT gamma. + Computer rendering programs often produce samples proportional to + scene intensity. Suppose the desired end-to-end exponent is near + 1, and the program would like to write its samples directly into + the frame buffer. For correct display, the CRT output intensity + must be nearly proportional to the sample values in the frame + buffer. This can be done with a special hardware lookup table + between the frame buffer and the CRT hardware. The lookup table + (often called LUT) is loaded with a mapping that implements a + power function with an exponent near 1/2.2, providing "gamma + correction" for the CRT gamma. Thus, gamma correction sometimes happens before the frame buffer, sometimes after. As long as images created on a particular platform are always displayed on that platform, everything is fine. But when people try to exchange images, differences in gamma correction conventions often result in images that seem far too bright and washed out, or far too dark and contrasty. 13.7. General gamma handling - the gamma of the CRT, generally 2.5 + the exponent of the CRT, generally 2.2 - file_gamma - the gamma of the image in the file, relative to the original - scene. This is - - file_gamma = camera_gamma * encoding_gamma + gamma + the exponent of the function mapping display output intensity + to file samples + + gamma = 1.0 / (decoding_exponent * display_exponent) - viewing_gamma - the overall gamma that we want to obtain to produce pleasing - images --- generally 1.0 to 1.5. + end-to-end exponent + the exponent of the function mapping image sensor input + intensity to display output intensity, generally 1.0 to 1.5 - The file_gamma value, as defined above, is what goes in the gAMA - chunk in a PNG file. If file_gamma is not 1.0, we know that gamma - correction has been done on the sample values in the file, and we - could call them "gamma corrected" samples. However, since there - can be so many different values of gamma in the image display - chain, and some of them are not known at the time the image is - written, the samples are not really being "corrected" for a - specific display condition. We are really using a power function - in the process of encoding an intensity range into a small integer - field, and so it is more correct to say "gamma encoded" samples - instead of "gamma corrected" samples. - - When displaying an image file, the image decoding program is - responsible for making the overall gamma of the system equal - to the desired viewing_gamma, by selecting the decoding_gamma - appropriately. When displaying a PNG file, the gAMA chunk - provides the file_gamma value. The display_gamma may be known for - this machine, or it might be obtained from the system software, - or the user might have to be asked what it is. The correct - viewing_gamma depends on lighting conditions, and that will - generally have to come from the user. + When displaying an image file, the image decoding program is + responsible for making gamma equal to the value specified in the + gAMA chunk, by selecting the decoding exponent appropriately: + + decoding_exponent = 1.0 / (gamma * display_exponent) + + The display exponent might be known for this machine, or it might + be obtained from the system software, or the user might have to be + asked what it is. - Ultimately, you should have - - file_gamma * decoding_gamma * display_gamma = viewing_gamma 13.8. Some specific examples - In digital video systems, camera_gamma is about 0.5 by declaration - of the various video standards documents. CRT_gamma is 2.5 as - usual, while encoding_gamma, decoding_gamma, and LUT_gamma are all - 1.0. As a result, viewing_gamma ends up being about 1.25. + In digital video systems, the camera exponent is about 0.52 by + declaration of the various video standards documents. The CRT + exponent is 2.2 as usual, while the encoding exponent, decoding + exponent, and LUT exponent are all 1.0. As a result, the end-to- + end exponent is about 1.14. - On frame buffers that have hardware gamma correction tables, - and that are calibrated to display linear samples correctly, - display_gamma is 1.0. + On frame buffers that have hardware gamma correction tables, and + that are calibrated to display samples that are proportional to + display output intensity, the display exponent is 1.0. Many workstations and X terminals and PC clones lack gamma correction lookup tables. - Here, LUT_gamma is always 1.0, so display_gamma is 2.5. + Here, the LUT exponent is always 1.0, so the display exponent is + 2.2. - On the Macintosh, there is a LUT. By default, it is loaded with - a table whose gamma is about 0.72, giving a display_gamma (LUT - and CRT combined) of about 1.8. Some Macs have a "Gamma" control - panel that allows gamma to be changed to 1.0, 1.2, 1.4, 1.8, or - 2.2. These settings load alternate LUTs that are designed to give - a display_gamma that is equal to the label on the selected button. - Thus, the "Gamma" control panel setting can be used directly as - display_gamma in decoder calculations. + On the Macintosh, there is a LUT. By default, it is loaded with a + table whose exponent is 1/1.45, giving a display exponent (LUT and + CRT combined) of about 1.52. Some Macs have a "Gamma" control + panel with selections labeled 1.0, 1.2, 1.4, 1.8, or 2.2. These + settings load alternate LUTs, but beware: the selection labeled + with the value g loads a LUT with exponent g/2.61, yielding + + display_exponent = (g/2.61) * 2.2 On recent SGI systems, there is a hardware gamma-correction table whose contents are controlled by the (privileged) "gamma" program. - The gamma of the table is actually the reciprocal of the number - that "gamma" prints, and it does not include the CRT gamma. To - obtain the display_gamma, you need to find the SGI system gamma - (either by looking in a file, or asking the user) and then - calculating - - display_gamma = 2.5 / SGI_system_gamma + On recent SGI systems, there is a hardware gamma-correction + table whose contents are controlled by the (privileged) gamma + program. The exponent of the table is actually the reciprocal of + the number g that gamma prints. You can obtain g from the file + /etc/config/system.glGammaVal and calculate + + display_exponent = 2.2 / g You will find SGI systems with g set to 1.0 and 2.2 (or higher), but the default when machines are shipped is 1.7. + On NeXT systems the LUT has exponent 1/2.2 by default, but it can + be modified by third-party applications. + + In summary, for images designed to need no correction on these + platforms: + + Platform LUT exponent Default LUT exponent Default gAMA + + PC clone 1.0 1.0 45455 + Macintosh g/2.61 1.8/2.61 = 1/1.45 65909 + SGI 1/g 1/1.7 77273 + NeXT 1/g 1/2.2 100000 + + The default gAMA values assume a CRT display. 13.9. Video camera transfer functions The original NTSC video standards specified a simple power-law camera transfer function with an exponent of 1/2.2 (about 0.45). This is not possible to implement exactly in analog hardware because the function has infinite slope at x=0, so all cameras deviated to some degree from this ideal. More recently, a new camera transfer function that is physically realizable has been accepted as a standard [SMPTE-170M]. It is Vout = 4.5 * Vin if Vin < 0.018 Vout = 1.099 * (Vin^0.45) - 0.099 if Vin >= 0.018 where Vin and Vout are measured on a scale of 0 to 1. Although the exponent remains 0.45, the multiplication and subtraction change the shape of the transfer function, so it is no longer a pure power function. + It can be well approximated, however, by a power function with + exponent 0.52. - If you want to perform extremely precise calculations on video - signals, you should use the expression above (or its inverse, as - required). - - However, PNG does not provide a way to specify that an image uses - this exact transfer function; the gAMA chunk always assumes a pure - power-law function. If we plot the two-part transfer function - above along with the family of pure power functions, we find that - a power function with a gamma of about 0.5 to 0.52 (not 0.45) most - closely approximates the transfer function. Thus, when writing - a PNG file with data obtained from digitizing the output of a - modern video camera, the gAMA chunk should contain 0.5 or 0.52, - not 0.45. The remaining difference between the true transfer - function and the power function is insignificant for almost all - purposes. (In fact, the alignment errors in most cameras are - likely to be larger than the difference between these functions.) - The designers of PNG deemed the simplicity and flexibility of a - power-law definition of gAMA to be more important than being able - to describe the SMPTE-170M transfer curve exactly. - - The PAL and SECAM video standards specify a power-law camera - transfer function with a gamma of 1/2.8 or 0.36 --- not the 1/2.2 - of NTSC. However, this is too low in practice, so real cameras - are likely to have their gamma set close to NTSC practice. Just - guessing 0.45 or 0.5 is likely to give you viewable results, but - if you want precise values you'll probably have to measure the - particular camera. + The PAL and SECAM video standards specify a power-law camera + transfer function with an exponent of 1/2.8 (about 0.36). + However, this is too low in practice, so real cameras are likely + to have exponents close to NTSC practice. 13.10. Further reading - If you have access to the World Wide Web, read Charles Poynton's - excellent "Gamma FAQ" [GAMMA-FAQ] for more information about - gamma. + Charles Poynton's "Gamma FAQ" [GAMMA-FAQ] is a excellent source + of information about gamma, although it claims that CRTs have an + exponent of 2.5. See also his book [DIGITAL-VIDEO]. 14.9. Converting between RGB and XYZ - Here we assume we are working with linear RGB floating point data - in the range 0..1. If the gamma is not 1.0, make it so on the - floating point data. Then convert source_RGB to XYZ by matrix - multiplication: + RGB intensity samples normalized to the range 0 to 1 can be + converted to XYZ by matrix multiplication. (If you have gamma- + encoded RGB samples, first undo the gamma encoding.) 16. Appendix: Online Resources - http://quest.jpl.nasa.gov/PNG/ + http://www.cdrom.com/pub/png/ 17. Appendix: Revision History The PNG format has been frozen since the Ninth Draft of March 7, 1995, and all future changes are intended to be backward compatible. The revisions since the Ninth Draft are simply clarifications, improvements in presentation, additions of supporting material, + and specifications for additional chunks. + In January 1997 it was published as RFC-2083 (informational) with + technical content identical to that of the W3C Recommendation. + + In October 1998, the PNG 1.1 specification was approved by the PNG + Development Group. + + Changes since version 1.0 + + (W3C Recommendation 01-October-1996, RFC 2083 January 1997) + + Note: These changes have been approved by the PNG Development + Group, but not by any standards body. + + * Redefined gAMA to be in terms of the desired display output + rather than the original scene, and revised all discussions + of gamma and references to gamma accordingly + + * Added the iCCP, sPLT, and sRGB chunks + + * Extended the scope of the 31-bit limit on chunk lengths and + image dimensions to apply to all four-byte unsigned + integers, and disallowed the value -2^31 in four-byte signed + integers + + * Mentioned the possibility of dithering the alpha channel + when converting it to binary transparency + + * Clarified that zlib window sizes smaller than 32K are valid + + * Updated the PNG web site URL and authors' email addresses + + * Editing and reformatting 18. References - Also available from - + [DIGITAL-VIDEO] + Poynton, Charles, A Technical Introduction to Digital Video. John + Wiley & Sons, 1996. ISBN 0-471-12253-X. + http://www.inforamp.net/~poynton/Poynton-T-I-Digital-Video.html + [ICC] + The International Color Consortium + http://www.color.org/ + [ISO-3664] + International Organization for Standardization, "Photography-- + Illumination Conditions for Viewing Colour Transparencies and + their Representation", IS 3664, 1975. - [ISO-8859] - International Organization for Standardization, "Information - Processing --- 8-bit Single-Byte Coded Graphic Character Sets --- - Part 1: Latin Alphabet No. 1", IS 8859-1, 1987. + [ISO/IEC-8859-1] + International Organization for Standardization and International + Electrotechnical Commission, "Information Technology--8-bit + Single-Byte Coded Graphic Character Sets--Part 1: Latin Alphabet + No. 1", IS 8859-1, 1998. [PNG-EXTENSIONS] - PNG Group, "PNG Special-Purpose Public Chunks". Available in - several formats from - ftp://ftp.uu.net/graphics/png/documents/pngextensions.* + PNG Group, "Extensions to the PNG 1.1 Specification, Version + 1.1.0". Available in several formats from + ftp://ftp.uu.net/graphics/png/documents/pngext-* - + ftp://ftp.isi.edu/in-notes/rfc1123.txt - + ftp://ftp.isi.edu/in-notes/rfc1950.txt - + ftp://ftp.isi.edu/in-notes/rfc1951.txt - + ftp://ftp.isi.edu/in-notes/rfc2045.txt - + ftp://ftp.isi.edu/in-notes/rfc2048.txt + [RFC-2119] + Bradner, Scott, "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, Harvard University, March 1997. + ftp://ftp.isi.edu/in-notes/rfc2119.txt + [sRGB] + Stokes, Michael, Matthew Anderson, Srinivasan Chandrasekar, and + Ricardo Motta, A Standard Default Color Space for the Internet - + sRGB. + http://www.w3.org/Graphics/Color/sRGB + + The key portions of this document are being adopted with revisions + into: + + International Electrotechnical Commission, "Colour Measurement and + Management in Multimedia Systems and Equipment - Part 2-1: Default + RGB Colour Space - sRGB", IEC 61966-2-1. + http://w3.hike.te.chiba-u.ac.jp/IEC/100/PT61966/parts/part2/ 19. Credits Editors - Thomas Boutell, boutell@boutell.com + * Glenn Randers-Pehrson (PNG 1.1), randeg @ alumni.rpi.edu + * Thomas Boutell (PNG 1.0), boutell @ boutell.com Contributing Editors - Tom Lane, tgl@sss.pgh.pa.us + * Adam M. Costello (PNG 1.1), amc @ cs.berkeley.edu + * Tom Lane (PNG 1.0), tgl @ sss.pgh.pa.us Authors Authors' names are presented in alphabetical order. + Spaces have been added to e-mail addresses (around the @ + symbols) to minimize the amount of unwanted e-mail via automated + harvesters. * Mark Adler, madler @ alumni.caltech.edu * Thomas Boutell, boutell @ boutell.com * John Bowler, jbowler @ acm.org * Christian Brunschen, cb @ df.lth.se * Adam M. Costello, amc @ cs.berkeley.edu * Lee Daniel Crocker, lee @ piclab.com * Andreas Dilger, adilger @ enel.ucalgary.ca - * Oliver Fromme, fromme@rz.tu-clausthal.de + * Oliver Fromme, oliver @ fromme.com - * Jean-loup Gailly, gzip@prep.ai.mit.edu + * Jean-loup Gailly, jloup @ gzip.org * Chris Herborth, chrish @ qnx.com * Alex Jakulin, Aleks.Jakulin @ snet.fri.uni-lj.si - * Neal Kettler, kettler@cs.colostate.edu + * Neal Kettler, neal @ westwood.com * Tom Lane, tgl @ sss.pgh.pa.us * Alexander Lehmann, alex @ hal.rhein-main.de * Chris Lilley, chris @ w3.org * Dave Martindale, davem @ cs.ubc.ca - * Owen Mortensen, 104707.650@compuserve.com + * Owen Mortensen, ojm @ acm.org * Keith S. Pickens, ksp @ swri.edu - * Robert P. Poole, lionboy@primenet.com + * Robert P. Poole - * Glenn Randers-Pehrson, glennrp@arl.mil or - randeg@alumni.rpi.edu + * Glenn Randers-Pehrson, randeg @ alumni.rpi.edu * Greg Roelofs, newt @ pobox.com - * Willem van Schaik, willem@gintic.gov.sg + * Willem van Schaik, willem @ schaik.com - * Guy Schalnat + * Guy Schalnat, gschal @ infinet.com * Paul Schmidt, pschmidt @ photodex.com * Michael Stokes, Michael_Stokes @ hp.com - * Tim Wegner, 71320.675@compuserve.com + * Tim Wegner, twegner @ phoenix.net - * Jeremy Wohl, jeremyw@anders.com + * Jeremy Wohl, jeremyw @ evantide.com Trademarks + Windows + Document source + + This document was built from the file... Copyright notice + Copyright (c) 1998 by: Glenn Randers-Pehrson + + This specification is a modification of the PNG 1.0 specification. + It is being provided by the copyright holder under the provisions + of the 1996 MIT copyright and license: