Skip to main content

Source code file content

Revision: 313 (of 313)

2016-09-23 update
» Project Revision History

» Checkout URL

community-source-archives / mng-lc-1.0-20010209-pdg.html

Size: 126365 bytes, 5 lines
<!doctype html public "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">

<html lang="en">






<title>
MNG-LC
1.0
</title>





</head>

<body>




<h1>MNG-LC (Multiple-image Network Graphics--Low Complexity) Format Version 1.0</h1>









<p>For list of authors, see <a href="#Credits">Credits (Chapter 19)</a>.

<h3>Status of this Memo</h3>


<p>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.

<p>Comments on this document can be sent to the MNG specification
maintainers at one of the following addresses:

<ul>

<li><a href="mailto:mng-list@ccrc.wustl.edu" ><span class=email>mng-list@ccrc.wustl.edu</span></a>

<li><a href="mailto:png-group@w3.org" ><span class=email>png-group@w3.org</span></a>

<li><a href="mailto:png-info@uunet.uu.net" ><span class=email>png-info@uunet.uu.net</span></a>

</ul>

<p>Distribution of this memo is unlimited.

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

<pre>
   <a href="ftp://swrinde.nde.swri.edu/pub/mng/documents/" >ftp://swrinde.nde.swri.edu/pub/mng/documents/</a>.
</pre>



<p>In the case of any discrepancy between this extract and the full MNG
specification, the full MNG specification shall take precedence.


<h2>Abstract</h2>




<p>This document presents the
MNG-LC (Multiple-image Network Graphics, Low Complexity) format,
which is a proper subset of the MNG
(Multiple-image Network Graphics) format.

<p>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
single-image datastreams.

<p>The MNG-LC
format uses the same chunk structure that is defined
in the PNG specification and shares other features of the PNG
format.  Any MNG-LC decoder must be able to decode valid PNG
datastreams.

<p>A MNG-LC
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
datastream.

<p>This document includes examples that demonstrate various capabilities
of MNG-LC including simple movies and composite frames.


<h3>Reading this document</h3>

<p>If "<code class=expr>2<sup>31</sup></code>" looks like 
the number "<code class=expr>231</code>"
instead of <code class=expr>2</code> raised to the power
<code class=expr>31</code>, your viewer is not
recognizing the HTML 4.0 &lt;SUP&gt; tag; you need
to look at the HTML 2.0, ASCII text, PDF, or PostScript
version of this document instead.


<h2>Table of Contents</h2>

<ul>
<li><a href="#introduction">1. Introduction</a>
<li><a href="#terminology">2. Terminology</a>
<li><a href="#objects">3. Objects</a>
<li><a href="#top-mng">4. MNG Chunks</a>
<ul>
<li><a href="#mng-critical">4.1. Critical MNG control chunks</a>
<ul>
<li><a href="#mng-MHDR">4.1.1. <span class=cn>MHDR </span>MNG datastream header</a>
<li><a href="#mng-MEND">4.1.2. <span class=cn>MEND </span>End of MNG datastream</a>
<li><a href="#mng-LOOP">4.1.3. <span class=cn>LOOP, ENDL</span> Define a loop</a>
</ul>
<li><a href="#critical-define">4.2. Critical MNG image defining chunks</a>
<ul>
<li><a href="#mng-DEFI">4.2.1. <span class=cn>DEFI</span> Define an object</a>
<li><a href="#mng-PLTE">4.2.2. <span class=cn>PLTE and tRNS</span> Global palette</a>
<li><a href="#mng-IHDR">4.2.3. <span class=cn>IHDR</span>, PNG chunks, <span class=cn>IEND</span></a>
<li><a href="#mng-JHDR">4.2.4. <span class=cn>JHDR</span>, JNG chunks, <span class=cn>IEND</span></a>
<li><a href="#mng-TERM">4.2.5. <span class=cn>TERM </span>Termination action</a>
</ul>
<li><a href="#critical-display">4.3. Critical MNG image displaying chunks</a>
<ul>
<li><a href="#mng-BACK">4.3.1. <span class=cn>BACK </span>Background</a>
<li><a href="#mng-FRAM">4.3.2. <span class=cn>FRAM </span>Frame definitions</a>
</ul>
<li><a href="#mng-SAVE-SEEK">4.4. <span class=cn>SAVE</span> and <span class=cn>SEEK</span> chunks</a>
<li><a href="#mng-ancillary">4.5. Ancillary MNG chunks</a>
<ul>
<li><a href="#mng-eXPI">4.5.1. <span class=cn>eXPI </span>Export image</a>
<li><a href="#mng-phys">4.5.2. <span class=cn>pHYg </span>Physical pixel size (global)</a>
</ul>
<li><a href="#mng-png">4.6. Ancillary PNG chunks</a>
</ul>
<li><a href="#jng">5. The JPEG Network Graphics (JNG) Format</a>
<li><a href="#Delta-PNG">6. The Delta-PNG Format</a>
<li><a href="#registration">7. Extension and Registration</a>
<li><a href="#copying">8. Chunk Copying Rules</a>
<li><a href="#d-minimum">9. Minimum Requirements for MNG-LC-Compliant Viewers</a>
<ul>
<li><a href="#d-min-MNG">9.1. Required MNG chunk support</a>
<li><a href="#d-min-PNG">9.2. Required PNG chunk support</a>
<li><a href="#d-min-JNG">9.3. Optional JNG chunk support</a>
</ul>
<li><a href="#encoders">10. Recommendations for Encoders</a>
<ul>
<li><a href="#E.color">10.1. Use a common color space</a>
<li><a href="#E.framing">10.2. Use the right framing mode</a>
<li><a href="#E.fram_sync">10.3. Immediate frame sync point</a>
</ul>
<li><a href="#decoders">11. Recommendations for Decoders</a>
<ul>
<li><a href="#d-simplicity">11.1. Using the simplicity profile</a>
<li><a href="#errors">11.2. Decoder handling of fatal errors</a>
<li><a href="#interlacing">11.3. Decoder handling of interlaced images</a>
<li><a href="#decoder-plte">11.4. Decoder handling of palettes</a>
<li><a href="#d-single">11.5. Behavior of single-frame viewers</a>
<li><a href="#d-clipping">11.6. Clipping</a>
</ul>
<li><a href="#decoders">12. Recommendations for Editors</a>
<li><a href="#Misc">13. Miscellaneous Topics</a>
<ul>
<li><a href="#File-name-extension">13.1. File name extension</a>
</ul>
<li><a href="#Rationale">14. Rationale</a>
<li><a href="#Revision-History">15. Revision History</a>
<ul>
<li><a href="#v100">15.1. Version 1.0</a>
<li><a href="#v99">15.2. Version 0.99</a>
<li><a href="#v98">15.3. Version 0.98</a>
<li><a href="#v97">15.4. Version 0.97</a>
<li><a href="#v96">15.5. Version 0.96</a>
<li><a href="#v95">15.6. Version 0.95</a>
</ul>
<li><a href="#References">16. References</a>
<li><a href="#Security">17. Security Considerations</a>
<li><a href="#Examples">18. Appendix: Examples</a>
<ul>
<li><a href="#example1">18.1. Example 1: A single image</a>
<li><a href="#example2">18.2. Example 2: A very simple movie</a>
<li><a href="#example3">18.3. Example 3: A simple slideshow</a>
<li><a href="#examples4-14">18.4. Examples 4-14: Omitted from MNG-LC.</a>
<li><a href="#x15">18.5. Example 15: Converting a simple GIF animation</a>
<li><a href="#x16">18.6. Example 16: Counting layers and frames</a>
<li><a href="#x17">18.7. Example 17: Storing an icon library</a>
<li><a href="#x18">18.8. Example 18: MAGN methods</a>
<li><a href="#x19">18.9. Example 19: MAGN chunks and ROI</a>
</ul>
<li><a href="#Credits">19. Credits</a>
</ul>

<h2><a name="introduction">1. Introduction</a></h2>


<p>This document presents
a low-complexity version (MNG-LC,
which is a proper subset)
of the MNG (Multiple-image Network Graphics) format.

<p>Note: This specification depends on the PNG (Portable Network
Graphics) <a href="#PNG">[PNG]</a>
and, for
MNG-LC
applications that are enhanced with JNG
support, the JNG (JPEG Network Graphics)
specifications.
The PNG specification is available at the PNG web site,
<pre>
   <a href="http://www.libpng.org/pub/png/">http://www.libpng.org/pub/png/</a>
</pre>

<p>and the JNG (JPEG Network Graphics) specification and the full MNG
specification are available at the MNG web site,
<pre>
   <a href="http://www.libpng.org/pub/mng/">http://www.libpng.org/pub/mng/</a>
</pre>

<p>MNG is a multiple-image member of the PNG format family that can contain
<ul>
<li>animations,
<li>slide shows, or
<li>complex still frames,
</ul>
<p>comprised of multiple PNG
single-image datastreams.

<p>Like PNG, a MNG datastream consists of an 8-byte signature, followed
by a series of chunks.  It begins with the <span class=cn>MHDR</span> chunk and ends
with the <span class=cn>MEND</span> 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).

<p>A MNG-LC datastream describes a sequence of zero or more single frames,
each of which can be composed of zero or more embedded images.

<p>The embedded images can be PNG or JNG datastreams.
MNG-LC datastreams do not contain JNG
(JPEG Network Graphics) datastreams, which are allowed in full MNG
datastreams, but MNG-LC
applications can be enhanced to recognize and process JNG datastreams as well.

<p>A typical
MNG-LC
datastream consists of:

<ul>

<li>The 8-byte MNG signature.

<li>The <span class=cn>MHDR</span> chunk.


<li>Frame definitions.  A frame is one or more layers,
the last of which has a nonzero interframe delay,
composited against whatever was already on the display.


<li>Layer definitions.

<ul>

<li>An embedded potentially visible image, described by PNG or JNG
datastreams
(a foreground layer).


<li>The background (a background layer).

</ul>


<li>The <span class=cn>MEND</span> chunk.

</ul>

<p>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.


<p>MNG is pronounced "Ming."

<p>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.

<p>The MNG datastream begins with an 8-byte signature containing

<pre>
    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)
</pre>

<p>which is similar to the PNG signature
with "\212 M N G"
instead of "\211 P N G" in bytes 0-3.


<p>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.

<p>The chunk copying rules for MNG employ the same mechanism as PNG,
but with rules that are explained more fully
in the full MNG specification.

<p>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.

<p>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-LC
decoders are required to recognize and decode independent
PNG datastreams, and any
MNG-LC
decoder that has been enhanced to
include JNG support is required to recognize and decode independent
JNG datastreams.

<p>Because the embedded objects making up a MNG are normally in PNG
format, MNG shares the good features of PNG:

<ul>

<li>It is unencumbered by patents.

<li>It is streamable.

<li>It has excellent, lossless compression.

<li>It stores up to four channels (red, green, blue, alpha), with up to
16 bits per channel.

<li>It provides both binary and alpha-channel transparency.

<li>It provides platform-independent rendition of colors by inclusion of
gamma and chromaticity information.

<li>It provides early detection of common file transmission errors and
robust detection of file corruption.

<li>Single-image GIF files can be losslessly converted to PNG.

<li>It is complementary to JPEG and does not attempt to replace JPEG
for lossy storage of images (however,
JNG-enhanced
MNG-LC
can accommodate JPEG-encoded
images that are encoded in the PNG-like JNG
format.

</ul>

<p>In addition:

<ul>

<li>It provides animation with
variable interframe delays.

<li>It allows composition of frames containing multiple images.

<li>Using JPEG compression together with a magnification factor, it can
achieve 1000:1 and higher lossy compression of Megapixel
truecolor images.  While some detail is lost, such highly-compressed
images are useful as full-scale previews and for layout work.


<li>Multiple-image GIF files
(except for those using
the "restore-to-previous" disposal method)
can be losslessly converted to
MNG-LC.


</ul>

<h2><a name="terminology">2. Terminology</a></h2>

<p>See also the glossary in the PNG
specification and the "terminology" section of the full MNG
specification.

<dl>

<dt><strong>requirement levels</strong>

<dd>The words "MUST", "MUST NOT",
"REQUIRED",
"SHOULD", "SHOULD NOT",
"RECOMMENDED", and "OPTIONAL" in this document,
which are to be interpreted as
described in <a href="#RFC-2119">RFC-2119</a>.
The word "CAN" is
equivalent to the word "MAY" as described
therein.  "NOT ALLOWED" and
"NOT PERMITTED" describe conditions
that "MUST NOT" occur.  "ALLOWED"
and "PERMITTED" describe conditions that "CAN" occur.


<p>

<dt><strong>embedded image</strong>

<dd>An image that appears in-line in a MNG datastream.

<p>

<dt><strong><a name="term-frame">frame</a></strong>

<dd>A composition of zero or more layers that have zero interframe delay time
followed by a layer with a specified nonzero delay time or by the <span class=cn>MEND</span>
chunk.  A frame is to be displayed as a still picture or as part of a sequence
of still images or an animation.
An animation would ideally appear to a perfect observer (with an inhumanly fast
visual system) as a sequence of still pictures.

<p>
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 <span class=cn>MHDR</span>
<code class=expr>ticks_per_second</code> field) is zero.  When the framing rate is zero,
the entire datastream describes a single frame.

