MNG (Multiple Network Graphics) Format Version 19961007

Subsequent chunks can modify, show, or discard a full clone or its associated PROP, INHR, or SBYK data without affecting the basis image, or they can modify, show, or discard the basis image or its associated data without affecting the clone.

Subsequent chunks can only modify the associated PROP data of a partial clone. When the image data in either the basis image or in any partial clone is modified, the basis image and all of its partial clones are changed. Decoders must take care that when the basis image or any partial clone is discarded, the image data is not discarded until the last remaining one of them is discarded.

The CLON chunk does not imply SHOW.

2.1.12. SVCF Save composited frame

2 bytes: image_id (unsigned integer)
4 bytes: width (unsigned integer)
4 bytes: height (unsigned integer)
1 byte:  bit_depth (unsigned integer)
1 byte:  color_type (unsigned integer)
1 byte:  compression_method (unsigned integer)
1 byte:  filter_type (unsigned integer)
1 byte:  interlace_type (unsigned integer)

2.1.13. SHOW Show images

2 bytes: first_id (unsigned integer) 
2 bytes: last_id  (unsigned integer) 

An instance of each image will be displayed at the location specified by the PROP chunk, or at {0,0} if noe PROP chunk is present with the same image_id. When the PROP chunk is used in the delta form, which will frequently be the case, each image must be displaced from its previous position by the values given in the PROP chunk.

It is not necessary to follow an IHDR-IEND or DHDR-DEND sequence with a SHOW chunk. Such images are always displayed if they are within clipping boundaries of the frame, unless the sequence was preceded by the DEFN chunk.

2.1.14. DISC Discard images

The chunk contains a sequence of zero or more two-byte image identifiers. The number of images to be discarded is the the chunk's data length, divided by two.

2 bytes: discard_id (unsigned integer) image identifier
         that can be discarded.  All information
         pertaining to the corresponding image can be
         discarded and the identifier can be reused by
         a DEFI chunk.
etc.

When an image is discarded, any PROP, INHR, or SBYK data associated with it is also discarded.

The appearance of an image_id in the discard_id list, when no such image has been stored, or when the image has already been discarded, should not be treated as a fatal error.

Discarding images that are defined prior to the SEEK chunk is permitted, but the image_id of such images must not be reused.

2.1.15. SAVE Save decoder state

It appears after the set of chunks that define the decoder state that must be restored upon encountering a SEEK chunk. The SAVE chunk must be present when the SEEK chunk is present.

Only one instance of the SAVE chunk is permitted in a MNG datastream. It is not allowed anywhere after the first SEEK chunk.

When an image_id is defined prior to the SAVE chunk, it is not permitted to modify the image or any of the data associated with that image_id after the SAVE chunk. Such an image can be discarded my means of the DISC chunk; if so, its image_id must not be reused.

2.1.16. SEEK Seek point

n bytes: previous (number of bytes since the
         previous SEEK chunk) If previous==0,
         then the number of bytes is unspecified.

n bytes: next (number of bytes to the next SEEK
         chunk) If next==0, then the number of
         bytes is unspecified.

n is the length of the SEEK chunk, divided by two.
         n must be either 4 or 8.

When n is eight, 32-bit machines will have to interpret "previous" as a set of two integers, the first representing the number of complete 4G blocks and the second (the last four bytes of "previous") as the remainder, and will have to treat "next" similarly.

"Previous" and "next" are measured from the first length byte of one SEEK chunk to the first length byte of another SEEK chunk.

Applications are allowed to forget everything preceding the SEEK chunk, except for

• data appearing in the MHDR chunk
• anything appearing ahead of the SAVE chunk.

The SEEK chunk is not permitted within the scope of a {LOOP, ENDL} pair. If a decoder encounters a SEEK chunk while any loop is active, either as a result of an illegal SEEK chunk appearing inside a loop or as the result of skipping corrupted data, all display loops must be immediately terminated.

Multiple instances of the SEEK chunk are permitted. The SEEK chunk must not appear prior to the SAVE chunk. The SAVE chunk must also be present if the SEEK chunk is present.

2.1.17. LOOP, ENDL Define a loop

1  byte: start_loop_level (unsigned integer)
1  byte: loop_effect (unsigned integer)
      0: Execution of the loop might modify or relocate
         (via the LOCA chunk) basis images.
      1: Execution of the loop might modify or relocate
         basis images, but upon completion of the loop,
         all basis images have been restored to their
         initial state and location.
      2: Execution of the loop does not modify or
         relocate any basis images.
4 bytes: repeat_count (unsigned integer) range 0 to
         2^31-1

When the LOOP chunk is present, an ENDL chunk with the same loop_level must be present later in the MNG datastream. Loops can be nested. Each inner loop must have a higher value of start_loop_level than the loop that encloses it.

If repeat_count is zero, the loop is done zero times. Upon encountering a LOOP chunk with repeat_count==0, decoders simply skip chunks until the matching ENDL chunk is found, and resume processing with the chunk immediately following it.

It is the responsibility of the encoder to make sure that the assertions made by the loop_effect field are true. Note that the loop_effect field says nothing about the appearance of the display at the end of the loop. It describes the state of the basis images at the end of each iteration of the loop. When loop_effect==1, all iterations of the loop are identical, and a viewer could choose to store copies of the frame buffer for redisplay. This is also true when loop_effect=2; furthermore, if the user has escaped from the interior of the loop it is safe to resume processing with the first chunk after the ENDL chunk without having to skip to a SEEK chunk.

