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/.
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. Some chunks no longer have the
same syntax as the corresponding MNG-1.0 chunks and have therefore been
renamed; for example, MHDR has
become GHDR,
DEFI has
become DOBJ,
and SEEK-SAVE
have become NAME.
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.
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,
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 GHDR chunk and
ending with the GEND chunk. Each chunk consists of
a 4-byte data length field, a 4-byte chunk type code (e.g., "GHDR"), 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
GHDR and GEND 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:
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. Simple decoders can handle it as if it were
procedural, compositing the layers into a 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
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 DOBJ chunk's 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:
See also the glossary in the PNG specification.
When the
layers of a frame do not cover the entire area defined by the width and
height fields from the GHDR 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.
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.
An "object", which is identified by
an 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.
An embedded object is:
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:
A nonzero object ceases to exist when it does not have
the "frozen" attribute and
Object 0 always exists. How an object or layer is to be composed against another object
or layer. Compose_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". The default compose_mode,
if no chunk has defined it, is "over".
The stereo_mode of a frame can be "unknown", "none", "left", "right",
or "both". The "both" mode means that the object contains two side-by-side
images. The default stereo_mode, if no chunk has defined it, is "unknown".
What a player does with this information is beyond the scope of this
specification.
An object buffer is created by the appearance of an embedded object
in the datastream, with a nonzero 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.
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 DOBJ chunk, the
PAST chunk or the
PLAY chunk, are applied to subsequent
embedded objects whose 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 DOBJ chunk that introduced them
set 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.
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.
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.
The GHDR 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 GHDR chunk contains 12 bytes, none of which can be omitted:
The The When 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:
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
GHDR chunk.
The layer structure array is always compressed according to the specified
compression method.
A layer is described by a structure of 37 bytes:
The The stored values of the boundaries and location are taken from
the DOBJ 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 ( If the 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 DOBJ
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 The interlayer delay and timeout are measured in
The timeout is meaningless when the interlayer delay is zero. Otherwise,
it takes precedence over the timeout from
the FRME chunk without resetting
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.
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:
Decoders must treat the chunks enclosed in a loop exactly as if they
had been repeatedly spelled out.
The Simple decoders can ignore all fields except for the
When the LOOP chunk is present,
an ENDL chunk
with the same The termination condition specifies how the actual number of
iterations is determined. It can take the following
values:
When the value of the The If The 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 The ENDL
chunk ends a loop that begins
with the LOOP chunk. It contains a single one-byte field:
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 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).
The FRME chunk provides the Frame_delay
and Timeout for subsequent layers (Object 0). It contains 0, 4, 8, or 9
bytes:
Both Frame_delay and Timeout are a number of "ticks",
where If Timeout is omitted, the existing timeout remains unchanged. If
Frame_delay is also omitted, the Frame_delay also remains unchanged.
The timeout field can be a number or <infinity>. Infinity
is represented by 0x7FFF FFFF. The timeout becomes the timeout for the
entire frame.
When the timeout for a frame is greater than the frame_delay,
the application can adjust the frame_delay, provided that it is
not greater than the greater of the specified
frame_delay and the timeout nor smaller than the
smaller of the specified frame_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 frame
delay nor no longer than the greater of the timeout and the frame
delay.
The stereo_mode field can be supplied if the frames contain
stereo pairs. If stereo_mode is 1, the frames are not stereo. If it
is 2 or 3, each frame contains a stereo pair. The mode should be consistent
with the embedded sTER in the PNG or JNG object,
if one is present. If it is 4 or 5, frames following the
FRME chunk are in pairs of frames, either
in left-right order or right-left order. If stereo_mode is omitted,
the existing stereo_mode is not changed. The default stereo_mode, when
it has not been defined on the current or a prior FRME
chunk, is 0 ("unknown").
If the FRME chunk is not present, the default
frame_delay and timeout are each 1 tick and stereo_mode is "unknown".
The TERM chunk suggests how the end of the APG
datastream should be handled, when a GEND chunk
is found. It contains either a single byte or ten bytes:
The final frame of the sequence endures at least for
the maximum of:
If no TERM chunk is present, viewers should assume
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
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.
The GEND chunk's data length is zero.
It signifies the end
of an APG datastream that began with the GHDR chunk.
APG datastreams that begin with the IHDR
or JHDR chunk are
terminated by the IEND chunk instead.
The chunks described in this section create
objects and may cause them to be immediately displayed.
The DOBJ chunk sets the default set of object
attributes
( The DOBJ chunk contains 2, 3, 4, 12, or 28 bytes.
If any field is omitted, all subsequent fields must also be omitted.
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
DOBJ chunk, if that chunk is still in effect.
If no DOBJ 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:
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 DOBJ chunk
whose The The 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 DOBJ chunk.
When 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 DOBJ chunk
prior to embedding Object 0 in any segment.
These default values are also used to fill any fields that were omitted from
the DOBJ chunk, when an object with
the same A set of object attributes is created or an existing one is modified when
the DOBJ chunk appears, but an object buffer
is neither created nor discarded (unless the 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.
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.
The intrapixel differencing transformation, which is a modification of
a method previously used in the LOCO image format
[LOCO],
is
in which S0-S3 are the samples to be passed to the next stage of the
filtering procedure.
The transformation is done in integer arithmetic in sufficient
precision to hold intermediate results, and the result is calculated
modulo Conceptually, the basic filtering is done after the
intrapixel differencing transformation has been done for all pixels
involved in the basic filter, although in practice the operations can
be combined.
To recover the samples, the transformation is undone after
undoing the basic filtering, by the inverse of the intrapixel differencing
transformation, which inverse is
As in the forward transformation, the inverse
transformation is done
in integer arithmetic in sufficient precision to hold intermediate
results and the result calculated modulo
Applications that convert an APG datastream to a series of PNG
datastreams must convert any PNG datastream with the additional filter
method 64 to a standard PNG datastream with a PNG filter method
(currently 0 is the only valid filter method).
Applications must not write independent PNG datastreams with the PNG
signature and .png file extension with the new
filter method, until and unless it should become officially approved
for use in PNG datastreams. They may write independent PNG datastreams
with the APG signature and .apg file extension with the new filter
method.
Note that the top-level color space chunks are used only to supply
missing color space information to subsequent embedded PNG or JNG datastreams.
They do not have any effect on already-decoded objects.
If If an object already exists with the same 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.
The SNAP chunk is useful for accomplishing the
equivalent of the GIF "restore-to-previous" disposal method.
It has two fields
The 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 DOBJ
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
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 DOBJ 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 DOBJ 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).
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.
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 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.
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
DOBJ,
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 GEND chunk. The
NAME chunk must not appear inside
a LOOP-ENDL pair.
The iNAM chunk contains the same segment name as in the
NAME chunk, except in an internationalized form.
The chunk contains
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.
This section describes ancillary APG chunks. APG-compliant decoders
are not required to recognize and process them.
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:
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 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 Multiple instances of the eXPI chunk are permitted
in an APG datastream, and they need not have different values of
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.
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:
Same format as in PNG. The tIME chunk can appear
at most once in the prologue segment (before the
second NAME chunk), and at most
once per segment (between two consecutive NAME chunks).
In the prologue it indicates the last time any part of the APG was modified.
In a regular segment (between NAME chunks or between
the final
NAME chunk and the GEND chunk),
it indicates the last time that segment was modified.
An APG editor that writes PNG datastreams should not include
the top-level iTXt, tEXt,
tIME,
and zTXt chunks in the generated PNG datastreams.
These PNG chunks are also defined at the APG top level.
They provide default values to be used in case they are not provided in
subsequent PNG datastreams. Any of these chunks can be nullified by the
appearance of a subsequent empty chunk with the same chunk name. Such
empty chunks are not legal PNG or JNG chunks and must only appear in the
APG top level.
In the APG top level, all of these chunks are written
as though
for 16-bit RGBA PNG datastreams. Decoders are responsible for
reformatting the chunk data to suit the actual bit depth and color
type of the datastream that inherits them.
An APG editor that writes PNG or JNG datastreams is expected to
include the top-level cHRM, gAMA,
iCCP, and sRGB chunks in
the generated PNG or JNG datastreams, if
the embedded image does not contain its own chunks that define the
color space. It is also expected to write the pHYs
chunk and the reformatted
top-level bKGD chunk in the generated PNG or JNG
datastreams, and
the reformatted sBIT chunk only in generated PNG
datastreams, when
the datastream does not have its own bKGD,
pHYs, or sBIT chunks.
The top-level sRGB chunk nullifies the preceding
top-level gAMA and cHRM chunks,
if any, and
either the top-level gAMA or the top-level
cHRM chunk
nullifies the preceding top-level sRGB chunk, if any.
This PNG chunk is also defined at the APG top
level. It
provides a value that takes precedence over those that might be provided
in subsequent PNG or JNG datastreams and provides a value to be used
when it is not provided in subsequent PNG or JNG datastreams.
It also takes precedence over the
PLTE chunk in a subsequent PNG datastream when the
PLTE and hIST chunks are being used as a suggested
palette (i.e., When a decoder needs to choose between a suggested palette
defined at the APG level and a suggested palette defined in the PNG
datastream
(either with the sPLT chunk, or with the PLTE/hIST
chunks for grayscale or truecolor images), it should give precedence to
the palette from the APG level, to avoid spurious layer-to-layer color
changes.
APG editors that write PNG datastreams should ignore the
sPLT data from the APG level and simply copy
any sPLT chunks appearing within the embedded PNG
datastreams.
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
png-mng-misc at lists.sf.net,
or
png-group at w3.org.
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.
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 GHDR 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.
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.
The following recommendations do not form a part of the
specification.
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.
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.
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).
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.
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.
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
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:
When the bottom pixel is fully opaque (Ab = 1.0), the function
reduces to:
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:
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.
The decoder must retain information about each object (except for
objects with 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 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.
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.
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.
Viewers that can only display a single frame must display the first
frame that they encounter.
APG provides two
types of clipping, in addition to any clipping that
might be required due to the physical limitations of the display device.
Decoders can use these parameters to establish the size of
a window in which to display the APG frames. When the In the case of an APG datastream that consists of only a PNG or JNG
datastream, with the APG, PNG or JNG signature,
the
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:
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.
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 On systems where file names customarily include an extension
signifying file type, the extension When and if the APG format becomes finalized, the
APG authors intend to register Segments and objects are externally accessible via named
NAME and eXPI chunk names.
They can be referred to by URI, as in
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
or by frame number, as in
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/.
A GIF that uses "restore-to-previous" can be converted to
an APG with a converter looking something like this:
Released 9 September 2007
Released 17 October 2007
Released 14 July 2010
Released 27 June 2013
Released 27 September 2015
Released 28 September 2015
Released 28 September 2015
Released 28 September 2015
Released 29 September 2015
Released 29 September 2015
Released 29 September 2015
Released 30 September 2015
Released 30 September 2015
Released 1 October 2015
Released 2 October 2015
Released 5 October 2015
Released 6 October 2015
Released 10 October 2015
See also
Pennebaker, William B., and Joan L. Mitchell,
"JPEG: Still Image Data Compression Standard,"
Van Nostrand Reinhold, ISBN:0442012721, September 1992
See also the PNG-1.2 specification:
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
frame delay or a long
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.
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:
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.
Table of Contents
1. Introduction
http://www.libpng.org/pub/png/
or a standalone PNG datastream:
or a standalone JNG datastream:
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)
Discard
field.
dispose_to_previous method, can be losslessly converted to APG.
2. Terminology
object_id is
an unsigned sixteen-bit number that serves as the identifier of a set of
object attributes.
ticks_per_second field
of the GHDR chunk.
3. Objects
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.
3.1. Embedded objects
3.2. Object attributes
object_id
replaces it without an intervening DOBJ chunk.
In this case, the new object
inherits the set of object attributes from the previous object with the same
object_id.
3.3. Object buffers
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.
3.4. Object 0
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
object_id to zero, to specify on-the-fly display.
4. APG Chunks
4.1. Critical APG control chunks
4.1.1. GHDR APG datastream header
Frame_width: 4 bytes (unsigned integer).
Frame_height: 4 bytes (unsigned integer).
Ticks_per_second: 4 bytes (unsigned integer).
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.
ticks_per_second field gives the
unit used by the PLAY chunk to specify
frame delay and timeout.
This field also provides the default framing rate (1/ticks_per_second)
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 frame_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
frame_delay and a zero timeout. Unless the user intervenes, viewers
will only display the first frame in the datastream.
ticks_per_second is nonzero,
and there is no other information available about frame_delay,
viewers should display the sequence of frames at the rate of
one frame per tick.
4.1.2. PLAY Playlist
Compression_method (1 byte) 0: zlib.
Layer_structure_array[n] (zlib compressed): layer structures.
(n > 0; n * 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.
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.
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).
compose_mode is not "none", it takes
precedence over any compose_mode associated with the
souce objects.
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.
ticks_per_second from the
GHDR chunk.
When the interlayer delay is zero, it has the effect of temporarily setting
the object's layer_type to 1, taking precedence over the value from
the DOBJ chunk without resetting it,
meaning that the frame is only partially constructed.
When the interlayer delay is non-zero, it has the effect of temporarily
the object's layer_type to 0, taking precedence over the value from
the DOBJ chunk without resetting it, and
temporarily setting the frame_delay to the given value, taking precedence
over the value from the FRME chunk without resetting
it.
4.1.3. LOOP, ENDL Define a loop
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...
termination_condition field can be used to
inform decoders that it is safe to change the number of loop iterations.
iteration_count.
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.
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.
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.
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.
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.
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.
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.
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.
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.
iteration_min
times, when
the termination condition is not <deterministic>.
Nest_level: 1 byte (unsigned integer), range [0..255].
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.
4.1.4. FRME Frame attributes
Frame_delay: 4 bytes (unsigned integer) Frame delay,
in ticks.
Timeout: 4 bytes (unsigned integer) Timeout,
in ticks.
Stereo mode: 1 byte (unsigned integer)
0: unknown
1: none
2: both, left-right
3: both, right-left
4: alternating left,right frames
5: alternating right,left frames
ticks is determined from
the ticks_per_second field of the GHDR chunk.
4.1.5. TERM Termination action
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
GEND 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.
before the sequence is repeated or before ceasing displaying anything.
termination_action=0 as the default.
iteration_min=1.
4.1.6. GEND End of APG datastream
4.2. Critical APG image defining chunks
4.2.1. DOBJ Define an object
object_id, compose_mode, layer_type,
location, and clipping boundaries) for
any subsequent images that are defined with IHDR-IEND
or JHDR-IEND datastreams.
Object_id: 2 bytes (unsigned integer) identifier to be
given to the objects that follow the DOBJ
chunk.
Layer_type: 1 byte (unsigned integer)
0: top layer, completes the frame
1: intermediate layer
2: discard this object's attribute set
and object buffer immediately.
Compose_mode: 1 byte (unsigned integer)
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).
Compose_mode = 0
Layer_type = 0
X location = 0
Y location = 0
Left_cb = 0
Right_cb = frame_width
Top_cb = 0
Bottom_cb = frame_height
Discard byte is 1. It is an
error to attempt to discard Object 0 or any "frozen" object in this manner.
compose_mode is not permitted to be
"under" for Object 0.
interlayer_delay
from the PLAY chunk take precedence over this
value in Object 0 but does not reset it.
object_id is nonzero,
the DOBJ chunk values
remain in effect until another DOBJ chunk or
a NAME
chunk appears. The object_id
can only be changed by using another DOBJ chunk.
object_id
has not been previously defined or a NAME chunk or
a DOBJ chunk has caused it to be discarded.
Discard
byte causes it to be discarded). If object_id is
an identifier that already exists when
a DOBJ 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
4.2.3. IHDR, PNG chunks, IEND
64: Adaptive filtering with five basic types and
intrapixel differencing.
S0 = Red - Green (when color_type is 2 or 6)
S1 = Green (when color_type is 2 or 6)
S2 = Blue - Green (when color_type is 2 or 6)
S3 = Alpha (when color_type is 6)
2sample_depth.
Intrapixel differencing (subtracting the green
sample) is only done for color types 2 and 6, and only when the filter
method is 64. This filter method is not permitted in images with
color types other than 2 or 6.
Red = S0 + S1
Green = S1
Blue = S2 + S1
Alpha = S3
2sample_depth.
object_id is zero, there is no need to store the
pixel data after decoding it and perhaps displaying it.
object_id, the
contents of its object buffer are replaced with the new data.
4.2.4. JHDR, JNG chunks, IEND
4.2.5. SNAP Snapshot of current frame
[It has been proposed to eliminate this chunk because the "PAST" chunk
can accomplish its purpose].
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.
object_id must not be zero, must already
have been the subject of a DOBJ chunk and must still
exist. The dimensions and location of the area to be recorded are specified
in the DOBJ chunk.
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.
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.
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...
4.3. NAME Name a segment
Segment_name: 1-79 bytes (Latin-1 string).
4.3.1. SAVE (obsolete)Save information
4.3.1 iNAM Internationalized NAME
Language tag : 1 or more bytes (character string)
Null separator : 1 byte
Translated name: 0 or more bytes
4.4. Ancillary APG chunks
4.4.1. eXPI Export image
Snapshot_id: 2 bytes (unsigned integer).
Snapshot_name: 1-79 bytes (Latin-1 text).
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.
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).
snapshot_id.
4.4.2. pHYg Physical pixel size (global)
4.5. Ancillary PNG chunks
color_type != 3). This chunk can appear for
any color type. There can be multiple sPLT chunks in an APG
datastream. If a palette_name is repeated, the previous
palette having the same palette_name is replaced. It is
not permitted, at the APG top level, to redefine a palette after the
SAVE chunk with the same palette_name as one that
appears ahead of the SAVE chunk. It is permitted, however, to
define and redefine other palettes with other palette_name
fields. A single empty sPLT chunk can be used to nullify all
sPLT chunks that have been previously defined in the APG top
level, except for those that appeared ahead of the SAVE chunk,
when the SAVE chunk has been read.
5. Extension and Registration
6. Chunk Copying Rules
7. Minimum Requirements for APG-Compliant Decoders
7.1. Required APG chunk support
ticks_per_second must be supported by animation viewers.
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.
7.2. Required PNG chunk support
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.
7.3. Required JNG chunk support
APG-compliant decoders must support JNG.
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.
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
8.1. Use a common color space
8.2. Embedded images in LOOPs
8.3. Including optional index in SAVE chunk
8.4. Interleaving JDAT, JDAA, and IDAT chunks
8.5. Use of the JDAA chunk
9. Recommendations for Decoders
9.1. ENDL without matching LOOP
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
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
Ac = 1
Rc = At Rt + (1 - At) Rb
Gc = At Gt + (1 - At) Gb
Bc = At Bt + (1 - At) Bb
Ac = 1 - (1 - At)(1 - Ab)
Rc = Rt + (1 - At) Rb
Gc = Gt + (1 - At) Gb
Bc = Bt + (1 - At) Bb
9.3. Retaining object data
object_id=0) for possible redisplay with the
PLAY chunk.
object_id=0 or by using the
NAME chunk.
9.4. Decoder handling of fatal errors
9.5. Decoder handling of interlaced images
9.6. Decoder handling of palettes
9.7. Behavior of single-frame viewers
9.8. Clipping
frame_width and frame_height are defined in
the GHDR chunk and cannot be changed by any other APG chunk.
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.
frame_width
and frame_height are defined by
the width and
height fields of the
IHDR (or JHDR) chunk.
0 <= x < frame_width (from the GHDR chunk)
0 <= y < frame_height
Left_cb <= x < right_cb (from the DOBJ chunk)
Top_cb <= y < bottom_cb
10. Recommendations for Editors
10.1. Editing datastreams with optional index
10.2. Handling LOOP and TERM chunks
iteration_min times. The loop created by the TERM
chunk should be executed only once.
11. Miscellaneous Topics
11.1. File name extension
.apg is recommended for
APG files. Lowercase .apg is
preferred if file names are case-sensitive.
11.2. Internet media type
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)
SRC=file.apg#segment_name
SRC=file.apg#snapshot_name
SRC=file.apg?segment_name#segment_name
SRC=file.apg?snapshot_name#snapshot_name
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)
SRC=file.apg#frame(10)
SRC=file.apg#frames(30-60)
SRC=file.apg?frames(30-60)#frames(30-60)
12. Goals
13. Design Model
14. Rationale
14.1 dispose method
write "GHDR"
write "DOBJ B"
write "IHDR ... IEND" (background image)
write "DOBJ 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 "DOBJ 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 "GEND"
15. Issues
i.e., object 0 -> layers -> scene -> frame
"Canvas" is sometimes used, but maybe "scene" is a better word because
"canvas" seems to imply a scene that cannot be made transparent once painted
(composed over).
16. Revision History
16.1. Version 0.1
16.2. Version 0.9
16.3. Version 0.91
16.4. Version 0.92
16.5. Version 0.93
hidden byte.
16.6. Version 0.93.1
16.7. Version 0.93.2
16.8. Version 0.93.3
16.9. Version 0.94.1
16.10. Version 0.94.2
16.11. Version 0.94.3
16.12. Version 0.94.4
16.13. Version 0.94.5
16.14. Version 0.94.6
16.15. Version 0.94.7
16.16. Version 0.94.8
16.17. Version 0.94.9
16.18. Version 0.94.10
17. References
ftp://ftp.simplesystems.org/pub/png/documents/.
ftp://ftp.simplesystems.org/pub/png/documents*.
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.
Randers-Pehrson, G., et. al., "PNG (Portable Network Graphics
Format) Version 1.2," which is available at
ftp://ftp.simplesystems.org/pub/png/documents/.
ftp://ftp.simplesystems.org/pub/png/documents/pngext-*.
ftp://ftp.isi.edu/in-notes/rfc2045.txt
ftp://ftp.isi.edu/in-notes/rfc2048.txt
ftp://ftp.isi.edu/in-notes/rfc2396.txt
18. Security Considerations
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 a very small frame 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.
18. Credits
Acknowledgments
Trademarks
Copyright Notice
End of APG Specification.