<p>When the
layers of a frame do not cover the entire area defined by the width and
height fields from the <span class=cn>MHDR</span> chunk, the layers
are composited over the previous frame to obtain the new frame.

<p>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.

<p>

<dt><strong>frame origin</strong>

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

<p>

<dt><strong>interframe delay</strong>

<dd>The amount of time a layer should be visible when a sequence of frames
or an animation is played.  A layer with a zero interframe delay is
combined with the subsequent layer or layers to form a frame; the frame
is completed by a layer with a nonzero interframe delay or by the <span class=cn>MEND</span>
chunk.  In reality, it takes a nonzero amount of time to display a
frame.  No matter which moment is picked as the "start" of
the frame, the interframe delay measures the time to the "start"
of the next frame.  There is no interframe delay prior to the implicit
background layer at the beginning of the sequence nor after the final
frame.

<p>

<dt><strong>interpolate</strong>

<dd>To determine the color or alpha values for new pixels
that have been created in the interval between two pixels with known values.
In this document, interpolation always means linear interpolation (the new
values are evenly spaced between the two known values).

<p>

<dt><strong>iteration</strong>

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


<p>

<dt><strong>layer</strong>

<dd>One of

<ul>

<li>A visible embedded
image,
located with respect to
the frame boundaries and clipped with respect to the layer clipping
boundaries and the image's own clipping boundaries.
<li>The background that is displayed before the
first image in the entire datastream is displayed.  Its contents can be defined
by the application or by the <span class=cn>BACK</span> chunk.
<li>
a solid rectangle filled with the background color and clipped to the
subframe boundaries, that is used as a background
when the framing mode is 3 or 4.

</ul>

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

<p>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.

<p>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"
<a href="#term-subframe">below</a>).

<p>An embedded visible PNG or JNG datastream generates a
single layer,
even though it might be interlaced or progressive.
<br>
&nbsp;


<dt><strong>MNG-LC</strong>

<dd>A low-complexity subset of MNG that does not use stored object
buffers or certain other complex features.  The "simplicity profile"
in the <span class=cn>MHDR</span> chunk must meet certain requirements
(see the <span class=cn>MHDR</span> chunk specification <a href="#mng-MHDR">below, Paragraph 4.1.1</a>).

<p>

<dt><strong>MNG-VLC</strong>

<dd>A very-low-complexity subset of MNG that does not use stored objects,
variable framing rates, location of images at positions other than (0,0),
or other complex features.  The "simplicity profile"
in the <span class=cn>MHDR</span> chunk must meet certain requirements
(see the <span class=cn>MHDR</span> chunk specification <a href="#mng-MHDR">below, Paragraph 4.1.1</a>).

<p>

<dt><strong>nullify</strong>

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

<p>

<dt><strong>object, object_id</strong>

<dd>An image.
The <code class=expr>object_id</code> is
an unsigned sixteen-bit number that serves as the identifier of a set of
object attributes.  In MNG-LC
only object 0 is permitted.

<p>

<dt><strong>object attributes</strong>

<dd>Properties of an object such as its existence, potential visibility,
location,
and clipping boundaries.

<p>

<dt><strong>potentially visible image</strong>

<dd>A
not-yet-defined object that is "marked",
by
setting its <code class=expr>do_not_show</code> flag to zero,
for
on-the-fly
display while the embedded image that defines it is being
decoded.




<p>

<dt><strong>signal</strong>

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

<p>

<dt><strong><a name="term-subframe">subframe</a></strong>

<dd>A subset of the layers defined by a MNG datastream, gathered
for convenience in applying frame parameters
(i.e., clipping information, interframe delay,
timeout, termination condition, and a name.
See the definition of "frame" <a href="#term-frame">above</a>).
The extent of a subframe depends on the framing mode; it can be
<ul>
<li>a single layer,
<li>the set of layers appearing between <span class=cn>FRAM</span> chunks,
<li>a background layer and a single foreground layer, or
<li>a background layer plus the set of layers
appearing between <span class=cn>FRAM</span> chunks.
</ul>
See the <span class=cn>FRAM</span> chunk
specification <a href="#mng-FRAM">below (Paragraph 4.3.2)</a>.<br>
&nbsp;</dd>



<dt><strong>visible image</strong>

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

<p>

</dl>


<h2><a name="objects">3. Objects</a></h2>

<p>Omitted.

<h2><a name="top-mng">4. MNG Chunks</a></h2>

<p>This chapter describes chunks that can appear at the top level of a
MNG datastream.

<p>Chunk structure (length, name, data, CRC) and the chunk-naming system
are identical to those defined in the PNG specification
<span class=ref>[<a href="#PNG">PNG</a>]</span>.  
As in PNG, all
integers that require more than one byte must be in network byte order.

<p>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.

<h3><a name="mng-critical">4.1. Critical MNG control chunks</a></h3>

<p>This section describes critical MNG control chunks that
MNG-LC-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.

<h4><a name="mng-MHDR">4.1.1. <span class=cn>MHDR </span>MNG datastream header</a></h4>

<p>The <span class=cn>MHDR</span> 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.

<p>The <span class=cn>MHDR</span> chunk contains 28 bytes, none of which can be omitted:

<pre>
   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
                            1: Absence of certain features is specified by
                               the remaining bits of the simplicity profile.
                            (must be 1 in MNG-LC datastreams)
                          bit 1: Simple MNG features
                            0: Simple MNG features are absent.
                            1: Simple MNG features may be present.
                          bit 2: Complex MNG features
                            0: Complex MNG features are absent.
                            (must be 0 in MNG-LC 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 datastreams)
                          bit 5: Delta-PNG
                            0: Delta-PNG is absent.
                            (must be 0 in MNG-LC 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.
                            (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.
</pre>

<p>Decoders can ignore the "informative"
<code class=expr>nominal_frame_count</code>, <code class=expr>nominal_layer_count</code>,
<code class=expr>nominal_play_time</code>, and <code class=expr>simplicity_profile</code> fields.

<p>The <code class=expr>frame_width</code> and <code class=expr>frame_height</code> fields
give the intended display size (measured in
pixels) and provide
the
default
clipping boundaries.
(see Recommendations for encoders, <a href="#d-clipping">below</a>).
It is strongly recommended that these be set to zero if
the MNG datastream contains no visible images.

<p>The <code class=expr>ticks_per_second</code> field gives the
unit used by the FRAM chunk to specify interframe delay and timeout.
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 <span class=cn>FRAM</span> 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.

<p>When <code class=expr>ticks_per_second</code> 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.

<p>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
<span class=cn>TERM</span> chunk.  If the frame count is greater
than <code class=expr>2<sup>31</sup>-1</code>,
encoders should write <code class=expr>2<sup>31</sup>-1</code>, representing an infinite
frame count.

<p>If the <code class=expr>nominal_layer_count</code> 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
<span class=cn>TERM</span> chunk.
If the layer count is greater than <code class=expr>2<sup>31</sup>-1</code>, encoders
should
write <code class=expr>2<sup>31</sup>-1</code>, representing an infinite layer count.

<p>If the <code class=expr>nominal_play_time</code> 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
<span class=cn>TERM</span> chunk.
Authors who write this field should choose a
value of <code class=expr>ticks_per_second</code> that will allow the nominal play time
to be expressed in a four-bit integer.  If the nominal play time is greater
than <code class=expr>2<sup>31</sup>-1</code> ticks, encoders should write <code class=expr>2<sup>31</sup>-1</code>,
representing an infinite nominal play time.

<p>When bit 0 of the <code class=expr>simplicity_profile</code> field is zero, the
simplicity (or complexity) of the MNG datastream is unspecified,
and <em>all</em> bits of the simplicity profile must be zero.
The simplicity profile must be nonzero in
MNG-LC
datastreams.

<p>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.

<p>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.

<p>Bits 10 through 15 of the simplicity profile are reserved for future
MNG versions, and must be zero in this version.

<p>Bits 16 through 30 are available for private test or experimental versions.
The most significant bit (bit 31) must be zero.

<p>When bit 1 is zero ("simple" MNG features are absent), the
datastream does not contain the <span class=cn>DEFI</span>, <span class=cn>FRAM</span>, <span class=cn>MAGN</span>,
or global <span class=cn>PLTE</span> and <span class=cn>tRNS</span> chunks, and filter method 64 is
not used in any embedded PNG datastream.


<p>"Transparency is absent or can be ignored" means that either the
MNG or
PNG <span class=cn>tRNS</span>
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).

<p>"Semitransparency is absent" means that if the
MNG or
PNG <span class=cn>tRNS</span>
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 <span class=cn>JDAA</span> chunk is not present.
The "semitransparency"
flag means nothing and must be 0 if bit 3 is 0 or bit 6 is 0.

<p>"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.

<p>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.

<p>The "stored object buffers" flag
must be zero in
MNG-VLC
and MNG-LC
datastreams.

<p>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.


<p>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
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.

<h4><a name="mng-MEND">4.1.2. <span class=cn>MEND </span>End of MNG datastream</a></h4>

<p>The <span class=cn>MEND</span> chunk's data length is zero.  It signifies the end
of a MNG datastream.

<h4><a name="mng-LOOP">4.1.3. <span class=cn>LOOP, ENDL</span> Define a loop</a></h4>

<p>The <span class=cn>LOOP</span> chunk
can be ignored by
MNG-LC
decoders, along with the <span class=cn>ENDL</span> chunk.

<h3><a name="critical-define">4.2. Critical MNG image defining chunks</a></h3>

<p>The chunks described in this section create
images and may cause them to be immediately displayed.


<h4><a name="mng-DEFI">4.2.1. <span class=cn>DEFI</span> Define an object</a></h4>

<p>The <span class=cn>DEFI</span> chunk sets the default set of object attributes
(<code class=expr>object_id</code>, <code class=expr>do_not_show</code> flag,
<code class=expr>concrete_flag</code>, location, and clipping boundaries) for
any subsequent images that are defined with <span class=cn>IHDR-IEND</span>,
or <span class=cn>JHDR-IEND</span> datastreams.

<p>If bit 1 of the <span class=cn>MHDR</span> simplicity profile is 0 and bit 0 is 1,
the <span class=cn>DEFI</span> chunk must not be present.

<p>The <span class=cn>DEFI</span> chunk contains 2, 3, 4, 12, or 28 bytes.  If any
field is omitted, all subsequent fields must also be omitted.

<pre>
   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).
</pre>


<p>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, <a href="#d-clipping">below</a>).

If no <span class=cn>DEFI</span> chunk has appeared in the datastream,
the decoder must use the following default values:
<pre>
                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
</pre>


<h4><a name="mng-PLTE">4.2.2. <span class=cn>PLTE and tRNS</span> Global palette</a></h4>

<p>The <span class=cn>PLTE</span> chunk has the same format as a PNG <span class=cn>PLTE</span>
chunk.  It provides a global palette that is inherited by PNG
datastreams that contain an empty <span class=cn>PLTE</span> chunk.

<p>The <span class=cn>tRNS</span> chunk has the same format as a PNG <span class=cn>tRNS</span>
chunk.  It provides a global transparency array that is inherited along
with the global palette by PNG
datastreams that contain an empty <span class=cn>PLTE</span> chunk.

<p>If a PNG datastream is present that does not contain an empty
<span class=cn>PLTE</span> chunk, neither the global <span class=cn>PLTE</span> nor the
global <span class=cn>tRNS</span> data is inherited by that datastream.

<p>If the global <span class=cn>PLTE</span> chunk is not present, each
indexed-color PNG in the datastream must supply its own <span class=cn>PLTE</span>
(and <span class=cn>tRNS</span>, if it has transparency) chunks.

<p>The global <span class=cn>PLTE</span> chunk is not permitted in MNG-VLC datastreams.


