Animated Portable Graphics (APG) Format Version 0.94.8

5 October 2015

Editor

Status of this Memo

This is a DRAFT proposal. Some version of this document may become version 1.0.

Comments on this document can be sent to the editor or to the PNG specification maintainers at one of the following addresses:

Distribution of this memo is unlimited.

At present, the latest version of this document is available on the World Wide Web from


ftp://ftp.simplesystems.org/pub/png-group/documents/.

Abstract

This document defines the Animated Portable Graphics( APG) format. It proposes a file extension ".apg" and an Internet Media Type "video/apg".

The APG format provides a mechanism for reusing image data without having to retransmit it. Multiple images can be composed into a "frame" and a group of images can be used as an animated "sprite" that moves from one location to another in subsequent frames.

APG is a multiple-image member of the PNG (Portable Network Graphics) format family. It can contain animations, slide shows, or complex still frames, comprised of multiple PNG or JNG (JPEG Network Graphics) single-image datastreams.

The APG format was derived from the MNG-1.0 format [MNG] by deletion of a number of chunks, elimination of the "simplicity profile", and by addition of the SNAP and PLAY chunks. The APG format uses the same chunk structure that is defined in the PNG specification, and it shares other features of the PNG format. Any APG decoder must be able to decode PNG and JNG datastreams.

Table of Contents

1. Introduction

This specification defines the format of an APG (Animated Portable Graphics) format, and proposes a file extension ".apg" and an Internet Media Type (MIME type) "video/apg".

Note: This specification depends on the PNG (Portable Network Graphics) [PNG] and the JNG (JPEG Network Graphics) [JNG] specifications. It was derived from the MNG (Multiple-image Network Graphics) specification [MNG] by deletion of a number of features and by addition of the PLAY and SNAP chunks. The PNG, JNG, and MNG specifications are available at the PNG web site,

   http://www.libpng.org/pub/png/

APG is a multiple-image member of the PNG format family that can contain

comprised of multiple PNG or JNG single-image datastreams.

Like PNG, an APG datastream consists of an 8-byte signature, followed by a series of chunks beginning with the MHDR chunk and ending with the MEND chunk. Each chunk consists of a 4-byte data length field, a 4-byte chunk type code (e.g., "MHDR"), data (unless the length is zero), and a CRC (cyclical redundancy check value). Alternatively, an APG datastream can consist of a single PNG or JNG datastream without the enclosing MHDR and MEND chunks.

An APG datastream describes a sequence of zero or more single frames, each of which can be composed of zero or more embedded images or directives to show previously defined images.

The embedded images can be PNG or JNG datastreams.

A typical APG datastream consists of:

or a standalone PNG datastream: or a standalone JNG datastream:

APG is fundamentally declarative; it describes the elements that go into an individual frame. It is up to the decoder to work out an efficient way of making the screen match the desired composition whenever a nonzero interlayer delay occurs. Simple decoders can handle it as if it were procedural, compositing the images into the frame buffer in the order that they appear, but efficient decoders might do something different, as long as the final appearance of the frame is the same.

APG is pronounced "a.p.g."

When an APG datastream is stored in a file, it is recommended that ".apg" be used as the file suffix. In network applications, the Media Type "video/x-apg" can be used. Registration of the media type "video/apg" might be pursued at some future date.

The APG datastream begins with an 8-byte signature containing

    140  65  77  71  13  10  26  10  (decimal)
     8c  41  4d  47  0d  0a  1a  0a  (hexadecimal)
   \214   A   P   G  \r  \n \032 \n  (ASCII C notation)

which is similar to the PNG signature with "\214 A P G" instead of "\211 P N G" in bytes 0-3.

Chunk structure (length, name, data, CRC) and the chunk-naming system are identical to those defined in the PNG specification. As in PNG, all integers that require more than one byte must be in network byte order.

The chunk copying rules for APG employ the same mechanism as PNG, but with rules that are explained more fully (see below, Chapter 6). An APG editor is not permitted to move unknown chunks across the NAME chunk, across any chunks that can cause images to be created or displayed, or into or out of a IHDR-IEND or similar sequence.

Note that decoders are not required to follow any decoding models described in this specification nor to follow the instructions in this specification, as long as they produce results identical to those that could be produced by a decoder that did use this model and did follow the instructions.

Each chunk of the APG datastream or of any embedded object is an independent entity, i.e., no chunk is ever enclosed in the data segment of another chunk.

APG-compliant decoders are required to recognize and decode independent PNG datastreams beginning with either the 8-byte PNG signature or with the 8-byte APG signature, or JNG datastreams beginning with either the 8-byte JNG signature or with the 8-byte APG signature,.

Most APG datastreams are valid MNG-1.0 datastreams. MNG-1.0 decoders will not recognize the SNAP and PLAY chunks, which were defined in 2007 and have not been registered by the PNG Registration Authority, nor will they properly handle the value 2 (discard) in the DEFI chunk's Discard field.

Because the embedded objects making up an APG are normally in PNG format, APG shares the good features of PNG:

In addition it has these features of the MNG format:

2. Terminology

See also the glossary in the PNG specification.

requirement levels
The words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "OPTIONAL" in this document, which are to be interpreted as described in RFC-2119. The word "CAN" is equivalent to the word "MAY" as described therein. "NOT ALLOWED" and "NOT PERMITTED" describe conditions that "MUST NOT" occur. "ALLOWED" and "PERMITTED" describe conditions that "CAN" occur.

animation
A sequence of images meant to be played at a framing rate that will give the impression of motion. We use the more generic term "sequence" to include any group of images meant to be played at some specified framing rate or under user control, not necessarily an animation, such as a slide show, as well as animations.

cacheable
A loop is "cacheable" if it produces the identical set of scenes for each iteration of the loop. Thus the scenes can be placed in a cache and replayed rather than having to be rebuilt each time.

cheap transparency
Image transparency data conveyed via the PNG tRNS chunk rather than via a full alpha channel.

clipping boundaries
Limits within which a pixel must fall to be displayed. The left and top boundaries are inclusive, while the right and bottom boundaries are exclusive.

color encoding
File gamma and chromaticity values, an sRGB rendering intent, an iCCP profile, or whatever is involved in mapping between RGB values and colors.

embedded object or image
An image that appears in-line in an APG datastream.

frame
A composition of zero or more layers that have zero interlayer delay time followed by a layer with a specified nonzero interlayer delay time or by the MEND chunk. A frame is to be displayed as a still picture or as part of a sequence of still images or an animation. An animation would ideally appear to a perfect observer (with an inhumanly fast visual system) as a sequence of still frames.

When the layers of a frame do not cover the entire area defined by the width and height fields from the MHDR chunk, the layers are composited over the previous frame to obtain the new frame, and any areas not covered by any layer are unchanged from the previous frame.

When the frame includes transparent pixels, such pixels are intended to be composited over the outside world. If the application does not have access to the outside world, then it can use data from an embedded object's bKGD chunk or it can choose its own background.

frame origin
The upper left corner of the output device (frame buffer, screen, window, page, etc.) where the pixels are to be displayed. This is the {0,0} position for the purpose of defining frame clipping boundaries, image locations, and image clipping boundaries. Note that in a windowing system, the frame origin might be moved offscreen, but the locations in DEFI and PLAY chunks would still be measured from this offscreen origin.

framing rate
The rate, measured in frames per second, at which frames are displayed on the output device. In an APG datastream, the framing rate is the interframe delay, in ticks, divided by the number of ticks per second, from the MHDR chunk.

frozen object
An object whose set of object attributes and whose object buffer are not allowed to be discarded, replaced, or modified.

image N or object N
Shorthand for "the object with the set of object attributes pointed to by `object_id=N'".

interframe delay
The amount of time a frame should be visible when a sequence of frames or an animation is played. In reality, it takes a nonzero amount of time to display a frame. No matter which moment is picked as the "start" of the frame, the interframe delay measures the time to the "start" of the next frame. Every frame has an interframe delay, including the frame that is displayed last; its delay is not really "interframe", nevertheless it is the amount of time that the frame should be visible before it is removed or replaced with something else. The interframe delay for a frame is the same as the (nonzero) interlayer delay of the final (top) layer of the layers constituting the frame.
interlayer delay
A time delay associated with a layer. A layer with a zero interlayer delay is combined with the subsequent layer or layers to form a frame; the frame is completed by a layer with a nonzero interframe delay or by the MEND chunk. That nonzero interlayer delay becomes the interframe delay of the frame.

iteration
One cycle of a loop. In this document, as is customary among computer programmers, the number of iterations of a loop includes the first cycle. A loop can have zero iterations, which means it is not executed at all.

layer
One of

Note that a layer can be completely empty if the image is entirely outside the clipping boundaries.

A layer can be thought of as a transparent rectangle with the same dimensions as the frame, with an image composited into it, or it can be thought of as a rectangle having the same dimensions (possibly zero) and location as those of the object after it has been located and clipped.

An embedded visible PNG or JNG datastream generates a single layer, even though it might be interlaced or progressive.

nullify
To nullify a chunk is to undo its effect, restoring the datastream to the condition it would have had if the chunk being nullified had never appeared.

object, object_id
An image. The object_id is an unsigned sixteen-bit number that serves as the identifier of a set of object attributes.

object attributes
Properties of an object such as its existence, compose mode, potential visibility, location, clipping boundaries, and a pointer to an object buffer. See Object attributes, below.