The ENDL chunk ends a loop that begins with the LOOP chunk. It contains a single one-byte field:

1 byte: end_loop_level (unsigned integer) range 0 to 255

When the ENDL chunk is present, a LOOP chunk with the same loop_level must be present earlier in the MNG datastream.

2.1.18. SYNC Synchronize display

2 bytes: sync_id (unsigned integer) sync identifier
      0: user input

The identifier sync_id==0 is defined to be a user input such as a keyboard input or a mouse-click.

2.1.19. NONE Define a blank image

The BLNK chunk defines a blank image. The chunk data is the same as that of the PNG IHDR chunk:

4 bytes: width (unsigned integer)
4 bytes: height (unsigned integer)
1 byte:  bit_depth (unsigned integer)
1 byte:  color_type (unsigned integer)
1 byte:  compression_method (unsigned integer)
1 byte:  filter_type (unsigned integer)
1 byte:  interlace_type (unsigned integer)

It generates a rectangle with zeroes in all of the pixel samples, which represents a black rectangle, fully transparent if the color type is 4 or 6. If color_type==3, it also generates a PLTE of length 2^bit_depth, filled with zeroes.

2.1.20. NEED Resources needed

The NEED chunk contains a list of keywords that the decoder must recognize. Keywords are typically chunk names.

n bytes: keyword
1  byte: null separator
etc.

The NEED chunk should be placed early in the MNG datastream, preferably immediately after the MHDR chunk.

The keywords are typically 4-character chunk names, but they could be any ASCII string that a decoder is required to recognize.

Decoders not recognizing a chunk name or keyword in the list should abandon the MNG datastream or request user intervention. The normal security precautions should be taken when displaying the keywords.

2.1.21. INHR Global INHR chunk

2.1.22. SBYK Global SBYK chunk

2.2. Ancillary MNG chunks

2.2.1. dURA Duration

4 bytes: frame_duration (unsigned integer), in ticks, using
         the tick length determined from ticks_per_second
         defined in the MHDR chunk.
1  byte: user_input_flag
      0: duration is only defined by the frame_duration
         value
      1: duration is defined by the sooner of (a) receipt
         of a user input (b) frame_duration

When user_input_flag==1, the decoder should immediately proceed to the next frame upon receiving a user input such as a keyboard character or a mouse-click. If no such input is received, then the decoder should proceed to the next frame when the frame_duration timer expires.

2.2.2. sPLT Suggested palette

The format of this chunk has not changed since version 19960914 of this document [i.e. the PNG proposed-chunks document, not this MNG propsal]. There has been no change to any part of the specification for this chunk since version 19960914. In the previous version it was called spLT and the name has been changed to avoid confusion. It is proposed to register the chunk as sPLT and to include it in the "PNG extensions" document. The "signature" field and its null separator will not be included in the registered version of this chunk.

This chunk's contents are a zero-byte-terminated text string that names the palette, a zero-byte-terminated signature to identify the version, followed by a 4-byte gamma value, followed by a series of palette entries, each a ten-byte series, containing five unsigned integers:

n bytes:  (ASCII text) palette name
1 byte:   (null) terminator

20 bytes: signature ("PNG group 1996-09-14")
1 byte:   (null) separator

4 bytes:  (unsigned integer) gamma

2 bytes:  (unsigned integer)  red intensity
          0:   black
          etc.
          65535: full red intensity
2 bytes:  (unsigned integer)  green intensity
2 bytes:  (unsigned integer)  blue intensity
2 bytes:  (unsigned integer)  alpha
          0: fully transparent
          etc.
          65535: fully opaque
2 bytes:  (unsigned integer)  frequency
          (relative frequency of occurrence)
etc.

The "name" (e.g. "256 color including Macintosh default", "256 color including Windows-3.1 default", "Browser Safe Palette") identifies the palette, which can permit applications or people to choose the appropriate one when more than one suggested palette appears in a PNG file. The "name" string must follow the format of a tEXt keyword: It must consist only of printable ASCII characters and must not have leading or trailing blanks, but can have single embedded blanks. There must be at least one and no more than 79 characters in the name. Names are case-sensitive.

The gamma field gives the value of gamma, times 100000, that is associated with the palette entries.

The red, green, and blue values are not premultiplied by alpha, nor are they precomposited against any background. A decoder can build a palette by compositing those palette entries against any background color or set of background colors that it chooses. See [link to bKGD]

Each frequency entry is proportional to the fraction of pixels in the image that are closest to that palette entry, without regard to any compositing against a background palette. 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 "frequency" values for "important" colors such as those in a company logo or in the facial features of a portrait. Zero is a valid value for frequency, meaning the color is "least important" or that it is rarely if ever used.

The palette uses 16 bits (2 bytes) per value regardless of the image bit depth specification. Decoders wishing to construct a palette with a smaller bit depth can accomplish this by scaling down the RGB entries, as described under "bit depth rescaling" in the PNG specification.

Note: Earlier versions of the PNG specification recommended that the PLTE [link to PLTE] and hIST chunks be used for this purpose. While this is still allowed, to maintain backward compatibility, the spAL chunk is preferable, particularly when transparent pixels are present. When both the PLTE and spAL chunks are present, the PLTE data should only be used for decoding the indexed-color (color type 3) pixels, and the spAL data should be used for constructing the display palette. If the hIST chunk is also present, decoders that process the spAL chunk should ignore it.