<h4><a name="mng-IHDR">4.2.3. <span class=cn>IHDR</span>, PNG chunks, <span class=cn>IEND</span></a></h4>

<p>A PNG (Portable Network Graphics) datastream.

<p>See the PNG specification <span class=ref>[<a href="#PNG">PNG</a>]</span>
and the Extensions to the PNG Specification document <span class=ref>[<a href="#PNG-EXT" >PNG-EXT</a>]</span> 
for the format of the PNG chunks.

<p>The <span class=cn>IHDR</span> and <span class=cn>IEND</span> 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.

<ul>
<li>An additional PNG filter method is defined:
<pre>
   64: Adaptive filtering with five basic types and intrapixel
       differencing.
</pre>
<p>
The intrapixel differencing transformation, which is a modification of
a method previously used in the LOCO image format
<span class=ref>[<a href="#LOCO">LOCO</a>]</span>, 
is
<pre>
   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)
</pre>
<p>
in which S0-S3 are the samples to be passed to the next stage of the
filtering procedure.

<p>The transformation is done in integer arithmetic in sufficient
precision to hold intermediate results, and the result is calculated
modulo <code class=expr>2<sup>sample_depth</sup></code>.
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.

<p>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.

<p>To recover the samples, the transformation is undone after
undoing the basic filtering, by the inverse of the intrapixel differencing
transformation, which inverse is
<pre>
   Red   = S0 + S1
   Green = S1
   Blue  = S2 + S1
   Alpha = S3
</pre>
<p>
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
<code class=expr>2<sup>sample_depth</sup></code>.

<p>
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).

<p>
The extra filter method can also be used in PNG datastreams that is
embedded in Delta-PNG and BASI datastreams.

<p>
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.

<p>
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.

<p>

<li>If a global <span class=cn>PLTE</span> chunk appears in the top-level MNG
datastream, the PNG datastream can have an empty <span class=cn>PLTE</span> chunk
to direct that the global <span class=cn>PLTE</span> and <span class=cn>tRNS</span> data be used.
If an empty
<span class=cn>PLTE</span> chunk is not present, the data is not inherited.  MNG
applications that recreate PNG files must write the global <span class=cn>PLTE</span>
chunk rather than the empty one in the output PNG file, along with the
global <span class=cn>tRNS</span> data if it is present.  The global <span class=cn>tRNS</span>
data can be subsequently overridden
by a <span class=cn>tRNS</span> chunk in the PNG datastream.  It is an error
for the PNG datastream to contain an empty <span class=cn>PLTE</span> chunk when the
global <span class=cn>PLTE</span> chunk is not present or has been nullified.


<p>

<li>The PNG <span class=cn>oFFs</span> and <span class=cn>pHYs</span> chunks and any chunks
in a future version of this specification
that attempt to set the pixel dimensions or the drawing location must
be ignored by MNG viewers and simply copied (according to the copying
rules) by MNG editors.

<p>

<li>The PNG <span class=cn>gIFg</span>, <span class=cn>gIFt</span>, and <span class=cn>gIFx</span> chunks must
be ignored by viewers and must be copied according to the copying rules
by MNG editors.
<p>

</ul>

<p>If <code class=expr>do_not_show</code> is zero for the image when the <span class=cn>IHDR</span>
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.


<h4><a name="mng-JHDR">4.2.4. <span class=cn>JHDR</span>, JNG chunks, <span class=cn>IEND</span></a></h4>

<p>A JNG (JPEG Network Graphics) datastream.

<p>See the JNG specification
for the format of the JNG datastream.

<p>The <span class=cn>JHDR</span> and <span class=cn>IEND</span> chunks and any chunks between them
are written and decoded according to the JNG specification.

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

<p>MNG-LC
applications are not expected to process JNG
datastreams unless they have been enhanced with JNG capability.


<h4><a name="mng-TERM">4.2.5. <span class=cn>TERM </span>Termination action</a></h4>

<p>The <span class=cn>TERM</span> chunk suggests how the end of the MNG datastream
should be handled, when a <span class=cn>MEND</span> chunk is found.  It contains
either a single byte or ten bytes:

<pre>
   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.
                              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.
   
                             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.
</pre>


<p>The <span class=cn>TERM</span> chunk, if present, must appear either immediately
after the <span class=cn>MHDR</span> chunk or immediately prior to a <span class=cn>SEEK</span>
chunk.
Only one <span class=cn>TERM</span> chunk is permitted in a MNG datastream.

<p>Simple viewers and single-frame viewers can ignore the <span class=cn>TERM</span>
chunk.  It has been made critical only so MNG editors will not
inadvertently relocate it.

<h3><a name="critical-display">4.3. Critical MNG image displaying chunks</a></h3>

<p>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.

<h4><a name="mng-BACK">4.3.1. <span class=cn>BACK </span>Background</a></h4>

<p>The <span class=cn>BACK</span> chunk suggests or mandates a background
color
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 <span class=cn>BACK</span> chunk provides new background information
before that happens.

<p>The <span class=cn>BACK</span> chunk contains 6, 7, 9, or 10 bytes.  If any field is
omitted, all subsequent fields must also be omitted.
<pre>
   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 is advisory.  Applications
                           can use it if they choose to.
                        1: Background color is mandatory.
                           Applications must use it.
                        This byte can be omitted.  If so, the
                        background color is advisory.
</pre>

<p>The first layer displayed by a viewer is always a
background layer that fills the entire frame.
The <span class=cn>BACK</span> 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
<span class=cn>BACK</span> 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 <span class=cn>FRAM</span> chunk with framing mode 3 or 4 causes another
background layer to be generated.

<p>Viewers are expected, however, to composite every foreground layer
against a fresh copy of the background, when the framing
mode given in the <span class=cn>FRAM</span> chunk is 3, and to composite the first
foreground layer of each subframe against a fresh copy of the background,
when the framing mode is 4.  Also, when the framing mode is 3 or 4 and no
foreground layer appears between consecutive <span class=cn>FRAM</span> chunks,
a background layer alone is displayed as a separate frame.

<p>The images and
the background are both clipped to the subframe boundaries given in the
<span class=cn>FRAM</span> chunk.  Anything outside these boundaries is inherited
from the previous subframe.
If the background layer is transparent and the subsequent foreground layers
do not cover the transparent area with opaque pixels, the application's
background becomes re-exposed in any uncovered pixels within the subframe
boundaries.


<p>Note that any background layer, including the one that begins the
first frame of the datastream, must be inserted at the latest
possible moment, in case the background image is
replaced
or in case a new <span class=cn>BACK</span> chunk appears,
before that moment.


<p>The three <span class=cn>BACK</span> components are always written as though
for an RGBA PNG with 16-bit sample depth.  For example, a mid-level
gray background could be specified with the RGB color samples
{1.09, 1.09, 1.09}.
The background color is interpreted in
the current color space as defined by any top-level <span class=cn>gAMA</span>,
<span class=cn>cHRM</span>, <span class=cn>iCCP</span>, <span class=cn>sRGB</span> chunks that have appeared
prior to the <span class=cn>BACK</span> chunk in the MNG datastream.  If no such
chunks appear, the color space is unknown.


<p>The data from the <span class=cn>BACK</span> chunk takes effect the next time the
decoder needs to insert a background layer, and remains in effect until
another <span class=cn>BACK</span> chunk appears.

<p>For the purpose of counting layers, when the background consists of
both a background color and a background image, these are considered to
generate a single layer and there is no delay
between displaying the background color and the background image.

<p>Multiple instances of the <span class=cn>BACK</span> chunk are permitted in a MNG
datastream.

<p>The <span class=cn>BACK</span> chunk can be omitted.  If a background is needed
and the <span class=cn>BACK</span> chunk is omitted, then the viewer must supply its
own background.  For the purpose of counting layers, such a viewer-supplied
background layer is counted the same as a background supplied by the
<span class=cn>BACK</span> chunk.

<p>In practice, most applications that use MNG as part of a
larger composition should ignore the <span class=cn>BACK</span> data if
<span class=expr>mandatory_background=0</span> and the application already has
its own background definition.  This will frequently be the case in
World Wide Web pages, to achieve nonrectangular transparent animations
displayed against the background of the page.

<h4><a name="mng-FRAM">4.3.2. <span class=cn>FRAM </span>Frame definitions</a></h4>

<p>The <span class=cn>FRAM</span> chunk provides information that a decoder needs for
generating frames and interframe delays.  The <span class=cn>FRAM</span> parameters
govern how the decoder is to behave when it encounters a <span class=cn>FRAM</span>
chunk, or an embedded image.
The <span class=cn>FRAM</span> chunk also delimits subframes.

<p>If bit 1 of the <span class=cn>MHDR</span> simplicity profile is 0 and bit 0 is 1,
the <span class=cn>FRAM</span> chunk must not be present.

<p>An empty <span class=cn>FRAM</span> chunk is just a subframe delimiter.  A
nonempty one is a subframe delimiter, and it also changes <span class=cn>FRAM</span>
parameters, either for the upcoming subframe or until reset
("upcoming subframe" refers to the subframe immediately following the
<span class=cn>FRAM</span> chunk).  When the
<span class=cn>FRAM</span> chunk is not empty, it contains a framing-mode byte, an
optional name string, a zero-byte separator, plus four 1-byte fields
plus a variable number of optional fields.

<p>When the <span class=cn>FRAM</span> parameters are changed, the new parameters
affect the subframe that is about to be defined, not the one that is
being terminated by the <span class=cn>FRAM</span> chunk.

<pre>
   Framing_mode:  1 byte.
   
                    0:  Do not change framing mode.
   
                    1:  No background layer is generated, except for one
                        ahead of the very first foreground layer in the
                        datastream.  The interframe delay is associated
                        with each foreground layer in the subframe.
   
                    2:  No background layer is generated, except for one
                        ahead of the very first image in the datastream.
                        The interframe delay is associated only with the
                        final layer in the subframe.  A zero interframe
                        delay is associated with the other layers in the
                        subframe.
   
                    3:  A background layer is generated ahead of each
                        foreground layer.  The interframe delay is
                        associated with each foreground layer, and a zero
                        delay is associated with each background layer.
   
                    4:  The background layer is generated only ahead of
                        the first foreground layer in the subframe.  The
                        interframe delay is associated only with the final
                        foreground layer in the subframe.  A zero
                        interframe delay is associated with the background
                        layers, except when there is no foreground layer
                        in the subframe, in which case the interframe delay
                        is associated with the sole background layer.
   
   Subframe_name: 0 or more bytes (Latin-1 Text).  Can be omitted; if so,
                  the subframe is nameless.
   
   Separator:     1 byte:  (null).  Must be omitted if the subsequent
                  fields are also omitted.
   
   Change_interframe_delay:
                  1 byte.
                    0:  No.
                    1:  Yes, for the upcoming subframe only.
                    2:  Yes, also reset default.
   
                  This field and all subsequent fields can be omitted as a
                  group if no frame parameters other than the framing mode
                  or the subframe name are changed.
   
   Change_timeout_and_termination:
                  1 byte
                    0:  No.
                    1:  Deterministic, for the upcoming subframe only.
                    2:  Deterministic, also reset default.
                    3:  Decoder-discretion, for the upcoming subframe only.
                    4:  Decoder-discretion, also reset default.
                    5:  User-discretion, for the upcoming subframe only.
                    6:  User-discretion, also reset default.
                    7:  External-signal, for the upcoming subframe only.
                    8:  External-signal, also reset default.
   
                 This field can be omitted only if the previous field is
                 also omitted.
   
   Change_layer_clipping_boundaries:
                 1 byte.
                    0:  No.
                    1:  Yes, for the upcoming subframe only.
                    2:  Yes, also reset default.
   
                 This field can be omitted only if the previous field is
                 also omitted.
   
   Change_sync_id_list:
                 1 byte.
                    0:  No.
                    1:  Yes, for the upcoming subframe only.
                    2:  Yes, also reset default list.
   
                 This field can be omitted only if the previous field is
                 also omitted.
   
   Interframe_delay:
                  4 bytes (unsigned integer).  This field must be omitted
                    if the change_interframe_delay field is zero or is
                    omitted.  The range is [0..2^31-1] ticks.
   
   Timeout:       4 bytes (unsigned integer).  This field must be omitted
                    if the change_timeout_and_termination field is zero or
                    is omitted.  The range is [0..2^31-1].  The value
                    2^31-1 (0x7fffffff) ticks represents an infinite
                    timeout period.
   
   Layer_clipping_boundary_delta_type:
                  1 byte (unsigned integer).
                    0: Layer clipping boundary values are given directly.
                    1: Layer clipping boundaries are determined by adding
                       the FRAM data to the values from the previous
                       subframe.
                  This and the following four fields must be omitted if the
                  change_layer_clipping_boundaries field is zero or is
                  omitted.
   
   Left_layer_cb or Delta_left_layer_cb:
                  4 bytes (signed integer).
   
   Right_layer cb or Delta_right_layer_cb:
                  4 bytes (signed integer).
   
   Top_layer_cb or Delta_top_layer_cb:
                  4 bytes (signed integer).
   
   Bottom_layer_cb or Delta_bottom_layer_cb:
                  4 bytes (signed integer).
   
   Sync_id:       4 bytes (unsigned integer).  Must be omitted if
                    change_sync_id_list=0 and can be omitted if the new
                    list is empty; repeat until all sync_ids have been
                    listed.  The range is [0..2^31-1].