object buffer
A 2D array of pixels, each of which has color and transparency information. See Object buffers, below.

prologue segment
The first segment, when there is more than one segment, or the entire animation, if there is only one segment.

regular segment
Any segment other than the first (also the first segment, when there is only one).

segment
A part of an APG datastream starting with the MHDR chunk or with a NAME chunk and extending to just before the next NAME chunk (or the MEND chunk if there is no next NAME chunk). The MHDR, MEND, NAME, and TERM chunks are not considered to be a part of any segment.

signal
An entity with a number that can arrive asynchronously at the decoder. More detailed semantics, like whether multiple signals of the same number (or even different numbers) can be queued, are beyond the scope of this specification.

tick
A "tick" is the unit of time used for measuring interlayer and interframe delays and timeouts. It is defined by the ticks_per_second field of the MHDR chunk.

tile
A "tile" is a pixel array copied from an object and used in the PLAY chunk to construct a layer.

visible image
Actually drawn on a display. If an object is visible, a person looking at the display can see it.

3. Objects

An "object", which is identified by an object_id, is a PNG or JNG image. The object_id is an unsigned sixteen-bit number that serves as the identifier of a set of object attributes.

Object 0 is a special object whose pixel data is not available for later use (see below). Whenever an image is decoded into Object 0 or copied into Object 0, it is immediately output to the application for further processing outside the scope of this specification.

3.1. Embedded objects

An embedded object is:

3.2. Object attributes

Objects have object attributes that can be defined and modified by the contents of various APG chunks. Decoders are responsible for keeping track of them. Object attributes include:

Existence
A nonzero object comes into existence when

A nonzero object ceases to exist when it does not have the "frozen" attribute and

Object 0 always exists.
 

Compose mode

How an object or layer is to be composed against another object or layer. The default mode "over" and "replace" are permitted modes for composing layers, and "under" is also permitted for composing one object other than Object 0 over another. Also, "none" is permitted in an object or layer that has no transparent pixels, and would normally be handled as if it were "replace".

Pointer to an object buffer
Every object (except for Object 0) has an object buffer. The representation of a pointer is decided by the application; pointers never appear explicitly in an APG datastream. Decoders can also create an object buffer for Object 0, if that is more convenient, but the information in that buffer cannot be depended upon to exist after the image has been displayed, nor can that buffer become "frozen".

Frozen or not frozen
All objects are initially "not frozen". Any objects in existence (except for Object 0) when the SAVE chunk is encountered become "frozen", along with the object buffers that they point to.

Location
The X and Y location of an object is determined by the DEFI chunk that introduced it and can be modified by the PLAY chunk when a layer has "update_mode == 1". It is permitted to change the location of "frozen" objects, provided that the encoder includes a DEFI or PLAY chunk prior to the end of the segment that restores their locations to their "saved" positions.

Clipping boundaries
The clipping boundaries of an object are determined by the DEFI chunk that introduced it and can be modified by the PLAY chunk. It is permitted to change the clipping boundaries of "frozen" objects, provided that the encoder includes a DEFI chunk or PLAY chunk prior to the end of the segment that restores the boundaries to their "saved" values.

Additional information
While not required by this specification, applications may wish to store other information about the object, for error-checking or other purposes outside the scope of this specification.

3.3. Object buffers

An object buffer is created by the appearance of an embedded object in the datastream, with a nonzero object_id, or by the first layer created after the SNAP chunk begins recording. The contents of an object buffer can be modified by decoding a new embedded object with the same object_id or by creating a layer while the SNAP chunk is recording.

An object buffer contains a 2D array of pixel data and can contain additional information. In addition, decoders are responsible for keeping track of some properties of the data in the object buffer:

Object 0 conceptually never has an object buffer. Decoding applications can create one for their own convenience, but such an object buffer must never be made available to the rest of the APG datastream.

Format of data in the object buffer
The data can be stored by the decoder in its original form or in any form that is convenient, such as an X Window System "pixmap", even though that form might not have sufficient resolution for exact, lossless conversion. In the case of a PNG image, the pixels could be stored after the gamma and chromaticity corrections have been made, and the sample depth could be the same as the display hardware, even though it is smaller than the original sample depth. Similarly, a JNG image could be stored in the same form, after the pixels have been decoded, converted to RGB form, and gamma-corrected.

Frozen or not frozen
All object buffers are initially "not frozen". Any object buffers in existence when the SAVE chunk is encountered become "frozen". Decoders do not actually have to store this flag except as a sanity check, because they can depend on the fact that a "frozen" object buffer will always have at least one "frozen" object whose "buffer pointer" points to it.

3.4. Object 0

Object 0 is a special object that has a set of object attributes that control its compose mode, location, and clipping properties, but does not have an object buffer. Whenever an image is written into Object 0, a layer is created instead of an object buffer. The object attributes, which can be modified by the DEFI chunk, the PAST chunk or the PLAY chunk, are applied to subsequent embedded objects whose object_id is zero. The pixel data for Object 0 is available only for on-the-fly output to a layer and not available for later internal use. If at the end of any segment the attribute values are different from the default/saved values, they become undefined when a NAME chunk appears.

3.5. Embedded images

In addition to creating APG objects (see below, Paragraph 4.2.3), and (below, Paragraph 4.2.4), the IHDR-IEND and JHDR-IEND chunks display them when the DEFI chunk that introduced them set object_id to zero, to specify on-the-fly display.

A viewer can choose to display the image while it is being decoded, perhaps taking advantage of the PNG interlacing method or the JNG progressive display feature, or to display it after decoding is complete.

4. APG Chunks

This chapter describes chunks that can appear at the top level of an APG datastream.

Chunk structure (length, name, data, CRC) and the chunk-naming system are identical to those defined in the PNG specification [PNG]. As in PNG, all integers that require more than one byte must be in network byte order.

Unlike PNG, fields can be omitted from some APG chunks with a default value if omitted. This is permitted only when explicitly stated in the specification for the particular chunk. If a field is omitted, all the subsequent fields in the chunk must also be omitted and the chunk length must be shortened accordingly.

4.1. Critical APG control chunks

This section describes critical APG control chunks that APG-compliant decoders must recognize and process. "Processing" a chunk sometimes can consist of simply recognizing it and ignoring it. Some chunks have been declared to be critical only to prevent them from being relocated by APG editors.

4.1.1. MHDR APG datastream header

The MHDR chunk is always first in all APG datastreams except for those that consist of a single PNG or JNG datastream with an APG, PNG or JNG signature.

The MHDR chunk contains 12 bytes, none of which can be omitted:

   Frame_width:         4 bytes (unsigned integer).
   Frame_height:        4 bytes (unsigned integer).
   Ticks_per_second:    4 bytes (unsigned integer).

The frame_width and frame_height fields give the intended display size (measured in pixels) and provide default clipping boundaries (see Recommendations for encoders, below). It is strongly recommended that these be set to zero if the APG datastream contains no visible images.

The ticks_per_second field gives the unit used by the PLAY chunk to specify interlayer delay and timeout. It also provides the default framing rate to be used for displaying embedded objects on-the-fly. It must be nonzero if the datastream contains a sequence of images. When the datastream contains exactly one frame, this field should be set to zero. When this field is zero, the length of a tick is infinite, and decoders will ignore any attempt to define interlayer delay, interframe delay, timeout, or any other variable that depends on the length of a tick. If the frames are intended to be displayed one at a time under user control, such as a slide show or a multi-page FAX, the tick length can be set to any positive number and a PLAY chunk can be used to set an infinite interframe delay and a zero timeout. Unless the user intervenes, viewers will only display the first frame in the datastream.

When ticks_per_second is nonzero, and there is no other information available about interframe delay, viewers should display the sequence of frames at the rate of one frame per tick.

4.1.2. PLAY Playlist

