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 AniPNG (Animated Portable Network Graphics) format. It proposes a file extension ".apg" and an Internet Media Type "video/apg".
The AniPNG 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.
AniPNG 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 AniPNG 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 RECO and PLAY chunks. The AniPNG format uses the same chunk structure that is defined in the PNG specification, and it shares other features of the PNG format. Any AniPNG decoder must be able to decode PNG and JNG datastreams.
If "231" looks like
the number "231"
instead of 2 raised to the power
31, your viewer is not
recognizing the HTML 4.0 <SUP> tag; you need
to look at the HTML 2.0, ASCII text, PDF, or PostScript
version of this document instead.
This specification defines the format of an AniPNG (Animated Portable Network 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 RECO chunks. The PNG, JNG, and MNG specifications are available at the PNG web site,
http://www.libpng.org/pub/png/
AniPNG 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 AniPNG 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).
An AniPNG 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 AniPNG datastream consists of:
AniPNG 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 interframe 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.
AniPNG is pronounced "ani-ping."
When an AniPNG 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 AniPNG 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 AniPNG employ the same mechanism as PNG, but with rules that are explained more fully (see below, Chapter 6). An AniPNG editor is not permitted to move unknown chunks across the SAVE and SEEK chunks, 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 AniPNG datastream or of any embedded object is an independent entity, i.e., no chunk is ever enclosed in the data segment of another chunk.
AniPNG-compliant decoders are required to recognize and decode independent PNG datastreams beginning with either the 8-byte PNG signature or with the 8-byte AniPNG signature, or JNG datastreams beginning with either the 8-byte JNG signature or with the 8-byte AniPNG signature,.
Most AniPNG datastreams are valid MNG-1.0 datastreams. MNG-1.0
decoders will not recognize the RECO
and PLAY chunks,
which were defined in 2007 and have not been registered by the PNG
Registration Authority, nor will they recognize the values 2 or 3
in the DEFI chunk's do_not_show
field.
Because the embedded objects making up an AniPNG are normally in PNG format, AniPNG shares the good features of PNG:
In addition it has these features of the MNG format:
dispose_to_previous method, can be losslessly converted to AniPNG.
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 MHDR chunk, the layers are composited over the previous frame to obtain the new frame.
When the frame includes a transparent background layer the transparent background is composited against the outside world and the subsequent layers are composited against the result to obtain the new frame. 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.
object_id is
an unsigned sixteen-bit number that serves as the identifier of a set of
object attributes.
do_not_show flag to zero or two,
for on-the-fly display while the embedded image that defines it is being
decoded.
do_not_show flag to zero or two.
ticks_per_second field
of the MHDR chunk.
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).
An embedded object is:
Objects have object attributes that can be defined and modified by the contents of various AniPNG 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_id
replaces it
without an intervening DEFI chunk. In this case,
the new object
inherits the set of object attributes from the previous object with the same
object_id.
Object 0 always exists.
do_not_show byte of the DEFI
chunk that introduced it. When an embedded object is
"potentially visible," it can be displayed "on-the-fly"
as it is being decoded.
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 RECO 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 RECO 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 AniPNG datastream.
Object 0 is a special object that has a set of object attributes
that control its location, clipping, and visibility properties,
but does not have
an object buffer. The object attributes, which can be modified by the
DEFI 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 display and not available for
later use.
If at the end of any segment the attribute values
are different from the default/saved values, they become undefined when
a SEEK chunk appears.
In addition to creating MNG 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 do_not_show
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.
This chapter describes chunks that can appear at the top level of an AniPNG 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 AniPNG 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 AniPNG control chunks that AniPNG-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 AniPNG editors.
The MHDR chunk is always first in all AniPNG datastreams except for those that consist of a single PNG or JNG datastream with an AniPNG, PNG or JNG signature.
The MHDR chunk contains 28 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). Nominal_layer_count: 4 bytes (unsigned integer). Nominal_frame_count: 4 bytes (unsigned integer). Nominal_play_time: 4 bytes (unsigned integer). Unused: 4 bytes (ignored).
Decoders can ignore the "informative"
nominal_frame_count,
nominal_layer_count,
and nominal_play_time fields.
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 AniPNG datastream contains no visible images.
The ticks_per_second field gives the
unit used by the PLAY chunk to specify
interframe delay and timeout.
It also provides the 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 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.
If the frame count field contains a zero, the frame
count is unspecified. If it is nonzero, it contains the number
of frames that would be displayed, ignoring the
TERM chunk. If the frame count is greater
than 231-1,
encoders should write 231-1 (0x7FFF FFFF),
representing an infinite frame count.
If the nominal_layer_count field contains a zero,
the layer
count is unspecified. If it is nonzero, it contains the number of
layers, including all background layers,
when the file is displayed ignoring the TERM chunk.
If the layer count is greater than 231-1,
encoders should
write 231-1, representing an infinite
layer count.
If the nominal_play_time field contains a zero, the
nominal play time is unspecified. Otherwise, it gives the play time,
in ticks, when the file is displayed ignoring the TERM
chunk.
Authors who write this field should choose a
value of ticks_per_second that will allow the nominal play time
to be expressed in a four-byte integer. If the nominal play time is greater
than 231-1 ticks, encoders should
write 231-1,
representing an infinite nominal play time.
The final four bytes of the MHDR chunk are unused. They are present for compatibility with MNG-1.0 decoders, and must be ignored by AniPNG decoders. AniPNG encoders should write the 32-bit unsigned integer "2015" in this field to indicate that any AniPNG features might be present, or "991" if the PLAY and RECO chunks are not present. If they wish, they may write any other appropriate MNG-1.0 "simplicity profile" as defined in the MNG-1.0 specification [MNG], but this is not required.
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 38-byte layer structures. The header gives the compression method:
Compression_method (1 byte) 0: deflate.
Layer_structure_array[n] (n > 0; n * 38 bytes
(compressed): layer structures.
Each layer is a tile combined with a transparent background to form a layer of size (frame_width, frame_height), from the MHDR chunk. Each layer is initialized to a transparent (RGBA(0,0,0,0)) rectangle
The layer structure array is always compressed according to the specified compression method.
A layer is described by a structure of 38 bytes:
Object (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 DEFI
values for the object.
Update mode (1 byte unsigned int) 0: Do not update DEFI
values of location and
boundaries.
1: Update DEFI values.
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) Interframe delay.
Timeout (4 byte unsigned integer) Interframe timeout.
Compose mode (1 byte unsigned int) 0: Over
1: Replace
Dispose mode (1 byte unsigned int) 0: None
1: Restore to background
2: Restore to previous
If the object_id is non-zero, the tile is taken
from the already existing object buffer as it exists when
the PLAY chunk is encountered. If it is
zero, the tile is taken from the next instance of Object 0 following the
PLAY chunk. If any layer of the playlist refers to
Object 0, all of
the layers in the playlist must refer to Object 0, and all of them are
taken from the single immediately following instance of Object 0.
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).
and composed against the existing frame according to the
compose_mode.
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.
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 delay is measured in ticks_per_second from
the MHDR chunk.
Even if a layer's tile is entirely outside the layer, the delay for the
resulting empty layer must be handled in the same way as if it were
inside the frame.
The timeout field can be a number or <infinity>. Infinity is represented by 0x7FFF FFFF. When the delay is nonzero and the timeout 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.
After the interframe delay or timeout has elapsed, the layer is
either left in place, replaced with the background, or restored to its
previous condition, before proceeding to the next layer, according to
its dispose mode
A playlist containing references to both Object 0 and a non-zero object, and two or more PLAY chunks referring to the same instance of Object 0 are error conditions, and decoders must reject such PLAY chunks.
The LOOP chunk provides a "shorthand" notation that can be used to avoid having to repeat identical chunks in an AniPNG 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 AniPNG
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:
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 AniPNG 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.
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 AniPNG entirely or just proceeding to the next SEEK chunk (the SEEK chunk makes it safe for a viewer to resume processing after it has jumped out of the interior of a segment).
AniPNG editors that extract a series of PNG or JNG files from an AniPNG
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 AniPNG
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 SAVE and SEEK chunks are 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.4).
The TERM chunk suggests how the end of the AniPNG 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:
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.
AniPNG editors that extract a series of PNG or JNG files from an AniPNG datastream are expected to execute the TERM loop only once, rather than emitting the files repeatedly.
The TERM chunk, if present, must appear either immediately after the MHDR chunk or immediately prior to a SEEK chunk. The TERM chunk is not considered to be a part of any segment for the purpose of determining the copy-safe status of any chunk. Only one TERM chunk is permitted in an AniPNG datastream.
Simple viewers and single-frame viewers can ignore the TERM chunk. It has been made critical only so AniPNG editors will not inadvertently relocate it.
The MEND chunk's data length is zero. It signifies the end of an AniPNG datastream that began with the MHDR chunk. AniPNG 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 DEFI chunk sets the default set of object
attributes
(object_id, do_not_show flag,
location, and clipping boundaries) for
any subsequent images that are defined with IHDR-IEND
or JHDR-IEND datastreams.
The DEFI chunk contains 2, 3, 4, 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.
Do_not_show: 1 byte (unsigned integer)
0: Make the existing object and
the following objects potentially
visible.
1: Make the existing object and
the following objects not
potentially visible.
2: Discard existing object; make the
following objects potentially
visible.
3: Discard existing object; make the
following objects not potentially
visible.
Concrete_flag: 1 byte (unsigned integer)
0: Make the objects "abstract" .
AniPNG decoders can ignore this flag.
AniPNG encoders should write "0".
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 class=cn>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 SEEK chunk has caused it to be discarded), the decoder must use the following default values for any omitted fields:
Do_not_show = 0
Concrete_flag = 0
X location = 0
Y location = 0
Left_cb = 0
Right_cb = frame_width
Top_cb = 0
Bottom_cb = frame_height
The do_not_show byte can be used to inform the decoder that it
can discard existing object data associated with the object identifier,
but does not cause 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 do_not_show byte is 2 or 3. It is an
error to attempt to discard Object 0 or any "frozen" object in this manner.
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 SEEK
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 SEEK chunk is encountered.
The object attributes for Object 0 become undefined when a SEEK 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 SEEK 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.
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.
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 AniPNG signature or are embedded in an AniPNG datastream that begins with an AniPNG signature.
64: Adaptive filtering with five basic types and
intrapixel differencing.
The intrapixel differencing transformation, which is a modification of a method previously used in the LOCO image format [LOCO], is
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)
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 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.
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
Red = S0 + S1 Green = S1 Blue = S2 + S1 Alpha = S3
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
2sample_depth.
Applications that convert an AniPNG 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 AniPNG signature and .mng 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 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.
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.
This chunk is currently not a registered MNG chunk. Registration is being pursued with the PNG Registration Authority. In the meantime, the private form of the chunk name (RECO, with a lowercase "e"), must be used in any public datastreams. 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 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 RECO chunk is in recording mode is composited over whatever is in the object.
It is permitted to have more than one RECO object open at the same time. The first RECO chunk for each object in a segment must have mode 0, and the last RECO chunk for each object in a segment must have mode 1.
Once a recording is completed (by the appearance of a
RECO 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.
The SAVE chunk marks a point in the datastream at which objects are "frozen" and other chunk information is "saved". The SEEK chunk marks positions in the AniPNG datastream where a restart is possible, and where the decoder must restore the "saved" information, if they have jumped or skipped to a SEEK 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.
Simple decoders that only read AniPNG datastreams sequentially can safely ignore the SAVE and SEEK chunks, although it is recommended that, for efficient use of memory, they at least mark existing objects as "frozen" when the SAVE chunk is processed and discard all "unfrozen" objects whenever the SEEK chunk is processed.
The SAVE chunk marks a point in the datastream at which objects are "frozen" and other chunk information is "saved"; a decoder skipping or jumping to a SEEK chunk from the interior of a segment must restore the "saved" chunk information if it has been redefined or discarded. In addition, the SAVE chunk can contain an optional index to the AniPNG datastream.
The SAVE chunk can be empty, or it can contain an index consisting of the following:
Offset_size: 1 byte (unsigned integer).
4: Offsets and nominal start times are
expressed as 32-bit integers.
8: Offsets and nominal start times are
expressed as 64-bit integers.
plus zero or more of the following index entries:
Entry_type: 1 byte (unsigned integer).
0: Segment with nominal start time, nominal
layer number, and nominal frame number.
1: Segment.
2: Subframe.
3: Exported image.
Offset: 4 or 8 bytes (unsigned integer). Must be
omitted if entry_type > 1, set equal to zero
if the offset is unknown.
Nominal_start_time:
4 or 8 bytes: (unsigned integer). Start time
of the segment, measured in ticks from the
beginning of the sequence, assuming that all
prior segments were played as intended on an
ideal player. Must be omitted if
entry_type > 0.
Nominal_layer_number:
4 bytes (unsigned integer). Sequence number of
the first layer in the segment, assuming
that all prior segments were played as
intended on an ideal player; the first layer
of the first segment being layer 0. Must be
omitted if entry_type > 0.
Nominal_frame_number:
4 bytes (unsigned integer). Sequence number of
the first frame in the segment, assuming
that all prior segments were played as
intended on an ideal player; the first
frame of the first segment being frame 0.
Must be omitted if entry_type > 0.
Name: 1-79 bytes (Latin-1 text). Must be omitted
for unnamed segments. The contents of this
field must be the same as the name field in
the corresponding SEEK or eXPI chunk.
Separator: 1 byte (null) (must be omitted after the final
entry).
The SAVE chunk must be present when the SEEK chunk is present. 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. If any chunks appear between the SAVE chunk and the first SEEK chunk, these chunks also form a part of the prologue segment, but their contents become undefined when the SEEK chunk appears.
Only one instance of the SAVE chunk is permitted in an AniPNG datastream. It is not allowed anywhere after the first SEEK chunk.
It is not permitted, at any point beyond the SAVE chunk, to modify or discard any object that was defined ahead of the SAVE chunk.
A chunk like gAMA that overwrites a single current value is permitted after the SAVE chunk, even if the chunk has appeared ahead of the SAVE chunk. Decoders are responsible for saving a copy of the chunk data (in any convenient form) when the SAVE chunk is encountered and restoring it when skipping or jumping to a SEEK chunk from the interior of a segment. If no instance of the chunk appeared ahead of the SAVE chunk, the decoder must restore the chunk data to its original "unknown" condition when it skips or jumps to a SEEK 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 SAVE/SEEK mechanism.
Known chunks in this category include DEFI, PLTE, 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 potential visibility, 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 after the SAVE chunk, but not with the same keyword as any instances that occurred ahead of the SAVE chunk. The decoder is required to forget such additional instances when it skips or jumps to a SEEK chunk from the interior of a segment, but it must retain those instances that were defined prior to the SAVE chunk. Encoders are required to nullify such additional instances prior to the end of the segment. Known chunks in this category include only sPLT.
If an entry for a segment (entry type 0 or 1) appears in the optional index, there must also be an entry for every segment, whether named or not, except for the prologue segment, that precedes it. All entries must appear in the index in the same order that they appear in the AniPNG datastream. There must never be a segment entry (type 0 or 1) for the prologue segment, but there can be entries for named images in the prologue, placed ahead of the first segment entry. Only named images are permitted, and it is not an error to omit any or all named images. Nor is it an error to omit a contiguous set of segments at the end of the datastream from the index.
Offsets are calculated from the first byte of the AniPNG 8-byte signature, which has offset=0. This is true even if the AniPNG datastream happens to be embedded in some other file and the signature bytes are not actually present.
Applications with direct access to the datastream can use the 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 one instance of the SAVE chunk is permitted in an AniPNG datastream. If the SEEK chunk is present, the SAVE chunk must be present, prior to the first SEEK chunk. The only chunks not allowed ahead of the SAVE chunk are the SEEK chunk and the MEND chunk. The SAVE chunk must not appear inside a LOOP-ENDL pair.
The SEEK chunk marks positions ("seek points") in the AniPNG datastream where a restart is possible, and where the decoder must restore certain information to the condition that existed when the SAVE chunk was processed, if it has skipped or jumped to the SEEK chunk from the interior of a segment.
The SEEK 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 can be included in the optional index that can appear in the SAVE chunk. It is recommended that the same name not appear in any other SEEK 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).
Applications must not use any information preceding the SEEK 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 SEEK 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.
When the SEEK chunk is encountered, the decoder can discard any objects appearing after the SAVE chunk.
In addition to providing a mechanism for skipping frames or backspacing over frames, the SEEK chunk provides a means of dealing with a corrupted datastream. The viewer would abandon processing and simply look for the next SEEK 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 SAVE chunk, and it must reset the object attributes for Object 0 to their default values. When it encounters a SEEK chunk during normal sequential processing of an AniPNG datastream, it need not restore anything, because the encoder will have written chunks that restore all saved information.
Multiple instances of the SEEK chunk are permitted. The SEEK chunk must not appear prior to the SAVE chunk. The SAVE chunk must also be present if the SEEK chunk is present. The SEEK chunk must not appear between a LOOP chunk and its ENDL chunk.
This section describes ancillary AniPNG chunks. AniPNG-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:
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
AniPNG 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 SEEK
chunk. A decoder that knows of no
"outside world" can simply ignore the eXPI chunk. This
chunk could be used in AniPNG 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 AniPNG. Thumbnail images are regular PNG or JNG images, but they would normally have smaller dimensions and fewer colors than the AniPNG 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 AniPNG datastream, and they need not have different values of
snapshot_id.
The AniPNG pHYg chunk is identical in syntax to the PNG pHYs chunk. It applies to complete full-frame AniPNG layers and not to the individual images within them.
Conceptually, an AniPNG 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. AniPNG datastreams can include both the PNG pHYs chunk (either at the AniPNG top level or within the PNG and JNG datastreams) and the AniPNG pHYg chunk (only at the AniPNG top level), to ensure that the images are properly displayed either when displayed by an AniPNG 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 AniPNG top-level pHYg chunk can be nullified by a subsequent empty pHYg chunk appearing in the AniPNG top level.
The namespace for AniPNG chunk names is separate from that of PNG. Only those PNG chunks named in this paragraph are also defined at the AniPNG 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 an appear at most once in the prologue segment (before the first SEEK chunk), and at most once per segment (between two consecutive SEEK chunks). In the prologue it indicates the last time any part of the AniPNG was modified. In a regular segment (between SEEK chunks or between the final SEEK chunk and the MEND chunk), it indicates the last time that segment was modified.
An AniPNG 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 AniPNG 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 AniPNG top level.
In the AniPNG 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 AniPNG 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 AniPNG 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., color_type != 3). This chunk can appear for
any color type. There can be multiple sPLT chunks in an AniPNG
datastream. If a palette_name is repeated, the previous
palette having the same palette_name is replaced. It is
not permitted, at the AniPNG 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 AniPNG top
level, except for those that appeared ahead of the SAVE chunk,
when the SAVE chunk has been read.
When a decoder needs to choose between a suggested palette defined at the AniPNG 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 AniPNG level, to avoid spurious layer-to-layer color changes.
AniPNG editors that write PNG datastreams should ignore the sPLT data from the AniPNG 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/AniPNG 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 AniPNG. 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 AniPNG are the same as those in PNG, except that an AniPNG 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 AniPNG datastream that render unknown chunks unsafe-to-copy, this does not affect the copy-safe status of any chunks beyond the next SEEK chunk or prior to the previous one. However, if it makes such changes prior the SAVE chunk, this affects the copy-safe status of all top-level unknown chunks in the entire AniPNG datastream.
Changes to the MHDR chunk do not affect the copy-safe status of any other chunk.
The SAVE, SEEK, and TERM chunks are not considered to be a part of any segment. Changes to the data in the SAVE or SEEK chunks do not affect the copy-safe status of any other chunks. Adding or removing a SEEK 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 AniPNG datastream can have ordering rules only with respect to critical chunks. Safe-to-copy ancillary chunks in the top-level AniPNG datastream can have ordering rules only with respect to the SAVE, SEEK, 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 AniPNG chunks.
This section specifies the minimum level of support that is expected of AniPNG-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.
ticks_per_second must be supported by animation viewers.
The frame count, layer count, and nominal play time can be ignored.
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.
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.
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.
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 AniPNG, 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 AniPNG datastream, decoders can improve the speed and consistency of the display.
For single-frame and slide-show AniPNG 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 AniPNG 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 AniPNG 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 nest_level should be terminated,
and processing can resume after the next SEEK chunk. Simple
viewers that do not process the SAVE chunk should abandon the
AniPNG datastream. See above.
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.
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
SEEK chunk.
When a fatal error is encountered, such as a bad CRC or an unknown critical AniPNG chunk, minimal viewers that do not implement the SAVE/SEEK mechanism should simply abandon the AniPNG datastream. More capable AniPNG viewers should attempt to recover gracefully by abandoning processing of the segment and searching for a SEEK chunk. If such errors occur before the SAVE chunk is reached, the viewer should abandon the AniPNG 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.
AniPNG 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 AniPNG 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.
AniPNG 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 are defined in
the MHDR chunk and cannot be changed by any other AniPNG chunk.
Decoders can use these parameters to establish the size of
a window in which to display the AniPNG 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 AniPNG datastream that consists of only a PNG or JNG
datastream, with the AniPNG, PNG or JNG signature,
the frame_width
and frame_height are defined by
the width and
height fields of the
IHDR (or JHDR) chunk.
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
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 AniPNG segment, so changing it has no effect on the copy-safe status of unknown chunks in any other part of the AniPNG 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
AniPNG 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.
On systems where file names customarily include an extension
signifying file type, the extension .mng is recommended for
AniPNG files. Lowercase .mng is
preferred if file names are case-sensitive.
When and if the AniPNG format becomes finalized, the
AniPNG authors intend to register video/apg
as the Internet Media Type for
AniPNG [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.
Segments and objects are externally accessible via named SEEK 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 SEEK 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 no SAVE chunk is present, the server must simply return the entire AniPNG datastream. Servers that are unwilling to parse the AniPNG datastream and are unconcerned about bandwidth can return the entire AniPNG datastream even when the SAVE 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 AniPNG 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 AniPNG 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 AniPNG 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 AniPNG datastream, or, preferably, it should construct a complete AniPNG file containing:
If the server does not send the entire AniPNG datastream, and the first segment after the SAVE chunk is not sent but a later segment is sent, the optional index must be written even if it does not exist in the source file. The index must contain at least one "type 0" entry that gives the nominal start time and frame number for the first segment that is sent after the SAVE chunk. The offset field can be set to zero and the segment name can be omitted.
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.
AniPNG 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/.
do_not_show byte.
Released 27 Sept 2015
Released 27 June 2013
Released 14 July 2010
Released 17 October 2007
Released 9 September 2007
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:
Randers-Pehrson, G., et. al., "PNG (Portable Network Graphics
Format) Version 1.2," which is available at
ftp://ftp.simplesystems.org/pub/png/documents/.
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
SEEK 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 SEEK 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.
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:
This document was built from the file anipng-0.92-20150927.html on 27 September 2015.
Copyright © 2013 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.