</pre>

<p>Framing modes:

<p>The <code class=expr>framing_mode</code> provides information to the decoder that it uses
whenever it is about to display an image, and when it is processing
the <em>next</em> <span class=cn>FRAM</span> chunk.

<p>Any of these events generates a layer, even
if no pixels are actually changed:

<ul>

<li>Decoding a <span class=cn>IHDR-IEND</span> sequence at the MNG level, when it
defines a potentially visible image.

<p>

<li>Decoding a <span class=cn>JHDR-IEND</span> sequence at the MNG level, when it
defines a potentially visible image.


<p>

<li>Also, decoding a <span class=cn>FRAM</span> chunk, when the current framing
mode requires a background layer (framing mode is 3 or 4) and none of
the above have already caused the background layer to be inserted
since the previous <span class=cn>FRAM</span> chunk.  Such background layers must
be included in the <code class=expr>nominal_layer_count</code> field of the <span class=cn>MHDR</span>
chunk.

<p>

</ul>

<p>When a decoder is ready to perform a display update, it must check
the framing mode, to decide whether it should
restore the background (framing modes 3 and 4) or not (framing modes 1 and 2),
and whether it needs to wait for the interframe delay to elapse before
continuing (framing modes 1 and 3) or not (framing modes 2 and 4).

<p>When the interframe delay is zero, viewers are not required actually
to update the display but can continue to process the remainder of the
frame and composite the next image over the existing frame before displaying
anything.  The final result must appear the same as if each image had been
displayed in turn with no delay.

<p>Regardless of the framing mode, encoders must insert a
background layer, with a zero delay, ahead of the first image layer in the
datastream,
even when the <span class=cn>BACK</span> chunk is not present or has been clipped
to less than full-frame.  This layer
must be included in the layer count but not in the frame count.


<dl>

<dt><strong>Framing mode 1</strong>

<dd>When <code class=expr>framing_mode</code> is 1, the decoder must wait until the
interframe delay for the previous frame has elapsed before displaying
each image.  Each foreground layer is a separate subframe and frame.

<p>

<dt><strong>Framing mode 2</strong>

<dd>Framing mode 2 is the same as framing mode 1, except that the
interframe delay occurs between subframes delimited by <span class=cn>FRAM</span> chunks
rather than between individual layers.
All of the foreground layers
between consecutive <span class=cn>FRAM</span> chunks make up a single subframe.

<p>In the usual case, the interframe delay is nonzero, and
multiple layers are present, so each
frame is a single subframe composed of several layers.  When the interframe
delay is zero, the subframe is combined with subsequent subframes until one with
a nonzero interframe delay is encountered, to make up a single frame.

The decoder must wait until the interframe delay for the previous
frame has elapsed before displaying the frame.
When <span class=expr>framing_mode=2</span>, viewers are
expected to display all of the images in a frame at once, if possible, or as
fast as can be managed, without clearing the display or restoring the
background.

<p>

<dt><strong>Framing mode 3</strong>

<dd>When <span class=expr>framing_mode=3</span>, a background layer is generated and
displayed immediately before each image layer is displayed.  Otherwise,
framing mode 3 is identical to framing mode 1.
Each foreground layer together with its background layer make up a single
subframe and frame.

<p>When the background layer is transparent or does not fill the clipping
boundaries of the image layer, the application
is responsible for supplying a background color or image against which
the image 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 (see the
"background transparency" bit of the simplicity profile).


<p>

<dt><strong>Framing mode 4</strong>

<dd>When <code class=expr>framing_mode=4</code>, the background layer is generated
and displayed immediately
before each frame, i.e., after each <span class=cn>FRAM</span> chunk, with no interframe
delay before each image.  The decoder must wait until the
interframe delay for the previous frame has elapsed before displaying the
background layer.
Otherwise, framing mode 4 is identical to framing mode 2.
All of the foreground layers
between consecutive <span class=cn>FRAM</span> chunks, together with one background
layer,  make up a single subframe.

<p>A transparent or clipped background layer is handled as in framing mode 3.

<p>

</dl>

<p>The subframe name must conform to the same formatting rules as
those for a PNG <span class=cn>tEXt</span> 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 (unless
the subframe name is omitted) and no more than 79 characters in the
keyword.  Keywords are case-sensitive.  There is no null byte within
the keyword.
Applications can use this
field for such purposes as constructing an external list of subframe
in the datastream.  The subframe name only applies to the upcoming
subframe; subsequent subframes are unnamed unless they also have their
own <code class=expr>frame_name</code> field.  It is recommended that the same name
not appear in any other <span class=cn>FRAM</span> chunk or in any <span class=cn>SEEK</span>
or <span class=cn>eXPI</span>
chunk.  Subframe names should not begin with the
case-insensitive
strings "CLOCK(", "FRAME(", or "FRAMES(",
which are reserved for use in URI queries and
fragments, as explained in the full MNG specification.

<p>The interframe delay value is the desired minimum time to elapse from
the beginning of displaying one frame until the beginning of displaying
the next frame.  When the interframe delay is nonzero, which will
probably be the usual case, layers are frames.  When it is zero, a
frame consists of any number of consecutive subframes, until
a nonzero delay subframe is encountered and completed.  Decoders are not
obligated or encouraged to display such subframes individually; they can
composite them offscreen and only display the complete frame.

<p>There is no interframe delay before the first layer (the implicit
background layer) in the datastream nor after the final frame, regardless
of the framing mode.

<p>The timeout field can be a number or &lt;infinity&gt;.  Infinity
can be represented by 0x7fffffff.  Under certain termination conditions,
the application can adjust the interframe delay, provided that it is
not greater than the sum of the specified interframe delay and
the timeout.

<p>The termination condition given in the
<code class=expr>change_timeout_and_termination</code> field specifies whether and
over what range the normal interframe delay can be lengthened or
shortened.  It can take the following values:

<dl>

<dt><strong>deterministic</strong>

<dd>The frame endures no longer than the normal interframe delay.  Even
though this is the default, a streaming encoder talking to a real-time
decoder might write a <span class=cn>FRAM</span> with a termination condition of
"deterministic" to force the display to be updated while the encoder
decides its next move.

<p>

<dt><strong>decoder-discretion</strong>

<dd>If the interframe delay is nonzero, the decoder can shorten or lengthen
the duration of the frame, to any duration between the interframe delay
and the timeout.  A streaming decoder could take the opportunity to
wait for its input buffer to fill to a comfortable level.

<p>

<dt><strong>user-discretion</strong>

<dd>If the interframe delay is nonzero, the decoder should wait for
permission from the user (e.g., via a keypress) before proceeding, but
must wait no less than the smaller of the timeout and the interframe
delay nor no longer than the greater of the timeout and the interframe
delay.  If the decoder cannot interact with the user, this condition
degenerates into "decoder-discretion".

<p>

<dt><strong>external-signal</strong>

<dd>If the interframe delay is nonzero, the decoder should wait for
the arrival of a signal whose number matches a <code class=expr>sync_id</code>, but
must wait no less than the smaller of the timeout and the interframe
delay nor no longer than the greater of the timeout and the interframe
delay.  If the decoder cannot receive signals, this condition degenerates
into "decoder-discretion".

<p>

</dl>

<p>The <code class=expr>sync_id</code> list can be omitted if the termination
condition is not "external-signal".

<p>When the <code class=expr>sync_id</code> list is changed, the number of
<code class=expr>sync_id</code> entries is determined by the remaining length of the
chunk data, divided by four.  This number can be zero, which either
inactivates the existing <code class=expr>sync_id</code> list for one frame or
deletes it.

<p>The initial values of the <span class=cn>FRAM</span> parameters are:

<pre>
     Framing mode             = 1
     Subframe name            = &lt;empty string&gt;
     Interframe delay         = 1
     Left subframe boundary   = 0
     Right subframe boundary  = frame_width
     Top subframe boundary    = 0
     Bottom subframe boundary = frame_height
     Termination              = deterministic
     Timeout                  = 0x7fffffff (infinite)
     Sync id                  = &lt;empty list&gt;
</pre>

<p>The layer clipping boundaries from
the <span class=cn>FRAM</span> chunk are only
used for clipping, not for placement.
The <span class=cn>DEFI</span>
chunk
can be used to specify the placement of each
image within the layer.  The <span class=cn>DEFI</span>
chunk can be used to specify
clipping boundaries for each image.
Even when the left and top subframe
boundaries are nonzero, the image locations are measured with respect to
the {0,0} position in the display area.
The left and top subframe boundaries are inclusive, while the right and bottom
boundaries are exclusive.

<p>If the layers
do not cover the entire area defined by the layer clipping
boundaries with opaque pixels, they are composited against
whatever already occupies the area, when the framing mode is 1 or 2.
When the framing mode is 3 or 4, they are composited against
the background defined by the
<span class=cn>BACK</span> chunk, or against an application-defined background, if
the <span class=cn>BACK</span> chunk is not present or does not define a mandatory
background.  The images, as well as the background, are clipped to the
layer clipping boundaries for the subframe.  Any pixels outside the
layer clipping boundaries remain unchanged from the previous layer.

<p>The <code class=expr>interframe_delay</code> field gives the duration of
display, which is the minimum time that must elapse from the
beginning of displaying one layer until the beginning of displaying
the next (unless the termination condition and timeout permit this
time to be shortened).  It
is measured in "ticks" using the tick length determined from
<code class=expr>ticks_per_second</code> defined in the <span class=cn>MHDR</span> chunk.
When the interframe delay is zero, it indicates that
the layer is to be combined with the subsequent layer or layers into a
single frame, until a nonzero interframe delay is specified or
the <span class=cn>MEND</span> chunk is reached.

<p>A viewer does not actually have to follow the procedure of erasing
the screen, redisplaying the background, and recompositing the images
against it, but what is displayed when the frame is complete must be the
same as if it had.  It is sufficient to redraw the parts of the display
that change from one frame to the next.

<p>The <code class=expr>sync_id</code> list provides a point at which the processor
must wait for all pending processes to reach the synchronization
point having the same <code class=expr>sync_id</code> before resuming, perhaps
because of a need to synchronize a sound datastream (not defined
in this specification) with the display, to synchronize stereo
images, and the like.  When the period defined by the sum of the
<code class=expr>interframe_delay</code> and the <code class=expr>timeout</code> fields
elapses, processing can resume even though the processor has not
received an indication that other processes have reached the
synchronization point.

<p>Note that the synchronization point does not occur immediately, but
at the end of the first frame that follows the <span class=cn>FRAM</span> chunk.

<p>The identifier <code class=expr>sync_id=0</code> is reserved to represent
synchronization with a user input from a keyboard or pointing device.
The <code class=expr>sync_id</code> values 1-255 are reserved to represent the
corresponding ASCII letter, received from the keyboard (or a simulated
keyboard), and values 256-1023 are reserved for future definition
by this specification.  If multiple channels (not defined in this
specification) are not present, viewers can ignore other values
appearing in the <code class=expr>sync_id</code> list.

<p>Note that the rules for omitting the interframe delay, timeout, clipping
boundary, and sync id fields of the <span class=cn>FRAM</span> chunk are different from
the general rule stated in MNG Chunks, <a href="#top-mng">above (Chapter 4)</a>.
These fields are either present in the chunk data or omitted from it according
to the contents of the corresponding "change" byte.



<h3><a name="mng-SAVE-SEEK">4.4. <span class=cn>SAVE</span> and <span class=cn>SEEK</span> chunks</a></h3>

<p>Simple decoders that only read MNG datastreams sequentially can
safely ignore the <span class=cn>SAVE</span> and <span class=cn>SEEK</span>
chunks.