The PLAY chunk contains a compressed "play list" that provides instructions to the decoder for constructing animation layers from pieces of previously defined objects. The PLAY chunk contains a 1-byte header followed by one or more 37-byte layer structures. The header gives the compression method:

      Compression_method (1 byte)    0: zlib.

      Layer_structure_array[n] (zlib compressed): layer structures.
                                     (n > 0; n * 37 bytes

Each layer is a tile composed over the previous layers according to the compose mode, to form a layer of the given dimensions and at location, clipped if necessary to fit inside the dimensions from the MHDR chunk.

The layer structure array is always compressed according to the specified compression method.

A layer is described by a structure of 37 bytes:

      Source_ID   (2 bytes unsigned int) Object ID of source image.
      Delta_mode  (1 byte unsigned int)  0: location and boundaries
                                            are absolute.
                                         1: location and boundaries
                                            are deltas from the
                                            object attributes.
      Update_mode (1 byte unsigned int)  0: Do not update the
                                            object attributes.
                                         1: Update object attributes.
      Compose_mode (1 byte unsigned int) 0: None
                                         1: Over
                                         2: Replace
      Left       (4 byte signed integer) Left of tile source.
      Top        (4 byte signed integer) Top of tile source.
      Right      (4 byte signed integer) Right of tile source.
      Bottom     (4 byte signed integer) Bottom of tile source.
      X_location (4 byte signed integer) X location of object
                                         destination.
      Y_location (4 byte signed integer) Y location of object
                                         destination.
      Delay    (4 byte unsigned integer) Interlayer delay.
      Timeout  (4 byte unsigned integer) Interlayer timeout.

The Source_ID must be non-zero. The tile is taken from the already existing object buffer as it exists when the PLAY chunk is encountered.

The stored values of the boundaries and location are taken from the DEFI chunk. These are used as the basis for computing current values to be used when delta_mode is 1, and the results, whether from a delta calculation or from supplied absolute values, are used to update the stored values when update_mode is 1.

The layer data identifies a rectangle (left,right, top,bottom) in the object containing pixels of a tile. The boundaries are measured from the upper left corner of the source object. The resulting rectangle is relocated to the position (x_location,y_location).

If the compose_mode is not "none", it takes precedence over any compose_mode associated with the souce objects.

Any part of the tile outside the object must be treated as transparent. Any part of the tile which extends outside the layer must be ignored. The tile width or height may be zero, in which case the layer contains no pixels, although it does contain an interlayer delay.

The location and clipping boundaries from the DEFI chunk for the object are used to initialize and store these values. These are used as the basis for computing current values to be used when delta_mode is 1, and the results, whether from a delta calculation or from supplied absolute values, are used to update the stored values in the object attributes when update_mode is 1.

The interlayer delay and timeout are measured in ticks_per_second from the MHDR chunk. Both values take precedence over the values from the DELA chunk. Even if a layer's tile is entirely outside the layer the layer has no pixels, but the delay of the resulting empty layer must be handled in the same way as if it were inside the frame.

A zero interlayer delay means that the frame is only partially constructed. A frame is not created until a layer with a non-zero interlayer delay is encountered. That non-zero delay becomes the interframe delay for that completed frame.

4.1.3. LOOP, ENDL Define a loop

The LOOP chunk provides a "shorthand" notation that can be used to avoid having to repeat identical chunks in an APG datastream. Its contents are the first two or more of the following fields. If any field is omitted, all subsequent fields must also be omitted:

   Nest_level:      1 byte (unsigned integer).
   Iteration_count: 4 bytes (unsigned integer),
                      range [0..2^31-1].
   Termination_condition:
                    1 byte (unsigned integer).
                      Must be omitted if
                      termination_condition=0, which
                      means Deterministic, not cacheable,
                      or if iteration_count=0.
                      1: Decoder discretion, not cacheable.
                      2: User discretion, not cacheable.
                      3: External signal, not cacheable.
                      4: Deterministic, cacheable.
                      5: Decoder discretion, cacheable.
                      6: User discretion, cacheable.
                      7: External signal, cacheable.
   Iteration_min:   4 bytes(unsigned integer).  Must be
                      present if termination_condition is
                      3 or 7.  If omitted, the default
                      value is 1.
   Iteration_max:   4 bytes (unsigned integer).  Must be
                      present if termination_condition is 3
                      or 7; must be omitted if iteration_min
                      is omitted; if omitted, the default
                      value is infinity.
   Signal_number:   4 bytes (unsigned integer).  Must be
                      present if termination_condition is 3
                      or 7.  Must not be present otherwise.
   Additional
     signal_number: 4 bytes.  May be present only if
                      termination_condition is 3 or 7.
   ...etc...

Decoders must treat the chunks enclosed in a loop exactly as if they had been repeatedly spelled out. The termination_condition field can be used to inform decoders that it is safe to change the number of loop iterations.

Simple decoders can ignore all fields except for the iteration_count.

When the LOOP chunk is present, an ENDL chunk with the same nest_level must be present later in the APG datastream. Loops can be nested. Each inner loop must have a higher value of nest_level than the loop that encloses it, though not necessarily exactly one greater.

The termination condition specifies how the actual number of iterations is determined. It can take the following values:

Deterministic
This is the default behavior, when the termination_condition field is omitted or has a value that is unrecognized by the decoder. The loop terminates after exactly the number of iterations specified by the iteration count. This value must be used if altering the number of repetitions would mess up the APG datastream, but can be used merely to preserve the author's intent.

Decoder-discretion
The number of iterations can be chosen by the decoder, and must not be less than iteration_min nor more than iteration_max. If the decoder has no reason to choose its own value, it should use the iteration_count. One example of a decoder wishing to choose its own value is a real-time streaming decoder hovering at a loop while waiting for its input buffer to fill to a comfortable level.

User-discretion
The number of iterations should be chosen by the user (e.g., by pressing the <escape> key), but the decoder must enforce the iteration_min and iteration_max limits. Some decoders might not be able to interact with the user, and many decoders will find that nested user-discretion loops present too great of a user-interface challenge, so the <user-discretion> condition will probably usually degenerate into the <decoder-discretion> condition.

External-signal
The number of iterations must not be less than iteration_min nor more than iteration_max. The exact number can be determined by the arrival of a signal whose number matches one of the signal_number fields.

When the value of the termination_condition field is 4 or more, the loop is guaranteed to be "cacheable", which means that each iteration of the loop produces the same sequence of frames, and that all objects and object buffers are left in the same condition at the end of each iteration. Decoders can use this information to select a different strategy for handling the loop, such as storing the composited frames in a cache and replaying them rather than decoding them repeatedly.

The iteration_min and iteration_max can be omitted. If the condition is <deterministic>, the values are not used. Otherwise, defaults of 1 and <infinity> are used. The iteration_count, iteration_min, and iteration_max can be any non-negative integers or <infinity>, but they must satisfy iteration_min <= iteration_count <= iteration_max. Infinity is represented by 0x7FFF FFFF.

If iteration_count is zero, the termination_condition, the subsequent fields must be omitted, and the loop is done zero times. Upon encountering a LOOP chunk whose iteration_count is zero, decoders simply skip chunks until the matching ENDL chunk is found, and resume processing with the chunk immediately following it.

The signal_number can be omitted only if the termination condition is not <external-signal>. There can be any number of signal_number fields. Signal_number=0 is reserved to represent any input from a keyboard or pointing device, and 1-255 are reserved to represent the corresponding character code, received from a keyboard or simulated keyboard, and values 256-1023 are reserved for future definition by this specification.

An infinite or just overly long loop could give the appearance of having locked up the machine. Therefore a decoder should always provide a simple method for users to escape out of a loop or delay, either by abandoning the APG entirely or just proceeding to the next NAME chunk (the NAME chunk makes it safe for a viewer to resume processing after it has jumped out of the interior of a segment).

APG editors that extract a series of PNG or JNG files from an APG datastream are expected to execute the loop only iteration_min times, when the termination condition is not <deterministic>.

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

   Nest_level: 1 byte (unsigned integer), range [0..255].

When the ENDL chunk is encountered, the loop iteration count is decremented, if it is not already zero. If the result is nonzero, processing resumes at the beginning of the loop. Otherwise processing resumes with the chunk immediately following the ENDL chunk.

When the ENDL chunk is present, a LOOP chunk with the same nest_level must be present earlier in the APG datastream. See below. Loops must be properly nested: if a LOOP chunk with higher nest_level appears inside a LOOP/ENDL pair, a matching ENDL chunk must also appear to close it.

The NAME chunk is not permitted inside a LOOP-ENDL pair. To rerun an entire datastream that includes these chunks, use the TERM chunk instead. See below (Paragraph 4.1.5).

4.1.4. DELA Interlayer delay

The DELA chunk provides the Interlayer delay and Timeout for subsequent layers (Object 0). It contains either 4 or 8 bytes:

  Interlayer delay: 4 bytes (unsigned integer) Delay,
                            in ticks.

  Timeout:          4 bytes (unsigned integer) Timeout,
                            in ticks.

Both numbers are a number of "ticks", where ticks is determined from the ticks_per_second field of the MHDR chunk.

A zero interlayer delay means that the frame is only partially constructed. A frame is not created until a layer with a non-zero interlayer delay is encountered. That non-zero delay becomes the interframe delay for that completed frame.

The timeout field can be a number or <infinity>. Infinity is represented by 0x7FFF FFFF. The timeout field is meaningless when the interframe delay is zero. When the interframe delay is nonzero, the timeout becomes the timeout for the entire frame. When the timeout for a frame is greater than the interframe delay, the application can adjust the interframe delay, provided that it is not greater than the greater of the specified interframe delay and the timeout nor smaller than the smaller of the specified interframe delay and the timeout. If the decoder can interact with the user, it should wait for permission from the user (e.g., via a keypress) before proceeding, but must wait no less than the smaller of the timeout and the interframe delay nor no longer than the greater of the timeout and the interframe delay.

If the DELA chunk is not present, the default interlayer delay and timeout are each 1 tick.

4.1.5. TERM Termination action

The TERM chunk suggests how the end of the APG datastream should be handled, when a MEND chunk is found. It contains either a single byte or ten bytes:

   Termination_action:      1 byte (unsigned integer)
                              0: Show the last frame
                                 indefinitely.
                              1: Cease displaying anything.
                              2: Show the first frame after
                                 the TERM chunk indefinitely.
                              3: Repeat the sequence starting
                                 immediately after the TERM
                                 chunk and ending with the
                                 MEND chunk.
   
   Action_after_iterations: 1 byte
                              0: Show the last frame
                                 indefinitely after
                                 iteration_max iterations
                                 have been done.
                              1: Cease displaying anything.
                              2: Show the first frame after
                                 the TERM chunk indefinitely.
   
                             This and the subsequent fields
                             must be present if
                             termination_action is 3, and
                             must be omitted otherwise.
   
   Delay:                  4 bytes (unsigned integer) Delay,
                             in ticks, before repeating the
                             sequence.
   
   Iteration_max:          4 bytes (unsigned integer) Maximum
                           number of times to execute the
                           sequence.  Infinity is represented
                           by 0x7FFF FFFF.

The final frame of the sequence endures at least for the maximum of:

before the sequence is repeated or before ceasing displaying anything.

If no TERM chunk is present, viewers should assume termination_action=0 as the default.

The loop created by processing a TERM chunk must always be treated by the decoder as if it were a cacheable <user-discretion> loop, with iteration_min=1.

Applications must not depend on anything that has been drawn on the output buffer or device during the previous iteration. Its contents become undefined when the TERM loop restarts.

APG editors that extract a series of PNG or JNG files from an APG datastream are expected to execute the TERM loop only once, rather than emitting the files repeatedly.

The TERM chunk, if present, may appear anywhere in or ahead of the prologue segment, and is not considered to be a part of any segment. Only one TERM chunk is permitted in an APG datastream.

Simple viewers and single-frame viewers can ignore the TERM chunk. It has been made critical only so APG editors will not inadvertently relocate it.

4.1.6. MEND End of APG datastream

The MEND chunk's data length is zero. It signifies the end of an APG datastream that began with the MHDR chunk. APG datastreams that begin with the IHDR or JHDR chunk are terminated by the IEND chunk instead.

4.2. Critical APG image defining chunks

The chunks described in this section create objects and may cause them to be immediately displayed.

4.2.1. DEFI Define an object

The DEFI chunk sets the default set of object attributes (object_id, location, and clipping boundaries) for any subsequent images that are defined with IHDR-IEND or JHDR-IEND datastreams.

The DEFI chunk contains 2, 3, 12, or 28 bytes. If any field is omitted, all subsequent fields must also be omitted.

   Object_id:     2 bytes (unsigned integer) identifier to be
                    given to the objects that follow the DEFI
                    chunk.
   
   Discard:       1 byte (unsigned integer)
                    0: no action
                    1: no action
                    2: discard this object's attribute set
                       and object buffer immediately.

   Compose_mode   1 byte (unsigned int)
                    0: None
                    1: Over
                    2: Replace
                    3: Under

   X_location:    4 bytes (signed integer).
                    The X_location and Y_location fields can
                    be omitted as a pair.
   
   Y_location:    4 bytes (signed integer).
   
   Left_cb:       4 bytes (signed integer).  Left clipping
                    boundary.  The left_cb, right_cb, top_cb,
                    and bottom_cb fields can be omitted as a
                    group.
   
   Right_cb:      4 bytes (signed integer).
   
   Top_cb:        4 bytes (signed integer).
   
   Bottom_cb:     4 bytes (signed integer).

If the object number for an object is nonzero, subsequent chunks can use this number to identify it.

When the object number for an object is zero, its object buffer can be discarded immediately after it has been processed. Its object attributes must be retained.

If fields are omitted, their values are as defined by a previous DEFI chunk, if that chunk is still in effect.

If no DEFI chunk is in effect (either because there is none in the datastream, or because a NAME chunk has caused it to be discarded), the decoder must use the following default values for any omitted fields:

                  Discard = 0
             Compose_mode = 0
               X location = 0
               Y location = 0
                  Left_cb = 0
                 Right_cb = frame_width
                   Top_cb = 0
                Bottom_cb = frame_height

The "Discard" byte can be used to inform the decoder that it can discard existing object data associated with the object identifier, and causes the object attributes to become undefined. Whether the decoder actually discards the data or not, it must not use it after encountering a DEFI chunk whose Discard byte is 1. It is an error to attempt to discard Object 0 or any "frozen" object in this manner.

The compose_mode is not permitted to be "under" for Object 0.

Negative values are permitted for the X and Y location and clipping boundaries. The left and top boundaries are inclusive, while the right and bottom boundaries are exclusive. The positive directions are downward and rightward from the frame origin (see Recommendations for encoders, below).

Multiple IHDR-IEND and JHDR-IEND objects can follow a single DEFI chunk. When object_id is nonzero, the DEFI chunk values remain in effect until another DEFI chunk or a NAME chunk appears. The object_id can only be changed by using another DEFI chunk.

The object attributes for all existing unfrozen objects except for object 0 become undefined when a NAME chunk is encountered, and their object buffers are no longer available and can be discarded..

The object attributes for Object 0 become undefined when a NAME chunk is encountered, only if they have been reset to values other than these defaults. It is the encoder's responsibility to reset them explicitly to these values prior to the end of every segment in which they have been changed, or to include a full DEFI chunk prior to embedding Object 0 in any segment.

These default values are also used to fill any fields that were omitted from the DEFI chunk, when an object with the same object_id has not been previously defined or a NAME chunk or a DEFI chunk has caused it to be discarded.

A set of object attributes is created or an existing one is modified when the DEFI chunk appears, but an object buffer is neither created nor discarded (unless the Discard byte causes it to be discarded). If object_id is an identifier that already exists when a DEFI chunk appears, the set of object attributes (except for the pointer to the object buffer) is immediately replaced. The contents of the object buffer do not change, however, until and unless an IHDR or JHDR chunk is encountered. When one of these chunks appears, all of the contents of the object buffer previously associated with the identifier are discarded and the new data is stored in the object buffer.

4.2.2. PLTE and tRNS Global palette

The PLTE chunk has the same format as a PNG PLTE chunk. It provides a global palette that is inherited by PNG datastreams that contain an empty PLTE chunk.

The tRNS chunk has the same format as a PNG tRNS chunk. It provides a global transparency array that is inherited along with the global palette by PNG datastreams that contain an empty PLTE chunk.

If a PNG datastream is present that does not contain an empty PLTE chunk, neither the global PLTE nor the global tRNS data is inherited by that datastream.

If the global PLTE chunk is not present, each indexed-color PNG in the datastream must supply its own PLTE (and tRNS, if it has transparency) chunks.

4.2.3. IHDR, PNG chunks, IEND

A PNG (Portable Network Graphics) datastream.

See the PNG specification [PNG] and the Extensions to the PNG Specification document [PNG-EXT] for the format of the PNG chunks.

The IHDR and IEND chunks and any chunks between them are written and decoded according to the PNG specification, except as extended in this section. These extensions do not apply to standalone PNG datastreams that have the PNG signature, but only to PNG datastreams that begin with the APG signature or are embedded in an APG datastream that begins with an APG signature.

If object_id is zero, there is no need to store the pixel data after decoding it and perhaps displaying it.

If an object already exists with the same object_id, the contents of its object buffer are replaced with the new data.

4.2.4. JHDR, JNG chunks, IEND

A JNG (JPEG Network Graphics) datastream.

See the JNG specification [JNG] for the format of the JNG datastream.

The JHDR and IEND chunks and any chunks between them are written and decoded according to the JNG specification.

The remaining discussion in the previous paragraph about PNG datastreams also applies to JNG datastreams.

4.2.5. SNAP Snapshot of current frame

[It has been proposed to eliminate this chunk because the "PAST" chunk can accomplish its purpose].

The SNAP chunk is useful for accomplishing the equivalent of the GIF "restore-to-previous" disposal method.

It has two fields

      Object_id  (16-bit unsigned int):  Existing object to be
                        used for storing image of frame
      Mode (byte)    0: Initialize object to transparent and start
                        recording offscreen copy of current frame
                        (including any background layers).
                     1: Stop recording.
                     2: Restart recording with existing contents.

The object_id must not be zero, must already have been the subject of a DEFI chunk and must still exist. The dimensions and location of the area to be recorded are specified in the DEFI chunk.

Each layer that is defined while the SNAP chunk is in recording mode is composited over whatever is in the object, or replaces it according to the "compose_mode" of the layer that is being generated. The "compose_mode" is from the DEFI chunk or from the PLAY or PAST chunk that generated the layer.

It is permitted to have more than one SNAP object open at the same time. The first SNAP chunk for each object in a segment must have mode 0, and the last SNAP chunk for each object in a segment must have mode 1.

Once a recording is completed (by the appearance of a SNAP chunk with mode == 1), the object_id can be used like any other defined object. It is an error to attempt to use the object_id as the source of any operation while recording is in progress.

4.2.6. PAST Paste an image into another Paste an image or images identified by source_id, or part of it, into an existing image identified by destination_id. The PAST chunk contains a 2-byte destination_id and 9 bytes giving a "target location", plus one or more 30-byte source data sequences.
   Target_id:         2 bytes (unsigned integer). The Destination ID.
   
   Target_delta_type: 1 byte (unsigned integer).
                        0:  Target_x and target_y are given directly.
                        1:  Target_x and target_y are deltas from their
                            previous values in a PAST chunk with the same
                            Target_id.
                        2:  Target_x and target_y are deltas from their
                            previous values in the previous PAST chunk
                            regardless of its destination_id.
   
   Target_x:        4 bytes (signed integer), measured rightward from the
                       left edge of the destination image.
   
   Target_y:        4 bytes (signed integer), measured downward from the
                       top edge of the destination image.
   
   Source_id:       2 bytes (unsigned nonzero integer).  An image to be
                       pasted in.
   
   Compose_mode:    1 byte (unsigned integer).
                      0:  None
                      1:  Over
                      2:  Replace
                      3:  Under
   
   Orientation:     1 byte (unsigned integer).
                       The source image is flipped to another orientation.
   
                      0:  Same as source image.
                      2:  Flipped left-right, then up-down.
                      4:  Flipped left-right.
                      6:  Flipped up-down.
                      8:  Tiled with source image.  The upper left corner of
                          the assembly is positioned according to the
                          prescribed offsets.
   
   Offset_origin:   1 byte (unsigned integer).
                      0: Offsets are measured from the {0,0} pixel in the
                         destination image.
                      1: Offsets are measured from the {target_x,target_y}
                         pixel in the destination image.
   
   X_offset:        4 bytes (signed integer).
   Y_offset:        4 bytes (signed integer).
   
   Boundary_origin: 1 byte (unsigned integer).
                      0: PAST clipping boundaries are measured from the
                         {0,0} pixel in the destination image.
                      1: PAST clipping boundaries are measured from the
                         {target_x,target_y} pixel in the destination image.
      
   Left_past_cb:    4 bytes (signed integer).
   Right_past_cb:   4 bytes (signed integer).
   Top_past_cb:     4 bytes (signed integer).
   Bottom_past_cb:  4 bytes (signed integer).
   ...etc...

The source images can have any color_type and sample_depth. The number of source images is ((chunk_length-11)/30).

The x_offset and y_offset distances and the PAST clipping boundaries are measured, in pixels, positive rightward and downward from either the {0,0} pixel of the destination image or the {target_x, target_y} position in the destination image. They do not necessarily have to fall within the destination image. Only those pixels of the source image that fall within the destination image and also within the specified clipping boundaries will be copied into the destination image. The coordinate system for offsets and clipping is with respect to the upper lefthand corner of the destination image, which is not necessarily the same coordinate system used by the DEFI chunk. If the source image has been flipped or rotated, X_offset and Y_offset give the location of its new upper left hand corner. When it is tiled, the offsets give the location of the upper left hand corner of the upper left tile, and tiling is done to the right and down. The PAST left and top clipping boundaries are inclusive, while the right and bottom clipping boundaries are exclusive (see Recommendations for encoders, below).

When compose_mode=0 (none), the compose_mode from the source object is used. If that is also 0, a default (replace) can be used.

When compose_mode=1 (over), any non-opaque pixels in the source image are combined with those of the destination image. If the destination pixel is also non-opaque, the resulting pixel will be non-opaque.

When compose_mode=2 (replace), all pixels simply replace those in the destination image. This mode can be used to make a transparent hole in an opaque image.

When compose_mode=3 (under), any non-opaque pixels in the destination image are combined with those of the source image. If the source pixel is also non-opaque, the resulting pixel will be non-opaque. When target_id=0, the resulting image is "write-only" and therefore this mode is not permitted. The compose_mode of the target object is not changed; it retains the value in its existing object attribute set.

The order of composition is the same as the order that the source_ids appear in the list (but a decoder can do the composition in any order it pleases, or all at once, provided that the resulting destination image is the same as if it had actually performed each composition in the specified order). Decoders must be careful when the destination image equals the source image--the pixels to be drawn are the ones that existed before the drawing operation began.

The clipping information from the DEFI chunks associated with the destination_id and the source_ids is not used in the PAST operation (but if a decoder is simultaneously updating and displaying the destination_id, the clipping boundaries for the destination_id are used in the display operation).

4.3. NAME Name a segment

The NAME separates the datastream into segments and names the segment that it begins.

The NAME chunk can be empty, or it can contain a segment name.

   Segment_name: 1-79 bytes (Latin-1 string).

The segment name is optional. It must follow the format of a tEXt keyword: It must consist only of printable Latin-1 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 keyword. There is no null byte terminator within the segment name, nor is there a separate null byte terminator. Segment names are case-sensitive. Use caution when printing or displaying keywords (Refer to Security considerations, below, Chapter 14). No specific use for the segment name is specified in this document, but applications can use the segment name for such purposes as constructing a menu of seek points for a slide-show viewer. It is recommended that the same name not appear in any other NAME chunk or in any eXPI chunk. Segment names should not begin with the case-insensitive strings "CLOCK(", "FRAME(", or "FRAMES(", which are reserved for use in URI queries and fragments (see Uniform Resource Identifier below).

The first NAME names the prologue segment.

The second NAME chunk completes the prologue segment and begins and names the next segment. It marks a point in the datastream at which objects are "frozen" and other chunk information is "saved". The NAME chunk marks positions in the APG datastream where a restart is possible, and where the decoder must restore the "saved" information, if they have jumped or skipped to a NAME point from the interior of a segment. They only need to restore information that they will use, e.g., a viewer that processes gAMA and global PLTE and tRNS, but ignores iCCP and sPLT, need only restore the value of gamma and the global PLTE and tRNS data from the prologue segment but not the values of the iCCP and sPLT data.

Subsequent NAME chunks complete a segment and begin and name the next segment.

Simple decoders that only read APG datastreams sequentially can safely ignore the NAME chunks, although it is recommended that, for efficient use of memory, they at least mark existing objects as "frozen" when the second NAME chunk is processed and discard all "unfrozen" objects whenever any NAME chunk is processed.

Applications must not use any information preceding the NAME chunk, except for:

They also must not depend on anything that has been drawn on the output buffer or device. Its contents become undefined when the NAME chunk is encountered. Viewers that make random access to a seek point from the interior of a segment must insert a background layer before processing the segment. Encoders must ensure that simple viewers do not need to do this. One simpole way of ensuring this is to make the first layer of a segment a full-frame transparent object with "compose_mode=replace".

When the NAME chunk is encountered, the decoder can discard any objects appearing after the second NAME chunk.

In addition to providing a mechanism for skipping frames or backspacing over frames, the NAME chunk provides a means of dealing with a corrupted datastream. The viewer would abandon processing and simply look for the next NAME chunk before resuming. Note that looking for a PNG IHDR chunk would not be sufficient because the PNG datastream might be inside a loop.

When a decoder jumps to a seek point from the interior of a segment, it must restore the information that it saved when it processed the second NAME chunk, and it must reset the object attributes for Object 0 to their default values. When it encounters a NAME chunk during normal sequential processing of an APG datastream, it need not restore anything, because the encoder will have written chunks that restore all saved information.

Multiple instances of the NAME chunk are permitted. The NAME chunk must not appear between a LOOP chunk and its ENDL chunk.

4.3.1. SAVE (obsolete)Save information

MOVE TO "NAME" It appears after the set of chunks that define information that must be retained for the remainder of the datastream. These chunks, collectively referred to as the prologue segment, are no different from chunks in other segments. They can be chunks that define objects, or they can be chunks that define other information such as gAMA, cHRM, and sPLT.

It is not permitted, at any point beyond the second NAME chunk, to modify or discard any object that was defined in the prologue segment, i.e., ahead of the second NAME chunk.

A chunk like gAMA that overwrites a single current value is permitted in any segment, even if the chunk has appeared in the prologue segment. Decoders are responsible for saving a copy of the chunk data (in any convenient form) when the second NAME chunk is encountered and restoring it when skipping or jumping to a NAME chunk from the interior of a segment. If no instance of the chunk appeared in the prologue segment, the decoder must restore the chunk data to its original "unknown" condition when it skips or jumps to any NAME chunk from the interior of a segment.

It is the encoder's responsibility, if it changes or discards any "saved" data, to restore it to its "saved" condition (or to nullify it, if it was unknown) prior to the end of the segment. This makes it safe for simple decoders to ignore the NAME mechanism.

Known chunks in this category include DEFI, PAST, PLTE, SNAP, cHRM, tRNS, gAMA, iCCP, bKGD, sBIT, pHYg, pHYs, and sRGB. In addition, it is the responsibility of the encoder to include chunks that restore the compose mode, location, and clipping boundaries of any "frozen" objects to their "saved" condition.

In the case of chunks like sPLT that can occur multiple times, with different "purpose" fields, additional instances of the chunk are permitted again after the NAME chunk, but not with the same keyword as any instances that occurred in the prologue segment. The decoder is required to forget such additional instances when it skips or jumps to a NAME chunk from the interior of a segment, but it must retain those instances that were defined prior to the second NAME chunk. Encoders are required to nullify such additional instances prior to the end of the segment. Known chunks in this category include only sPLT.

Applications with direct access to the datastream can use the segment names to create an index to find segments and exported images quickly. After processing the prologue segment, they can jump directly to any segment and then process the remaining datastream until the desired image or time is found. Applications that have only streaming access to the datastream can still use the index to decide whether to decode the chunks in a segment or to skip over them. only chunks not allowed ahead of the second NAME chunk is the MEND chunk. The NAME chunk must not appear inside a LOOP-ENDL pair.

4.3.1 iNAM Internationalized NAME

The iNAM chunk contains the same segment name as in the NAME chunk, except in an internationalized form.

The chunk contains

      Language tag   : 1 or more bytes (character string)
      Null separator : 1 byte
      Translated name: 0 or more bytes

The Language tag and the translated name follows the same rules as those for a the language tag and translated keyword in a PNG iTXt chunk.

The iNAM chunk must follow the associated iNAM chunk NAME chunk, and must appear before any layer is generated by the segment.

Multiple iNAM chunks, with different language tags, are allowed in a segment.

4.4. Ancillary APG chunks

This section describes ancillary APG chunks. APG-compliant decoders are not required to recognize and process them.

4.4.1. eXPI Export image

The eXPI chunk takes a snapshot of an object, associates the name with that snapshot, and makes the name available to the "outside world" (like a scripting language).

The chunk contains an object identifier (snapshot id) and a name:

   Snapshot_id:   2 bytes (unsigned integer).
   Snapshot_name: 1-79 bytes (Latin-1 text).

When the snapshot_id is zero, the snapshot is the first instance of an embedded image with object_id=0 following the eXPI chunk. When the snapshot_id is nonzero, the snapshot is an already-defined object with that object_id as it already exists when the eXPI chunk is encountered.

Note that the snapshot_name is associated with the snapshot, not with the snapshot_id nor its subsequent contents; changing the image identified by snapshot_id will not affect the snapshot. The snapshot_name means nothing inside the scope of the APG specification, except that it can be included in the optional index that can appear in the SAVE chunk. If two eXPI chunks use the same name, it is the outside world's problem (and the outside world's prerogative to regard it as an error). It is recommended, however, that the snapshot_name not be the same as that appearing in any other eXPI chunk or in any NAME chunk. A decoder that knows of no "outside world" can simply ignore the eXPI chunk. This chunk could be used in APG datastreams that define libraries of related images, rather than animations, to allow applications to extract images by their snapshot_id.