This chunk can appear for any color type. If this chunk does appear, it must precede the first IDAT chunk. There can be multiple spAL chunks, with different names.

2.2.3. PNG chunks

• tEXt
• tIME
• zTXt

• cHRM
• gAMA

• sPLT [same as PNG proposed sPLT (or spAL) chunk] (this chunk also takes precedence over the PLTE chunk in a subsequent PNG datastream when the PLTE chunk is being used as a suggested palette (i.e. color_type != 3).

2.2.4. fPRi Frame priority

1 byte: fPRi_delta_type (unsigned integer)
     0: Values are given directly
     1: Values are determined by adding
        the fPRi data to the previous
        values, modulo 256

1 byte: priority (unsigned integer) value to
        be assigned to subsequent frames
        until another vALu chunk is reached

1 byte: max_priority (unsigned integer) maximum
        priority that will appear in any subsequent
        fPRI chunk.

It is not permissible for a portion of the datastream to depend on any portion of the datastream having a lower value, because a decoder might have skipped the lower value portion. Use of the fPRi chunk is illustrated in Example 4.

When a SEEK chunk is encountered, the value of priority reverts to its value when the SAVE chunk was processed. Viewers that care about the priority can assume priority==255 for any portion of the MNG datastream that is processed prior to the first fPRi chunk.

3. The PND format

No provision is made for storing a PND datastream as a standalone file. A PND datastream will normally be found as a component of a MNG datastream. Applications that need to store a PND datastream separately can wrap it in a MNG datastream consisting of the MNG signature, the MHDR chunk, a NONE chunk, the PND datastream, and a MEND chunk.

The decoder must have available a basis (decoded) image from which the original chunk data is known. The basis image can be the result of decoding a PNG, another PND datastream, or it could have been generated by a BLNK chunk or a PNG-like datastream introduced by a BASI chunk.

The new image is always of the same basic type (at present only PNG is defined) as the basis image.

The decoder must not have modified the pixel data in the basis image by applying output transformations such as gAMA or cHRM, or by compositing the image against a background. Instead, the decoder must make available to the PND decoder the unmodified pixel data along with the values for the gAMA, cHRM, and any other recognized chunks from the basis image datastream.

A PND datastream consists of a DHDR and DEND enclosing other optional chunks (if there are no other chunks, the decoder simply copies the basis image).

Chunk structure (length, name, CRC) and the chunk-naming system are identical to those defined in the PNG specification. Definitions of compression_type, filter_type, and interlace_type are also the same as defined in the PNG specification.

3.1. PND critical chunks

3.1.1. DHDR PND datastream header

The DHDR chunk must contain exactly 20 bytes:

2 bytes: image_id (unsigned integer)
         Identifies the basis image from which changes
         will be made.  This is also the image_id
         of the resulting modified image, which can be
         used as the basis image for a subsequent PND
         datastream.

1  byte: image_type
      0: Image type is unspecified.  An IHDR chunk
         must be present.
      1: Image type is PNG.  IHDR can be omitted
         if no IHDR fields are different from those
         in the basis image and delta_type is 0, 1,
         or 3, and if IHDR would otherwise have
         appeared immediately after DHDR.

1  byte: delta_type
      0: image replacement
      1: pixel addition, by samples, modulo
         2^bit_depth.
      2: alpha addition, by samples, modulo
         2^bit_depth.  Regardless of the color
         type of the basis image, the IDAT data
         are written as a grayscale image (color
         type 0) but the decoded samples are used
         as deltas to the alpha samples in the
         basis image.  The basis image must have
         (or be promoted to via the PROM chunk)
         color type 4 or color type 6.
      3: no change to pixel data

4 bytes: block_width (unsigned integer)

4 bytes: block_height (unsigned integer)

4 bytes: block_x_location (unsigned integer) measured
         in pixels from the left edge of the basis
         image.

4 bytes: block_y_location (unsigned integer) measured
         in pixels from the top edge of the basis
         image.

The block_width and block_height fields give the size of the block of pixels to be modified or replaced, and block_x_location and block_y_location give its location with respect to the top left corner of the basis image. The block must fall entirely within the basis image.

The block size and location fields are ignored when delta_type==3.

3.1.2. DEND End of PND datastream

The DEND chunk is empty.

3.1.3. PROM Promotion of basis image

1 byte: new color_type
1 byte: new bit_depth

When a grayscale or truecolor basis image is promoted to an image with an alpha channel, the alpha samples are initialized to 2^bit_depth-1 (fully opaque). When an indexed-color image is promoted, the alpha channel data is obtained from the basis image's tRNS chunk data, if present, or initialized to 2^bit_depth-1, if the tRNS chunk is not present or not recognized by the decoder.

The PROM chunk is not permitted to "demote" a basis image to an image with a lesser bit depth or from one with an alpha channel to one without an alpha channel.

The resulting image must not exceed max_bit_depth or max_samples_per_pixel from the MHDR chunk.

3.1.4. IHDR, PNG chunks, IEND

See the PNG specification for the format of the PNG chunks. The PNG datastream must contain at least IHDR and IEND but can inherit other chunk data from the basis image. Except for IDAT, any chunks appearing between IHDR and IEND are always treated as replacements or additions and not as deltas.

A gAMA, cHRM, or similar chunk existing in the basis image would not affect the pixel data inherited by this PND datastream because they are not used in decoding the pixel data. Applications are responsible for ensuring that the pixel values that are inherited from the basis image have not been transformed in any way after decompressing and unfiltering them.

When processing the tRNS chunk, if color_type==3 and PLTE is not supplied, then the number of allowable entries is determined from the number of PLTE entries in the basis image.

MNG viewers are expected to ignore the pHYS and oFFs chunks but MNG editors are expected to recognized and copy the pHYS chunk, because it is a known chunk that is specified in the PNG specification, and to treat the oFFs chunk as an unknown chunk that will be handled as described in Paragraph 3.1.5, below.

The IHDR chunk can be omitted if all of the IHDR fields would be identical to those in the basis image, the image_type is 1, and the IHDR chunk would otherwise have appeared immediately after the DHDR chunk with no intervening PND chunks such as INHR. The decoder must treat this datastream as though the IHDR were present, immediately after the DHDR chunk, with all IHDR chunk data identical to that of the basis image. The IHDR chunk can also be omitted when no PNG chunks are present. When delta_type is 2, it is not necessary to include an IHDR chunk for the sole purpose of specifying that the IDAT is in grayscale format.

When the IHDR chunk is present and delta_type is nonzero, its width and height must match those of the basis image. Also, when the IHDR chunk is present, the block height and width must match the height and width of the basis image, and the block location must be (0,0).

The PNG specification places ordering requirements on many chunks with respect to the PLTE and IDAT chunks. If neither of these two chunks is present, and the INHR chunk is not present, known chunks (always including all standard chunks described in the PNG specification) are considered to have appeared in their proper order with respect to the critical chunks. Unknown chunks are ordered as described in Paragraph 3.1.5, below. When the INHR chunk is present, then all chunks are considered to have appeared in the order given by the INHR chunk.

The IEND chunk can be omitted, if it would be the last chunk in the PND datastream before the DEND, or when no PNG chunks are present.

3.1.4.1. Image replacement

3.1.4.2. Image pixel deltas

The image color_type and bit_depth must match those of the basis image, and the basis image must have been derived from a PNG datastream or from a sequence of PND datastreams that depend upon a PNG datastream.

The compression method, filter method, and interlace method need not be the same.

[We might want to add a compression_type that uses deflate with the final 32 kilobytes of the basis image data as a preset dictionary]

The IDAT chunk data contains a filtered and perhaps interlaced set of delta pixel samples. The delta samples are presented in the order specified by interlace method, filtered according to the filter method and compressed according to the compression method given in the IHDR chunk. The actual pixel values are calculated using the method defined in the delta_type field of the DHDR chunk.

When delta_type==1, an encoder calculates the new sample values from the samples in the basis image and those in the new image by subtracting the basis image samples from the new image samples, modulo 2^sample_bit_depth. When decoding the IDAT chunk, the new image bytes are obtained by adding the delta bytes to the basis image bytes, modulo 2^sample_bit_depth. This is similar in operation to the PNG SUB filter, except that it works by samples instead of by bytes.

When color_type==3, the deltas are differences between index values, not between color samples.

3.1.4.3. Image alpha deltas

The image bit_depth must match those of the basis image, but color type must be 0 (grayscale). The basis image must have an alpha channel or must have been promoted to a type that has an alpha channel. The compression method, filter method, and interlace method need not be the same.

3.1.4.4. No change to pixel data

When delta_type==3 in the DHDR chunk, it is an error for IDAT to appear.

3.1.5. INHR Inherited chunks

The INHR chunk contains a series of five-byte entries, each giving a chunk name and a rule.

4 bytes: chunkname

1  byte:  rule

      0: (Replace) Inherit all instances of the chunk
         in the basis image.  If a new instance is found
         in the PND datastream, delete all inherited
         instances and replace them with the new instance
         or instances.

      1: (Append) Inherit all instances of the chunk in
         the basis image.  Append any new instances found
         in the PND datastream.

      2: (Ignore) Ignore any instances of the chunk in
         the basis image.  Insert any new instances found
         in the PND datastream.

      3: (Replace by Keyword) The chunk is one for which
         multiple instances are permitted, and the first
         field of the chunk is a null-byte terminated
         ASCII keyword or name (tEXt, zTXt, spAL, for
         example).  Inherit all instances of the chunk
         from the basis image.  If a new instance is
         found in the PND datastream, delete all
         inherited instances having the same keyword or
         name and replace them with the new instance or
         instances.

      4: (Special) Inheritance and placement of this
         chunk is governed by special rules that must be
         known to the PND decoder (IDAT, for example)

      5: (Select by Keyword) The chunk is one whose first
         field is a null-byte terminated ASCII keyword or
         name (tEXt, zTXt, spAL, for example).  Inherit
         only those instances named in SBYK chunks.
         Append any new instances found in the PND
         datastream.

      6: (Reject by Keyword) The chunk is one whose first
         field is a null-byte terminated ASCII keyword or
         name (tEXt, zTXt, spAL, for example).  Inherit
         all instances except those instances named in
         SBYK chunks.  Append any new instances found in
         the PND datastream.

The INHR chunk also gives a template for the arrangement of chunks within the resulting PNG datastream. The decoder can place them in any order, relative to their order in the basis image, that obeys the chunk-ordering rules for copy-safe chunks given in the PNG specification, but when it encounters unknown but copy-safe chunks, it should use the INHR chunk data as a template to ensure that they are properly placed.

The INHR chunk can be omitted. If no INHR chunk appears in a PND datastream or is associated with its basis image, then data from the global INHR chunk, defined Paragraph 2.1.21, above, can be used if it is present. PND applications are expected to know the copying rules and order of placement of those chunks defined in the core specification for the image format corresponding to the DHDR image_type, regardless of whether an INHR chunk is present and whether those chunks are listed in it. In particular, the PNG IHDR and IEND chunks need not be listed in the INHR chunk, because the position of these chunks is already well-defined. PLTE (with rule==0) and IDAT (with rule==4) should be listed, however, because other chunks need to be located with respect to them. It is not an error for a chunkname to appear in the list, when that chunk does not appear in the basis image or in the PND datastream.

When an unknown chunk is found in the PND datastream that appears in the basis image but is not listed in the INHR chunk, the decoder can copy the chunk into the same position relative to critical chunks that it occupied in the basis image. When an unknown chunk appears neither in the basis image nor in the INHR list, or when a chunk's rule==4 and the PND decoder does not know the special copying rules for the chunk in question, the decoder must treat it as an unknown chunk, ignoring it if it is ancillary, and abandoning the PND datastream if it is critical.

The INHR chunk data itself is inherited, so an INHR chunk need only appear in the first of a sequence of PND datastreams that have the same image_id, if there are no changes. When a INHR chunk is inherited and also appears on the PND datastream, the entire list of chunk names and rules is replaced.

Applications that reconstruct a PNG datastream from a PND datastream and a basis PNG or PND datastream must not write the INHR chunk itself to the resulting PNG datastream, because the INHR chunk would not be recognized by a PNG decoder.

There can be only one instance of the INHR chunk in a PND datastream. The INHR chunk must appear before IHDR if it is present.

3.1.6. SBYK Select chunks by keyword

4 bytes:  (four ASCII bytes) chunk name
n bytes:  (ASCII string) Keyword

The keyword need not be terminated by a null byte; if it is, the null byte will be ignored. The keyword must follow the format of a tEXt keyword: It must consist only of printable ASCII characters and must not have leading or trailing blanks, but can have single embedded blanks. There must be at least one and no more than 79 characters in the name. Keywords are case-sensitive. Use caution when printing or displaying keywords (Refer to Security considerations, Chapter 8, below).

Any chunks in the basis image having the same chunk name and keyword are selected (if INHR rule==5) or rejected (if INHR rule==6) for inclusion in the resulting PND image. It is a nonfatal error to select a {chunkname, keyword} pair that does not exist in the basis image. It is a fatal error to fail to include the chunkname in the INHR chunk if it appears in an SBYK chunk.

The SBYK chunk can be omitted. If no SBYK chunk appears in a PND datastream or is associated with its basis image, then data from the global SBYK chunk, defined Paragraph 2.1.22, above, can be used if it is present.

The keyword, "purpose," or other identifying string must appear first in the chunk's data segment. The practice of putting a version identifying "signature" first in the data segment of unregistered experimental chunks will defeat this mechanism, so it is better to place such a "signature" after the keyword, if you wish to use the SBYK mechanism with your experimental chunk.

Applications that reconstruct a PNG datastream from a PND datastream and a basis PNG or PND datastream must not write the SBYK chunk itself to the resulting PNG datastream, because the SBYK chunk would not be recognized by a PNG decoder.

Multiple instances of the SBYK chunk are permitted in a PND datastream. Any instances must appear prior to the IHDR chunk, if the IHDR chunk is present.

3.2. PND ancillary chunks

3.2.1. fADE Fade in or out

1  byte: (unsigned integer) fade_type
      0: fade out
      1: fade in
      2: fade in but don't change fully transparent
         pixels
2 bytes: (unsigned integer) alpha_delta

When "fade_type==1", the value of alpha_delta is added to the alpha sample of every pixel in the basis image, but the result is not allowed to exceed the maximum alpha value for the image's bit depth.

When "fade_type==2", the value of alpha_delta is added to the alpha sample of any pixel in the basis image that has a non-zero value, and the result is not allowed to exceed the maximum alpha value for the image's bit depth.

If color_type==3, then the value of alpha_delta is added to or subtracted from the alpha values that were defined by the tRNS chunk data in the basis image, and the resulting values become the tRNS data exported to any subsequent image. The maximum alpha value for this color_type is 255, regardless of the bit depth.

If color_type is 0 or 2, the fADE chunk is ignored.

If IHDR is also present, the fADE chunk must appear before IHDR. The fade operation is performed on the image data after decoding the chunks between IHDR and IEND.

3.2.2. PNG chunks

• tEXt
• tIME
• zTXt

4. Retaining image data

The following information must be retained, for each image_id that is defined and not subsequently discarded:

• The data from the PROP chunk.
• The pixel data and the values associated with other recognized PNG chunks such as PLTE and gAMA, subject to the chunk copying rules and the INHR chunk.
• The contents of the INHR chunk and SBYK chunks associated with the image_id, if the decoder needs this information.

When the encoder knows that image data will not be needed by subsequent frames, it can make life easier for decoders by using the ok_to_discard field of the MHDR chunk or by using the DISC or the SEEK chunk.

5. Decoder handling of fatal errors

When an error occurs within a image datastream, such as an unknown critical PNG chunk or a missing basis image where one was required, only that image should be abandoned and the associated image_id should be discarded.

MNG editors, on the other hand, should be more strict and reject any file with errors unless the user intervenes.

6. Decoder handling of interlaced files

7. Decoder handling of palettes

If PLTE is present in a PND datastream, the new palette is used in displaying the image defined by the PND; if no IDAT chunk is present and the image type is PNG indexed-color, then the image is redisplayed using the old pixel samples as indices into the new palette.

If a frame contains two or more images, the PLTE chunk in one image does not affect the display of the other, unless one image is a PND without a PLTE chunk, that has been declared by the DHDR image_id field to depend on the other.

Note that a composite frame consisting only of indexed-color images should not be assumed to contain 256 or fewer colors, since the individual palettes do not necessarily contain the same set of colors. Encoders can supply a sPLT chunk with a reduced global palette, to help decoders build an appropriate palette when necessary.

8. Security considerations

An infinite or just overly long loop could give the appearance of having locked up the machine, as could an unreasonably long inter-frame delay or a misplaced SYNC chunk. Therefore a decoder should always provide a simple method for users to escape out of a loop or delay, either by canceling the MNG entirely or just proceeding on to the next SEEK chunk.

The sPLT chunk contains a "name" field that might be printed or displayed as text by some applications. As with the tEXt chunk, any non-printable characters in the sPLT "name" field, especially the ESC character, should not be displayed directly.

No known additional security concerns are raised by this format.

Detection of corrupted file transfers can be improved even beyond that available in PNG by using the MHDR max_chunk_size field to determine whether any chunk length (except for that of MHDR itself, which has a known length that can be checked) is unreasonably large.

9. Appendix: Examples

9.1. Example 1: Simple movie

\211 M N G \r \n ^z \n  # MNG signature
MHDR 720 468 720 468    # Width and height
     20 65536  # 20 frames, max chunk length = 65kbytes
     30  3 60  # 10 frames per second, duration 60 ticks
     0000  8  # four unused bytes, max_bit_depth 8
     3         # Max 3 samples per pixel (color type 2)
     0         # Not OK discard
     000000    # Six reserved bytes
tEXtTitle\0Sample Movie

SAVE
SEEK 0 n1
IHDR 720 468 8 2 0 0 0   # DEFI 0 is implied
IDAT ...
IEND 


DHDR 0 1 1 20 30 100 220   # A PNG-delta frame
IDAT ...       # The IDAT gives the 20x30 block
DEND           # of deltas

DHDR 0 1 1 20 30 102 222     # Another PNG-delta frame
IDAT ...       # This time the deltas are in a 20 x 30
DEND           # block at a slightly different location

SEEK n1 n2      # Ok to restart here because a
                # complete PNG frame follows
IHDR 720 468 ...
IDAT ...
IEND

DHDR 0 1 1 720 468 0 0     # Another PNG-delta frame
IDAT ...   # The entire 720x468 rectangle changes
DEND       # this time.

SEEK n2 0
MEND            # End of MNG datastream

9.2. Example 2: Single composite frame

\211 M N G \r \n ^z \n # MNG signature
MHDR 1024 512 500 500 # Width, height
     1 8192   # Nframes, maxchunklen
     1 0 0    # Frame duration can be zero since there's
              # only one frame but ticklength must be nonzero
     0000     # four unused bytes (was default_gamma)
     16 1     # Max depth 16, max 1 sample per pixel
     0        # Not ok to discard
     000000   # Six reserved bytes
BACK 0 0 64 64 192   # Sky blue background
FRAM 1               # Composite frame, 1024 x 512
PROP 0 0 0 0 6 6 0     # Location of first image
                     # DEFI 0 is implied
IHDR 500 500 16 0 .. # A 16-bit graylevel image
gAMA 50000
IDAT ...
IEND                 # End of image
                     # SHOW 0 0 is implied

PROP 0 0 0 0 518 6 0   # Location to display a modified image.
DHDR 0 1 3 0 0 0 0   # Reload image 0 and modify it
INHR gAMA 0 tEXt 3 faLT 0 IDAT 4 # establish chunk order
gAMA 100000   # gamma value is 100000 (gamma=1.0)
tEXtComment\0The faLT chunk is described in ftp://swrinde....
faLT ...             # Apply pseudocolor to basis image
DEND                 # End of image

PROP 0 0 0 0 900 400 0     # Overlay near lower right-hand corner
IHDR 101 101 2 3 ... # Image 0 is redefined, but this does
                     # not affect the images already on screen
gAMA 50000           # We need a new gAMA because
PLTE ...             #    this is not a PND datastream
tRNS ...             # It's transparent (maybe a logo)
IDAT ...             # Note that the color type can differ
IDAT ...             #    from that of the other images.
IEND                 # End of image

MEND                 # End of MNG datastream

9.3. Example 3: Movie with sprites

\211 M N G \r \n ^z \n  # MNG signature
MHDR 512 512 512 512  # Start of MNG datastream
     0 0          # Nframes, maxchunklen undefined
     30 3 3000   # 10 frames/sec, not more than 100 sec
     0000 8     # max_bit_depth 8
     1           # Max samples per pixel
     0           # Not ok to discard
     000000      # Six reserved bytes
FRAM 1           # First frame
DEFI 1           # Define image 1
                 # Location for image 1 is (0,0)
IHDR 512 512 ... # It's a full-display PNG image
etc              # Chunks according to PNG spec
IEND             # SHOW 1 1 is implied by DEFI 1
DEFI 2           # Define image 2
PROP 2 0 0 0 0 300 200 0   # Location for image 2
IHDR 32 32 ...   # It's a small PNG
gAMA 50000
IDAT ...
DEND             # IEND is omitted
FRAM 1           # Start new frame
                 # New location for image 1 is still 0,0
SHOW 1 1         # Display image 1 from previous frame
PROP 2 0 0 1 10 5 0   # New (delta) location for image 2
SHOW 2 2         # Retrieve image 2 from previous frame,
CLON 2 3 0       # make a full clone of it as image 3
PROP 3 0 0 0 400 500 0 # Location for image 3
DHDR 3 1 3 0 0 0 0      # Modify image 3
tRNS ...         # Make it semitransparent
DEND             # SHOW 3 3 is implied by DHDR
FRAM 1           # Next frame (repeat this FRAM-SHOW 3 3
                 #   sequence with different locations to
                 #   move the images around)
                 # New location for image 1 is still 0,0
SHOW 1 1         # Display image 1 from previous frame
PROP 2 0 0 1 10 5 0    # New (delta) location for image 2
SHOW 2 2         # Show image 2 from previous frame,
PROP 3 0 0 1 5 -2 0    # New location for image 3
SHOW 3 3         # Show image 3
FRAM 1           #  Another frame
etc.
FRAM 1
etc.             # More frames
MEND             # End of MNG datastream

9.4. Example 4: "Fading in" a transparent image

\211 M N G \r \n ^z \n # MNG signature
MHDR 64 64 64 64  # Width, height
     16 8192      # Nframes, maxchunklen
     30 6 140  # Tick length, frame and total duration
     0000     # unused
     8 1       # Max bit depth 8, 1 sample per pixel
     0         # Not ok to discard
     000000    # Six reserved bytes
BACK 1 0 192 192 192 # "Browser gray" default background
DEFN 1
IHDR ...    # PNG header
PLTE ...
tRNS ...    # Entries are zero for the transparent color
            # and 255 for the nontransparent ones.
IDAT ...
IEND
fPRi 0 0 255  # Give the fade-in sequence a low priority
CLON 1 2 0  # Make a working copy of the image because
            # it will be modified during the low-priority
            # part of the datastream.  It's a full clone.
DHDR 2 1 3 0 0 0 0 
fADE 0 254  # Subtract 254 to alpha for all nontransparent
            # pixels to bring them down from 255 to 1
LOOP 0 0 15
DHDR 2 1 3 0 0 0 0 
fADE 2 16   # Add 16 to alpha for all nontransparent
DEND        # colors.
ENDL 0      # Repeat loop.  After 15 iterations, the
            # opaque colors will end up with alpha=241
            # and the transparent ones will still be 0.
DISC 2      # Discard the working copy
fPRi 0 255 255  # Give the final frame the highest value
dURA 60     # Hold the last frame for at least 60 ticks
            # (2 sec).  Applications might show it longer,
            # or they might ignore dURA; it's ancillary.
SHOW 1 1    # This copy still has alpha=255 for the
            # opaque pixels and alpha=0 for the others.
MEND        # End of MNG

9.5. Example 5: Storing three-dimensional images

\211 M N G \r \n ^z \n # MNG signature
MHDR 150 150 150 150 24  # Width, height, nframes
     65000       #  Maxchunklen (doesn't have to be 2^n)
     30 0 0      # Tick length, duration (can be zero)
     100000      # default gamma (voxel data is linear)
     16 1        # Max bit depth 8, 1 sample per pixel
     0           # Not ok to discard
     000000      # Six reserved bytes

tEXtTitle\0Weather modeling results
tEXtComment\0The pcAL, xsCL, ysCL, zsCA, and tsCL chunks
 in this file are written according to the PNG Sci-vis
 chunks specification version 19960921 available at
 ftp://swrinde.nde.swri.edu/pub/png-group/documents/

xsCLkilometers\0 0\0 150 # Sci-vis "xsCL" chunk
ysCLkilometers\0 0\0 150 # Sci-vis "ysCL" chunk
zsCAHeight (kilometers)\0 0\0 15
tsCLTime (hours)\0 0\0 24 # See proposed sci-vis chunks
pcAL 0 2 Degrees Celsius\0 0\0 45  # Sci-vis "pcAL" chunk
SAVE
SEEK 0 3588720    # 3588720 bytes to the next SEEK chunk
FRAM 1           # Initial composite image
IHDR 150 150 16  # Width, height, bit depth for top layer
     0 0 0 0     # Color, comp, filter, interlace
IDAT ...
IEND             # No DEFI chunk, so it's image 0
DHDR 0 1 0       # Source=0, PNG, pixel subtraction,
     150 150 0 0 # Block is entire image
IDAT ...     # IHDR is omitted; everything matches top
DEND         # IEND is also omitted
etc.         # Repeat DHDR through DEND 148 more times
SEEK 3588720 4621885
FRAM 1       # End of first block
etc.         # Repeat FRAM through SEEK 19 more times
SEEK 2285321 0
MEND         # End of MNG

9.6. Example 6: Tiling

\211 M N G \r \n ^z \n  # MNG signature
MHDR 1024 768 128 64 ... # Start of MNG datastream
FRAM 1
PROP 1 0 0 0 0 -64 0 # Set up an offscreen copy of the tile
DEFN 1        # Give it ID==1, don't show it immediately
IHDR 128 64 ...
PLTE ...
IDAT ...      # Nothing will be displayed because it's
IEND ...      # outside the 1024 by 768 composite frame
              # and because we used DEFN instead of DEFI

LOOP 0 0 12   # Y loop -- make 12 rows of tiles
PROP 1 0 0 1 0 64 0 # Move the first copy down 64 rows
SHOW 1 1      # Display it
CLON 1 2 1    # Create a partial clone of the tile

LOOP 1 0 7    # X loop - 7 additional columns
PROP 2 0 0 1 0 128 0 # Move it to the right 128 columns
SHOW 2 2      # Use the second copy
ENDL 1

ENDL 0
MEND

9.7. Example 7: Scrolling

\211 M N G \r \n ^z \n  # MNG signature
MHDR 512 256      # Width and height on screen
     512 3000     # Max_image must accommodate the
                  # Largest stored image
     3257        # Max no of frames
     32000       #  Maxchunklen
     30 1 3257   # Tick length, duration, total dur. 
     50000       # Default gamma
     4 1         # Max bit depth 4, 1 sample per pixel
     0           # Not ok to discard
     000000      # Six reserved bytes
FRAM 1
DEFN 1            # Define image 1 but don't display now
PROP 1 0 0 0 0 256 0    # Initially it's offscreen, just
                  # below the 512 by 256 window
IHDR 512 3000 ... # A PNG datastream containing the
PLTE ...          # text (or whatever) to be scrolled
IDAT ...
IEND

DEFI 2
IHDR 512 256 ... # A PNG datastream containing some kind
PLTE ...         # of alpha-blended border that is
tRNS ...         # transparent in the center
IDAT ...
IEND

LOOP 0 0 3256
FRAM 1
PROP 1 0 0 1 0 1 0 # Jack image 1 up one scanline, 3256 times
SHOW 1 1   # It ends up just above the 512 by 256 window
           # The border does not move (PROP 0 0 0 0 0 0 0 implied)
SHOW 2 2   # Overlay the transparent border
ENDL 0

MEND

9.8. Example 8: Converting a GIF animation to MNG

begin
    write MHDR chunk
    write BACK chunk
    write SAVE chunk
    framing_mode := 0
    frame_duration := 0
    
    for subimage in gif89a file do
       if(frame_duration != gif_duration) then
           frame_duration := gif_duration
           write dURA frame_duration chunk
       endif
       case gif_disposal_method in
          0: /* (undefined) */
             write <image>
             if (framing_mode == 1) then
                 write FRAM 0 chunk
                 framing_mode := 0
             endif
          1: /* (keep) */
             if (framing_mode == 0) then
                 write FRAM 1 chunk
                 framing_mode := 1
             endif
             write <image>
          2: /* (restore background) */
             write <image>
             if (framing_mode == 1) then
                 write FRAM 0 chunk
                 framing_mode := 0
             endif
          3: /* (restore previous) */
             write SVCF 1 width height ... chunk
             write <image>
             write FRAM 1 chunk
             framing_mode := 1
             write SHOW 1 1 chunk
       endcase
    endfor
    write MEND chunk
end

10. Credits

• Mark Adler, madler@alumni.caltech.edu
• Thomas Boutell, boutell@boutell.com
• John Bowler, jbowler@acm.org
• Christian Brunschen, cb@df.lth.se
• Glen Chapman, glenc@clark.net
• Adam M. Costello, amc@cs.berkeley.edu
• Lee Daniel Crocker, lee@piclab.com
• Peter da Silva, peter@starbase.neosoft.com
• Andreas Dilger, adilger@enel.ucalgary.ca
• Oliver Fromme, fromme@rz.tu-clausthal.de
• Jean-loup Gailly, gzip@prep.ai.mit.edu
• Chris Herborth, chrish@qnx.com
• Alex Jakulin, alex@hermes.si
• Neal Kettler, kettler@cs.colostate.edu
• 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
• Carl Morris, msftrncs@htcnet.com
• Owen Mortensen, ojm@csi.compuserve.com
• Keith S. Pickens, ksp@swri.edu
• Glenn Randers-Pehrson, glennrp@arl.mil or randeg@alumni.rpi.edu
• Greg Roelofs, newt@pobox.com
• Willem van Schaik, gwillem@ntuvax.ntu.ac.sg
• Guy Schalnat
• Paul Schmidt, pschmidt@photodex.com
• Smarasderagd, smar@reptiles.org
• Thomas R. Tanner, ttehtann@argonet.co.uk
• Guido Vollbeding, guivol@esc.de
• Tim Wegner, 71320.675@compuserve.com
• Alaric B. Williams, png@abwillms.demon.co.uk

• GIF is a service mark of CompuServe Incorporated.
• Macintosh is a trademark of Apple Computer, Inc.
• Windows 3.1 is a trademark of Microsoft Corporation.

Author's Address

Phone: (410) 278-6554

EMail: glennrp@arl.mil or randeg@alumni.rpi.edu

End of MNG Specification. Expires 07 April 1997