<h3><a name="mng-ancillary">4.5. Ancillary MNG chunks</a></h3>

<p>This section describes ancillary MNG chunks.  MNG-compliant decoders
are not required to recognize and process them.

<h4><a name="mng-eXPI">4.5.1. <span class=cn>eXPI </span>Export image</a></h4>

<p>The <span class=cn>eXPI</span> chunk takes a snapshot of
an image,
associates the name with that snapshot, and makes
the name available to the "outside world" (like a scripting
language).

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

<pre>
   Snapshot_id:   2 bytes (unsigned integer).  Must be zero in
                    MNG-LC datastreams.
   Snapshot_name: 1-79 bytes (Latin-1 text).
</pre>

<p>When the snapshot_id is zero, the snapshot is the first instance
of an embedded image
following the <span class=cn>eXPI</span> chunk.

<p>Note that the <code class=expr>snapshot_name</code> is associated with the
snapshot, not with the <code class=expr>snapshot_id</code> nor its subsequent contents;
changing the image identified by <code class=expr>snapshot_id</code> will not
affect the snapshot.
The <code class=expr>snapshot_name</code> means nothing inside the scope of the
MNG-LC specification.
If two <span class=cn>eXPI</span> 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 <code class=expr>snapshot_name</code> not be
the same as that appearing in any other <span class=cn>eXPI</span>
chunk or in any <span class=cn>FRAM</span>
chunk.  A decoder that knows of no
"outside world" can simply ignore the <span class=cn>eXPI</span> chunk.  This
chunk could be used in MNG datastreams that define libraries of related
images, rather than animations, to allow applications to extract
images by their <code class=expr>snapshot_id</code>.

<p>Names beginning with the word "thumbnail" are reserved for snapshot
images that are intended to make good icons for the MNG.  Thumbnail
images are regular PNG
images, but they would normally have
smaller dimensions and fewer colors than the MNG 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.

<p>The <code class=expr>snapshot_name</code> string must follow the format of a
<span class=cn>tEXt</span> 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 <code class=expr>snapshot_name</code> 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 <a href="#URL">below</a>).

<p>Multiple instances of the <span class=cn>eXPI</span> chunk are permitted
in a MNG datastream, and they need not have different values of
<code class=expr>snapshot_id</code>.


<h4><a name="mng-phys">4.5.2. <span class=cn>pHYg </span>Physical pixel size (global)</a></h4>

<p>The MNG <span class=cn>pHYg</span> chunk is identical in syntax to the PNG
<span class=cn>pHYs</span> chunk.  It applies to complete
full-frame MNG layers and not to the individual images within them.
<p>Conceptually, a MNG viewer that processes the <span class=cn>pHYg</span> chunk will
first composite each image into a full-frame layer, then apply
the <span class=cn>pHYg</span> scaling to the layer, and finally composite the scaled
layer against the frame.
MNG datastreams can include both the PNG <span class=cn>pHYs</span> chunk (either at the
MNG top level or within the PNG and JNG datastreams) and the MNG
<span class=cn>pHYg</span> chunk (only at the MNG top level), to ensure that the images
are properly displayed either when displayed by a MNG viewer or
when extracted into a series of individual PNG or JNG datastreams
and then displayed by a PNG or JNG application.  The <span class=cn>pHYs</span> and
<span class=cn>pHYg</span> chunks would normally contain the same values, but this is
not necessary.

<p>The MNG top-level <span class=cn>pHYg</span> chunk can be nullified by a
subsequent empty <span class=cn>pHYg</span> chunk appearing in the MNG top level.

<h3><a name="mng-png">4.6. Ancillary PNG chunks</a></h3>

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

<ul>

<li><span class=cn>iTXt</span>, <span class=cn>tEXt</span>, <span class=cn>zTXt</span>

<p>

<li><span class=cn>tIME</span> Same format as in PNG.  Can appear at most once in the
prologue segment (before the first <span class=cn>SEEK</span> chunk), and at most
once per segment (between two consecutive <span class=cn>SEEK</span> chunks).  In the
prologue it indicates the last time any part of the MNG was modified.
In a regular segment (between <span class=cn>SEEK</span> chunks or between the final
<span class=cn>SEEK</span> chunk and the <span class=cn>MEND</span> chunk), it indicates the
last time that segment was modified.

<p>A MNG editor that writes PNG datastreams should not include
the top-level <span class=cn>iTXt</span>, <span class=cn>tEXt</span>, <span class=cn>tIME</span>,
and <span class=cn>zTXt</span> chunks in the generated PNG datastreams.

<p>

<li><span class=cn>cHRM</span>, <span class=cn>gAMA</span>, <span class=cn>iCCP</span>, <span class=cn>sRGB</span>,
<span class=cn>bKGD</span>, <span class=cn>sBIT</span>, <span class=cn>pHYs</span>

<p>These PNG chunks are also defined at the MNG 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
MNG top level.

<p>In the MNG 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.

<p>A MNG editor that writes PNG or JNG datastreams is expected to
include the top-level <span class=cn>cHRM</span>, <span class=cn>gAMA</span>, <span class=cn>iCCP</span>,
and <span class=cn>sRGB</span> chunks in the generated PNG or JNG datastreams, if
the embedded image does not contain its own chunks that define the
color space.  When it writes the <span class=cn>sRGB</span> chunk, it should write
the <span class=cn>gAMA</span> chunk (and perhaps the <span class=cn>cHRM</span> chunk), in
accordance with the PNG specification, even though no <span class=cn>gAMA</span> or
<span class=cn>cHRM</span> chunk is present in the MNG datastream.
It is also expected to write the <span class=cn>pHYs</span> chunk and the reformatted
top-level <span class=cn>bKGD</span> chunk in the generated PNG or JNG datastreams, and
the reformatted <span class=cn>sBIT</span> chunk only in generated PNG datastreams, when
the datastream does not have its own <span class=cn>bKGD</span>, <span class=cn>pHYs</span>,
or <span class=cn>sBIT</span> chunks.

<p>The top-level <span class=cn>sRGB</span> chunk nullifies the preceding
top-level <span class=cn>gAMA</span> and <span class=cn>cHRM</span> chunks, if any, and
either the top-level <span class=cn>gAMA</span> or the top-level <span class=cn>cHRM</span> chunk
nullifies the preceding top-level <span class=cn>sRGB</span> chunk, if any.


<p>

</ul>


<h2><a name="jng">5. The JPEG Network Graphics (JNG) Format</a></h2>

<p>JNG (JPEG Network Graphics) is the lossy sub-format for MNG
objects.
It is described in the full MNG specification and is also available
as a separate extract from the full MNG specification.
Both documents are available at the MNG home page,
<pre>
   <a href="http://www.libpng.org/pub/mng/">http://www.libpng.org/pub/mng/</a>
</pre>

<p>MNG-LC
applications can choose to support JNG or not. Those that
do not can check bit 4 (JNG is present/absent) of the <span class=cn>MHDR</span>
simplicity profile to decide whether they can process the datastream.



<h2><a name="Delta-PNG">6. The Delta-PNG Format</a></h2>

<p>Omitted.

<h2><a name="registration">7. Extension and Registration</a></h2>

<p>New public chunk types, and additional options in existing
public chunks, can be proposed for inclusion in this specification
by contacting the PNG/MNG specification maintainers at <a href="mailto:png-info@uunet.uu.net"><span class=email>png-info@uunet.uu.net</span></a>,
<a href="mailto:png-group@w3.org"><span class=email>png-group@w3.org</span></a>, 
or
at <a href="mailto:mng-list@ccrc.wustl.edu" ><span class=email>mng-list@ccrc.wustl.edu</span></a>.

<p>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 MNG.  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.

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

<p>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.

<h2><a name="copying">8. Chunk Copying Rules</a></h2>

<p>The chunk copying rules for MNG are similar to those in PNG.
Authors of MNG editing applications should consult the full MNG
specification for details.


<h2><a name="d-minimum">9. Minimum Requirements for MNG-LC-Compliant Viewers</a></h2>

<p>This section specifies the minimum level of support that is expected of
MNG-LC-compliant
decoders, and provides recomendations 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.


<p>
Applications that provide less than minimal MNG
support should check the MHDR "simplicity profile" for the
presence of features that they are unable to support or do not wish to
support.  A specific subset, in which
"complex MNG features"
and JNG are absent,
is called <em>"MNG-LC"</em>.
In MNG-LC datastreams, bit 0
of the simplicity profile must be 1 and bits 2 and 4
must be 0.
Another subset is called <em>"MNG-VLC"</em>.
In MNG-VLC datastreams, "simple MNG features"
are also absent, and bit 1 must therefore also be 0.

<p>Subsets are useable when the set of MNG datastreams to be processed
is known to be (or is very likely to be) limited to the feature set in
MNG-LC.
Limiting the feature set in a widely-deployed WWW browser to anything
less than MNG with 8-bit JNG support would be highly inappropriate.

<p>Some subsets of MNG
support are listed in the following table, more
or less in increasing order of complexity.
<pre>
   MHDR Profile bits        Profile  Level of support
   31-10 9 8 7 6 5 4 3 2 1 0 value
   
     0   0 0 0 1 0 0 0 0 0 1   65    MNG-VLC without transparency
     0   0 1 1 1 0 0 1 0 0 1  457    MNG-VLC
     0   0 1 1 1 0 1 1 0 0 1  473    MNG-VLC with JNG
     0   0 1 1 1 0 0 1 0 1 1  459    MNG-LC
     0   0 1 1 1 0 1 1 0 1 1  475    MNG-LC with JNG
         | | | | | | | | | |
         | | | | | | | | | +- Validity
         | | | | | | | | +--- Simple MNG features
         | | | | | | | +----- Must be zero in MNG-LC
         | | | | | | +------- Transparency
         | | | | | +--------- JNG
         | | | | +----------- Must be zero in MNG-LC
         | | | +------------- Validity of bits 7,8, and 9
         | | +--------------- Semitransparency
         | +----------------- Background transparency
         +------------------- Must be zero in MNG-LC
</pre>

<p>One reasonable path for an application developer to follow might
be to develop and test the application at each of the following
levels of support in turn:
<ol>
<li>MNG-VLC,
<li>MNG-LC,
<li>MNG-LC with JNG,
<li>MNG (according to the full MNG specification).
</ol>
<p>An equally reasonable development path might be
<ol>
<li>MNG-VLC with JNG,
<li>MNG-LC with JNG,
<li>MNG (according to the full MNG specification).
</ol>
<p>On the other hand, a developer
working on an application for storing multi-page fax documents might
have no need for more than "MNG-VLC without transparency".


<h3><a name="d-min-MNG">9.1. Required MNG chunk support</a></h3>

<dl>

<dt><strong>MHDR</strong>

<dd>The
<code class=expr>ticks_per_second</code> must be supported by animation viewers.
The simplicity profile, frame count, layer count, and nominal play time
can be ignored.  Decoders that provide less than minimal support can use
the simplicity profile to identify datastreams that they are incapable
of processing.

<p>

<dt><strong>MEND</strong>

<dd>The <span class=cn>MEND</span> chunk must be recognized but does not require any
processing other than completing the last frame.

<p>

<dt><strong>Global PLTE and tRNS</strong>

<dd>Must be fully supported.  Bit 1 of the simplicity profile can be
used to promise that these chunks are not present.


<p>

<dt><strong>DEFI, BACK, MAGN,</strong>

<dd>Must be fully supported.

<p>

<dt><strong>FRAM</strong>

<dd>The <code class=expr>framing_mode</code> and clipping parameters must be
supported.  The <code class=expr>interframe_delay</code> must be supported
except by single-frame viewers.  The <code class=expr>sync_id</code> and
<code class=expr>timeout</code> data can be ignored.  Bit 1 of the simplicity profile
can be used to promise that the <span class=cn>FRAM</span> chunk is not present.


<p>

<dt><strong>LOOP, ENDL, SAVE, SEEK, TERM</strong>


<dd>Must be recognized but can be ignored.

<p>

</dl>


<h3><a name="d-min-PNG">9.2. Required PNG chunk support</a></h3>

<dl>

<dt><strong>IHDR, PLTE, IDAT, IEND</strong>

<dd>All PNG critical chunks must be fully supported.  All
values of <code class=expr>color_type</code>, <code class=expr>bit_depth</code>,
<code class=expr>compression_method</code>, <code class=expr>filter_method</code> and
<code class=expr>interlace_method</code> 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.  Alpha is not present, or can be ignored because it has no
effect on the appearance of any frame, if bit 3 of the simplicity profile is 0.
Bit 1 of the simplicity profile can be used to promise that only filter methods
defined in the PNG specification are present.