Names beginning with the word "thumbnail" are reserved for snapshot images that are intended to make good icons for the APG. Thumbnail images are regular PNG or JNG images, but they would normally have smaller dimensions and fewer colors than the APG frames. They can be defined with the potential visibility field set to "invisible" if they are not intended to be shown as a part of the regular display.

The snapshot_name string must follow the format of a tEXt keyword: It must consist only of printable Latin-1 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 keyword. Keywords are case-sensitive. There is no null byte terminator within the snapshot_name string, nor is there a separate null byte terminator. Snapshot names should not begin with the case-insensitive strings "CLOCK(", "FRAME(", or "FRAMES(" which are reserved for use in URI queries and fragments (see Uniform Resource Identifier below).

Multiple instances of the eXPI chunk are permitted in an APG datastream, and they need not have different values of snapshot_id.

4.4.2. pHYg Physical pixel size (global)

The APG pHYg chunk is identical in syntax to the PNG pHYs chunk. It applies to complete full-frame APG layers and not to the individual images within them.

Conceptually, an APG viewer that processes the pHYg chunk will first composite each image into a full-frame layer, then apply the pHYg scaling to the layer, and finally composite the scaled layer against the frame. APG datastreams can include both the PNG pHYs chunk (either at the APG top level or within the PNG and JNG datastreams) and the APG pHYg chunk (only at the APG top level), to ensure that the images are properly displayed either when displayed by an APG viewer or when extracted into a series of individual PNG or JNG datastreams and then displayed by a PNG or JNG application. The pHYs and pHYg chunks would normally contain the same values, but this is not necessary.

