For list of authors, see Credits (Chapter 19).
This document is a specification by the PNG development group. It has been approved by a vote of the group. Future technical changes will require formal approval by a vote of the group. It is the intent of the group to maintain backward compatibility if possible.
Comments on this document can be sent to the MNG 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://swrinde.nde.swri.edu/pub/mng/documents/.
This document defines the MNG (Multiple-image Network Graphics) format. It also defines the MNG-LC (Low Complexity), MNG-VLC (Very Low Complexity), and JNG (JPEG Network Graphics) formats. These are proper subsets of MNG.
MNG 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 single-image datastreams.
The MNG and JNG formats use the same chunk structure that is defined in the PNG specification, and they share other features of the PNG format. Any MNG decoder must be able to decode PNG and JNG datastreams.
The MNG format (but not MNG-LC or MNG-VLC) 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. "Palette animations" are also possible. MNG can also store images in a highly compressible "Delta-PNG" format, defined herein.
A MNG frame normally contains a two-dimensional image or a two-dimensional layout of smaller images. It could also contain three-dimensional "voxel" data arranged as a series of two-dimensional planes (or tomographic slices), each plane being represented by a PNG or Delta-PNG datastream.
A Delta-PNG datastream defines an image in terms of a parent PNG or Delta-PNG image and the differences from that image. This provides a much more compact way of representing subsequent images than using a complete PNG datastream for each.
This document includes examples that demonstrate various capabilities of MNG. These include simple movies, composite frames, loops, fades, tiling, scrolling, storage of voxel data, and converting GIF animations to MNG format.
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 a MNG (Multiple-image Network Graphics) format. It also defines low-complexity and very-low-complexity versions (MNG-LC and MNG-VLC), and the JNG (JPEG Network Graphics) format, which are proper subsets of MNG.
Note: This specification depends on the PNG (Portable Network Graphics) [PNG] and the JPEG (Joint Photographic Experts Group) specifications. The PNG specification is available at the PNG web site,
http://www.libpng.org/pub/png/
MNG is a multiple-image member of the PNG format family that can contain
comprised of multiple PNG or JNG single-image datastreams.
Like PNG, a MNG datastream consists of an 8-byte signature, followed by a series of chunks. It begins with the MHDR chunk and ends 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).
A MNG 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, JNG, or Delta-PNG datastreams. MNG-LC and MNG-VLC datastreams do not contain JNG datastreams, but MNG-LC and MNG-VLC applications can be enhanced to recognize and process JNG datastreams as well.
A typical MNG datastream consists of:
MNG 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.
Images can be "concrete" or "abstract". The distinction allows decoders to use more efficient ways of manipulating images when it is not necessary to retain the image data in its original form or equivalent in order to show it properly on the target display system.
MNG is pronounced "Ming."
When a MNG datastream is stored in a file, it is recommended that ".mng" be used as the file suffix. In network applications, the Media Type "video/x-mng" can be used. Registration of the media type "video/mng" might be pursued at some future date.
The MNG datastream begins with an 8-byte signature containing
138 77 78 71 13 10 26 10 (decimal)
8a 4d 4e 47 0d 0a 1a 0a (hexadecimal)
\212 M N G \r \n \032 \n (ASCII C notation)
which is similar to the PNG signature with "\212 M N G" instead of "\211 P N G" in bytes 0-3.
MNG does not yet accommodate sound or complex sequencing information, but these capabilities might be added at a later date, in a backward-compatible manner. These issues are being discussed in the mng-list@ccrc.wustl.edu mailing list.
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 MNG employ the same mechanism as PNG, but with rules that are explained more fully (see below, Chapter 8). A MNG 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 MNG datastream or of any embedded object is an independent entity, i.e., no chunk is ever enclosed in the data segment of another chunk. MNG-compliant decoders are required to recognize and decode independent PNG or JNG datastreams.
Because the embedded objects making up a MNG are normally in PNG format, MNG shares the good features of PNG:
In addition:
See also the glossary in the PNG specification.
In MNG-VLC datastreams, each frame (except for the first, which also
includes the background layer) contains a single layer,
unless the framing rate (from the MHDR
ticks_per_second field) is zero. When the framing rate is zero,
the entire datastream describes a single frame.
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 the background layer, and the background layer is transparent, the transparent background is composited against the outside world and the subsequent layers are composited against the result to obtain the new frame.
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.
The layers in a MNG datastream are gathered into one or more subframes for convenience in applying frame parameters to a subset of the layers (see the definition of "subframe" below).
An embedded visible PNG or JNG datastream generates a
single layer,
even though it might be interlaced or progressive.
If the background
consists of both a background color and a background image, these
are combined into a single layer.
object_id is
an unsigned sixteen-bit number that serves as the identifier of a set of
object attributes. In MNG-LC
and MNG-VLC
only object 0 is permitted.
do_not_show flag to zero,
for
on-the-fly
display while the embedded image that defines it is being
cloned or
decoded.
do_not_show flag to zero.
An "object", which is identified by
an object_id, is an
image or it is a nonviewable entity that is created by the BASI
chunk. The object_id is an unsigned sixteen-bit number that
serves as the identifier of a set of object attributes.
An "image" is a viewable object.
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 MNG chunks. Decoders are responsible for keeping track of them. The simplest decoder might establish a 65,536-element array for each attribute, but real applications will undoubtedly use a more memory-efficient method. 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 or CLON chunk
that introduced it. The "potential visibility" of viewable objects
can be changed by the SHOW chunk. When an embedded object is
"potentially visible," it can be displayed "on-the-fly"
as it is being
decoded. Later, the SHOW chunk can direct that a "potentially
visible" viewable object be displayed.
It is permitted to change the potential visibility of "frozen"
objects; if this is done, the potential visibility must be restored to
its "saved" condition by the encoder prior to the end of the
segment.
A nonviewable object becomes viewable immediately when the decoder receives a viewable object buffer or when an image delta makes it viewable, and if the object is potentially visible it can be displayed "on-the-fly" while the object buffer is being decoded or updated. Note that object 0 is only viewable while its embedded image is being decoded and displayed on-the-fly, after which it becomes nonviewable again because no object buffer is ever created for object 0.
An object buffer is created by the appearance of an embedded object
in the datastream, with a nonzero object_id, or by the
appearance of a CLON chunk that specifies a "full clone".
The contents of an object buffer can be modified by processing an image
delta or a PAST chunk.
Object buffers contain 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 MNG datastream or be considered viewable after it has been processed.
When the "stored object buffers" flag (bit 9 of the simplicity
profile) is 0
and valid (i.e., bit 6 is 1 and bit 9 is 0), an object buffer need not be
created even when an embedded object with a nonzero object_id
appears, since the flag promises that the object buffer will never be used
again.
There is no requirement not to create an object buffer; no
harm will be done except for some unnecessary memory consumption.
When a partial clone is made of an object via the CLON chunk, the reference count for the object buffer is incremented, and no new object buffer is created.
When an object is discarded and it points to an object buffer that has a nonzero reference count, that reference count is decremented and the object buffer is also discarded if the resulting reference count is zero.
Object 0 is a special object that has a set of object attributes
that control its location, clipping, and visibility properties, and
also has a set of magnification factors and methods, but does not have
an object buffer. The object attributes and magnification data,
which can be modified by the DEFI, MOVE, CLIP,
and MAGN chunks, 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 or magnification data
are different from the default/saved values, they become undefined when
a SEEK chunk appears.
This chapter describes chunks that can appear at the top level of a MNG datastream. Unless otherwise specified in the Delta-PNG chapter of this specification, they need not be recognized within a Delta-PNG 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 MNG 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 MNG control chunks that MNG-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 MNG editors.
The MHDR chunk is always first in all MNG datastreams except for those that consist of a single PNG or JNG datastream with a 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).
Simplicity_profile: 4 bytes:(unsigned integer).
bit 0: Profile Validity
0: Absence of any features is unspecified.
All other bits of the simplicity profile
must be zero (i.e, all other even numbers
are invalid).
1: Absence of certain features is specified by
the remaining bits of the simplicity profile.
(must be 1 in MNG-LC and MNG-VLC
datastreams)
bit 1: Simple MNG features
0: Simple MNG features are absent.
1: Simple MNG features may be present.
(must be 0 in MNG-VLC datastreams)
bit 2: Complex MNG features
0: Complex MNG features are absent.
1: Complex MNG features may be present.
(must be 0 in MNG-LC and MNG-VLC datastreams)
bit 3: Internal transparency
0: Transparency is absent or can be ignored.
All images in the datastream are opaque or
can be rendered as opaque without affecting
the final appearance of any frame.
1: Transparency may be present.
bit 4: JNG
0: JNG and JDAA are absent.
1: JNG or JDAA may be present.
(must be 0 in MNG-LC and MNG-VLC
datastreams)
bit 5: Delta-PNG
0: Delta-PNG is absent.
1: Delta-PNG may be present.
(must be 0 in MNG-LC and MNG-VLC datastreams)
bit 6: Validity flag for bits 7, 8, and 9
0: The absence of background transparency,
semitransparency, and stored object buffers
is unspecified; bits 7, 8, and 9 have no
meaning and must be 0.
1: The absence or possible presence of
background transparency is expressed by
bit 7, of semitransparency by bit 8, and of
stored object buffers by bit 9.
bit 7: Background transparency
0: Background transparency is absent (i.e., the
first layer fills the entire MNG frame with
opaque pixels).
1: Background transparency may be present.
bit 8: Semi-transparency
0: Semitransparency (i.e., an image with an
alpha channel that has values that are
neither 0 nor the maximum value) is absent.
1: Semitransparency may be present.
If bit 3 is zero this field has no meaning.
bit 9: Stored object buffers
0: Object buffers need not be stored.
1: Object buffers must be stored.
(must be 0 in MNG-LC and MNG-VLC
datastreams)
If bit 2 is zero, this field has no meaning.
bits 10-15: Reserved bits
Reserved for public expansion. Must be zero in
this version.
bits 16-30: Private bits
Available for private or experimental expansion.
Undefined in this version and can be ignored.
bit 31: Reserved bit. Must be zero.
Decoders can ignore the "informative"
nominal_frame_count, nominal_layer_count,
nominal_play_time, and simplicity_profile 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 MNG datastream contains no visible images.
The ticks_per_second field gives the
unit used by the FRAM chunk to specify interframe delay and timeout.
In MNG-VLC datastreams, it gives the framing rate.
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 FRAM 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
fPRI chunks and the
TERM chunk. If the frame count is greater
than 231-1,
encoders should write 231-1, representing an infinite
frame count.
In MNG-VLC datastreams, the frame count is the same as the number of
embedded images in the datastream (or one, the background layer, if there are
no embedded images).
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)
in the datastream, ignoring any effects of the
fPRI chunks and the
TERM chunk.
If the layer count is greater than 231-1, encoders
should
write 231-1, representing an infinite layer count.
In MNG-VLC datastreams, the layer count is the number of embedded images,
plus one (for the background layer).
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
fPRI chunks and 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-bit integer. If the nominal play time is greater
than 231-1 ticks, encoders should write 231-1,
representing an infinite nominal play time.
In MNG-VLC datastreams, the nominal play time is the same as the frame count,
except when the ticks_per_second field is zero, in which case the
nominal play time is also zero.
When bit 0 of the simplicity_profile field is zero, the
simplicity (or complexity) of the MNG datastream is unspecified,
and all bits of the simplicity profile must be zero.
The simplicity profile must be nonzero in
MNG-LC and MNG-VLC
datastreams.
If the simplicity profile is nonzero, it can be regarded as a 32-bit profile, with bit 0 (the least significant bit) being a "profile-validity" flag, bit 1 being a "simple MNG" flag, bit 2 being a "complex MNG" flag, bits 3, 7, and 8 being "transparency" flags, bit 4 being a "JNG" flag, bit 5 being a "Delta-PNG" flag, and bit 9 being a "stored object buffers" flag. Bit 6 is a "validity" flag for bits 7, 8, and 9, which were added at version 0.98 of this specification. These three flags mean nothing if bit 6 is zero.
If a bit is zero, the corresponding feature is guaranteed to be absent or if it is present there is no effect on the appearance of any frame if the feature is ignored. If a bit is one, the corresponding feature may be present in the MNG datastream.
Bits 10 through 15 of the simplicity profile are reserved for future MNG versions, and must be zero in this version.
Bits 16 through 30 are available for private test or experimental versions. The most significant bit (bit 31) must be zero.
When bit 1 is zero ("simple" MNG features are absent), the datastream does not contain the DEFI, FRAM, MAGN, or global PLTE and tRNS chunks, and filter method 64 is not used in any embedded PNG datastream.
When bit 2 is zero, the datastream does not contain any "complex MNG features". These are the BASI, CLON, DHDR/IEND, PAST, DISC, MOVE, CLIP, and SHOW chunks, or any chunk in a future version of this specification that defines or uses stored objects. If the DEFI chunk is present, it only defines object 0. If the BACK chunk is present, it does not define a background image. If the LOOP chunk is present, it has iteration_min=1. A MNG with a "complex MNG feature" (which has a simplicity profile that has bit 2 set to 1) may contain at least one of these chunks. A simple decoder can display "simple" MNGs (which have a simplicity profile with bit 2 set to 0) without having to store any objects or dealing with the SAVE/SEEK mechanism, and it can ignore the LOOP and ENDL chunks and execute all loops exactly once.
"Transparency is absent or can be ignored" means that either the MNG or PNG tRNS chunk is not present and no PNG or JNG image has an alpha channel, or if they are present they have no effect on the final appearance of any frame and can be ignored (e.g., if the only transparency in a MNG datastream appears in a thumbnail that is never displayed in a frame, or is in some pixels that are overlaid by opaque pixels before being displayed, the transparency bit should be set to zero).
"Semitransparency is absent" means that if the MNG or PNG tRNS chunk is present or if any PNG or JNG image has an alpha channel, they only contain the values 0 and the maximum (opaque) value. It also means that the JDAA chunk is not present. The "semitransparency" flag means nothing and must be 0 if bit 3 is 0 or bit 6 is 0.
"Background transparency is absent" means that the first layer of every segment fills the entire frame with opaque pixels, and that nothing following the first layer causes any frame to become transparent. Whatever is behind the first layer does not show through.
When "Background transparency" is present, the application is responsible for supplying a background color or image against which the MNG background layer is composited, and if the MNG is being displayed against a changing scene, the application should refresh the entire MNG frame against a new copy of the background layer whenever the application's background scene changes. The "background transparency" flag means nothing and must be 0 if bit 6 is 0. Note that bit 3 does not make any promises about background transparency.
The "stored object buffers" flag is only useful when bit 2 is nonzero (i.e., "complex MNG features" are present). This flag promises that even though such features are present, no chunk will ever use the information in an existing object buffer; therefore it is not necessary to store an object buffer for any object. A set of object attributes is necessary for each object, however. Therefore, the MOVE, CLIP, DISC, deterministic LOOP, partial CLON, and immediately-displayed BASI chunk are permissible. The "stored object buffers" flag means nothing if bit 2 is 0 or bit 6 is 0.
A MNG-LC (i.e., a "low-complexity MNG") datastream must have a simplicity profile with bit 0 equal to 1 and all other bits except possibly for bits 1, 3, 6, 7, and 8 ("simple MNG" MNG features and transparency) equal to zero. If bit 4 (JNG) is 1, the datastream is a "MNG-LC that might contain a JNG" datastream carrying an image or an alpha channel. MNG-LC decoders are allowed to reject such datastreams unless they have been enhanced with JNG capability.
A MNG-VLC (i.e., a "very low-complexity MNG") datastream must have a simplicity profile with bit 0 equal to 1 and all other bits except possibly for bits 3, 6, 7, and 8 (transparency) equal to 0. If bit 4 (JNG) is 1, the datastream is a "MNG-VLC with JNG" datastream. It might contain a JNG datastream carrying an image or an alpha channel. MNG-VLC decoders are allowed to reject such datastreams unless they have been enhanced with JNG capability.
Encoders that write a nonzero simplicity profile should endeavor to be accurate, so that decoders that process it will not unnecessarily reject datastreams or avoid possible optimizations. For example, the simplicity profile 351 (0x15f) indicates that JNG, critical transparency, semitransparency, and at least one "complex" MNG feature are all present, but Delta-PNG, stored object buffers, and background transparency are not. This example would not qualify as a MNG-LC or a MNG-VLC datastream because a "complex" MNG feature might be present. If the simplicity profile promises that certain features are absent, but they are actually present in the MNG datastream, the datastream is invalid.
The MEND chunk's data length is zero. It signifies the end of a MNG datastream.
The LOOP chunk provides a "shorthand" notation that can be used to avoid having to repeat identical chunks in a MNG datastream. The LOOP chunk can be ignored by MNG-LC and MNG-VLC decoders, along with the ENDL chunk. 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. Therefore, during the first iteration
of the loop, the parent objects for any Delta-PNG datastreams in the
loop are the images in existence prior to entering the LOOP
chunk, but in subsequent iterations these parent objects might have been
modified. 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 MNG
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 is very similar to the termination condition field of the FRAM chunk, and can take the same 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 MNG 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 every 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 0x7fffffff. If all of the loops in
a MNG datastream have iteration_min=1, the datastream
can qualify as a "simple" MNG for the purpose of setting bits
1 and 2
of the "simplicity profile" to zero, unless there are other
reasons for setting them to one.
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 MNG 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).
MNG editors that extract a series of PNG or JNG files from a MNG 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 MNG
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.2.11).
The chunks described in this section create objects and initialize their object attributes, or change their object attributes or the data in their object buffers. Some of them also may cause images to be immediately displayed.
The DEFI chunk sets the default set of object attributes
(object_id, do_not_show flag,
concrete_flag, location, and clipping boundaries) for
any subsequent images that are defined with IHDR-IEND,
BASI-IEND,
or JHDR-IEND datastreams.
If bit 1 of the MHDR simplicity profile is 0 and bit 0 is 1, the DEFI chunk must not be present.
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. This field must be
zero in MNG-LC files.
Do_not_show: 1 byte (unsigned integer)
0: Make the objects potentially visible.
1: Make the objects not potentially visible.
Concrete_flag: 1 byte (unsigned integer)
0: Make the objects "abstract" (image cannot be the
source for a Delta-PNG)
1: Make the objects "concrete" (object can be the
source for a Delta-PNG).
MNG-LC decoders can ignore this flag.
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, and it can
be treated as an "abstract" image, regardless of the contents of the
concrete_flag field.
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, JHDR-IEND, and
BASI-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, unless they are modified by SHOW, MOVE,
or CLIP chunks.
The object_id and concrete_flag
can only be changed by using another DEFI chunk. If no
DEFI chunk is in effect (either because there is none in
the datastream, or because a DISC or SEEK chunk has
caused it to be discarded),
the decoder must use the following default values:
Object_id = 0
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 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 DISC or SEEK chunk has
caused it to be discarded.
An 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, JHDR, BASI, or PAST 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.
Note that if the object has partial clones, the object buffer of the clones is naturally affected by the new data because it is shared, but the object attributes sets of the clones are not affected.
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.
The global PLTE chunk is not permitted in MNG-VLC datastreams.
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 are embedded in a MNG datastream that begins with a MNG signature. Nor are they allowed in MNG-VLC datastreams.
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 a MNG 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).
The extra filter method can also be used in PNG datastreams that is embedded in Delta-PNG and BASI datastreams.
It is suggested that encoders write a "nEED MNG-1.0" chunk if they use this feature, for the benefit of pre-MNG-1.0 decoders.
Applications must not write MNG-VLC datastreams or independent PNG datastreams (with either the .png or .mng file extension) with the new filter method, until and unless it should become officially approved for use in PNG datastreams.
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 do_not_show is zero for the image when the IHDR
chunk is encountered, a viewer can choose to display the image while
it is being decoded, perhaps taking advantage of the PNG interlacing
method, or to display it after decoding is complete.
If object_id is zero, there is no need to store the
pixel data after decoding it and perhaps displaying it.
If concrete_flag=1 is 1 and object_id is nonzero,
the decoder must store the original pixel data losslessly, along
with data from other recognized PNG chunks, because it is possible
that a subsequent Delta-PNG datastream might want to modify it. If
concrete_flag is zero, the decoder can store the pixel data in any
form that it chooses.
If the "stored object buffers" flag in the simplicity profile is
valid and zero, there is no need to store the pixel data and other chunk
data after decoding and perhaps displaying the image.
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 below (Chapter 5) 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.
MNG-LC and MNG-VLC applications are not expected to process JNG datastreams unless they have been enhanced with JNG capability.
The BASI chunk introduces a basis object that, while it might be incomplete, can serve as a parent object to which a delta image can be applied.
The first 13 bytes of the BASI chunk are identical to those of the IHDR chunk. The next 8 bytes, which can be omitted, provide sixteen-bit {red, green, blue, alpha} values that are used to fill the entire basis object when the IDAT chunk is not present, and a 1-byte "viewable" flag can also be present.
Width: 4 bytes (unsigned integer).
Height: 4 bytes (unsigned integer).
Sample_depth: 1 byte (unsigned integer) 1, 2, 4, 8, or 16.
Color_type: 1 byte (unsigned integer) 0: Gray, 2: RGB, 3: indexed
color, 4: Gray-alpha, 6: RGBA
Compression_method: 1 byte (unsigned integer).
0: zlib with deflate
Filter_method: 1 byte (unsigned integer).
0: five basic filter types.
64: intrapixel differencing and five basic filter
types.
Interlace_method: 1 byte (unsigned integer).
0: none, 1: Adam7
Red_sample or
gray_sample: 2 bytes (unsigned integer).
Green_sample: 2 bytes (unsigned integer).
Blue_sample: 2 bytes (unsigned integer).
Alpha_sample: 2 bytes (unsigned integer).
Viewable: 1 byte (unsigned integer).
0: Basis object is not viewable.
1: Basis object is viewable.
The sample depth, color type, compression method, and interlace method must be valid PNG types, and the width and height must be within the valid range for PNG datastreams. The filter method must be one of the filter methods allowed in PNG datastreams (currently only 0) or the additional filter method (64) allowed in PNG datastreams that are embedded in MNG datastreams.
The alpha_sample can be omitted if the viewable
field is also omitted. If so, and the color_type is one
that requires alpha, the alpha value corresponding to an opaque
pixel will be used. If the color samples are omitted, zeroes will
be used. If the viewable field is omitted, the object is not
viewable.
The decoder is responsible for converting the color and
alpha samples to the appropriate format and sample depth for the
specified color_type.
The color and alpha samples are written as four sixteen-bit samples
regardless of the color_type and sample_depth.
When the sample_depth is less than sixteen, the least
significant bits are used and the remaining bits must be zero
filled.
When color_type is 0 or 4, the green and blue
samples must be present but must be ignored by decoders.
When color_type is 0 or 2,
only the values 0 and 2sample_depth should be written.
Any other alpha value must be interpreted as fully opaque.
When color_type is 3, the
decoder must generate a palette of length 2sample_depth,
whose first entry contains the given {red_sample, green_sample,
blue_sample} triple, and whose remaining entries are filled with
zeroes. It must also generate an alpha array whose first entry is the
given alpha sample and the rest are opaque
(i.e., if the alpha sample is not opaque, it creates a one-entry tRNS
chunk containing the least significant byte of the given alpha sample).
The BASI datastream contains PNG chunks, but is not necessarily a PNG datastream. It can be incomplete or empty and it can deviate in certain ways from the PNG specification. It can serve as a parent object for a Delta-PNG datastream, which must supply the missing data or correct the other deviations before the image is displayed. The end of the datastream is denoted by an IEND chunk.
The permitted deviations from the PNG format in a BASI datastream are:
color_type is 3. If so, the subsequent Delta-PNG that uses this
as the parent object can supply a complete replacement PLTE chunk,
if the single-entry palette that is generated is not desired.
This deviation is only permitted when the object is concrete and not viewable.
The BASI chunk can be used to introduce such things as a library of iCCP chunks from which one or another can be selected for use with any single image, or it can be used to introduce a simple blank or colored rectangle that will be immediately displayed or into which other images will be pasted by means of the PAST chunk.
A BASI chunk appearing in a MNG datastream receives its
object_id, location, and potential visibility from the
preceding DEFI chunk, if one is present, or the default
values for DEFI, if one is not present. The
concrete_flag can be either 0 (abstract) or 1 (concrete),
depending on whether the basis image is intended for subsequent use by
a Delta-PNG datastream or not. When it is abstract, it must also be
viewable. When it is viewable, the
resulting object, after the pixel samples are filled in, must be identical
to an object that would have been obtained by decoding a legal
PNG datastream. If viewable is 1 and
do_not_show is 0, a viewer is expected to display
it immediately, as if it were decoding a PNG datastream.
If an object already exists with the same object_id, the
contents of its object buffer are replaced with the new data.
Top-level gAMA, sRGB, cHRM, bKGD, sBIT, pHYs, iCCP, and sPLT chunks are inherited by a BASI datastream in the same manner as by a PNG datastream.
No provision is made in this specification for storing a BASI datastream as a standalone file. A BASI datastream will normally be found as a component of a MNG datastream. Applications that need to store a BASI datastream separately should use a different file signature and filename extension. Better, they can wrap it in a MNG datastream consisting of the MNG signature, the MHDR chunk, the BASI datastream, and the MEND chunk.
Create a clone (a new copy) of an image, with a new
object_id. The CLON chunk contains 4, 5, 6, 7, or
16 bytes. If a field is omitted, all subsequent fields must also be
omitted.
Source_id: 2 bytes (nonzero unsigned integer). Identifier of the
parent object to be cloned.
Clone_id: 2 bytes (nonzero unsigned integer). Identifier of the child
object that is created.
Clone_type: 1 byte (unsigned integer).
0: Full clone of the set of object attributes and the
object buffer.
1: Partial clone; only set of object attributes (the
location, clipping boundaries, and potential
visibility) are copied and a link is made to the
object buffer.
2: Renumber object (this is equivalent to
"CLON source_id clone_id 1
DISC source_id").
If this field is omitted, the clone_type defaults to zero
(full clone).
Do_not_show: 1 byte (unsigned integer).
0: Make the clone potentially visible and display it
immediately.
1: Make the clone not potentially visible.
When this field is omitted, the object retains the
potential visibility of the parent object.
Concrete_flag:
1 byte (unsigned integer).
0: Concrete_flag is the same as that of the parent
object.
1: Make the clone "abstract" (concrete_flag=0).
When this field is omitted, the object retains the
concrete flag of the parent object.
Loca_delta_type:
1 byte (unsigned integer)
0: Location data gives X_location and Y_location
directly.
1: New positions are determined by adding the location
data to the position of the parent object.
This field, together with the X_location and Y_location
fields, can be omitted as a group. When they are omitted,
the clone has the same location as the parent object.
X_location or delta_X_location:
4 bytes (signed integer).
Y_location or delta_Y_location:
4 bytes (signed integer).
The source_id must be an existing object identifier, and
the clone_id must not be an existing object identifier.
Negative values are permitted for the X and Y position. The positive directions are downward and rightward from the frame origin.
The clone is initially identical to the parent object except for the
location and potential visibility. It has the same clipping boundaries
as the parent object. Subsequent DHDR, SHOW,
CLON, CLIP, MOVE, PAST, and
DISC chunks can use the clone_id to identify it. If
the parent object is not a viewable image, neither is the clone.
Subsequent chunks can modify, show, or discard a full clone or modify its potential visibility, location and clipping boundaries without affecting the parent object. They can also modify, show, or discard the parent object or modify its set of object attributes without affecting the clone.
The concrete_flag byte must be zero or omitted when the
clone_type byte is nonzero.
If an object has partial clones, and the data in the object buffer of a parent object or any of its partial clones is modified, the parent object and all of its partial clones are changed. Decoders must take care that when the parent object or any partial clone is discarded, the object buffer is not discarded until the last remaining one of them is discarded. Only the location, potential visibility, and clipping boundaries can be changed independently for each partial clone.
If viewable is 1 and
do_not_show is 0, the resulting image is displayed immediately.
A Delta-PNG datastream.
See The Delta-PNG Format (Chapter 6),
below, for the
format of the Delta-PNG datastream. Any chunks between DHDR
and IEND are written and decoded according to the Delta-PNG
format. The object_id of the Delta-PNG DHDR
chunk must point to an existing parent object. The resulting image
is immediately displayed if its do_not_show is 0. The parent
object must be concrete (i.e., concrete_flag must be 1).
Paste an image or images identified by source_id,
or part of it, into an existing abstract 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.
Destination_id: 2 bytes (unsigned integer).
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
destination_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.
Composition_mode:
1 byte (unsigned integer).
0: Composite over.
1: Replace.
2: Composite under.
Orientation: 1 byte (unsigned integer).
The source image is flipped to another orientation.
0: Same as source image.
2: Flipped left-right, then up-down.
4: Flipped left-right.
6: Flipped up-down.
8: Tiled with source image. The upper left corner of
the assembly is positioned according to the
prescribed offsets.
Offset_origin: 1 byte (unsigned integer).
0: Offsets are measured from the {0,0} pixel in the
destination image.
1: Offsets are measured from the {target_x,target_y}
pixel in the destination image.
X_offset: 4 bytes (signed integer).
Y_offset: 4 bytes (signed integer).
Boundary_origin: 1 byte (unsigned integer).
0: PAST clipping boundaries are measured from the
{0,0} pixel in the destination image.
1: PAST clipping boundaries are measured from the
{target_x,target_y} pixel in the destination image.
Left_past_cb: 4 bytes (signed integer).
Right_past_cb: 4 bytes (signed integer).
Top_past_cb: 4 bytes (signed integer).
Bottom_past_cb: 4 bytes (signed integer).
...etc...
The destination image must have the "abstract" property
(concrete_flag=0). When destination_id=0, the
resulting image is "write-only" and therefore
only "composite-over"
(composition_mode=0) operations are permitted.
The source images can be "abstract" or "concrete"
and have any
color_type and sample_depth. They must
have the "viewable" property. The number of source images is
((chunk_length-11)/30).
The x_offset and y_offset distances and the
PAST clipping boundaries are measured, in pixels, positive
rightward and
downward from either the {0,0} pixel of the destination image
or the {target_x, target_y} position in the destination
image. They do not necessarily have to fall within the destination
image. Only those pixels of the source image that fall within the
destination image and also within the specified clipping boundaries
will be copied into the destination image. The coordinate
system for offsets and clipping is with respect to the upper lefthand
corner of the destination image, which is not necessarily the same
coordinate system used by the DEFI, MOVE and CLIP
chunks.
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 composition_mode=0, 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 composition_mode=1, all pixels simply replace those
in the destination image. This mode can be used to make a transparent
hole in an opaque image.
When composition_mode=2, 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.
The order of composition is the same as the order that the
source_ids appear in the list (but a decoder can do the
composition in any order it pleases, or all at once, provided that the
resulting destination image is the same as if it had actually performed
each composition in the specified order). Decoders must be careful when
the destination image equals the source image--the pixels to be drawn
are the ones that existed before the drawing operation began.
The clipping information from the DEFI, MOVE
or CLIP 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).
This chunk provides mandatory magnification factors for existing objects and/or for subsequent embedded images whose object id is 0.
The chunk contains 0 to 18 bytes. If any field is omitted, all subsequent fields must also be omitted.
First_magnified_object_id:
2 bytes. If omitted, any previous MAGN chunk is
nullified.
Last_magnified_object_id:
2 bytes. If omitted, last object_id = first object_id.
X_method: 1 byte
0 or omitted: No magnification
1: Pixel replication of color and alpha samples.
2: Magnified intervals with linear interpolation of
color and alpha samples.
3: Magnified intervals with replication of color and
alpha samples from the closest pixel.
4: Magnified intervals with linear interpolation of
color samples and replication of alpha samples from
the closest pixel.
5: Magnified intervals with linear interpolation of
alpha samples and replication of color samples from
the closest pixel.
MX: 2 bytes. X magnification factor, range 1-65535. If
omitted, MX=1. Ignored if X_method is 0 and assumed to
be 1.
MY: 2 bytes. Y magnification factor. If omitted, MY=MX.
ML: 2 bytes. Left X magnification factor. If omitted, ML=MX.
MR: 2 bytes. Right X magnification factor. If omitted, MR=MX.
MT: 2 bytes. Top Y magnification factor. If omitted, MT=MY.
Ignored if Y_method is 0 and assumed to be 1.
MB: 2 bytes. Bottom Y magnification factor. If omitted,
MB=MY.
Y_method: 1 byte. If omitted, Y_method is the same as X_method.
The MAGN chunk causes the contents of the object buffers pointed to by the specified range of objects to be immediately and irreversibly magnified.
The first_magnified_object_id can be zero. If so, any subsequent
embedded
objects whose object_id is 0 must be magnified immediately when they
appear in the datastream. Magnification factors and methods for object 0 are
updated by the appearance of a subsequent MAGN chunk whose
first_magnified_object_id is 0. Magnification of object 0 is turned
off by the appearance of an empty MAGN chunk or by a MAGN
chunk whose first_magnified_object_id is zero and
whose X_method
and Y_method are zero, explicitly or by omission.
The magnification factor for object 0 becomes undefined when a SEEK
chunk appears. Therefore, it is the encoder's responsibility either
to include a MAGN chunk that turns off magnification of object 0
prior to the end of any segment in which object 0 was magnified, or to
include a MAGN chunk for object 0 prior to the first embedded object 0
in every segment that contains an embedded object 0.
The last_magnified_object_id must be greater than or equal to the
first_magnified_object_id. It
is not an error to include a nonexistent object or an existing
"frozen"
object in the range; decoders must do nothing to any such objects. If an
object is potentially visible and viewable, it is displayed immediately
after it is magnified. If any object_id is nonzero, the result
of magnifying that object is stored in place of its original object buffer
for later use.
If the MAGN chunk is present, all existing objects in the specified range must conceptually be magnified immediately in accordance with the given magnification factors and methods. Decoders may wish to save the magnification factors and delay the magnification until display time, or until the object is used as the parent object of a Delta-PNG, to save memory. There is nothing preventing this, provided that the end effect is the same as if the magnification had been accomplished immediately. If object 0 is in the specified range, then any subsequent embedded objects with object_id=0 must be magnified immediately when they appear in the datastream.
When X_method is 0, all X magnification factors in
the MAGN chunk
are ignored and can be assumed to be 1.
When X_method is 1, X magnification is done by simple pixel
replication.
The leftmost pixel of each row is replicated ML-1 times.
If the original
width is greater than 1, the rightmost pixel is replicated MR-1 times.
If the original width is greater than 2, the original interior pixels are
replicated MX-1 times. The magnified width W is
W = ML; if (width > 1) W = W + MR; if (width > 2) W = W + (width-2)*MX;
When X_method is 2, X magnification is done by linear interpolation between
pixels. If the original width of the image is greater than 1, the interval
between the leftmost pixel and the second pixel of each row is subdivided
into ML equal intervals by inserting ML-1 pixels with
color and alpha values
that are obtained by linear interpolation. If the original width is 1, then
the pixel is simply magnified as if X method is 1. If the original width is
greater than 2, the rightmost interval is subdivided into MR equal intervals.
If the original width is greater than 3, each original interior interval is
subdivided into MX equal intervals. The magnified width W is
/* The orginal pixels: */
W = width;
/* Add the new pixels in the left interval: */
if (width > 1) W = W + ML-1;
/* Add the new pixels in the right interval: */
if (width > 2) W = W + MR-1;
/* Add the new interior pixels: */
if (width > 3) W = W + (width-3)*(MX-1);
When X_method is 3, intervals are subdivided as in X method 2,
and the
color and alpha values for the new pixels are obtained by replicating
the closest original pixel, with ties being broken by replicating the
pixel to the left. The magnified width is calculated in the same manner
as in X method 2.
When X_method is 4, the color samples are magnified as in
X method 2 and
the alpha samples are magnified as in X method 3.
When X_method is 5, the color samples are magnified as in
X method 3 and
the alpha samples are magnified as in X method 2.
When Y_method is 0, all Y magnification factors in
the MAGN chunk are ignored and can be assumed to be 1.
When Y_method is 1, Y magnification is done by simple pixel
replication.
The topmost pixel of each column is replicated MT-1 times. If the
original
height is greater than 1, the bottom pixel is replicated MB-1 times.
If the original height is greater than 2, the original interior pixels of each
column are replicated MY-1 times. The magnified height H is
H = MT; if (height > 1) H = H + MB; if (height > 2) H = H + (height-2)*MY;
When Y_method is 2, Y magnification is done by linear interpolation between
pixels. If the original height of the image is greater than 1, the interval
between the topmost pixel and the second pixel of each column is subdivided
into MT equal intervals by inserting MT-1 pixels with color and alpha
values
that are obtained by linear interpolation. If the original height is 1, then
the pixel is simply magnified as if Y method is 1. If the
original height is
greater than 2, the bottom interval is subdivided into MB equal intervals.
If the original height is greater than 3, each original interior interval is
subdivided into MY equal intervals. The magnified height H is
H = height; if (height > 1) H = H + MT-1; if (height > 2) H = H + MB-1; if (height > 3) H = H + (height-3)*(MY-1);
When Y_method is 3, intervals are subdivided as in Y method 2,
and the
color and alpha values for the new pixels are obtained by replicating
the closest original pixel, with ties being broken by replicating the
pixel above. The magnified width is calculated in the same manner
as in Y method 2.
When Y_method is 4, the color samples are magnified as in
Y method 2 and
the alpha samples are magnified as in Y method 3.
When Y_method is 5, the color samples are magnified as in
Y method 3 and
the alpha samples are magnified as in Y method 2.
When the image being magnified is a concrete object, it must not be a JNG or indexed-color PNG (the latter could be promoted to RGB or RGBA via a Delta-PNG PROM chunk first). The result of the magnification is also a concrete object. The Method 2 magnification is conceptually done first in the vertical (Y) direction, the results rounded to the sample depth, then in the horizontal (X) direction. Linear interpolation must be done on the raw pixels, prior to any color correction, using integer arithmetic, to ensure that the result is deterministic. For each channel, the m-1 interpolated samples s[i] are obtained from the two samples s0 and s1 by the following ISO C code or by any other method that obtains the identical results:
if(s1 == s0)
for (i=1; i < m; i++)
s[i] = s0;
else
for (i=1; i < m; i++)
s[i] = ((2*i*(s1-s0)+m)/(m*2) + s0;
Signed arithmetic in a precision large enough to hold the intermediate results must be used, and the final results must be modulo the sample depth.
When the image being magnified is an abstract object, which is always true of object 0, interpolation can be done by any means that achieves a visually similar but not necessarily identical result, such as rounding the results to the sample depth later, using video hardware that is capable of interpolation, or using floating point addition in the loop instead of integer multiplication and division as in:
float delta = ((float)(s1-s0)/(float)m);
float sf= (float)s0;
for (i=1; i < m; i++) {
sf = sf+delta;
s[i]=(int)(sf+0.5);
}
If the abstract object being magnified is being stored in an indexed representation, interpolation must be accomplished by a method that achieves a similar result to that obtained by interpolating between RGB or RGBA pixels.
Note that if an object and partial clones of it appear in the range of objects to be magnified, the object buffer will be magnified repeatedly.
Because the MAGN chunk was added late in the development of MNG-1.0, it is recommended that encoders place an empty MAGN chunk or a nEED MAGN chunk early in the datastream, so that pre-MNG-1.0 applications that do not recognize the MAGN chunk will encounter one quickly.
The DISC chunk can be used to inform the decoder that it can discard the object data associated with the associated object identifiers. Whether the decoder actually discards the data or not, it must not use it after encountering the DISC chunk.
The chunk contains a sequence of zero or more two-byte object identifiers. The number of objects to be discarded is the chunk's data length, divided by two.
Discard_id: 2 bytes (nonzero unsigned integer). ...etc...
If the DISC chunk is empty, all nonzero objects except those preceding the SAVE chunk (i.e., except for the "frozen" objects) can be discarded. If a SAVE chunk has not been encountered, all objects can be discarded. Note that each appearance of a SEEK chunk in the datastream implies an empty DISC chunk.
If the DISC chunk is not empty, the listed objects can be discarded.
When an object is discarded, any location, potential visibility, and clipping boundary data associated with it is also discarded.
It is not an error to include an object_id in the
discard_id list, when no such object has been stored, or when
the object has already been discarded.
It is an error to name explicitly any "frozen" object in the DISC list.
When the object is a partial clone or is the source of a partial clone that has not been discarded, only the set of object attributes (location, potential visibility, clipping boundaries, etc.) can be discarded. The data in the object buffer must be retained until the last remaining partial clone is discarded.
The TERM chunk suggests how the end of the MNG 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.
If processing the fPRI chunk, use a "cost"
of 255.
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.
If processing the fPRI chunk, use a "cost"
of 255.
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 0x7fffffff.
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.
MNG editors that extract a series of PNG or JNG files from a MNG 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 a MNG datastream.
Simple viewers and single-frame viewers can ignore the TERM chunk. It has been made critical only so MNG editors will not inadvertently relocate it.
The chunks in this section cause existing objects and embedded objects to be displayed on the output device, and control their location, clipping, and timing and the background against which they are displayed.
The BACK chunk suggests or mandates a background color, image, or both against which transparent, clipped, or less-than-full-frame images can be displayed. This information will be used whenever the application subsequently needs to insert a background layer, unless another BACK chunk provides new background information before that happens.
The BACK chunk contains 6, 7, 9, or 10 bytes. If any field is omitted, all subsequent fields must also be omitted.
Red_background: 2 bytes (unsigned integer).
Green_background: 2 bytes (unsigned integer).
Blue_background: 2 bytes (unsigned integer).
Mandatory_background:
1 byte (unsigned integer).
0: Background color and background image are
advisory. Applications can use them if they
choose to.
1: Background color is mandatory. Applications
must use it. Background image is advisory.
2: Background image is mandatory. Applications
must use it. Background color is advisory.
3: Background color and background image are both
mandatory. Applications must use them.
This byte can be omitted if the subsequent fields
are also omitted. If so, the background color is
advisory.
Background_image_id:
2 bytes (unsigned nonzero integer). Object_id of an
image that is to be used as the background layer or
part of it. If the image does not cover the area
defined by the layer clipping boundaries with opaque
pixels, the remainder of this area is filled with the
background color or application background and the
background image is composited against it. This
field can be omitted if the background_tiling byte is
also omitted; if so, no background image is defined,
and the background image_id from any previous BACK
chunk becomes undefined. This byte must be omitted
in MNG-LC and MNG-VLC datastreams, and when the
"stored object buffers" flag in the simplicity
profile is valid and is zero.
Background_tiling:
1 byte (unsigned integer).
0: Do not tile the background.
1: Tile the background with the background image.
This field can be omitted; if so, do not tile the
background. This byte must be omitted in MNG-LC and
MNG-VLC datastreams.
The first layer displayed by a viewer is always a background layer that fills the entire frame. The BACK chunk provides a background that the viewer can use for this purpose (or must use, if it is mandatory). If it is not "mandatory" the viewer can choose another background if it wishes. If the BACK chunk is not present, or if the background is not fully opaque or has been clipped to less than full frame, the viewer must provide or complete its own background layer for the first frame. Each layer after the first must be composited over the layers that precede it, until a FRAM chunk with framing mode 3 or 4 causes another background layer to be generated.
Viewers are expected, however, to composite every foreground layer against a fresh copy of the background, when the framing mode given in the FRAM chunk is 3, and to composite the