<p>

<dt><strong>tRNS</strong>

<dd>The PNG <span class=cn>tRNS</span> chunk, although it is an ancillary chunk, must be
supported in MNG-compliant viewers, at least to the degree that fully
opaque pixels are opaque and fully transparent ones are transparent.  It
is recommended that alpha data from the <span class=cn>tRNS</span> chunk be fully
supported in the same manner as alpha data from an RGBA image or a JNG
with an alpha channel contained in <span class=cn>IDAT</span> chunks.
The <span class=cn>tRNS</span> chunk is not present (or can be ignored because it has no
effect on the appearance of any frame) if bit 3 of the simplicity profile is 0.

<p>

<dt><strong>Other PNG ancillary chunks</strong>

<dd>Ancillary chunks other than PNG <span class=cn>tRNS</span> can be ignored, and do
not even have to be recognized.

<p>

<dt><strong>Color management</strong>

<dd>It is highly recommended that decoders support at least the
<span class=cn>gAMA</span> chunk to allow platform-independent color rendering.
If they support the <span class=cn>gAMA</span> chunk, they must also support the
<span class=cn>sRGB</span> chunk, at least to the extent of interpreting it as
if it were a <span class=cn>gAMA</span> chunk with gamma value 0.45455.

<p>

</dl>


<h3><a name="d-min-JNG">9.3. Optional JNG chunk support</a></h3>

<p>Bit 4 of the simplicity profile can be used to promise that
JNG chunks are not present.  Viewers that choose not to support
JNG can check this bit before deciding to proceed.
MNG-LC
decoders are not required to support JNG.

<dl>

<dt><strong>JHDR, JDAT, IDAT, JDAA, JSEP, IEND</strong>

<dd>All JNG critical chunks must be fully supported.  All
values of <code class=expr>color_type</code>, <code class=expr>bit_depth</code>,
<code class=expr>compression_method</code>, <code class=expr>filter_method</code> and
<code class=expr>interlace_method</code> 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.

<p>

<dt><strong>JNG ancillary chunks</strong>

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

<p>

<dt><strong>JNG image sample depth</strong>

<dd>Only <code class=expr>image_sample_depth=8</code> must be supported.  The <span class=cn>JSEP</span>
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 <code class=expr>image_sample_depth=20</code> in the
<span class=cn>JHDR</span> chunk.  When <code class=expr>image_sample_depth=12</code>, 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 <span class=cn>JHDR</span> chunk.

<p>

</dl>



<h2><a name="encoders">10. Recommendations for Encoders</a></h2>

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


<h3><a name="E.color">10.1. Use a common color space</a></h3>

<p>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 MNG, using
either an <span class=cn>sRGB</span> chunk or the <span class=cn>gAMA</span> and
<span class=cn>cHRM</span> chunks and perhaps the <span class=cn>iCCP</span>
chunk, and removing any color space chunks from the individual images
after converting them to the common color space.

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

<p>For single-frame MNG 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.

<h3><a name="E.framing">10.2. Use the right framing mode</a></h3>

<p>Always use framing mode 1 or 2 when all of the images are opaque.
This avoids unnecessary screen clearing, which can cause flickering.

<h3><a name="E.fram_sync">10.3. Immediate frame sync point</a></h3>

<p>If it
is necessary to establish a synchronization point immediately, this can
be done by using two consecutive <span class=cn>FRAM</span> chunks, the first setting
a temporary <code class=expr>interframe_delay=0</code>, <code class=expr>timeout</code>, and
<code class=expr>sync_id</code>, and the second establishing the synchronization
point:

<pre>
   FRAM 2 0 1 1 0 1 0000 timeout sync_id
   FRAM 0 name
</pre>




<h2><a name="decoders">11. Recommendations for Decoders</a></h2>

<h3><a name="d-simplicity">11.1. Using the simplicity profile</a></h3>

<p>The simplicity profile in the <span class=cn>MHDR</span> chunk can be ignored or
it can be used for
<ul>
<li>Deciding whether to abandon a datatream immediately if it is beyond
the decoder's capabilities.  Decoders are of course free to
plunge ahead, rendering whatever is possible and abandoning any segments
that contain critical chunks that they do not recognize or cannot handle.
Unmanageable features might not be present even when the simplicity
profile indicates that the features "might be present".
The profile
never guarantees that a certain feature is present; it only guarantees
that certain features are not present or have no effect on the appearance
of any frame.
<p>

<li>Deciding whether to perform certain optimizations.  For example, the
transparency flags can be used to determine whether full alpha composition
is going to be necessary, and to choose appropriate code paths and
internal representations of abstract objects accordingly.
<p>

</ul>


<h3><a name="errors">11.2. Decoder handling of fatal errors</a></h3>

<p>When a fatal error is encountered, such as a bad CRC or an unknown
critical MNG chunk, minimal viewers
should simply abandon the MNG datastream.

<h3><a name="interlacing">11.3. Decoder handling of interlaced images</a></h3>

<p>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 MNG authors should not
assume that the frames will be displayed in other than their final form.

<h3><a name="decoder-plte">11.4. Decoder handling of palettes</a></h3>

<p>When a <span class=cn>PLTE</span> 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.


<p>If a frame contains two or more images, the <span class=cn>PLTE</span> chunk in
one image does not affect the display of the
other.

<p>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.

<h3><a name="d-single">11.5. Behavior of single-frame viewers</a></h3>

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

<h3><a name="d-clipping">11.6. Clipping</a></h3>

<p>MNG-LC provides three
types of clipping, in addition to any clipping that
might be required due to the physical limitations of the display device.

<dl>

<dt><strong>Frame width and frame height</strong>

<dd>The <code class=expr>frame_width</code> and <code class=expr>frame_height</code> are defined in
the <span class=cn>MHDR</span> chunk and cannot be changed by any other MNG chunk.


<p>Decoders can use these parameters to establish the size of
a window in which to display the MNG frames.  When the <code class=expr>frame_width</code>
or <code class=expr>frame_height</code> 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.

<p>In the case of a MNG datastream that consists of a PNG or JNG
datastream, with the PNG or JNG signature, the <code class=expr>frame_width</code>
and <code class=expr>frame_height</code> are defined by the <code class=expr>width</code> and
<code class=expr>height</code> fields of the <span class=cn>IHDR</span> (or <span class=cn>JHDR</span>) chunk.


<p>

<dt><strong>Layer clipping boundaries</strong>

<dd>The layer clipping boundaries are optionally defined in the
<span class=cn>FRAM</span> chunk, and cannot be changed within a subframe.  When
the framing mode is 3 or 4, viewers must, prior to displaying
the foreground layers of each frame, clear the area within the layer
clipping boundaries to the background color,
thus creating a separate layer at the beginning of each frame.
Viewers must not change any pixels outside the layer
boundaries; encoders must be able to rely on the fact that the part of
the display that is outside the layer clipping boundaries (but inside
the area defined by <code class=expr>frame_width</code> and <code class=expr>frame_height</code>)
will remain on the display from frame to frame without being explicitly
redisplayed.

<p>

<dt><strong>Image clipping boundaries</strong>

<dd>The image clipping boundaries are defined in the
<span class=cn>DEFI</span> chunk.
They are associated with individual objects, not
with the layers, and they can be changed within a subframe of layers.
They are useful for exposing only a portion of an image in a
frame.

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

<p>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:


<pre>
   0        &lt;= x &lt; frame_width  (from the MHDR chunk)
   0        &lt;= y &lt; frame_height
   Left_lcb &lt;= x &lt; right_lcb    (from the FRAM chunk)
   Top_lcb  &lt;= y &lt; bottom_lcb
   Left_cb  &lt;= x &lt; right_cb     (from the DEFI chunk)
   Top_cb   &lt;= y &lt; bottom_cb
</pre>


<p>

</dl>

<h2><a name="decoders">12. Recommendations for Editors</a></h2>

<p>Omitted.

<h2><a name="Misc">13. Miscellaneous Topics</a></h2>

<h3><a name="File-name-extension">13.1. File name extension</a></h3>

<p>On systems where file names customarily include an extension
signifying file type, the extension <code class=expr>.mng</code> is recommended for
MNG (including MNG-LC)
files.  Lowercase <code class=expr>.mng</code> is
preferred if file names are case-sensitive.  The extension <code class=expr>.jng</code> is
recommended for JNG files.


<h2><a name="Rationale">14. Rationale</a></h2>

<p>This (incomplete as of version 1.0) section does not form a part of
the specification.  It provides
the rationale behind some of the design decisions in
MNG.

<h3>Interframe delay</h3>

<p>Explain why the interframe delay has to be provided <em>before</em>
the subframes of layers are defined, instead of having a simpler
<span class=cn>DELA</span> chunk that occurs in the stream where the delay is
wanted.

<h3>DHDR delta types</h3>

<p>Some delta types are not allowed when the parent object is a JNG
image.  Explain why types 4 and 6 (pixel replacement and color channel
replacement) are not allowed under these circumstances.


<h3>Additional filter methods</h3>

<p>Filter method 64 could have been implemented as a new critical chunk in
embedded PNG datastreams.
<pre>
   FILT
      method (1 byte)
        64: intrapixel differencing
      data (variable, depends on method)
        method 64 requires no data
</pre>
<p>The <span class=cn>FILT</span> chunk would turn on this type of filtering.

<p>The choice of using a new filter method instead of a new critical chunk was
made based on simplicity of implementation and possible eventual inclusion
of this method in PNG. Also, using the filter-method byte helps implementors
avoid confusion about whether this is a color transform (which could affect
the implementation of <span class=cn>tRNS</span> and other color-related chunks) or part
of the filtering mechanism (which would not conceivably affect color-related
chunks).

<p>We considered using an ancillary chunk (e.g., <span class=cn>fILt</span>
or <span class=cn>fILT</span>) to turn on the new
filtering method. This would have the advantage that existing applications
could manipulate the files, but viewers that ignore the chunk would display
the image in unacceptably wrong colors, and editors could mistakenly discard
the chunk.

<h3>MAGN chunk rationale</h3>

<p>Q. Why not just use a <span class=cn>BASI</span> chunk to encode solid-color rectangles?

<p>A. The <span class=cn>MAGN</span> chunk also allows encoding of gradient-filled
rectangles.

<p>Q. Why not just use PNG to encode gradient-filled rectangles?

<p>A. While PNG can encode vertical and horizontal gradients fairly
efficiently, it cannot do diagonal ones efficiently, and none
are as efficient as a 30-byte MAGN chunk plus a 4-pixel PNG.

<p>Q. Why not use full-scale low-quality JPEG/JNG?

<p>A. Low-quality JPEG with reduced dimensions can be much smaller than even
the lowest-quality full-sized JPEG.  Such images can then be magnified to
full scale with the <span class=cn>MAGN</span> chunk, for
use as preview ("LOWSRC") images.
this has been demonstrated to be about 40 to 50 times as efficient as using
Adam7 interlacing of typical natural images,

<p> It appears that in general, usable preview images of truecolor
photographic images can be made at compression ratios from M*800:1 to
M*2500:1, where M is the number of megapixels in the original image, by
reducing the original image spatially to width and height in the range
64 to 200 pixels and then compressing the result to a medium-quality JNG.

<p>Q. Why not use the <span class=cn>pHYg</span> chunk?

<p>A. It is not mandatory for decoders to process the <span class=cn>pHYg</span> chunk
and it does not apply to individual images; it
is used to scale the entire MNG frame.  The <span class=cn>pHYs</span> chunk cannot be
used either because MNG decoders are required to ignore it.

<p>Q. Why not 4-byte magnification factors instead of 2-byte ones?

<p>A. Encoders can start with a larger object or, except for
object 0, magnify it twice.

<p>Q. Why not 1-byte magnification factors, then?

<p>A. With typical screen widths currently 1280 or 1600 pixels and film and
printer pages currently about 3000 pixels wide, magnifying a 1x1 image
to a width of more than 255 pixels would not be uncommon.

<p>Q. I want to magnify a "frozen" object.

<p>A. You can make a full clone and magnify that.

<p>Q. Why define Methods 4 and 5?

<p>A. Method 4 is useful for magnifying an alpha-encoded image while maintaining
binary transparency.  Method 5 is useful for making an alpha-gradient
while preserving sharp edges in the main image.

<h3>Global JPEG tables</h3>