The APG top-level pHYg chunk can be nullified by a subsequent empty pHYg chunk appearing in the APG top level.

4.5. Ancillary PNG chunks

The namespace for APG chunk names is separate from that of PNG. Only those PNG chunks named in this paragraph are also defined at the APG top level. They have exactly the same syntax and semantics as when they appear in a PNG datastream:

5. Extension and Registration

New public chunk types, and additional options in existing public chunks, can be proposed for inclusion in this specification by contacting the PNG/APG specification maintainers at , or .

New public chunks and options will be registered only if they are of use to others and do not violate the design philosophy of PNG and APG. Chunk registration is not automatic, although it is the intent of the authors that it be straightforward when a new chunk of potentially wide application is needed. Note that the creation of new critical chunk types is discouraged unless absolutely necessary.

Applications can also use private chunk types to carry data that is not of interest to other applications.

Decoders must be prepared to encounter unrecognized public or private chunk type codes. If the unrecognized chunk is critical, then decoders should abandon the segment, and if it is ancillary they should simply ignore the chunk. Editors must handle them as described in the following section, Chunk Copying Rules.

6. Chunk Copying Rules

The chunk copying rules for APG are the same as those in PNG, except that an APG editor is not permitted to move unknown chunks across any of the following chunks, or across any critical chunk in a future version of this specification that creates or displays an image:

The copy-safe status of an unknown chunk is determined from the chunk name, just as in PNG. If bit 5 of the first byte of the name is 0 (Normally corresponding to an uppercase ASCII letter), the unknown chunk is critical and cannot be processed or copied. If it is 1 (usually corresponding to a lowercase ASCII letter), the unknown chunk is ancillary and its copy-safe status is determined by bit 5 of the fourth byte of the name, 0 meaning copy-unsafe and 1 meaning copy-safe.

If an editor makes changes to the APG datastream that render unknown chunks unsafe-to-copy, this does not affect the copy-safe status of any chunks beyond the next NAME chunk or prior to the previous one. However, if it makes such changes prior the second NAME chunk, this affects the copy-safe status of all top-level unknown chunks in the entire APG datastream.

Changes to the MHDR chunk do not affect the copy-safe status of any other chunk.

Changes to the data in the TERM chunk or the NAME chunks do not affect the copy-safe status of any other chunks. Adding or removing a NAME chunk affects the copy-safe status of unknown chunks in the newly-merged or newly-separated segments. Adding, removing, or changing the TERM chunk has no effect on the copy-safe status of any chunk.

As in PNG, unsafe-to-copy ancillary chunks in the top-level APG datastream can have ordering rules only with respect to critical chunks. Safe-to-copy ancillary chunks in the top-level APG datastream can have ordering rules only with respect to the NAME, PLAY, IHDR-IEND, JHDR-IEND sequences, or with respect to any other critical "header-end" sequence that might be defined in the future that could contain IDAT or similar chunks.

The copying rules for unknown chunks inside IHDR-IEND, and JHDR-IEND sequences are governed by the PNG and JNG specifications, and any changes inside such sequences have no effect on the copy-safe status of any top-level APG chunks.

7. Minimum Requirements for APG-Compliant Decoders

This section specifies the minimum level of support that is expected of APG-compliant decoders, and provides recommendations for viewers that will support slightly more than the minimum requirements. All critical chunks must be recognized, but some of them can be ignored after they have been read and recognized. Ancillary chunks can be ignored, and do not even have to be recognized.

Anything less than this level of support requires subsetting.

We are allowing conformant decoders to skip twelve-bit JNGs because those are likely to be rarely encountered and used only for special purposes.

7.1. Required APG chunk support

MHDR
The ticks_per_second must be supported by animation viewers.

MEND
The MEND chunk must be recognized but does not require any processing other than completing the last frame.

Global PLTE and tRNS
Must be fully supported.

LOOP, ENDL
The iteration_count must be supported. The nest_level should be used as a sanity check but is not required. When iteration_min=1 either explicitly or when it is omitted and the termination_condition is not 0 or 4, the LOOP chunk and its ENDL chunk can be ignored.

DEFI
Must be fully supported.

NAME
Must be recognized but can be ignored. However, partial support is recommended: All existing objects should be marked "frozen" when the second NAME chunk is processed, so that unneeded objects can be discarded when another NAME chunk is processed. Chunk information need only be "saved" and "restored" when the viewer is able to skip or jump to random NAME chunk locations from the interior of a segment, such as when recovering from a corrupted datastream or from a segment containing an unknown critical chunk, or when escaping from a deterministic loop in response to a user request. The optional index can be ignored. Slide-show controllers may wish to support the NAME chunk fully.

TERM
Must be recognized but can be ignored.

7.2. Required PNG chunk support

IHDR, PLTE, IDAT, IEND
All PNG critical chunks must be fully supported. All values of color_type, bit_depth, compression_method, filter_method and interlace_method must be supported. Interlacing, as in PNG, need not necessarily be displayed on-the-fly; the image can be displayed after it is fully decoded. The alpha-channel must be supported, at least to the degree that fully opaque pixels are opaque and fully transparent ones are transparent. It is recommended that alpha be fully supported.

tRNS
The PNG tRNS chunk, although it is an ancillary chunk, must be supported in APG-compliant viewers, at least to the degree that fully opaque pixels are opaque and fully transparent ones are transparent. It is required that alpha data from the tRNS chunk be supported in the same manner as alpha data from an RGBA image.

Other PNG ancillary chunks
Ancillary chunks other than PNG tRNS can be ignored, and do not even have to be recognized.

Color management
It is highly recommended that decoders support at least the gAMA chunk to allow platform-independent color rendering. If they support the gAMA chunk, they must also support the sRGB chunk, at least to the extent of interpreting it as if it were a gAMA chunk with gamma value 0.45455.

7.3. Required JNG chunk support

APG-compliant decoders must support JNG.
JHDR, JDAT, IDAT, JDAA, JSEP, IEND
All JNG critical chunks must be fully supported. All values of color_type, bit_depth, compression_method, filter_method and interlace_method must be supported. Interlacing, as in PNG, need not necessarily be displayed on-the-fly; the image can be displayed after it is fully decoded. The alpha-channel must be supported, at least to the degree that fully opaque pixels are opaque and fully transparent ones are transparent. It is recommended that alpha be fully supported.

JNG ancillary chunks
All JNG ancillary chunks can be ignored, and do not even have to be recognized.