<p>It has been suggested that a new global MNG chunk, <span class=cn>JTAB</span>,
be defined to hold global JPEG quantization and Huffman tables that
could be inherited by JNG datastreams from which these have been
omitted.  This has not been tested, and we are reluctant to add new
critical chunks to the MNG specification now.

<h2><a name="Revision-History">15. Revision History</a></h2>

<h3><a name="v100">15.1. Version 1.0</a></h3>

<p>Released 31 January 2001

<ul>
<li>No changes.
</ul>

<h3><a name="v99">15.2. Version 0.99</a></h3>

<p>Released 10 December 2000


<ul>
<li>Miscellaneous technical changes
<ul>

<li>A new filter method (method 64, intrapixel differencing) is defined for
PNG datastreams that are embedded in MNG-LC, MNG, and
Delta-PNG datastreams.  This was approved by formal vote on December 4, 2000.

<li>Deleted "or can be ignored" from the definition of the background
transparency profile flag.
This was approved by consensus on October 28, 2000.


</ul>


<li>Revised the author list.
<p>

</ul>

<h3><a name="v98">15.3. Version 0.98</a></h3>

<p>Released 01 October 2000

<ul>

<li>Added JPEG-encoded alpha channel in JNG and Delta-PNG datastreams,
stored in a new <span class=cn>JDAA</span> chunk.  This was approved by a formal vote.

<li>Added the <span class=cn>MAGN</span> chunk.  This was approved by a formal vote.
Caution: there were errors in the interpolation formula
for <span class=cn>MAGN</span> (unbalanced parentheses, "+m" was
"+1") in the proposal that was voted upon; those errors have
been fixed in this public release.

<li>Added a "stored object buffers" flag to promise that even
when "complex MNG features" are present, it is not necessary
to create object buffers.  This proposal was approved by a formal vote.

<li>Separated the "transparency" profile bit
into "transparency", "semitransparency",
and "background transparency", and added discussion
of "background
transparency" to the BACK
and FRAM chunk specifications.
This
proposal was approved by a formal vote.

<li>Added a "validity" flag to maintain backward compatibility
of the simplicity profile.  If it is zero, then the "background
transparency", "semitransparency",
and "stored object buffers" flags do <em>not</em>
make any promises.

<li>Global <span class=cn>sRGB</span> nullifies global <span class=cn>gAMA</span> and <span class=cn>cHRM</span>,
and <em>vice versa</em>.

<li>It is permitted to change the potential visibility,
location, and clipping boundaries of "frozen" objects, provided
that the encoder writes chunks to restore them to their "frozen"
values prior to the end of the segment.

<li>Added a note that top-level color-space chunks do not have any effect
on already-decoded objects.






<li>Added terminology entries for "animation",
"framing rate",
"interpolation",
"iteration",
"replication",
and "nullify".



<li>Added two examples related to the <span class=cn>MAGN</span> chunk.

<li>Various editorial changes.

</ul>

<h3><a name="v97">15.4. Version 0.97</a></h3>

<p>Released 28 February 2000.

<ul>
<li>Minor editorial changes only.
</ul>

<h3><a name="v96">15.5. Version 0.96</a></h3>

<p>Released 18 July 1999.


<p>The changes that are not simple editorial
changes were approved by votes of the
PNG Development group that closed 16 July 1999 (<span class=cn>pHYg</span>
and change to treatment of the <span class=cn>pHYs</span> chunk), 14 July 1999 (global
<span class=cn>bKGD</span> and <span class=cn>sBIT</span>) and 25 June 1999 (change to <span class=cn>LOOP</span>
chunk and treatment of the <span class=cn>DEFI</span> chunk and nonviewable objects).


<ul>


<li>An object "comes into existence" when it is named in a
<span class=cn>DEFI</span> chunk instead of later, when the corresponding embedded image is
received.

<li>The special treatment of the set of object attributes for object 0 was
eliminated.


<li>If fields are omitted from the <span class=cn>DEFI</span> chunk, values are inherited
from a previous <span class=cn>DEFI</span> chunk, if one was present.  In MNG-0.95,
such fields assumed specified default values.  In this version, the
default values are only used if no prior <span class=cn>DEFI</span> chunk with the same
object_id was present or if the prior <span class=cn>DEFI</span> chunk has been discarded.

<li> Revised Example 14.


<li>Started a Revision History section.

<li>Added the <span class=cn>pHYg</span> chunk and changed
the meaning of the global <span class=cn>pHYs</span> chunk.

<li>Added the global <span class=cn>bKGD</span> and <span class=cn>sBIT</span> chunks.



</ul>

<h3><a name="v95">15.6. Version 0.95</a></h3>

<ul>
<li>Initial public release, approved by the PNG Development Group
on 11 May 1999.
</ul>


<h2><a name="References">16. References</a></h2>

<dl>


<dt><strong>[<a name="LOCO">LOCO</a>]</strong>

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



<p>

<dt><strong>[<a name="PNG">PNG</a>]</strong>

<dd>Boutell, T., et. al.,  "PNG (Portable Network Graphics Format)
Version 1.0", RFC 2083,<br>
<span class=url><a href="ftp://ftp.isi.edu/in-notes/rfc2083.txt"> ftp://ftp.isi.edu/in-notes/rfc2083.txt</a></span>
also available at<br>
<span class=url><a href="ftp://swrinde.nde.swri.edu/pub/png/documents/"> ftp://swrinde.nde.swri.edu/pub/png/documents/</a></span>.  
This
specification has also been published as a W3C Recommendation, which is
available at<br>
<span class=url><a href="http://www.w3.org/TR/REC-png.html"> http://www.w3.org/TR/REC-png.html</a></span>.

<p>See also the PNG-1.2 specification:<br>
Randers-Pehrson, G., et. al.,  "PNG (Portable Network Graphics
Format) Version 1.2", which is available at<br>
<span class=url><a href="ftp://swrinde.nde.swri.edu/pub/png/documents/"> ftp://swrinde.nde.swri.edu/pub/png/documents/</a></span>.

<p>

<dt><strong>[<a name="PNG-EXT">PNG-EXT</a>]</strong>

<dd>Randers-Pehrson, G., et al,
"Extensions to the PNG 1.2 Specification",<br>
<span class=url><a href="ftp://swrinde.nde.swri.edu/pub/png/documents/"> ftp://swrinde.nde.swri.edu/pub/png/documents/pngext-*</a></span>.

<p>

<dt><strong>[RFC-2119]</strong>

<dd>Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119/BCP 14, Harvard University, March&nbsp;1997.

<p>

<dt><strong>[RFC-2045]</strong>

<dd>Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft,
First Virtual, November&nbsp;1996.<br>
<span class=url><a href="ftp://ftp.isi.edu/in-notes/rfc2045.txt"> ftp://ftp.isi.edu/in-notes/rfc2045.txt</a></span>

<p>

<dt><strong>[RFC-2048]</strong>

<dd>Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
Innosoft, MCI, USC/Information Sciences Institute, November&nbsp;1996.<br>
<span class=url><a href="ftp://ftp.isi.edu/in-notes/rfc2048.txt"> ftp://ftp.isi.edu/in-notes/rfc2048.txt</a></span>


<p>

</dl>

<h2><a name="Security">17. Security Considerations</a></h2>

<p>Security considerations are addressed in the PNG specification.


<p>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.

<p>No known additional security concerns are raised by this format.


<h2><a name="Examples">18. Appendix: Examples</a></h2>

<p>We use the "#" character to denote commentary in these
examples; such comments are not present in actual MNG datastreams.



<h3><a name="example1">18.1. Example 1: A single image</a></h3>

<p>The simplest MNG datastream is a single-image PNG datastream.  The
simplest way to create a MNG from a PNG is:

<pre>
   copy file.png file.mng
</pre>

<p>The resulting MNG file looks like:

<pre>
   \211 P N G \r \n ^z \n  # PNG signature.
   IHDR 720 468 8 0 0 0 0  # Width and Height, etc.
   sRGB 2
   gAMA 45455
   IDAT ...
   IEND
</pre>

<p>If <samp class=filename>file.png</samp> contains an <span class=cn>sRGB</span> chunk and
also <span class=cn>gAMA</span> and <span class=cn>cHRM</span> chunks that are recommended in the
PNG specification for "fallback" purposes, you can remove
those <span class=cn>gAMA</span> and <span class=cn>cHRM</span> chunks from <samp class=filename>file.mng</samp>
because any MNG viewer that processes the <span class=cn>gAMA</span> chunk is also
required to recognize and process the <span class=cn>sRGB</span> chunk, so those
chunks will always be ignored.  Any MNG editor that converts the MNG file
back to a PNG file is supposed to insert the recommended <span class=cn>gAMA</span>
and <span class=cn>cHRM</span> chunks.


<h3><a name="example2">18.2. Example 2: A very simple movie</a></h3>

<p>This example demonstrates a very simple movie, such as might result
from directly converting an animated GIF that contains a simple series
of full-frame images:

<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 256 300   # Width and height.
        1         # 1 tick per second.
        5 4 4     # Layers, frames, play time
        65        # MNG-VLC simplicity
   TERM 3 0 120 10   # When done, repeat animation 10 times.
   IHDR ...  IDAT ...  IEND # Four PNG datastreams
   IHDR ...  IDAT ...  IEND # are read and displayed.
   IHDR ...  IDAT ...  IEND
   IHDR ...  IDAT ...  IEND
   MEND
</pre>



<h3><a name="example3">18.3. Example 3: A simple slideshow</a></h3>

<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 720 468 1 # Width and height, 1 tick per second.
        6 5 5     # Layers, frames, play time.
        67        # Simplicity profile (MNG-LC no transparency)
   FRAM 1 0 2 2 0  2 1 600 0 # Set interframe_delay to 1,
     # timeout to 600 sec, and sync_id list to {0}.
   SAVE
   SEEK "Briefing to the Workforce"
   IHDR ...  IDAT ...  IEND  # DEFI 0, visible, abstract
   SEEK "Outline"            # is implied.
   IHDR ...  IDAT ...  IEND
   SEEK "Our Vision"       IHDR ...  IDAT ...  IEND
   SEEK "Our Mission"      IHDR ...  IDAT ...  IEND
   SEEK "Downsizing Plans" IHDR ...  IDAT ...  IEND
   MEND
</pre>

<h3><a name="examples4-14">18.4. Examples 4-14: Omitted from MNG-LC.</a></h3>

<p>These examples in the full MNG specification use features
that are not available in MNG-LC.


<h3><a name="x15">18.5. Example 15: Converting a simple GIF animation</a></h3>

<p>Outline of a program to convert simple GIF animations that do not
use the "restore-to-previous" disposal method to "simple" MNG
(or "MNG-LC") format:

<pre>
   begin
      write "MHDR" chunk
      Interframe_delay := 0; Previous_mode := 1
      Framing_mode := 1
      if(loops&gt;1) "write TERM 3 0 0 loops"
      write "mandatory BACK" chunk
      for subimage in gif89a file do
         if(interframe_delay != gif_duration) then
            interframe_delay := gif_duration
            write "FRAM 0 0 2 2 0 2 0 interframe_delay 0"
         endif
         if(X_loc != 0 OR Y_loc != 0) then
            write "DEFI 0 0 0 X_loc Y_loc" chunk
         endif
         write "&lt;image&gt;"
         if (gif_disposal_method &lt; 1) then
            /* (none or keep) */
            Framing_mode := 1
         else if (gif_disposal_method == 2) then
            /* (restore background) */
            write "FRAM 4 0 1 0 1 0 0 L R T B"
            Previous_mode := 4; Framing_mode := 1
         else if (gif_disposal_method == 3) then
            /* (restore previous) */
            error ("can't do gif_disposal method = previous.")
         endif
         if(Framing_mode != Previous_mode) then
            write "FRAM Framing_mode" chunk
            Previous_mode := Framing_mode
         endif
      end
      write "MEND" chunk
   end
</pre>

<p>Where "&lt;image&gt;" represents a PNG datastream containing a GIF
frame that has been converted to PNG format.

<p>Caution: if you write such a program, you might have to pay royalties
in order to convey it to anyone else.



<h3><a name="x16">18.6. Example 16: Counting layers and frames</a></h3>

<P>This demonstrates the determination of the layer count and frame count
that should be written in the <span class=cn>MHDR</span> chunk.
For framing_modes 1 and 2, the <span class=cn>FRAM</span> chunks themselves
do not generate layers.  For framing_modes 3 and 4, they do
generate layers ("B" for background), and also generate frames if
there is no embedded image with which to combine the background layer.
Note that every framing_mode creates a "B" layer at the beginning.