JNG image sample depth
Only image_sample_depth=8 must be supported. The JSEP chunk must be recognized and must be used by minimal decoders to select the eight-bit version of the image, when both eight-bit and twelve-bit versions are present, as indicated by image_sample_depth=20 in the JHDR chunk. When image_sample_depth=12, minimal decoders are not obligated to display anything. Such decoders can choose to display nothing or an empty rectangle of the width and height specified in the JHDR chunk.

8. Recommendations for Encoders

The following recommendations do not form a part of the specification.

8.1. Use a common color space

It is a good idea to use a single color space for all of the layers in an animation, where speed and fluidity are more important than exact color rendition. This is best accomplished by defining a single color space at the top level of APG, using either an sRGB chunk or the gAMA and cHRM chunks and perhaps the iCCP chunk, and removing any color space chunks from the individual images after converting them to the common color space.

When the encoder converts all images to a single color space before putting them in the APG datastream, decoders can improve the speed and consistency of the display.

For single-frame and slide-show APG datastreams, however, decoding speed is less important and exact color rendition might be more important. Therefore, it is best to leave the images in their original color space, as recommended in the PNG specification, retaining the individual color space chunks if the images have different color spaces. This will avoid any loss of data due to conversion.

8.2. Embedded images in LOOPs

Embedded images should not be enclosed in loops unless absolutely necessary. It is better to store them ahead of time and then use PLAY chunks inside the loops.

8.3. Including optional index in SAVE chunk

Authors of APG files that are intended for transmission over a network should consider whether it is more economical for the client to rebuild the index from scratch than it is to transmit it. Web pages that are likely to be downloaded over slow lines, and whose clients are unlikely to use the index anyway, generally should have empty SAVE chunks. No information is lost by deleting the index, because the APG datastream contains all of the information needed to build the index. If an application does build an index, and the file is going to be kept as a local file, the application should replace the empty SAVE chunk with one containing the index. See above (Paragraph 4.3.1).

8.4. Interleaving JDAT, JDAA, and IDAT chunks

When a JNG datastream contains an alpha channel, and the file is intended for transmission over a network, it is useful to interleave the IDAT or JDAA and the JDAT chunks. In the case of sequential JPEG, the interleaving should be arranged so that the alpha data arrives more or less in sync with the color data for the scanlines. In the case of progressive JPEG, the alpha data should be interleaved with the first JPEG pass, so that all of the alpha data has arrived before the beginning of the second JPEG pass.

8.5. Use of the JDAA chunk

It is recommended that the JDAA chunk be used only to convey smoothly varying alpha channels and not to convey binary transparency which is more precisely and efficiently conveyed in IDAT chunks.

9. Recommendations for Decoders

9.1. ENDL without matching LOOP

If a decoder reads an ENDL chunk for which the matching LOOP chunk is missing, or has been skipped for some reason, any active loops with a higher nest_level should be terminated, and processing can resume after the next NAME chunk. Simple viewers that do not process the NAME chunk should abandon the APG datastream. See above.

9.2. Note on compositing

The PNG specification gives a good explanation of how to composite a partially transparent image over an opaque image, but things get more complicated when both images are partially transparent.

Pixels in PNG and JNG images are represented using gamma-encoded RGB (or gray) samples along with a linear alpha value. Alpha processing can only be performed on linear samples. This chapter assumes that R, G, B, and A values have all been converted to real numbers in the range [0..1], and that any gamma encoding has been undone.

For a top pixel {Rt,Gt,Bt,At} and a bottom pixel {Rb,Gb,Bb,Ab}, the composite pixel {Rc,Gc,Bc,Ac} is given by:

   Ac = 1 - (1 - At)(1 - Ab)
   if (Ac != 0) then
     s = At / Ac
     t = (1 - At) Ab / Ac
   else
     s = 0.0
     t = 1.0
   endif
   Rc = s Rt + t Rb
   Gc = s Gt + t Gb
   Bc = s Bt + t Bb

When the bottom pixel is fully opaque (Ab = 1.0), the function reduces to:

   Ac = 1
   Rc = At Rt + (1 - At) Rb
   Gc = At Gt + (1 - At) Gb
   Bc = At Bt + (1 - At) Bb

When the bottom pixel is not fully opaque, the function is much simpler if premultiplied alpha is used. A pixel that uses non-premultiplied alpha can be converted to premultiplied alpha by multiplying R, G, and B by A.

For a premultiplied top pixel {Rt,Gt,Bt,At} and a premultiplied bottom pixel {Rb,Gb,Bb,Ab}, the premultiplied composite pixel {Rc,Gc,Bc,Ac} is given by:

   Ac = 1 - (1 - At)(1 - Ab)
   Rc = Rt + (1 - At) Rb
   Gc = Gt + (1 - At) Gb
   Bc = Bt + (1 - At) Bb

As mentioned in the PNG specification, the equations become much simpler when no pixel has an alpha value other than 0.0 or 1.0, and the RGB samples need not be linear in that case.

9.3. Retaining object data

The decoder must retain information about each object (except for objects with object_id=0) for possible redisplay with the PLAY chunk.

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

When the encoder knows that data in the object buffer will not be needed later, it can help decoders operate more efficiently by using object_id=0 or by using the NAME chunk.

9.4. Decoder handling of fatal errors

When a fatal error is encountered, such as a bad CRC or an unknown critical APG chunk, minimal viewers that do not implement the NAME mechanism should simply abandon the APG datastream. More capable APG viewers should attempt to recover gracefully by abandoning processing of the segment and searching for a NAME chunk. If such errors occur before the second NAME chunk is reached, the viewer should abandon the APG datastream.

When an error occurs within a image datastream, such as an unknown critical PNG chunk or a missing parent object where one was required, only that image should be abandoned and the associated object should be discarded. If a bad CRC is found, indicating a corrupted datastream, the entire segment should be abandoned, as above.

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

9.5. Decoder handling of interlaced images

Decoders are required to be able to interpret datastreams that contain interlaced PNG images, but are only required to display the completed frames. They are not required to display the images as they evolve. Viewers that are decoding datastreams coming in over a slow communication link might want to do that, but APG authors should not assume that the frames will be displayed in other than their final form.

9.6. Decoder handling of palettes

When a PLTE chunk is received, it only affects the display of the PNG datastream that includes or inherits it. Decoders must take care that it does not retroactively affect anything that has already been decoded.

If a frame contains two or more images, the PLTE chunk in one image does not affect the display of the other.

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 top-level sPLT chunk with a suggested reduced global palette to help decoders build an appropriate palette when necessary.

9.7. Behavior of single-frame viewers

Viewers that can only display a single frame must display the first frame that they encounter.

9.8. Clipping

APG provides two types of clipping, in addition to any clipping that might be required due to the physical limitations of the display device.

Frame width and frame height
The frame_width and frame_height are defined in the MHDR chunk and cannot be changed by any other APG chunk.

Decoders can use these parameters to establish the size of a window in which to display the APG frames. When the frame_width or frame_height exceeds the physical dimensions of the display hardware, the contents of the area outside those dimensions is undefined. If a viewer chooses, it can create "scroll bars" or the like, to enable persons to pan and scroll to the offscreen portion of the frame. If this is done, then the viewer is responsible for maintaining and updating the offscreen portion of the frame.

In the case of an APG datastream that consists of only a PNG or JNG datastream, with the APG, PNG or JNG signature, the frame_width and frame_height are defined by the width and height fields of the IHDR (or JHDR) chunk.

Image clipping boundaries
The image clipping boundaries are defined in the DEFI chunk and can be changed by the PLAY chunk. They are associated with individual objects, not with the layers, and they can be changed within a seqence of layers. They are useful for exposing only a portion of an image in a frame, to achieve effects such as scrolling, panning, or gradual exposure.

The clipping boundaries are expressed in pixels, measured rightward and downward from the frame origin.

The left and top clipping boundaries are inclusive and the right and bottom clipping boundaries are exclusive, i.e., the pixel located at {x,y} is only displayed if the pixel falls within the physical limits of the display hardware and all of the following are true:

   0        <= x < frame_width  (from the MHDR chunk)
   0        <= y < frame_height
   Left_cb  <= x < right_cb     (from the DEFI chunk)
   Top_cb   <= y < bottom_cb

10. Recommendations for Editors

10.1. Editing datastreams with optional index

Editors must recreate or delete the optional SAVE chunk index whenever they make any change that affects the offsets of chunks following the portion of the datastream that is changed. If the changes do not involve the addition, deletion, or relocation of segments, frames, and images, then it is sufficient to zero out the offsets.

The SAVE chunk is not considered to be in any APG segment, so changing it has no effect on the copy-safe status of unknown chunks in any other part of the APG datastream.

When the SAVE chunk is expanded to include an index, all chunks that follow will have their offsets changed by an amount equal to the change in the length of the data segment of the SAVE chunk, so the offset table will have to be adjusted accordingly. If a SAVE chunk is already present with zero offsets, the correct offsets can be written without adjustment.

10.2. Handling LOOP and TERM chunks

Editors that create a series of PNG or JNG datastreams from an APG datastream should check the termination condition of any LOOP chunks and execute loops only iteration_min times. The loop created by the TERM chunk should be executed only once.

11. Miscellaneous Topics

11.1. File name extension

On systems where file names customarily include an extension signifying file type, the extension .apg is recommended for APG files. Lowercase .apg is preferred if file names are case-sensitive.

11.2. Internet media type

When and if the APG format becomes finalized, the APG authors intend to register video/apg as the Internet Media Type for APG [RFC-2045], [RFC-2048]. At the date of this document, the media type registration process had not been started. It is recommended that implementations also recognize the interim media type video/x-apg.

11.3. Uniform Resource Identifier (URI)

Segments and objects are externally accessible via named NAME and eXPI chunk names. They can be referred to by URI, as in

   SRC=file.apg#segment_name
   SRC=file.apg#snapshot_name
   SRC=file.apg?segment_name#segment_name
   SRC=file.apg?snapshot_name#snapshot_name

When the URI specializer ("#" or "?") is "#", and the fragment identifier (the string following the specializer) is the name of a segment, i.e., a named NAME chunk, the viewer should display the sequence from the beginning of the named segment up to the next segment. When it refers to an image, i.e., a named eXPI chunk, it should display the single image that is identified by the fragment identifier. The client can find the needed segment quickly if the SAVE chunk is present and contains the optional index.

When the URI specializer is "?" (server side query), the "query component" is the string following the "?" specializer and up to but not including the "#" if the "#" specializer is also present. The server should find the segment that is named in the query component or the segment that contains the image named in the query component, and it should return a datastream consisting of:

If a second NAME chunk is not present, the server must simply return the entire APG datastream. Servers that are unwilling to parse the APG datastream and are unconcerned about bandwidth can return the entire APG datastream even when the NAME chunk is present. Authors should defend against this behavior by including both a query and a fragment in the URI even when a segment is being requested.

The client can process this as a complete APG datastream, either displaying the entire segment, if no fragment identifier is present, or extracting the segment or image that is named in a fragment identifier and displaying it, if a fragment identifier is present (a fragment identifier must be present if an image is being requested).

A part of the APG datastream can also be requested by timecode, as in

   SRC=file.apg#clock(10s-20s)
   SRC=file.apg#clock(0:00-0:15)
   SRC=file.apg?clock(0:00-0:15)#clock(0:00-0:15)

or by frame number, as in

   SRC=file.apg#frame(10)
   SRC=file.apg#frames(30-60)
   SRC=file.apg?frames(30-60)#frames(30-60)

The timecode must consist of starting and ending clock values, as defined in the W3C SMIL recommendation, separated by a hyphen (ASCII code 45).

When the URI specializer is "#", the viewer should play that part of the sequence beginning and ending at the requested times, measuring from zero time at the beginning of the APG datastream, or beginning and ending with the specified frame numbers. To do this it must start with the segment containing the requested time and decode any part of the segment up to that time, composing but not displaying the frames. This will provide the background against which the desired frames are displayed.

When the URI specializer is "?", the server can send the entire APG datastream, or, preferably, it should construct a complete APG file containing:

The query component should always be repeated as a fragment identifier, so clients can find the requested item in case the server sends more than what was requested.

APG datastreams should not contain segment or image names that begin with the case-insensitive strings "CLOCK(", "FRAME(", or "FRAMES(", which are reserved for use in URI queries and fragments (see Uniform Resource Identifier below).

See [RFC-2396] and the W3C SMIL recommendation at http://www.w3.org/TR/.

12. Goals

13. Design Model

14. Rationale

14.1 dispose method

A GIF that uses "restore-to-previous" can be converted to an APG with a converter looking something like this:

      write MHDR
      write DEFI B
      write IHDR ... IEND (background image)
      write DEFI A compose=replace
      write SNAP A start
      previous_dispose = none
      for number of GIF images {
        if dispose==previous
          write SNAP A stop
        elseif previous_dispose==previous
          write SNAP A restart
        write DEFI 0
        write IHDR ... IEND (one scene converted to PNG)
        write PLAY 0, delay
        if (dispose == previous)
          write PLAY A with 0 delay
        if (dispose == back)
          write PLAY B with 0 delay
        previous_dispose = dispose
      }
      write MEND

15. Issues

16. Revision History

16.1. Version 0.1

Released 9 September 2007

16.2. Version 0.9

Released 17 October 2007

16.3. Version 0.91

Released 14 July 2010

16.4. Version 0.92

Released 27 June 2013

16.5. Version 0.93

Released 27 September 2015

16.6. Version 0.93.1

Released 28 September 2015

16.7. Version 0.93.2

Released 28 September 2015

16.8. Version 0.93.3

Released 28 September 2015

16.9. Version 0.94.1

Released 29 September 2015

16.10. Version 0.94.2

Released 29 September 2015

16.11. Version 0.94.3

Released 29 September 2015

16.12. Version 0.94.4

Released 30 September 2015

16.13. Version 0.94.5

Released 30 September 2015

16.14. Version 0.94.6

Released 1 October 2015

16.15. Version 0.94.7

Released 2 October 2015

16.16. Version 0.94.8

Released 5 October 2015

17. References

[ISO/IEC-10918-1]
International Organization for Standardization and International Electrotechnical Commission, "Digital Compression and Coding of Continuous-tone Still Images, Part 1: Requirements and guidelines," ISO/IEC IS 10918-1, ITU-T T.81.

See also Pennebaker, William B., and Joan L. Mitchell, "JPEG: Still Image Data Compression Standard," Van Nostrand Reinhold, ISBN:0442012721, September 1992

[JFIF]
C-Cube Microsystems, "JPEG File Interchange Format, Version 1.02," September 1992.

[JNG]
Randers-Pehrson, G., et al, "JNG (JPEG Network Graphics) Format,"
ftp://ftp.simplesystems.org/pub/png/documents/.

[LOCO]
Weinberger, Marcelo J., Gadiel Seroussi, and Guillermo Sapiro, "The LOCO-I Lossless Image Compression Algorithm: Principles and Standardization into JPEG-LS" Hewlett Packard Report HPL-98-193R1, November 1998, revised October 1999,, available at http://www.hpl.hp.com/loco/.

[MNG]
Randers-Pehrson, G., et al, "MNG (Multiple-image Network Graphics Format,"
ftp://ftp.simplesystems.org/pub/png/documents*.

[PNG]
Boutell, T., et. al., "PNG (Portable Network Graphics Format) Version 1.0," RFC 2083,
ftp://ftp.isi.edu/in-notes/rfc2083.txt also available at
ftp://ftp.simplesystems.org/pub/png/documents/. This specification has also been published as a W3C Recommendation, which is available at
http://www.w3.org/TR/REC-png.html.

See also the PNG-1.2 specification:
Randers-Pehrson, G., et. al., "PNG (Portable Network Graphics Format) Version 1.2," which is available at
ftp://ftp.simplesystems.org/pub/png/documents/.

[PNG-EXT]
Randers-Pehrson, G., et al, "Extensions to the PNG 1.2 Specification,"
ftp://ftp.simplesystems.org/pub/png/documents/pngext-*.

[RFC-2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119/BCP 14, Harvard University, March 1997.

[RFC-2045]
Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies," RFC 2045, Innosoft, First Virtual, November 1996.
ftp://ftp.isi.edu/in-notes/rfc2045.txt

[RFC-2048]
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures," RFC 2048, Innosoft, MCI, USC/Information Sciences Institute, November, 1996.
ftp://ftp.isi.edu/in-notes/rfc2048.txt

[RFC-2396]
Berners-Lee, T., R. Fielding, U. C. Irvine, and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 2396, MIT/LCS, Xerox Corporation, University of Minnesota, August 1998.
ftp://ftp.isi.edu/in-notes/rfc2396.txt

18. Security Considerations

Security considerations are addressed in the PNG specification.

An infinite or just overly long loop could give the appearance of having locked up the machine, as could an unreasonably long interframe delay or a long timeout value. Therefore a decoder should always provide a simple method for users to escape out of a loop or delay, either by abandoning the MNG entirely or just proceeding to the next NAME chunk. Decoders should check for user input after each loop iteration (not just after each frame) in case of infinite loops that are empty or that generate layers with zero interframe delay. The NAME chunk makes it safe for a viewer to resume processing after it encounters a corrupted portion of a MNG datastream or jumps out of the interior of a segment for any reason.

Some people may experience epileptic seizures when they are exposed to certain kinds of flashing lights or patterns that are common in everyday life. This can happen even if the person has never had any epileptic seizures. All graphics software and file formats that support animation and/or color cycling make it possible to encode effects that may induce an epileptic seizure in these individuals. It is the responsibility of authors and software publishers to issue appropriate warnings to the public in general and to animation creators in particular.

No known additional security concerns are raised by this format.

18. Credits

Acknowledgments

The following persons contributed to the development of the PLAY chunk or its predecessor, the proposed PNG aNIM chunk:

Thanks to the following person for carefully proofreading several versions of this document:

Trademarks

Copyright Notice

Copyright © 2015 by Glenn Randers-Pehrson

This specification is being provided by the copyright holder under the following license. By obtaining, using and/or copying this specification, you agree that you have read, understood, and will comply with the following terms and conditions:

Permission to use, copy, and distribute this specification for any purpose and without fee or royalty is hereby granted, provided that the full text of this NOTICE appears on ALL copies of the specification or portions thereof, including modifications, that you make.

THIS SPECIFICATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDER MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, COPYRIGHT HOLDER MAKES NO REPRESENTATIONS OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDER WILL BEAR NO LIABILITY FOR ANY USE OF THIS SPECIFICATION.

The name and trademarks of copyright holder may NOT be used in advertising or publicity pertaining to the specification without specific, written prior permission. Title to copyright in this specification and any associated documentation will at all times remain with copyright holder.

End of APG Specification.