<p>Given the following chunk stream:

<pre>
   MHDR sRGB Fn F I I I F F I I I F F I I I MEND
</pre>

<p>in which

<pre>
   Fn represents a FRAM chunk with framing_mode n
   F represents an empty FRAM chunk;
   I represents an embedded image
</pre>

<p>This table shows the layer count and frame count for each of
the four possible values of framing-mode:
<pre>
   Framing  Layer count                 Frame count
    mode
   
      1     B,I,I,I, I,I,I, I,I,I = 10  BI,I,I, I,I,I, I,I,I =  9
      2     B,I,I,I, I,I,I, I,I,I = 10  BIII,III,III         =  3
      3     3*(B, B,I, B,I, B,I)  = 21  3*(B,BI,BI,BI)       = 12
      4     3*(B,B,I,I,I)         = 15  B,BIII,B,BIII,B,BIII =  6
</pre>



<h3><a name="x17">18.7. Example 17: Storing an icon library</a></h3>

<p>Here is an example of storing a library of icons in a
MNG-LC datastream.
All of the icons use the same palette, transparency, and colorspace,
so these are put in global chunks at the beginning.  Empty <span class=cn>PLTE</span>
chunks in the embedded images are used to import the global palette and
transparency data.
<pre>
   MHDR 96 96 1 6 5 5 459 # Profile 459 is MNG-LC
   sRGB 2                 # Global sRGB
   PLTE ...               # Global PLTE
   tRNS 0                 # Global tRNS
   eXPI 0 "thumbnail"
   IHDR 32 32 ... PLTE IDAT ... IEND
   eXPI 0 "left arrow"
   IHDR 96 96 ... PLTE IDAT ... IEND
   eXPI 0 "right arrow"
   IHDR 96 96 ... PLTE IDAT ... IEND
   eXPI 0 "up arrow"
   IHDR 96 96 ... PLTE IDAT ... IEND
   eXPI 0 "down arrow"
   IHDR 96 96 ... PLTE IDAT ... IEND
   MEND
</pre>


<h3><a name="x18">18.8. Example 18: MAGN methods</a></h3>

<p>This demonstrates the methods used in the <span class=cn>MAGN</span> chunk.

<p>Original 3x2 object or embedded image:
<pre>
   1  9  1
   9 17  9
</pre>
<p>Magnification method 1, XM = 5, YM = 3.
Replicates each pixel 4 additional times in
the X direction and 2 additional times in the
Y direction; new size is 15x6:
<pre>
   1  1  1  1  1  9  9  9  9  9  1  1  1  1  1
   1  1  1  1  1  9  9  9  9  9  1  1  1  1  1
   1  1  1  1  1  9  9  9  9  9  1  1  1  1  1
   9  9  9  9  9 17 17 17 17 17  9  9  9  9  9
   9  9  9  9  9 17 17 17 17 17  9  9  9  9  9
   9  9  9  9  9 17 17 17 17 17  9  9  9  9  9
</pre>
<p>Magnification method 2, XM = 8, YM = 4.
Fills the X intervals with 7 new pixels
and the Y interval with 3 new pixels
and interpolates to get pixel values;
new size is 17x5:
<pre>
   1  2  3  4  5  6  7  8  9  8  7  6  5  4  3  2  1
   3  4  5  6  7  8  9 10 11 10  9  8  7  6  5  4  3
   5  6  7  8  9 10 11 12 13 12 11 10  9  8  7  6  5
   7  8  9 10 11 12 13 14 15 14 13 12 11 10  9  8  7
   9 10 11 12 13 14 15 16 17 16 15 14 13 12 11 10  9
</pre>
<p>Magnification method 3, XM = 8, YM = 4
Fills the X intervals with 7 new pixels
and the Y interval with 3 new pixels
replicating the closest pixel to get
pixel values; new size is 17x5:
<pre>
   1  1  1  1  1  9  9  9  9  9  9  9  9  1  1  1  1
   1  1  1  1  1  9  9  9  9  9  9  9  9  1  1  1  1
   1  1  1  1  1  9  9  9  9  9  9  9  9  1  1  1  1
   9  9  9  9  9 17 17 17 17 17 17 17 17  9  9  9  9
   9  9  9  9  9 17 17 17 17 17 17 17 17  9  9  9  9
</pre>


<h3><a name="x19">18.9. Example 19: MAGN chunks and ROI</a></h3>

<p>This example demonstrates the use of MNG to display a region of interest
(ROI) at a higher quality than the rest of the frame, and the <span class=cn>MAGN</span>
chunk to convey a highly-compressed but very lossy image, a drop shadow,
and a diagonal gradient background.
<pre>
   MHDR 600 600 0 5 1 0 83
   # Gradient background
   MAGN 00 00 2 599
   sRGB 1
   IHDR IDAT IEND &lt;dblue2x2.png&gt;   # 93 bytes
   
   # Drop shadow
   DEFI 0 0 0 52 52
   BASI 512 512 1 4 0 0 0 51 51 51 153 1
   IEND         # Grey-Alpha object, 46 bytes
   
   # Main image, with most of the region of interest
   # replaced with a solid rectangle, and reduced to
   # 128x128 dimensions, low quality JPEG compression.
   DEFI 0 0 0 36 36
   MAGN 00 00 2 04 04 06 05 06 05
   JHDR 128 128 10 8 8 0 0 0 0 0
   JDAT &lt;lena_q25_fourth.jpg&gt;      # 2514 bytes
   IEND
   
   # Region of interest, full scale, cropped to
   # dimensions 200x313 at location 192,200,
   # high quality JPEG compression.
   MAGN # Turn off magnification of all subsequent object 0
   DEFI 0 0 0 228 236
   JHDR 200 312 10 8 8 0 0 0 0 0
   JDAT &lt;lena_face_q65.jpg&gt;        # 8001 bytes
   IEND
   
   MEND
</pre>
<p>For this image, the resulting 600x600 frame occupies about 2.6
times the file size when written as a simple JNG and about 26 times the
file size when written as a simple PNG.  The particular image used in
this example was the 512x512 color Lena from<br>
<span class=url><a href="http://links.uwaterloo.ca/bragzone.base.html"> http://links.uwaterloo.ca/bragzone.base.html</a></span>.



<h2><a name="Credits">19. Credits</a></h2>


<h3>Editor</h3>

<ul>

<li>Glenn Randers-Pehrson,
<span class=email><a href="mailto:randeg@alum.rpi.edu"> randeg&nbsp;&#64;&nbsp;alum.rpi.edu</a></span>

<p>

</ul>


<h3>Contributors</h3>

<p>Contributors' names are presented in alphabetical order:

<ul>

<li><a href="http://quest.jpl.nasa.gov/Mark.Adler/">Mark Adler</a>,
<span class=email>madler&nbsp;&#64;&nbsp;alumni.caltech.edu</span>
<li>Matthias Benkmann, <span class=email>mbenkmann&nbsp;&#64;&nbsp;gmx.de</span>
<li><a href="http://www.boutell.com/boutell/">Thomas Boutell</a>,
<span class=email>boutell&nbsp;&#64;&nbsp;boutell.com</span>
<li>John Bowler, <span class=email>jbowler&nbsp;&#64;&nbsp;acm.org</span>
<li><a href="http://www.brunschen.com/christian">Christian Brunschen</a>,
<span class=email>christian&nbsp;&#64;&nbsp;brunschen.com</span>
<li>Glen Chapman, <span class=email>glenc&nbsp;&#64;&nbsp;clark.net</span>
<li><a href="http://www.cs.berkeley.edu/~amc/">Adam M. Costello</a>,
<span class=email>amc&nbsp;&#64;&nbsp;cs.berkeley.edu</span>
<li><a href="http://www.piclab.com/lcrocker.html">Lee Daniel Crocker</a>, 
<span class=email>lee&nbsp;&#64;&nbsp;piclab.com</span>
<li>Peter da Silva, <span class=email>peter&nbsp;&#64;&nbsp;starbase.neosoft.com</span>
<li><a href="http://www-mddsp.enel.ucalgary.ca/People/adilger/">Andreas Dilger</a>, 
<span class=email>adilger&nbsp;&#64;&nbsp;turbolinux.com</span>
<li><a href="http://www.fromme.com/">Oliver Fromme</a>,
<span class=email>oliver&nbsp;&#64;&nbsp;fromme.com</span>
<li>Jean-loup Gailly, <span class=email>jloup&nbsp;&#64;&nbsp;gzip.org</span>
<li><a href="http://www.qnx.com/~chrish/">Chris Herborth</a>,
<span class=email>chrish&nbsp;&#64;&nbsp;pobox.com</span>
<li>Alex Jakulin,
<span class=email>jakulin&nbsp;&#64;&nbsp;acm.org</span>
<li>Gerard Juyn, <span class=email>gjuyn&nbsp;&#64;&nbsp;xs4all.nl</span>
<li><a href="http://www.vis.colostate.edu/~user1209/">Neal Kettler</a>,
<span class=email>neal&nbsp;&#64;&nbsp;westwood.com</span>
<li>Tom Lane, <span class=email>tgl&nbsp;&#64;&nbsp;sss.pgh.pa.us</span>
<li>Alexander Lehmann, <span class=email>lehmann&nbsp;&#64;&nbsp;usa.net</span>
<li><a href="http://www.w3.org/people/chris">Chris Lilley</a>,
<span class=email>chris&nbsp;&#64;&nbsp;w3.org</span>
<li>Dave Martindale, <span class=email>davem&nbsp;&#64;&nbsp;cs.ubc.ca</span>
<li>Carl Morris, <span class=email>msftrncs&nbsp;&#64;&nbsp;htcnet.com</span>
<li>Owen Mortensen, <span class=email>ojm&nbsp;&#64;&nbsp;acm.org</span>
<li>Josh M. Osborne, <span class=email>stripes&nbsp;&#64;&nbsp;va.pubnix.com</span>
<li>Keith S. Pickens, <span class=email>ksp&nbsp;&#64;&nbsp;rice.edu</span>
<li>Glenn Randers-Pehrson,
<span class=email>randeg&nbsp;&#64;&nbsp;alum.rpi.edu</span>
<li>Nancy M. Randers-Pehrson,
<span class=email>randeg&nbsp;&#64;&nbsp;alum.rpi.edu</span>
<li><a href="http://pobox.com/~newt">Greg Roelofs</a>,
<span class=email>newt&nbsp;&#64;&nbsp;pobox.com</span>
<li><a href="http://www.schaik.com">Willem van Schaik</a>, 
<span class=email>willem&nbsp;&#64;&nbsp;schaik.com</span>
<li>Guy Schalnat, <span class=email>gschal&nbsp;&#64;&nbsp;infinet.com</span>
<li>Paul Schmidt, <span class=email>pschmidt&nbsp;&#64;&nbsp;photodex.com</span>
<li>Smarry Smarasderagd, <span class=email>smar&nbsp;&#64;&nbsp;reptiles.org</span>
<li>Alaric B. Snell, <span class=email>alaric&nbsp;&#64;&nbsp;alaric-snell.com</span>
<li>Thomas R. Tanner, <span class=email>ttehtann&nbsp;&#64;&nbsp;argonet.co.uk</span>
<li><a href="http://www.cs.toronto.edu/~cosmin">Cosmin Truta</a>,
<span class=email>cosmin&nbsp;&#64;&nbsp;cs.toronto.edu</span>
<li>Guido Vollbeding, <span class=email>guivol&nbsp;&#64;&nbsp;esc.de</span>
<li>Tim Wegner, <span class=email>twegner&nbsp;&#64;&nbsp;phoenix.net</span>

</ul>


<h3>Trademarks</h3>

<ul>

<li>GIF is a service mark of CompuServe Incorporated.

<li>PostScript is a trademark of Adobe Systems.


</ul>


<h3>Document source</h3>

<p>This document was built from the file <samp class=filename>mng-master-20010209</samp>
on 09&nbsp;February&nbsp;2001.

<h3>Copyright Notice</h3>

<p><strong>Copyright &copy; 1998-2001, by Glenn Randers-Pehrson</strong>

<p>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:

<p>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 <strong>NOTICE</strong> appears on <em>ALL</em> copies
of the specification or portions thereof, including modifications, that
you make.

<p><strong>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 HOLDERS MAKE 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.</strong>

<p>The name and trademarks of copyright holder may <em>NOT</em> 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.




<h2><em>End of MNG-LC Specification.</em></h2>

</body>

</html>
 
 
Close
loading
Please Confirm
Close