Skip to main content

Source code file content

Revision: 1

add archives
» Project Revision History

» Checkout URL

community-source-archives / index.html

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

<html lang="en">






<title>
MNG
1.0
</title>





</head>

<body>




<h1>MNG (Multiple-image Network Graphics) 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>



<h2>Abstract</h2>



<p>This document defines the MNG
(Multiple-image Network Graphics) format.
It also defines the MNG-LC (Low Complexity), MNG-VLC (Very Low Complexity),
and JNG (JPEG Network Graphics) formats.
These are proper subsets of MNG.


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


<p>The MNG and JNG formats use the same chunk structure that is defined
in the PNG specification, and they share other features of the PNG
format.  Any MNG decoder must be able to decode PNG and JNG datastreams.

<p>The MNG format (but not MNG-LC or MNG-VLC)
provides a mechanism for reusing image data without
having to retransmit it.  Multiple images can be composed into
a "frame"
and a group of images can be used as an animated "sprite" that
moves from one location to another in subsequent frames.  "Palette
animations" are also possible.  MNG can also
store images in a highly compressible "Delta-PNG" format,
defined herein.

<p>A MNG
frame normally contains a two-dimensional image or a
two-dimensional layout of smaller images.  It could also contain
three-dimensional "voxel" data arranged as a series of
two-dimensional planes (or tomographic slices), each plane being
represented by a PNG
or
Delta-PNG datastream.

<p>A Delta-PNG datastream defines an image in terms of a parent PNG
or Delta-PNG image and the differences from that image.  This
provides a much more compact way of representing
subsequent images than using a complete PNG datastream for each.


<p>This document includes examples that demonstrate various capabilities
of MNG.  These include simple movies, composite frames, loops, fades, tiling,
scrolling, storage of voxel data, and converting GIF animations to MNG
format.


<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>
<ul>
<li><a href="#obj-embedded">3.1. Embedded objects</a>
<li><a href="#obj-attributes">3.2. Object attributes</a>
<li><a href="#obj-buffers">3.3. Object buffers</a>
<li><a href="#object-0">3.4. Object 0</a>
</ul>
<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-BASI">4.2.5. <span class=cn>BASI</span>, PNG chunks, <span class=cn>IEND</span></a>
<li><a href="#mng-CLON">4.2.6. <span class=cn>CLON </span>Clone an object</a>
<li><a href="#mng-DHDR">4.2.7. <span class=cn>DHDR</span>, Delta-PNG chunks, <span class=cn>IEND</span></a>
<li><a href="#mng-PAST">4.2.8. <span class=cn>PAST </span>Paste an image into another</a>
<li><a href="#mng-MAGN">4.2.9. <span class=cn>MAGN </span>Magnify objects</a>
<li><a href="#mng-DISC">4.2.10. <span class=cn>DISC </span>Discard objects</a>
<li><a href="#mng-TERM">4.2.11. <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>
<li><a href="#mng-MOVE">4.3.3. <span class=cn>MOVE </span>New image location</a>
<li><a href="#mng-CLIP">4.3.4. <span class=cn>CLIP </span>Object clipping boundaries</a>
<li><a href="#mng-SHOW">4.3.5. <span class=cn>SHOW </span>Show images</a>
</ul>
<li><a href="#mng-SAVE-SEEK">4.4. <span class=cn>SAVE</span> and <span class=cn>SEEK</span> chunks</a>
<ul>
<li><a href="#mng-SAVE">4.4.1. <span class=cn>SAVE </span>Save information</a>
<li><a href="#mng-SEEK">4.4.2. <span class=cn>SEEK </span>Seek point</a>
</ul>
<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-fPRI">4.5.2. <span class=cn>fPRI </span>Frame priority</a>
<li><a href="#mng-nEED">4.5.3. <span class=cn>nEED </span>Resources needed</a>
<li><a href="#mng-phys">4.5.4. <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>
<ul>
<li><a href="#JNG-crit">5.1. Critical JNG chunks</a>
<ul>
<li><a href="#JNG-JHDR">5.1.1. <span class=cn>JHDR </span>JNG header</a>
<li><a href="#JNG-JDAT">5.1.2. <span class=cn>JDAT </span>JNG image data</a>
<li><a href="#JNG-IDAT">5.1.3. <span class=cn>IDAT </span>JNG PNG-encoded alpha data</a>
<li><a href="#JNG-JDAA">5.1.4. <span class=cn>JDAA </span>JNG JPEG-encoded alpha data</a>
<li><a href="#JNG-JSEP">5.1.5. <span class=cn>JSEP</span> 8-bit/12-bit image separator</a>
<li><a href="#JNG-IEND">5.1.6. <span class=cn>IEND </span>End of JNG datastream</a>
</ul>
<li><a href="#JNG-anc">5.2. Ancillary JNG chunks</a>
</ul>
<li><a href="#Delta-PNG">6. The Delta-PNG Format</a>
<ul>
<li><a href="#D-crit">6.1. Delta-PNG critical chunks</a>
<ul>
<li><a href="#Delta-PNG-DHDR">6.1.1. <span class=cn>DHDR </span>Delta-PNG datastream header</a>
<li><a href="#DPNG-IDAT">6.1.2. <span class=cn>IDAT, JDAT</span>, and <span class=cn>JDAA </span> New pixel data</a>
<li><a href="#Delta-PNG-PROM">6.1.3. <span class=cn>PROM </span>Promotion of parent object</a>
<li><a href="#D-IHDR">6.1.4. <span class=cn>IHDR</span> PNG image header</a>
<li><a href="#D-IPNG">6.1.5. <span class=cn>IPNG</span> Incomplete PNG</a>
<li><a href="#D-PLTE">6.1.6. <span class=cn>PLTE</span> and <span class=cn>tRNS</span></a>
<li><a href="#D-PPLT">6.1.7. <span class=cn>PPLT</span> Partial palette</a>
<li><a href="#D-JHDR">6.1.8. <span class=cn>JHDR</span> JNG image header</a>
<li><a href="#D-IJNG">6.1.9. <span class=cn>IJNG</span> Incomplete JNG</a>
<li><a href="#Delta-PNG-DROP">6.1.10. <span class=cn>DROP </span>Drop chunks</a>
<li><a href="#Delta-PNG-DBYK">6.1.11. <span class=cn>DBYK </span>Drop chunks by keyword</a>
<li><a href="#Delta-PNG-ORDR">6.1.12. <span class=cn>ORDR </span>Ordering restrictions</a>
</ul>
<li><a href="#DPNG-anc">6.2. Ancillary Delta-PNG chunks</a>
<ul>
<li><a href="#D-col">6.2.1. <span class=cn>gAMA, cHRM, iCCP, sRGB</span> Color space chunks</a>
<li><a href="#DPNG-offs">6.2.2. <span class=cn>oFFs</span> and <span class=cn>pHYs</span></a>
<li><a href="#DPNG-other-anc">6.2.3. Other ancillary PNG chunks</a>
<li><a href="#Delta-PNG-IEND">6.2.4. <span class=cn>IEND </span>End of Delta-PNG datastream</a>
</ul>
<li><a href="#Delta-PNG-order">6.3. Chunk ordering requirements</a>
</ul>
<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-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. Required JNG chunk support</a>
<li><a href="#d-min-DPNG">9.4. Required Delta-PNG 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>
<li><a href="#e-loops">10.4. Embedded images in LOOPs</a>
<li><a href="#e-index">10.5. Including optional index in SAVE chunk</a>
<li><a href="#e-jng-int">10.6. Interleaving JDAT, JDAA, and IDAT chunks</a>
<li><a href="#e-jng-jdaa">10.7. Use of the JDAA chunk</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="#d-endl">11.2. ENDL without matching LOOP</a>
<li><a href="#compositing">11.3. Note on compositing</a>
<li><a href="#retaining">11.4. Retaining object data</a>
<li><a href="#errors">11.5. Decoder handling of fatal errors</a>
<li><a href="#interlacing">11.6. Decoder handling of interlaced images</a>
<li><a href="#decoder-plte">11.7. Decoder handling of palettes</a>
<li><a href="#d-single">11.8. Behavior of single-frame viewers</a>
<li><a href="#d-clipping">11.9. Clipping</a>
</ul>
<li><a href="#decoders">12. Recommendations for Editors</a>
<ul>
<li><a href="#editors-save">12.1. Editing datastreams with optional index</a>
<li><a href="#editors-loops">12.2. Handling LOOP and TERM chunks</a>
</ul>
<li><a href="#Misc">13. Miscellaneous Topics</a>
<ul>
<li><a href="#File-name-extension">13.1. File name extension</a>
<li><a href="#Media-type">13.2. Internet media type</a>
<li><a href="#EBNF">13.3. EBNF Grammar for MNG, PNG, and JNG</a>
<li><a href="#URL">13.4. Uniform Resource Identifier (URI)</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="#example4">18.4. Example 4: A more storage-efficient slideshow</a>
<li><a href="#example5">18.5. Example 5: A simple movie</a>
<li><a href="#example6">18.6. Example 6: A single composite frame</a>
<li><a href="#example7">18.7. Example 7: A movie with sprites</a>
<li><a href="#example8">18.8. Example 8: A movie with an animated sprite</a>
<li><a href="#example9">18.9. Example 9: "Fading in" a transparent image</a>
<li><a href="#example10">18.10. Example 10: Storing three-dimensional images</a>
<li><a href="#example11">18.11. Example 11: Tiling</a>
<li><a href="#example12">18.12. Example 12: Scrolling</a>
<li><a href="#example13">18.13. Example 13: Cycling animations</a>
<li><a href="#example14">18.14. Example 14: Converting a GIF animation</a>
<li><a href="#x15">18.15. Example 15: Converting a simple GIF animation</a>
<li><a href="#x16">18.16. Example 16: Counting layers and frames</a>
<li><a href="#x17">18.17. Example 17: Storing an icon library</a>
<li><a href="#x18">18.18. Example 18: MAGN methods</a>
<li><a href="#x19">18.19. 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 specification defines the format of a MNG (Multiple-image Network
Graphics) format.
It also defines low-complexity and very-low-complexity versions (MNG-LC and
MNG-VLC), and the JNG (JPEG Network Graphics) format, which are proper subsets
of MNG.


<p>Note: This specification depends on the PNG (Portable Network
Graphics) <a href="#PNG">[PNG]</a>
and the JPEG (Joint Photographic Experts Group)
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>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
or JNG
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 datastream describes a sequence of zero or more single frames,
each of which can be composed of zero or more embedded images or directives
to show previously defined images.

<p>The embedded images can be PNG, JNG, or Delta-PNG datastreams.
MNG-LC and MNG-VLC datastreams do not contain JNG
datastreams, but MNG-LC and MNG-VLC
applications can be enhanced to recognize and process JNG datastreams as well.

<p>A typical
MNG
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
or the MNG <span class=cn>BASI</span> chunk
(a foreground layer).


<li>An image that is generated from a stored object as directed by certain
MNG chunks (a foreground layer).


<li>The background (a background layer).

</ul>


<li><span class=cn>LOOP-ENDL</span> chunks.

<li><span class=cn>SEEK</span> chunks that mark points in the datastream where
processing can be restarted.

<li>Various chunks for creating and manipulating images and other
objects.


<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>Images can be "concrete" or "abstract".  The
distinction allows
decoders to use more efficient ways of manipulating images when it
is not necessary to retain the image data in its original form or
equivalent in order to show it properly on the target display system.


<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>MNG does not yet accommodate sound or complex sequencing
information, but these capabilities might be added at a later date, in
a backward-compatible manner.  These issues are being discussed in the
<span class=email>mng-list@ccrc.wustl.edu</span> mailing list.

<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
(see <a href="#copying">below, Chapter 8</a>).
A MNG editor is not permitted to move unknown chunks across
the <span class=cn>SAVE</span> and <span class=cn>SEEK</span> chunks, across any chunks that can
cause images to be created or displayed, or into or out of a
<span class=cn>IHDR-IEND</span> or similar sequence.

<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-compliant decoders are required to recognize and decode independent
PNG or 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,
MNG can accommodate JPEG-encoded
images that are encoded in the PNG-like JNG
format that is defined herein).

</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>It facilitates the use of images as "sprites" or groups of
images as "animated sprites" that can be reused in subsequent
frames.
<li>It capitalizes on frame-to-frame similarities to reduce the amount
of data that must be included in a datastream.

<li>It provides "restart" points at which processing can be
safely resumed in case of data loss or corruption, or to which applications
can jump if they have random access to the file.

<li>A "frame priority" chunk allows authors to indicate which frame
should be displayed by single-image viewers, and a subset of the frames
that should be displayed by slow viewers.

<li>Images and frames can be given names, allowing authors to mark them
for export outside the scope of MNG, where they can be used for icons or
similar purposes.

<li>A series of PNG and JNG images can be losslessly converted to MNG
and back to a series of equivalent PNG or JNG images, even when the
delta format is used to store them in the MNG.

<li>JNG provides JPEG with alpha-channel transparency and color space
information.


<li>Multiple-image GIF files
can be losslessly converted to MNG, and,
(except for those using
the "restore-to-previous" disposal method)
can be losslessly converted to
MNG-LC and (except for those with a variable framing
rate, and less efficiently, except also for those using the
"restore-to-background" disposal method) to MNG-VLC.

<li>Most JPEG files can be losslessly converted to JNG or MNG, and all
JNG datastreams can be losslessly converted to JPEG files.

<li>It is complementary to MPEG and does not attempt to replace MPEG for
lossy storage of video.  MNG does, however, provide the capability of
storing animations consisting of JPEG-encoded images that have been
wrapped in the JNG format.

</ul>

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

<p>See also the glossary in the PNG
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>abstract image or object</strong>

<dd>An image whose pixels have a private representation, and which does
not necessarily carry PNG or JNG chunk data.  An image delta cannot be
applied to an abstract image.  All abstract objects are viewable.
Object 0 is always abstract, since it is never stored.

<p>

<dt><strong>animation</strong>

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

<p>

<dt><strong>cheap transparency</strong>

<dd>Image transparency data conveyed via the PNG <span class=cn>tRNS</span> chunk rather
than via a full alpha channel.

<p>

<dt><strong>child, or child image</strong>

<dd>An image produced by applying an image delta to a parent object.

<p>

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

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

<p>

<dt><strong>color encoding</strong>

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

<p>

<dt><strong>concrete image or object</strong>

<dd>An image or object whose pixels have a publicly known representation,
and which uses a publicly known color encoding.  A concrete PNG or JNG
image also carries data from other known PNG or JNG chunks that are
present.


<p>

<dt><strong>embedded object or image</strong>

<dd>A concrete object or 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>, <span class=cn>MOVE</span>, and <span class=cn>CLIP</span> chunks
would still be measured from this offscreen origin.
In MNG-VLC, all images must be placed with the image's upper left
corner at the frame origin.

<p>

<dt><strong>framing rate</strong>

<dd>The rate, measured in frames per second, at which frames are displayed
on the output device.  In a MNG datastream, the framing rate is
the interframe delay, in ticks, divided by the number of ticks per second,
from the <span class=cn>MHDR</span> chunk.
The <span class=cn>FRAM</span> chunk can be used to change the framing rate for a portion
of the datastream.

<p>

<dt><strong>frozen object</strong>

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

<p>

<dt><strong>image delta</strong>

<dd>An object that can be applied to a concrete image or object to
produce another concrete image.  For any two concrete images, there
exists an image delta that will produce one from the other.

<p>

<dt><strong>image N or object N</strong>

<dd>Shorthand for "the object with the set of object attributes pointed
to by <span class=expr>`object_id=N'</span>".
In MNG-LC and MNG-VLC, only image 0 is permitted.


<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>A stored image that is displayed in
response to a <span class=cn>SHOW</span>, <span class=cn>CLON</span>, or <span class=cn>MAGN</span> chunk directive,
located and clipped.
<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>
The background image, clipped, located, and displayed against
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.
If the background
consists of both a background color and a background image, these
are combined into a single layer.
<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 or a nonviewable basis object.
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
and MNG-VLC
only object 0 is permitted.

<p>

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

<dd>Properties of an object such as its existence, potential visibility,
location,
clipping boundaries, and a pointer to an object buffer.
See <a href="#obj-attributes">Object attributes</a>, 
below.

<p>

<dt><strong>object buffer</strong>

<dd>A 2D array of pixels or pixel deltas, each of which has color and
transparency information.  More than one object can point to a given
object buffer.  See <a href="#obj-buffers">Object buffers</a>, 
below.

<p>

<dt><strong>parent, parent object, or parent image</strong>

<dd>An object to which a delta is applied.

<p>

<dt><strong>pixel sample depth and alpha sample depth</strong>

<dd>The sample depth used for decoding <span class=cn>IDAT</span> data
in Delta-PNG and JNG datastreams and <span class=cn>JDAA</span> data in JNG datastreams.
They are not necessarily the same as the
sample depth of the object, which is called "sample depth" or
"object sample depth" in this document.


<p>

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

<dd>One of

<ul>

<li>
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
cloned or
decoded.

<li>an existing object that has been made potentially visible (i.e., it has
been marked for being made visible by subsequent <span class=cn>SHOW</span> chunks), by
setting its <code class=expr>do_not_show</code> flag to zero.

</ul>
&nbsp;</dd>


<dt><strong>prologue segment</strong>

<dd>The first segment, when there is more than one segment.

<p>

<dt><strong>regular segment</strong>

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

<p>

<dt><strong>replication</strong>

<dd>Making an additional copy.  If you replicate something
N times, you end up with N+1 of them.

<p>

<dt><strong>segment</strong>

<dd>A part of a MNG datastream starting with the <span class=cn>MHDR</span> chunk
or with a <span class=cn>SEEK</span> chunk and extending to just before the next
<span class=cn>SEEK</span> chunk (or the <span class=cn>MEND</span> chunk if there is no next
<span class=cn>SEEK</span> chunk).  The <span class=cn>MHDR</span>, <span class=cn>MEND</span>, <span class=cn>SAVE</span>,
<span class=cn>SEEK</span>, and <span class=cn>TERM</span> chunks are not considered to be a part
of any segment.



<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>viewable image</strong>

<dd>A stored object or embedded object that is capable of being made visible.
An image is viewable, while some objects resulting from decoding a <span class=cn>BASI</span>
datastream are not viewable.


<p>

<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>An "object", which is identified by
an <code class=expr>object_id</code>, is an
image or it is a nonviewable entity that is created by the <span class=cn>BASI</span>
chunk.  The <code class=expr>object_id</code> is an unsigned sixteen-bit number that
serves as the identifier of a set of object attributes.

<p>An "image" is a viewable object.

<p>Object 0 is a special object whose pixel data is not available for later
use (see <a href="#object-0">below</a>).

<h3><a name="obj-embedded">3.1. Embedded objects</a></h3>

<p>An embedded object is:

<ul>

<li>A PNG datastream (<span class=cn>IHDR</span>, PNG chunks, <span class=cn>IEND</span>).

<li>A JNG datastream (<span class=cn>JHDR</span>, JNG chunks, <span class=cn>IEND</span>).

<li>A BASI datastream (<span class=cn>BASI</span>, PNG chunks, <span class=cn>IEND</span>).

</ul>

<h3><a name="obj-attributes">3.2. Object attributes</a></h3>

<p>Objects have <em>object attributes</em> that can be defined
and modified by the contents of various MNG chunks.  Decoders are
responsible for keeping track of them.  The simplest decoder might
establish a 65,536-element array for each attribute, but real
applications will undoubtedly use a more memory-efficient method.
Object attributes include:

<dl>

<dt><strong>Existence</strong>

<dd>A nonzero object comes into existence when

<ul>

<li>a <span class=cn>DEFI</span> chunk creates it.

<li>a <span class=cn>CLON</span> chunk creates it.

</ul>

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

<ul>

<li>it is the subject of a <span class=cn>DISC</span> chunk.

<li>an empty <span class=cn>DISC</span> chunk appears.

<li>a <span class=cn>SEEK</span> chunk appears.

<li>the <span class=cn>MEND</span> chunk appears (or the <span class=cn>IEND</span> chunk appears
in a simple PNG or JNG file).

<li>a new embedded object with the same <code class=expr>object_id</code> replaces it
without an intervening <span class=cn>DEFI</span> chunk.  In this case, the new object
inherits the set of object attributes from the previous object with the same
<code class=expr>object_id</code>.

</ul>

<p>Object 0 always exists.<br>
&nbsp; </dd>

<dt><strong>Pointer to an object buffer</strong>

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

<p>

<dt><strong>Frozen or not frozen</strong>

<dd>All objects are initially "not frozen".  Any objects in
existence (except for object 0) when the <span class=cn>SAVE</span> chunk is encountered
become "frozen", along with the object buffers that they point to.

<p>

<dt><strong>Potential visibility</strong>

<dd>The "potential visibility" of an object is determined by the
<code class=expr>do_not_show</code> byte of the <span class=cn>DEFI</span> or <span class=cn>CLON</span> chunk
that introduced it.  The "potential visibility" of viewable objects
can be changed by the <span class=cn>SHOW</span> chunk.  When an embedded object is
"potentially visible," it can be displayed "on-the-fly"
as it is being
decoded.  Later, the <span class=cn>SHOW</span> chunk can direct that a "potentially
visible" viewable object be displayed.
It is permitted to change the potential visibility of "frozen"
objects; if this is done, the potential visibility must be restored to
its "saved" condition by the encoder prior to the end of the
segment.

<p>

<dt><strong>Viewability.</strong>

<dd>An object is viewable if it has a viewable object buffer.  It is
nonviewable if it has a nonviewable object buffer or if its object buffer
has not yet been created or has been destroyed.  Any attempt to display a
nonviewable object must be ignored and not treated as an error.

<p>A nonviewable object becomes viewable immediately when the
decoder receives a viewable object buffer or when an image delta makes it
viewable, and if the object is potentially visible it can be displayed
"on-the-fly" while the object buffer is being decoded or updated.
Note that object 0 is only viewable while its embedded image is being
decoded and displayed on-the-fly, after which it becomes nonviewable
again because no object buffer is ever created for object 0.

<p>

<dt><strong>Location</strong>

<dd>The X and Y location of an object is determined by the <span class=cn>DEFI</span>
chunk that introduced it, and can be changed by the <span class=cn>MOVE</span> chunk.
It is permitted to change the location of "frozen"
objects, provided that the encoder includes a <span class=cn>MOVE</span> or <span class=cn>DEFI</span>
chunk prior to the end of the segment that restores their locations to their
"saved" positions.

<p>

<dt><strong>Clipping boundaries</strong>

<dd>The clipping boundaries of an object are determined by the
<span class=cn>DEFI</span> chunk that introduced it, and can be changed by means of
the <span class=cn>CLIP</span> chunk.
It is permitted to change the clipping boundaries of "frozen"
objects, provided that the encoder includes a <span class=cn>CLIP</span> chunk
prior to the end of the segment that restores the boundaries to their
"saved" values.

<p>

<dt><strong>Additional information</strong>

<dd>While not required by this specification, applications may wish to
store other information about the object, such as whether it is eligible
to be updated by block-alpha-addition, for error-checking purposes.

<p>

</dl>

<h3><a name="obj-buffers">3.3. Object buffers</a></h3>

<p>An object buffer is created by the appearance of an embedded object
in the datastream, with a nonzero <code class=expr>object_id</code>, or by the
appearance of a <span class=cn>CLON</span> chunk that specifies a "full clone".
The contents of an object buffer can be modified by processing an image
delta or a <span class=cn>PAST</span> chunk.

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

<p>Object 0 conceptually never has an object buffer. Decoding applications
can create one for their own convenience, but such an object buffer must
never be made available to the rest of the MNG datastream or be considered
viewable after it has been processed.

<p>When the "stored object buffers" flag (bit 9 of the simplicity
profile) is 0
and valid (i.e., bit 6 is 1 and bit 9 is 0), an object buffer need not be
created even when an embedded object with a nonzero <code class=expr>object_id</code>
appears, since the flag promises that the object buffer will never be used
again.
There is no requirement <em>not</em> to create an object buffer; no
harm will be done except for some unnecessary memory consumption.

<dl>

<dt><strong>Viewability of object buffer</strong>

<dd>Any object that points to a viewable object buffer can be
displayed, but one that points to a nonviewable one cannot.
Any attempt to do so must be ignored.

<ul>

<li>A PNG or JNG datastream always has the "viewable" attribute.

<p>

<li>The "viewable" attribute of a <span class=cn>BASI</span> datastream is
defined in the <span class=cn>BASI</span> chunk.  Only <span class=cn>BASI</span> datastreams that
describe an object equivalent to one described by a legal PNG datastream
can be declared "viewable".

<p>

<li>When a Delta-PNG is applied to a parent object, the resulting object
buffer always has the "viewable" attribute.

<p>

</ul>

<p>

<dt><strong>Format of data in the object buffer</strong>

<dd>The data format can be:

<ul>

<li>A concrete PNG or JNG object.
A concrete object must be stored by the decoder in a form that
retains the complete object description, sufficient to regenerate the
original object description or its equivalent without loss.  Its pixels
have a publicly known representation and it uses a publicly known color
encoding.
PNG objects might contain deviations from what is allowed in legal PNG
datastreams, if they were created by a <span class=cn>BASI</span> datastream and are
nonviewable.

<ul>

<li>In the case of a PNG object, the object also carries data from other
known PNG chunks that are present.  This means that the decoder must
store sufficient information to make it possible to restore exactly the
original decoded and unfiltered pixel samples as they existed prior
to any gamma correction (but not the original compressed datastream
or line-by-line filter selections and "zlib" compression flags),
and data from the <span class=cn>IHDR</span> and <span class=cn>PLTE</span> chunks and any
additional recognized PNG chunks such as <span class=cn>gAMA</span>, <span class=cn>cHRM</span>,
and <span class=cn>tRNS</span> that the application plans to use.  The sample depth,
color type, filter method, compression method, and interlacing method
of the image must be retained, and if the object has
been modified by a Delta-PNG, the
<a href="#Delta-PNG-decoding">"pixel sample depth"</a> 
and
"alpha sample depth" must also be retained for use in decoding
subsequent Delta-PNG datastreams.

<p>

<li>In the case of a JNG image, the object also carries data from other
known JNG chunks that are present.  This means that the decoder must
store sufficient information to make it possible to restore exactly the
original JPEG datastream and decoded alpha channel as
they existed in the original JNG file, and data from the <span class=cn>JHDR</span>
chunk and any additional recognized JNG chunks such as <span class=cn>gAMA</span> and
<span class=cn>cHRM</span> that the application plans to use.  As with PNG objects,
when the object has been modified by a Delta-PNG, the
"alpha sample depth" must also be retained for use in decoding
subsequent Delta-PNG datastreams.  The "alpha compression method"
must be retained as well.

<p>

<li>A decoder that recreates PNG or JNG files from a series of PNG,
JNG, and Delta-PNG datastreams will also have to store the contents of
any unknown chunks that it finds, in case they turn out to be safe to
copy (see <a href="#Delta-PNG-DROP">DROP (Paragraph 6.1.10)</a>,
<a href="#Delta-PNG-DBYK">DBYK (Paragraph 6.1.11)</a>,
and <a href="#Delta-PNG-ORDR">ORDR (Paragraph 6.1.12)</a>, 
below).

<p>

</ul>

<p>

<li>An abstract image.  An abstract image can be stored by the decoder
in any form
that is convenient, such as an X Window System "pixmap", even
though that form might not have sufficient resolution for exact,
lossless conversion.
In the case of a PNG image, the pixels could be stored after the gamma
and chromaticity corrections have been made, and the sample depth could
be the same as the display hardware, even though it is smaller than
the original sample depth.  Similarly, a JNG image could be stored in
the same form, after the pixels have been decoded, converted to RGB
form, and gamma-corrected.  It is always safe, however, to store an
abstract image as though it were concrete, if decoders do not wish to
take advantage of the distinction between abstract and concrete objects.

<p>

</ul>

<p>

<dt><strong>Frozen or not frozen</strong>

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

<p>

<dt><strong>A reference count</strong>

<dd>When an object buffer is first created, its reference count is set to
1.

<p>When a partial clone is made of an object via the <span class=cn>CLON</span>
chunk, the reference count for the object buffer is incremented, and no
new object buffer is created.

<p>When an object is discarded and it points to an object
buffer that has a nonzero reference count, that reference count
is decremented and the object buffer is also
discarded if the resulting reference count is zero.

<p>

</dl>

<h3><a name="object-0">3.4. Object 0</a></h3>

<p>Object 0 is a special object that has a set of object attributes
that control its location, clipping, and visibility properties, and
also has a set of magnification factors and methods, but does not have
an object buffer.  The object attributes and magnification data,
which can be modified by the <span class=cn>DEFI</span>, <span class=cn>MOVE,</span> <span class=cn>CLIP,</span>
and <span class=cn>MAGN</span> chunks, are applied to subsequent
embedded objects whose <code class=expr>object_id</code> is zero.  The pixel data for
object 0 is available only for on-the-fly display and not available for later use.
If at the end of any segment the attribute values or magnification data
are different from the default/saved values, they become undefined when
a <span class=cn>SEEK</span> chunk appears.


<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.
Unless otherwise specified in the Delta-PNG chapter of
this specification, they need not be recognized within a Delta-PNG 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-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
                            0: Absence of any features is unspecified.
                               All other bits of the simplicity profile
                               must be zero (i.e, all other even numbers
                               are invalid).
                            1: Absence of certain features is specified by
                               the remaining bits of the simplicity profile.
                            (must be 1 in MNG-LC and MNG-VLC
                            datastreams)
                          bit 1: Simple MNG features
                            0: Simple MNG features are absent.
                            1: Simple MNG features may be present.
                            (must be 0 in MNG-VLC datastreams)
                          bit 2: Complex MNG features
                            0: Complex MNG features are absent.
                            1: Complex MNG features may be present.
                            (must be 0 in MNG-LC and MNG-VLC datastreams)
                          bit 3: Internal transparency
                            0: Transparency is absent or can be ignored.
                               All images in the datastream are opaque or
                               can be rendered as opaque without affecting
                               the final appearance of any frame.
                            1: Transparency may be present.
                          bit 4: JNG
                            0: JNG and JDAA are absent.
                            1: JNG or JDAA may be present.
                            (must be 0 in MNG-LC and MNG-VLC
                            datastreams)
                          bit 5: Delta-PNG
                            0: Delta-PNG is absent.
                            1: Delta-PNG may be present.
                            (must be 0 in MNG-LC and MNG-VLC datastreams)
                          bit 6: Validity flag for bits 7, 8, and 9
                            0: The absence of background transparency,
                               semitransparency, and stored object buffers
                               is unspecified; bits 7, 8, and 9 have no
                               meaning and must be 0.
                            1: The absence or possible presence of
                               background transparency is expressed by
                               bit 7, of semitransparency by bit 8, and of
                               stored object buffers by bit 9.
                          bit 7: Background transparency
                            0: Background transparency is absent (i.e., the
                               first layer fills the entire MNG frame with
                               opaque pixels).
                            1: Background transparency may be present.
                          bit 8: Semi-transparency
                            0: Semitransparency (i.e., an image with an
                               alpha channel that has values that are
                               neither 0 nor the maximum value) is absent.
                            1: Semitransparency may be present.
                            If bit 3 is zero this field has no meaning.
                          bit 9: Stored object buffers
                            0: Object buffers need not be stored.
                            1: Object buffers must be stored.
                            (must be 0 in MNG-LC and MNG-VLC
                             datastreams)
                            If bit 2 is zero, this field has no meaning.
                          bits 10-15: Reserved bits
                            Reserved for public expansion.  Must be zero in
                            this version.
                          bits 16-30: Private bits
                            Available for private or experimental expansion.
                            Undefined in this version and can be ignored.
                          bit 31: Reserved bit. Must be zero.
</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
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.
In MNG-VLC datastreams, it gives the framing rate.
It must be nonzero if the datastream contains a sequence of images.
When the datastream contains exactly one frame,
this field should be set to zero.
When this field is zero, the length of a tick is infinite, and
decoders will ignore any
attempt to define interframe delay, timeout, or any other variable that
depends on the length of a tick.  If the frames are intended to be
displayed one at a time under user control, such as a slide show or
a multi-page FAX, the tick length can be set to any positive number
and a <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>fPRI</span> chunks and 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.
In MNG-VLC datastreams, the frame count is the same as the number of
embedded images in the datastream (or one, the background layer, if there are
no embedded images).

<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>fPRI</span> chunks and 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.
In MNG-VLC datastreams, the layer count is the number of embedded images,
plus one (for the background layer).

<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>fPRI</span> chunks and 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.
In MNG-VLC datastreams, the nominal play time is the same as the frame count,
except when the <code class=expr>ticks_per_second</code> field is zero, in which case the
nominal play time is also zero.

<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 and MNG-VLC
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>When bit 2 is zero, the datastream does not contain any "complex MNG
features".  These are the <span class=cn>BASI</span>,
<span class=cn>CLON</span>, <span class=cn>DHDR/IEND</span>, <span class=cn>PAST</span>, <span class=cn>DISC</span>,
<span class=cn>MOVE</span>, <span class=cn>CLIP</span>, and <span class=cn>SHOW</span>
chunks, or any chunk in a future version of this specification
that defines or uses stored objects.  If
the <span class=cn>DEFI</span> chunk is present, it only defines object 0.
If the <span class=cn>BACK</span> chunk is present, it does not define
a background image.
If the <span class=cn>LOOP</span> chunk is present, it has <span class=expr>iteration_min=1</span>.
A MNG with a "complex MNG feature" (which has a simplicity
profile that has bit 2 set to 1) may contain
at least one of these chunks.  A simple
decoder can display "simple" MNGs (which have a simplicity
profile with bit 2 set to 0) without having to store any
objects or dealing with the <span class=cn>SAVE/SEEK</span> mechanism, and it can ignore
the <span class=cn>LOOP</span> and <span class=cn>ENDL</span> chunks and execute all loops
exactly once.

<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
is only useful when bit 2
is nonzero (i.e., "complex MNG features" are present).  This
flag promises that even though such features are present, no chunk will
ever use the information in an existing object buffer; therefore it is not
necessary to store an object buffer for any object.  A set of object attributes
is necessary for each object, however.  Therefore, the <span class=cn>MOVE</span>,
<span class=cn>CLIP</span>, <span class=cn>DISC</span>, deterministic <span class=cn>LOOP</span>,
partial <span class=cn>CLON</span>, and immediately-displayed <span class=cn>BASI</span> chunk
are permissible.  The "stored object buffers" flag means nothing
if bit 2 is 0 or bit 6 is 0.

<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>A MNG-VLC (i.e., a "very low-complexity MNG") datastream must
have a simplicity profile with
bit 0 equal to 1 and all other bits except possibly for bits 3, 6, 7, and 8
(transparency)
equal to 0.  If bit 4 (JNG) is 1, the datastream is a "MNG-VLC with
JNG" datastream.  It might contain a
JNG datastream carrying an image or an alpha channel.
MNG-VLC decoders are allowed to reject such datastreams unless
they have been enhanced with JNG capability.

<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 or a MNG-VLC
datastream because a "complex" MNG feature might be present.
If the simplicity profile
promises that certain features are absent, but they are actually present in
the MNG datastream, the datastream is invalid.

<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
provides a "shorthand" notation that can be
used to avoid having to repeat identical chunks in a MNG datastream.
The <span class=cn>LOOP</span> chunk
can be ignored by
MNG-LC and MNG-VLC
decoders, along with the <span class=cn>ENDL</span> chunk.
Its contents are the first two or more of the following fields.  If
any field is omitted, all subsequent fields must also be omitted:

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

<p>Decoders must treat the chunks enclosed in a loop exactly as if they
had been repeatedly spelled out.  Therefore, during the first iteration
of the loop, the parent objects for any Delta-PNG datastreams in the
loop are the images in existence prior to entering the <span class=cn>LOOP</span>
chunk, but in subsequent iterations these parent objects might have been
modified.  The <code class=expr>termination_condition</code> field can be used to
inform decoders that it is safe to change the number of loop iterations.

<p>Simple decoders can ignore all fields except for the
<code class=expr>iteration_count</code>.

<p>When the <span class=cn>LOOP</span> chunk is present, an <span class=cn>ENDL</span> chunk
with the same <code class=expr>nest_level</code> must be present later in the MNG
datastream.  Loops can be nested.  Each inner loop must have a higher
value of <code class=expr>nest_level</code> than the loop that encloses it, though
not necessarily exactly one greater.

<p>The termination condition specifies how the actual number of
iterations is determined.  It is very similar to the termination
condition field of the <span class=cn>FRAM</span> chunk, and can take the same
values:

<dl>

<dt><strong>Deterministic</strong>

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

<p>

<dt><strong>Decoder-discretion</strong>

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

<p>

<dt><strong>User-discretion</strong>

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

<p>

<dt><strong>External-signal</strong>

<dd>The number of iterations must not be less than
<code class=expr>iteration_min</code> nor more than <code class=expr>iteration_max</code>.  The
exact number can be determined by the arrival of a signal whose number
matches one of the <code class=expr>signal_number</code> fields.

<p>

</dl>

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

<p>The <code class=expr>iteration_min</code> and <code class=expr>iteration_max</code>
can be omitted.  If the condition is &lt;deterministic&gt; the
values are not used.  Otherwise,
defaults of 1 and &lt;infinity&gt; are used.  The <code class=expr>iteration_count</code>,
<code class=expr>iteration_min</code>, and <code class=expr>iteration_max</code> can be any
non-negative integers or &lt;infinity&gt;, but they must satisfy
<code class=expr>iteration_min &lt;= iteration_count &lt;= iteration_max</code>.
Infinity is represented by 0x7fffffff.  If all of the loops in
a MNG datastream have <code class=expr>iteration_min=1</code>, the datastream
can qualify as a "simple" MNG for the purpose of setting bits
1 and 2
of the "simplicity profile" to zero, unless there are other
reasons for setting them to one.

<p>If <code class=expr>iteration_count</code> is zero,
the <code class=expr>termination_condition</code>, the subsequent fields must be
omitted, and the loop is done zero times.
Upon encountering a <span class=cn>LOOP</span> chunk whose <code class=expr>iteration_count</code>
is zero,
decoders simply skip chunks until the matching <span class=cn>ENDL</span> chunk is
found, and resume processing with the chunk immediately following it.

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

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

<p>MNG editors that extract a series of PNG or JNG files from a MNG datastream
are expected to execute the loop only <code class=expr>iteration_min</code> times, when
the termination condition is not &lt;deterministic&gt;.

<p>The <a name="mng-ENDL"><span class=cn>ENDL</span></a> 
chunk ends a loop that begins
with the <span class=cn>LOOP</span> chunk.  It contains a single one-byte field:

<pre>
   Nest_level: 1 byte (unsigned integer), range [0..255].
</pre>

<p>When the <span class=cn>ENDL</span> chunk is encountered, the loop
iteration count is decremented, if it is not already zero.  If
the result is nonzero, processing resumes at the beginning of the loop.
Otherwise processing resumes with the chunk immediately following the
<span class=cn>ENDL</span> chunk.

<p>When the <span class=cn>ENDL</span> chunk is present, a <span class=cn>LOOP</span> chunk with
the same <code class=expr>nest_level</code> must be present earlier in the MNG
datastream.  See <a href="#d-endl">below</a>.  
Loops must be properly
nested: if a <span class=cn>LOOP</span> chunk with higher <code class=expr>nest_level</code>
appears inside a <span class=cn>LOOP/ENDL</span> pair, a matching <span class=cn>ENDL</span> chunk
must also appear to close it.

<p>The <span class=cn>SAVE</span> and <span class=cn>SEEK</span> chunks are not permitted
inside a <span class=cn>LOOP-ENDL</span> pair.  To rerun an entire datastream that
includes these chunks, use the <span class=cn>TERM</span> chunk instead.
See <a href="#mng-TERM">below (Paragraph 4.2.11)</a>.


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

<p>The chunks described in this section create
objects and initialize their object attributes, or change their object
attributes or the data in their object buffers.  Some of them also
may cause images to be immediately displayed.


<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>,
<span class=cn>BASI-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>If the object number for an object is nonzero, subsequent chunks can
use this number to identify it.

<p>When the object number for an object is zero, its object buffer
can be discarded immediately after it has been processed, and it can
be treated as an "abstract" image, regardless of the contents of the
<code class=expr>concrete_flag</code> field.

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

<p>Multiple <span class=cn>IHDR-IEND</span>, <span class=cn>JHDR-IEND</span>, and
<span class=cn>BASI-IEND</span> objects can follow a single <span class=cn>DEFI</span> chunk.
When <code class=expr>object_id</code> is nonzero, the <span class=cn>DEFI</span> chunk values
remain in effect until another <span class=cn>DEFI</span> chunk or a <span class=cn>SEEK</span>
chunk appears, unless they are modified by <span class=cn>SHOW</span>, <span class=cn>MOVE</span>,
or <span class=cn>CLIP</span> chunks.
The <code class=expr>object_id</code> and <code class=expr>concrete_flag</code>
can only be changed by using another <span class=cn>DEFI</span> chunk.  If no
<span class=cn>DEFI</span> chunk is in effect (either because there is none in
the datastream, or because a <span class=cn>DISC</span> or <span class=cn>SEEK</span> chunk has
caused it to be discarded),
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>

<p>The object attributes for all existing unfrozen objects except for object
0 become undefined when a <span class=cn>SEEK</span> chunk is encountered.

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

<p>These default values are also used to fill any fields that were omitted from
the <span class=cn>DEFI</span> chunk, when an object with the same <code class=expr>object_id</code>
has not been previously defined or a <span class=cn>DISC</span> or <span class=cn>SEEK</span> chunk has
caused it to be discarded.

<p>An set of object attributes is created or an existing one is modified when
the <span class=cn>DEFI</span> chunk appears, but an object buffer is neither created
nor discarded.
If <code class=expr>object_id</code> is an identifier that already exists when
a <span class=cn>DEFI</span> chunk appears, the set of object attributes (except for
the pointer to the object buffer) is immediately replaced.  The
contents of the object buffer do not change, however, until and unless
an <span class=cn>IHDR</span>, <span class=cn>JHDR</span>, <span class=cn>BASI</span>, or <span class=cn>PAST</span> chunk is
encountered.  When one of these chunks appears, all of the contents
of the object buffer previously associated with the identifier are discarded
and the new data is stored in the object buffer.

<p>Note that if the object has partial clones, the object buffer of the clones
is naturally affected by the new data because it is shared, but the object
attributes sets of the clones are not affected.


<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>If the PNG <span class=cn>sRGB</span>, <span class=cn>gAMA</span>, <span class=cn>iCCP</span>, or
<span class=cn>cHRM</span> chunks appear in the top-level MNG datastream (and have
not been nullified), but none of them appear in the PNG datastream,
then the values are inherited from the top level as though the chunks
had actually appeared in the PNG datastream.  Data from such chunks
appearing in the PNG datastream take precedence over the inherited
values.  If any one of these chunks, or any chunk in a future
version of this specification that defines
the color space, appears in the PNG datastream, none of them is
inherited.  MNG applications that recreate PNG files must write
these chunks, if they are inherited, in the output PNG files.  If
the <span class=cn>sRGB</span> chunk is present in a MNG datastream, it need not
be accompanied in the MNG datastream by <span class=cn>gAMA</span> and <span class=cn>cHRM</span>
chunks, despite the recommendation in the PNG
specification.  Any MNG viewer that processes the <span class=cn>gAMA</span> chunk must
also recognize and process the <span class=cn>sRGB</span> chunk.  It can treat
it as if it were a <span class=cn>gAMA</span> chunk containing the value .45455
and it can ignore its "intent" field.  If the <span class=cn>sRGB</span> chunk
is present in the MNG datastream, editors that write PNG datastreams should
add the <span class=cn>gAMA</span> and <span class=cn>cHRM</span> chunks to the PNG datastream, even
though they are not present in the MNG datastream.

<p>
Note that the top-level color space chunks are used only to supply
missing color space information to subsequent embedded PNG or JNG datastreams.
They do not have any effect on already-decoded objects.

<p>

<li>If the PNG <span class=cn>sPLT</span> chunk appears in the top-level MNG
datastream, it takes precedence over any <span class=cn>sPLT</span> chunk appearing
in the PNG datastream.  MNG applications that recreate PNG files should
not copy top-level <span class=cn>sPLT</span> chunks to the output PNG files, because
a suggested palette for rendering a group of images is not necessarily
the best palette for rendering a single image.

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

<p>If <code class=expr>object_id</code> is zero, there is no need to store the
pixel data after decoding it and perhaps displaying it.

<p>If <code class=expr>concrete_flag=1</code> is 1 and <code class=expr>object_id</code> is nonzero,
the decoder must store the original pixel data losslessly, along
with data from other recognized PNG chunks, because it is possible
that a subsequent Delta-PNG datastream might want to modify it.  If
<code class=expr>concrete_flag</code> is zero, the decoder can store the pixel data in any
form that it chooses.
If the "stored object buffers" flag in the simplicity profile is
valid and zero, there is no need to store the pixel data and other chunk
data after decoding and perhaps displaying the image.

<p>If an object already exists with the same <code class=expr>object_id</code>, the
contents of its object buffer are replaced with the new data.

<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
<a href="#jng">below (Chapter 5)</a>
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 and MNG-VLC
applications are not expected to process JNG
datastreams unless they have been enhanced with JNG capability.

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

<p>The <span class=cn>BASI</span> chunk introduces a basis object that, while it
might be incomplete, can serve as a parent object to which a delta image
can be applied.

<p>The first 13 bytes of the <span class=cn>BASI</span> chunk are identical to those
of the <span class=cn>IHDR</span> chunk.  The next 8 bytes, which can be omitted,
 provide sixteen-bit {red, green, blue, alpha} values that are used to fill
the entire basis object when the <span class=cn>IDAT</span> chunk is not present, and a
1-byte "viewable" flag can also be present.

<pre>
   Width:              4 bytes (unsigned integer).
   Height:             4 bytes (unsigned integer).
   Sample_depth:       1 byte (unsigned integer) 1, 2, 4, 8, or 16.
   Color_type:         1 byte (unsigned integer) 0: Gray, 2: RGB, 3: indexed
                         color, 4: Gray-alpha, 6: RGBA
   Compression_method: 1 byte (unsigned integer).
                         0: zlib with deflate
   Filter_method:      1 byte (unsigned integer).
                         0: five basic filter types.
                         64: intrapixel differencing and five basic filter
                             types.
   Interlace_method:   1 byte (unsigned integer).
                         0: none, 1: Adam7
   Red_sample or
     gray_sample:      2 bytes (unsigned integer).
   Green_sample:       2 bytes (unsigned integer).
   Blue_sample:        2 bytes (unsigned integer).
   Alpha_sample:       2 bytes (unsigned integer).
   Viewable:           1 byte (unsigned integer).
                         0: Basis object is not viewable.
                         1: Basis object is viewable.
</pre>

<p>The sample depth, color type, compression method, and
interlace method must be valid PNG types, and the width and height
must be within the valid range for PNG datastreams.  The filter method
must be one of the filter methods allowed in PNG datastreams (currently
only 0) or the additional filter method (64) allowed in PNG
datastreams that are embedded in MNG datastreams.

<p>The <code class=expr>alpha_sample</code> can be omitted if the <code class=expr>viewable</code>
field is also omitted.  If so, and the <code class=expr>color_type</code> is one
that requires alpha, the alpha value corresponding to an opaque
pixel will be used.  If the color samples are omitted, zeroes will
be used.  If the <code class=expr>viewable</code> field is omitted, the object is not
viewable.

<p>The decoder is responsible for converting the color and
alpha samples to the appropriate format and sample depth for the
specified <code class=expr>color_type</code>.

<p>The color and alpha samples are written as four sixteen-bit samples
regardless of the <code class=expr>color_type</code> and <code class=expr>sample_depth</code>.
When the <code class=expr>sample_depth</code> is less than sixteen, the least
significant bits are used and the remaining bits must be zero
filled.

<p>When <code class=expr>color_type</code> is 0 or 4, the green and blue
samples must be present but must be ignored by decoders.

<p>When <code class=expr>color_type</code> is 0 or 2,
only the values 0 and <code class=expr>2<sup>sample_depth</sup></code> should be written.
Any other alpha value must be interpreted as fully opaque.

<p>When <code class=expr>color_type</code> is 3, the
decoder must generate a palette of length <code class=expr>2<sup>sample_depth</sup></code>,
whose first entry contains the given <code class=expr>{red_sample, green_sample,
blue_sample}</code> triple, and whose remaining entries are filled with
zeroes.  It must also generate an alpha array whose first entry is the
given alpha sample and the rest are opaque
(i.e., if the alpha sample is not opaque, it creates a one-entry tRNS
chunk containing the least significant byte of the given alpha sample).

<p>The <span class=cn>BASI</span> datastream contains PNG chunks, but is not
necessarily a PNG datastream.  It can be incomplete or empty and it can
deviate in certain ways from the PNG specification.  It can serve as a
parent object for a Delta-PNG datastream, which must supply the missing
data or correct the other deviations before the image is displayed.  The
end of the datastream is denoted by an <span class=cn>IEND</span> chunk.

<p>The <a name="MNG-BASI-Dev">permitted deviations</a> 
from the PNG format
in a <span class=cn>BASI</span> datastream are:

<ul>

<li>The <span class=cn>IDAT</span> chunk can be omitted or there can be a single
empty <span class=cn>IDAT</span> chunk.  If so, all of the pixels are filled with the
given color and alpha samples from the <span class=cn>BASI</span> chunk.

<p>

<li>Multiple instances of some chunks can be present even though the PNG
specification allows only one.  The subsequent Delta-PNG that uses this
as the parent object must select only one, through the <span class=cn>DBYK</span> or
similar mechanism.  This deviation is only permitted when
the object is concrete and not viewable.

<p>

<li>The <span class=cn>PLTE</span> chunk can be omitted or incomplete even when
<code class=expr>color_type</code> is 3.  If so, the subsequent Delta-PNG that uses this
as the parent object can supply a complete replacement <span class=cn>PLTE</span> chunk,
if the single-entry palette that is generated is not desired.
This deviation is only permitted when the object is concrete and not viewable.

<p>

</ul>

<p>The <span class=cn>BASI</span> chunk can be used to introduce such things as
a library of <span class=cn>iCCP</span> chunks from which one or another can be
selected for use with any single image, or it can be used to introduce a
simple blank or colored rectangle that will be immediately displayed or
into which other images will be pasted
by means of the <span class=cn>PAST</span> chunk.

<p>A <span class=cn>BASI</span> chunk appearing in a MNG datastream receives its
<code class=expr>object_id</code>, location, and potential visibility from the
preceding <span class=cn>DEFI</span> chunk, if one is present, or the default
values for <span class=cn>DEFI</span>, if one is not present.  The
<code class=expr>concrete_flag</code> can be either 0 (abstract) or 1 (concrete),
depending on whether the basis image is intended for subsequent use by
a Delta-PNG datastream or not.  When it is abstract, it must also be
viewable.  When it is viewable, the
resulting object, after the pixel samples are filled in, must be identical
to an object that would have been obtained by decoding a legal
PNG datastream.  If <code class=expr>viewable</code> is 1 and
<code class=expr>do_not_show</code> is 0, a viewer is expected to display
it immediately, as if it were decoding a PNG datastream.

<p>If an object already exists with the same <code class=expr>object_id</code>, the
contents of its object buffer are replaced with the new data.

<p>Top-level <span class=cn>gAMA</span>, <span class=cn>sRGB</span>, <span class=cn>cHRM</span>, <span class=cn>bKGD</span>,
<span class=cn>sBIT</span>, <span class=cn>pHYs</span>, <span class=cn>iCCP</span>, and <span class=cn>sPLT</span> chunks
are inherited by a <span class=cn>BASI</span> datastream in the same manner as by a PNG
datastream.

<p>No provision is made in this specification for storing a BASI
datastream as a standalone file.  A <span class=cn>BASI</span> datastream will
normally be found as a component of a MNG datastream.  Applications
that need to store a <span class=cn>BASI</span> datastream separately should use a
different file signature and filename extension.  Better, they can wrap
it in a MNG datastream consisting of the MNG signature, the <span class=cn>MHDR</span>
chunk, the <span class=cn>BASI</span> datastream, and the <span class=cn>MEND</span> chunk.

<h4><a name="mng-CLON">4.2.6. <span class=cn>CLON </span>Clone an object</a></h4>

<p>Create a clone (a new copy) of an image, with a new
<code class=expr>object_id</code>.  The <span class=cn>CLON</span> chunk contains 4, 5, 6, 7, or
16 bytes.  If a field is omitted, all subsequent fields must also be
omitted.

<pre>
   Source_id:   2 bytes (nonzero unsigned integer).  Identifier of the
                  parent object to be cloned.
   
   Clone_id:    2 bytes (nonzero unsigned integer).  Identifier of the child
                  object that is created.
   
   Clone_type:  1 byte (unsigned integer).
   
                  0: Full clone of the set of object attributes and the
                     object buffer.
   
                  1: Partial clone; only set of object attributes (the
                     location, clipping boundaries, and potential
                     visibility) are copied and a link is made to the
                     object buffer.
   
                  2: Renumber object (this is equivalent to
                     "CLON source_id clone_id 1
                      DISC source_id").
   
                If this field is omitted, the clone_type defaults to zero
                (full clone).
   
   Do_not_show: 1 byte (unsigned integer).
                  0:  Make the clone potentially visible and display it
                      immediately.
                  1:  Make the clone not potentially visible.
                When this field is omitted, the object retains the
                potential visibility of the parent object.
   
   Concrete_flag:
                1 byte (unsigned integer).
                  0:  Concrete_flag is the same as that of the parent
                      object.
                  1:  Make the clone "abstract" (concrete_flag=0).
                When this field is omitted, the object retains the
                concrete flag of the parent object.
   
   Loca_delta_type:
                1 byte (unsigned integer)
   
                  0: Location data gives X_location and Y_location
                     directly.
   
                  1: New positions are determined by adding the location
                     data to the position of the parent object.
   
                This field, together with the X_location and Y_location
                fields, can be omitted as a group.  When they are omitted,
                the clone has the same location as the parent object.
   
   X_location or delta_X_location:
                4 bytes (signed integer).
   
   Y_location or delta_Y_location:
                4 bytes (signed integer).
</pre>

<p>The <code class=expr>source_id</code> must be an existing object identifier, and
the <code class=expr>clone_id</code> must not be an existing object identifier.

<p>Negative values are permitted for the X and Y position.  The positive
directions are downward and rightward from the frame origin.

<p>The clone is initially identical to the parent object except for the
location and potential visibility.  It has the same clipping boundaries
as the parent object.  Subsequent <span class=cn>DHDR</span>, <span class=cn>SHOW</span>,
<span class=cn>CLON</span>, <span class=cn>CLIP</span>, <span class=cn>MOVE</span>, <span class=cn>PAST</span>, and
<span class=cn>DISC</span> chunks can use the <code class=expr>clone_id</code> to identify it.  If
the parent object is not a viewable image, neither is the clone.

<p>Subsequent chunks can modify, show, or discard a full clone or modify
its potential visibility, location and clipping boundaries without
affecting the parent object.  They can also modify, show, or discard the
parent object or modify its set of object attributes without affecting the
clone.

<p>The <code class=expr>concrete_flag</code> byte must be zero or omitted when the
<code class=expr>clone_type</code> byte is nonzero.

<p>If an object has partial clones, and the data in the object buffer
of a parent object or any of its partial clones is modified, the parent
object and all of its partial clones are changed.  Decoders must take
care that when the parent object or any partial clone is discarded, the
object buffer is not discarded until the last remaining one of them
is discarded.  Only the location, potential visibility, and clipping
boundaries can be changed independently for each partial clone.

<p>If <code class=expr>viewable</code> is 1 and
<code class=expr>do_not_show</code> is 0, the resulting image is displayed immediately.

<h4><a name="mng-DHDR">4.2.7. <span class=cn>DHDR</span>, Delta-PNG chunks, <span class=cn>IEND</span></a></h4>

<p>A Delta-PNG datastream.

<p>See <a href="#Delta-PNG">The Delta-PNG Format (Chapter 6)</a>, 
below, for the
format of the Delta-PNG datastream.  Any chunks between <span class=cn>DHDR</span>
and <span class=cn>IEND</span> are written and decoded according to the Delta-PNG
format.  The <code class=expr>object_id</code> of the Delta-PNG <span class=cn>DHDR</span>
chunk must point to an existing parent object.  The resulting image
is immediately displayed if its <code class=expr>do_not_show</code> is 0.  The parent
object must be concrete (i.e., <code class=expr>concrete_flag</code> must be 1).

<h4><a name="mng-PAST">4.2.8. <span class=cn>PAST </span>Paste an image into another</a></h4>

<p>Paste an image or images identified by <code class=expr>source_id</code>,
or part of it, into an existing abstract image identified by
<code class=expr>destination_id</code>.

<p>The <span class=cn>PAST</span> chunk contains a 2-byte <code class=expr>destination_id</code>
and 9 bytes giving a "target location", plus one or more 30-byte source
data sequences.

<pre>
   Destination_id:  2 bytes (unsigned integer).
   
   Target_delta_type:
                    1 byte (unsigned integer).
                      0:  Target_x and target_y are given directly.
                      1:  Target_x and target_y are deltas from their
                          previous values in a PAST chunk with the same
                          destination_id.
                      2:  Target_x and target_y are deltas from their
                          previous values in the previous PAST chunk
                          regardless of its destination_id.
   
   Target_x:        4 bytes (signed integer), measured rightward from the
                       left edge of the destination image.
   
   Target_y:        4 bytes (signed integer), measured downward from the
                       top edge of the destination image.
   
   Source_id:       2 bytes (unsigned nonzero integer).  An image to be
                       pasted in.
   
   Composition_mode:
                    1 byte (unsigned integer).
                      0:  Composite over.
                      1:  Replace.
                      2:  Composite under.
   
   Orientation:     1 byte (unsigned integer).
                       The source image is flipped to another orientation.
   
                      0:  Same as source image.
                      2:  Flipped left-right, then up-down.
                      4:  Flipped left-right.
                      6:  Flipped up-down.
                      8:  Tiled with source image.  The upper left corner of
                          the assembly is positioned according to the
                          prescribed offsets.
   
   Offset_origin:   1 byte (unsigned integer).
                      0: Offsets are measured from the {0,0} pixel in the
                         destination image.
                      1: Offsets are measured from the {target_x,target_y}
                         pixel in the destination image.
   
   X_offset:        4 bytes (signed integer).
   Y_offset:        4 bytes (signed integer).
   
   Boundary_origin: 1 byte (unsigned integer).
                      0: PAST clipping boundaries are measured from the
                         {0,0} pixel in the destination image.
                      1: PAST clipping boundaries are measured from the
                         {target_x,target_y} pixel in the destination image.
   
   Left_past_cb:    4 bytes (signed integer).
   Right_past_cb:   4 bytes (signed integer).
   Top_past_cb:     4 bytes (signed integer).
   Bottom_past_cb:  4 bytes (signed integer).
   ...etc...
</pre>

<p>The destination image must have the "abstract" property
<code class=expr>(concrete_flag=0)</code>.  When <code class=expr>destination_id=0</code>, the
resulting image is "write-only" and therefore
only "composite-over"
(<code class=expr>composition_mode=0</code>) operations are permitted.

<p>The source images can be "abstract" or "concrete"
and have any
<code class=expr>color_type</code> and <code class=expr>sample_depth</code>.  They must
have the "viewable" property.  The number of source images is
<code class=expr>((chunk_length-11)/30)</code>.

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

<p>When <code class=expr>composition_mode=0</code>, any non-opaque pixels in the
source image are combined with those of the destination image.  If
the destination pixel is also non-opaque, the resulting pixel will be
non-opaque.

<p>When <code class=expr>composition_mode=1</code>, all pixels simply replace those
in the destination image.  This mode can be used to make a transparent
hole in an opaque image.

<p>When <code class=expr>composition_mode=2</code>, any non-opaque pixels in the
destination image are combined with those of the source image.  If the
source pixel is also non-opaque, the resulting pixel will be non-opaque.

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

<p>The clipping information from the <span class=cn>DEFI</span>, <span class=cn>MOVE</span>
or <span class=cn>CLIP</span> chunks associated with the
<code class=expr>destination_id</code> and the <code class=expr>source_ids</code> is not used in
the <span class=cn>PAST</span> operation (but if a decoder is simultaneously updating
and displaying the <code class=expr>destination_id</code>, the clipping boundaries
for the <code class=expr>destination_id</code> are used in the display
operation).

<h4><a name="mng-MAGN">4.2.9. <span class=cn>MAGN </span>Magnify objects</a></h4>

<p>This chunk provides mandatory magnification factors for existing objects
and/or for subsequent embedded images whose object id is 0.

<p>The chunk contains 0 to 18 bytes.  If any field is omitted, all subsequent
fields must also be omitted.
<pre>
   First_magnified_object_id:
                   2 bytes.  If omitted, any previous MAGN chunk is
                     nullified.
   Last_magnified_object_id:
                   2 bytes.  If omitted, last object_id = first object_id.
   X_method:       1 byte
                     0 or omitted: No magnification
                     1: Pixel replication of color and alpha samples.
                     2: Magnified intervals with linear interpolation of
                        color and alpha samples.
                     3: Magnified intervals with replication of color and
                        alpha samples from the closest pixel.
                     4: Magnified intervals with linear interpolation of
                        color samples and replication of alpha samples from
                        the closest pixel.
                     5: Magnified intervals with linear interpolation of
                        alpha samples and replication of color samples from
                        the closest pixel.
   MX:             2 bytes. X magnification factor, range 1-65535.  If
                     omitted, MX=1.  Ignored if X_method is 0 and assumed to
                     be 1.
   MY:             2 bytes. Y magnification factor.  If omitted, MY=MX.
   ML:             2 bytes. Left X magnification factor.  If omitted, ML=MX.
   MR:             2 bytes. Right X magnification factor.  If omitted, MR=MX.
   MT:             2 bytes. Top Y magnification factor.  If omitted, MT=MY.
                     Ignored if Y_method is 0 and assumed to be 1.
   MB:             2 bytes. Bottom Y magnification factor.  If omitted,
                     MB=MY.
   Y_method:       1 byte.  If omitted, Y_method is the same as X_method.
</pre>

<p>The <span class=cn>MAGN</span> chunk causes the contents of the object buffers pointed to
by the specified range of objects to be immediately and irreversibly magnified.

<p>The <code class=expr>first_magnified_object_id</code> can be zero.  If so, any subsequent
embedded
objects whose <code class=expr>object_id</code> is 0 must be magnified immediately when they
appear in the datastream. Magnification factors and methods for object 0 are
updated by the appearance of a subsequent <span class=cn>MAGN</span> chunk whose
<code class=expr>first_magnified_object_id</code> is 0.  Magnification of object 0 is turned
off by the appearance of an empty <span class=cn>MAGN</span> chunk or by a <span class=cn>MAGN</span>
chunk whose <code class=expr>first_magnified_object_id</code> is zero and
whose <code class=expr>X_method</code>
and <code class=expr>Y_method</code> are zero, explicitly or by omission.
The magnification factor for object 0 becomes undefined when a <span class=cn>SEEK</span>
chunk appears.  Therefore, it is the encoder's responsibility either
to include a <span class=cn>MAGN</span> chunk that turns off magnification of object 0
prior to the end of any segment in which object 0 was magnified, or to
include a <span class=cn>MAGN</span> chunk for object 0 prior to the first embedded object 0
in every segment that contains an embedded object 0.

<p>The <code class=expr>last_magnified_object_id</code> must be greater than or equal to the
<code class=expr>first_magnified_object_id</code>. It
is not an error to include a nonexistent object or an existing
"frozen"
object in the range; decoders must do nothing to any such objects. If an
object is potentially visible and viewable, it is displayed immediately
after it is magnified. If any <code class=expr>object_id</code> is nonzero, the result
of magnifying that object is stored in place of its original object buffer
for later use.

<p>If the <span class=cn>MAGN</span> chunk is present, all existing objects in the
specified range
must conceptually be magnified immediately in accordance with the given
magnification factors and methods.  Decoders may wish to save the magnification
factors and delay the magnification until display time, or until the object
is used as the parent object of a Delta-PNG, to save memory.  There is
nothing preventing this, provided that the end effect is the same as if the
magnification had been accomplished immediately.  If object
0 is in the specified range, then any subsequent embedded objects with
<span class=expr>object_id=0</span> must be magnified immediately when they appear in
the datastream.

<p>When <code class=expr>X_method</code> is 0, all X magnification factors in
the <span class=cn>MAGN</span> chunk
are ignored and can be assumed to be 1.

<p>When <code class=expr>X_method</code> is 1, X magnification is done by simple pixel
replication.
The leftmost pixel of each row is replicated <span class=expr>ML-1</span> times.
If the original
width is greater than 1, the rightmost pixel is replicated <span class=expr>MR-1</span> times.
If the original width is greater than 2, the original interior pixels are
replicated <span class=expr>MX-1</span> times.  The magnified width W is
<pre>
   W = ML;
   if (width &gt; 1) W = W + MR;
   if (width &gt; 2) W = W + (width-2)*MX;
</pre>
<p>When <code class=expr>X_method</code> is 2, X magnification is done by linear interpolation between
pixels.  If the original width of the image is greater than 1, the interval
between the leftmost pixel and the second pixel of each row is subdivided
into <code class=expr>ML</code> equal intervals by inserting <span class=expr>ML-1</span> pixels with
color and alpha values
that are obtained by linear interpolation.  If the original width is 1, then
the pixel is simply magnified as if X method is 1.  If the original width is
greater than 2, the rightmost interval is subdivided into MR equal intervals.
If the original width is greater than 3, each original interior interval is
subdivided into <code class=expr>MX</code> equal intervals.  The magnified width W is
<pre>
   /* The orginal pixels:                        */
      W = width;
   /* Add the new pixels in the left interval:   */
      if (width &gt; 1) W = W + ML-1;
   /* Add the new pixels in the right interval:  */
      if (width &gt; 2) W = W + MR-1;
   /* Add the new interior pixels:               */
      if (width &gt; 3) W = W + (width-3)*(MX-1);
</pre>
<p>When <code class=expr>X_method</code> is 3, intervals are subdivided as in X method 2,
and the
color and alpha values for the new pixels are obtained by replicating
the closest original pixel, with ties being broken by replicating the
pixel to the left.  The magnified width is calculated in the same manner
as in X method 2.

<p>When <code class=expr>X_method</code> is 4, the color samples are magnified as in
X method 2 and
the alpha samples are magnified as in X method 3.

<p>When <code class=expr>X_method</code> is 5, the color samples are magnified as in
X method 3 and
the alpha samples are magnified as in X method 2.

<p>When <code class=expr>Y_method</code> is 0, all Y magnification factors in
the <span class=cn>MAGN</span> chunk are ignored and can be assumed to be 1.

<p>When <code class=expr>Y_method</code> is 1, Y magnification is done by simple pixel
replication.
The topmost pixel of each column is replicated <span class=expr>MT-1</span> times.  If the
original
height is greater than 1, the bottom pixel is replicated <span class=expr>MB-1</span> times.
If the original height is greater than 2, the original interior pixels of each
column are replicated <span class=expr>MY-1</span> times.  The magnified height H is
<pre>
   H = MT;
   if (height &gt; 1) H = H + MB;
   if (height &gt; 2) H = H + (height-2)*MY;
</pre>
<p>When <code class=expr>Y_method</code> is 2, Y magnification is done by linear interpolation between
pixels.  If the original height of the image is greater than 1, the interval
between the topmost pixel and the second pixel of each column is subdivided
into MT equal intervals by inserting <span class=expr>MT-1</span> pixels with color and alpha
values
that are obtained by linear interpolation.  If the original height is 1, then
the pixel is simply magnified as if Y method is 1.  If the
original height is
greater than 2, the bottom interval is subdivided into MB equal intervals.
If the original height is greater than 3, each original interior interval is
subdivided into MY equal intervals.  The magnified height H is
<pre>
   H = height;
   if (height &gt; 1) H = H + MT-1;
   if (height &gt; 2) H = H + MB-1;
   if (height &gt; 3) H = H + (height-3)*(MY-1);
</pre>

<p>When <code class=expr>Y_method</code> is 3, intervals are subdivided as in Y method 2,
and the
color and alpha values for the new pixels are obtained by replicating
the closest original pixel, with ties being broken by replicating the
pixel above.  The magnified width is calculated in the same manner
as in Y method 2.

<p>When <code class=expr>Y_method</code> is 4, the color samples are magnified as in
Y method 2 and
the alpha samples are magnified as in Y method 3.

<p>When <code class=expr>Y_method</code> is 5, the color samples are magnified as in
Y method 3 and
the alpha samples are magnified as in Y method 2.

<p>When the image being magnified is a concrete object, it must not be a
JNG or indexed-color PNG (the latter could be promoted to RGB or RGBA via
a Delta-PNG <span class=cn>PROM</span> chunk first).  The result of the magnification is
also a concrete object.  The Method 2 magnification is conceptually done first
in the vertical (Y) direction, the results rounded to the sample depth,
then in the horizontal (X) direction.  Linear interpolation must be done
on the raw pixels, prior to any color correction,
using integer arithmetic, to ensure that the result is deterministic.
For each channel, the m-1 interpolated samples s[i] are obtained from the
two samples s0 and s1 by the following ISO C code or by any other method
that obtains the identical results:
<pre>
   if(s1 == s0)
      for (i=1; i &lt; m; i++)
         s[i] = s0;
   else
      for (i=1; i &lt; m; i++)
         s[i] = ((2*i*(s1-s0)+m)/(m*2) + s0;
</pre>
<p>Signed arithmetic in a precision large enough to hold the intermediate
results must be used, and the final results must be modulo the sample depth.

<p>When the image being magnified is an abstract object, which is always
true of object 0, interpolation can be done by any means that achieves a
visually similar but not necessarily identical result, such as rounding the
results to the sample depth later, using video hardware that is capable of
interpolation, or using floating point addition in the loop instead
of integer multiplication and division as in:
<pre>
   float delta = ((float)(s1-s0)/(float)m);
   float sf= (float)s0;
   for (i=1; i &lt; m; i++) {
      sf = sf+delta;
      s[i]=(int)(sf+0.5);
      }
</pre>

<p>If the abstract object being magnified is being stored in an indexed
representation, interpolation must be accomplished by a method that achieves
a similar result to that obtained by interpolating between RGB or RGBA
pixels.

<p>Note that if an object and partial clones of it appear in the range
of objects to be magnified, the object buffer will be magnified repeatedly.

<p>Because the <span class=cn>MAGN</span> chunk was added late in the development of
MNG-1.0, it is recommended that encoders place an empty <span class=cn>MAGN</span> chunk or
a <span class=cn>nEED MAGN</span>
chunk early in the datastream, so that pre-MNG-1.0 applications that do not
recognize the <span class=cn>MAGN</span> chunk will encounter one quickly.

<h4><a name="mng-DISC">4.2.10. <span class=cn>DISC </span>Discard objects</a></h4>

<p>The <span class=cn>DISC</span> chunk can be used to inform the decoder that it
can discard the object data associated with the associated object
identifiers.  Whether the decoder actually discards the data or not, it
must not use it after encountering the <span class=cn>DISC</span> chunk.

<p>The chunk contains a sequence of zero or more two-byte object
identifiers.  The number of objects to be discarded is the chunk's data
length, divided by two.

<pre>
   Discard_id: 2 bytes (nonzero unsigned integer).
   ...etc...
</pre>

<p>If the <span class=cn>DISC</span> chunk is empty, all nonzero objects except those
preceding the <span class=cn>SAVE</span> chunk (i.e., except for
the "frozen" objects)
can be discarded.  If a <span class=cn>SAVE</span> chunk has not been encountered, all
objects can be discarded.  Note that each appearance of a <span class=cn>SEEK</span>
chunk in the datastream implies an empty <span class=cn>DISC</span> chunk.

<p>If the <span class=cn>DISC</span> chunk is not empty, the listed objects can be
discarded.

<p>When an object is discarded, any location, potential visibility, and
clipping boundary data associated with it is also discarded.

<p>It is not an error to include an <code class=expr>object_id</code> in the
<code class=expr>discard_id</code> list, when no such object has been stored, or when
the object has already been discarded.

<p>It is an error to name explicitly any "frozen" object in the
<span class=cn>DISC</span> list.

<p>When the object is a partial clone or is the source of a partial
clone that has not been discarded, only the set of object attributes
(location, potential visibility, clipping boundaries, etc.) can be
discarded.  The data in the object buffer must be retained until the
last remaining partial clone is discarded.


<h4><a name="mng-TERM">4.2.11. <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.
                                 If processing the fPRI chunk, use a "cost"
                                 of 255.
                              3: Repeat the sequence starting immediately
                                 after the TERM chunk and ending with the
                                 MEND chunk.
   
   Action_after_iterations: 1 byte
                              0: Show the last frame indefinitely after
                                 iteration_max iterations have been done.
                              1: Cease displaying anything.
                              2: Show the first frame after the TERM chunk.
                                 If processing the fPRI chunk, use a "cost"
                                 of 255.
   
                             This and the subsequent fields must be present
                             if termination_action is 3, and must be omitted
                             otherwise.
   
   Delay:                  4 bytes (unsigned integer).  Delay, in ticks,
                           before repeating the sequence.
   
   Iteration_max:          4 bytes (unsigned integer).  Maximum number of
                           times to execute the sequence.  Infinity is
                           represented by 0x7fffffff.
</pre>

<p>The loop created by processing a <span class=cn>TERM</span> chunk must always be treated
by the decoder as if it were a cacheable &lt;user-discretion&gt; loop, with
<code class=expr>iteration_min=1</code>.

<p>Applications must not depend on anything that has been drawn on the output
buffer or device during the previous iteration.  Its contents become
undefined when the <span class=cn>TERM</span> loop restarts.

<p>MNG editors that extract a series of PNG or JNG files from a MNG datastream
are expected to execute the <span class=cn>TERM</span> loop only once, rather than emitting
the files repeatedly.

<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.
The <span class=cn>TERM</span> chunk is not considered to be a part of any
segment for the purpose of determining the copy-safe status of any
chunk.
Only one <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, image, or both
against which
transparent, clipped,
or less-than-full-frame images can be displayed.  This information will be
used whenever the application subsequently needs to insert a background
layer, unless another <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 and background image are
                           advisory.  Applications can use them if they
                           choose to.
                        1: Background color is mandatory.  Applications
                           must use it.  Background image is advisory.
                        2: Background image is mandatory.  Applications
                           must use it.  Background color is advisory.
                        3: Background color and background image are both
                           mandatory.  Applications must use them.
                        This byte can be omitted if the subsequent fields
                        are also omitted.  If so, the background color is
                        advisory.
   
   Background_image_id:
                     2 bytes (unsigned nonzero integer).  Object_id of an
                     image that is to be used as the background layer or
                     part of it.  If the image does not cover the area
                     defined by the layer clipping boundaries with opaque
                     pixels, the remainder of this area is filled with the
                     background color or application background and the
                     background image is composited against it.  This
                     field can be omitted if the background_tiling byte is
                     also omitted; if so, no background image is defined,
                     and the background image_id from any previous BACK
                     chunk becomes undefined.  This byte must be omitted
                     in MNG-LC and MNG-VLC datastreams, and when the
                     "stored object buffers" flag in the simplicity
                     profile is valid and is zero.
   
   Background_tiling:
                     1 byte (unsigned integer).
                        0: Do not tile the background.
                        1: Tile the background with the background image.
                     This field can be omitted; if so, do not tile the
                     background.  This byte must be omitted in MNG-LC and
                     MNG-VLC datastreams.
</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.

The background image (or tiled assembly) is also
clipped to its own boundaries and located like any other image,
and is only displayed if it is potentially visible.  When
the background image is used for tiling, the upper left tile is located
according to the background image's location attributes and the entire
assembly is clipped according to its clipping attributes.  Viewers might
actually follow some other procedure, but the final appearance of each
frame must be the same as if they had filled the area within the subframe
boundaries with the background color, then displayed the background
image, and then displayed the foreground image (or images), without
delay.

<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 is modified
by a Delta-PNG datastream or its location or clipping boundaries are
changed by a <span class=cn>MOVE</span> or  <span class=cn>CLIP</span> chunk,
or in case a new <span class=cn>BACK</span> chunk appears,
before that moment.

<p>It is an error to specify a <code class=expr>background_image_id</code> when the
"stored object buffers" flag in the simplicity profile is
valid and zero.

<p>It is not an error to specify a <code class=expr>background_image_id</code>
when such an image is not viewable and potentially visible or
does not yet exist or ceases to exist for some reason,
or to fail to specify one even when
the <code class=expr>mandatory_background</code> flag is 2 or 3.
Viewers must be prepared to fall back temporarily to using the background
color or application background in this event, and to resume using the
background image whenever a potentially visible viewable object with the
<code class=expr>background_image_id</code> becomes available.
They also must be prepared for the contents, viewability, location, potential
visibility, and clipping boundaries of the background image to change, just
like any other object, if it has not been "frozen".  The
background image is allowed to have transparency, subject to any promises
made in the simplicity profile.

<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 color space of the background image, if one is used, is determined
in the same manner as the color space of any other image.

<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, an embedded image, or a <span class=cn>SHOW</span> chunk.
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>Decoding a <span class=cn>DHDR-IEND</span> sequence, when it defines a
potentially visible image.

<p>

<li>Decoding a <span class=cn>BASI-IEND</span> sequence, when it defines a
potentially visible image.

<p>

<li>Decoding a <span class=cn>CLON</span> chunk, when it defines a
potentially visible image.

<p>

<li>Decoding a <span class=cn>PAST</span> chunk, when its destination is a
potentially visible image.

<p>

<li>Decoding a <span class=cn>SHOW</span>  chunk, when it directs that a potentially
visible image be displayed.  When the <span class=cn>SHOW</span> chunk directs that
several images be displayed, each one in turn generates a separate layer
(or two layers, if the framing mode requires that a background layer be
inserted before each).

<p>

<li>Decoding a <span class=cn>MAGN</span>  chunk, when it directs that an existing
potentially visible image be magnified.  When the <span class=cn>MAGN</span> chunk
directs that several images be magnified and displayed, each one in turn
generates a separate layer.

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

<p>Also, viewers that jump to a segment must insert a
background layer, with a zero delay, ahead of the segment,
even when the <span class=cn>BACK</span> chunk is not present in the prologue segment,
if they jumped from the interior of a segment.
Such layers are <em>not</em> included in either the layer count
or 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.
No specific use for the subframe name is specified in
this document, except that it can be included in the optional index
that can appear in the <span class=cn>SAVE</span> chunk.
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 (see Uniform Resource Identifier <a href="#URL">below</a>).

<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>
or <span class=cn>MOVE</span>
chunk
can be used to specify the placement of each
image within the layer.  The <span class=cn>DEFI</span>
or <span class=cn>CLIP</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.

<h4><a name="mng-MOVE">4.3.3. <span class=cn>MOVE </span>New image location</a></h4>

<p>The <span class=cn>MOVE</span> chunk gives a new location of an existing object or
objects (replacing or incrementing the location given in the <span class=cn>DEFI</span>
chunk).

<p>The position is measured downward and
to the right of the frame origin, in pixels, where the named object or
group of objects is to be located.

<p>The chunk's contents are:

<pre>
   First_object:       2 bytes (unsigned integer).
   
   Last_object:        2 bytes (unsigned integer).
   
   Location_delta_type:1 byte (unsigned integer).
                         0: MOVE data gives X_location and Y_location
                            directly.
                         1: New locations are determined by adding the MOVE
                            data to the location of the parent object.
   
   X_location or delta_X_location:
                       4 bytes (signed integer).
   
   Y_location or delta_Y_location:
                       4 bytes (signed integer).
</pre>

<p>The new location applies to a single object, if
<code class=expr>first_object=last_object</code>, or to a group of consecutive
<code class=expr>object_ids</code>, if they are different.  <code class=expr>Last_object</code>
must not be less than <code class=expr>first_object</code>.  Negative values are
permitted for the X and Y location.  The positive directions are
downward and rightward from the frame origin.  The <span class=cn>MOVE</span> chunk
can specify an image placement that is partially or wholly outside the
display boundaries.  In such cases, the resulting image must be clipped
to fit within its clipping boundaries, or not displayed at all if it
falls entirely outside its clipping boundaries.  The clipping boundaries
are determined as described in the specification for the <span class=cn>CLIP</span>
chunk <a href="#mng-CLIP">below (Paragraph 4.3.4)</a>.
The left and top boundaries are inclusive, while the right and bottom
boundaries are exclusive.

<p>It is not an error for the <span class=cn>MOVE</span> chunk to name an object that
has not previously been defined.  In such cases, nothing is done to the
nonexistent object.  It is permitted to move "frozen" objects
provided that the encoder includes chunks to move them back to their
original positions prior to then end of the segment.

<p>When an object is discarded, its set of object attributes, which includes
the <span class=cn>MOVE</span> data, is also discarded.

<h4><a name="mng-CLIP">4.3.4. <span class=cn>CLIP </span>Object clipping boundaries</a></h4>

<p>This chunk gives the new boundaries (replacing or incrementing those
from the <span class=cn>DEFI</span> chunk) to which an existing object or group of
objects must be clipped for display.  It contains the following 21
bytes:

<pre>
   First_object:                 2 bytes (unsigned integer).
   
   Last_object:                  2 bytes (unsigned integer).
   
   Clip_delta_type:              1 byte (unsigned integer).
                                   0: CLIP data gives boundary values
                                      directly.
                                   1: CLIP boundaries are determined by
                                      adding the CLIP data to their
                                      previous values for this object.
   
   Left_cb or delta_left_cb:     4 bytes (signed integer).
   
   Right_cb or delta_right_cb:   4 bytes (signed integer).
   
   Top_cb or delta_top_cb:       4 bytes (signed integer).
   
   Bottom_cb or delta_bottom_cb: 4 bytes (signed integer).
</pre>

<p>The new clipping boundaries apply to a single object, if
<code class=expr>first_object=last_object</code>, or to a group of consecutive
objects, if they are different.  the <code class=expr>last_object</code> must not be less
than <code class=expr>first_object</code>.

<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 CLIP chunk)
   Top_cb   &lt;= y &lt; bottom_cb
</pre>

<p>It is not an error for the <span class=cn>CLIP</span> chunk to name an object that
has not previously been defined.  In such cases, nothing is done to the
nonexistent object.  It is permitted to clip "frozen" objects
provided that another <span class=cn>CLIP</span> chunk resets them to their original
values prior to the end of the segment.

<p>When an object is discarded, its set of object attributes, which includes
the <span class=cn>CLIP</span> data, is also discarded.

<h4><a name="mng-SHOW">4.3.5. <span class=cn>SHOW </span>Show images</a></h4>

<p>The <span class=cn>SHOW</span> chunk is used to change the potential visibility
of one or more previously-defined objects and to direct that they be
displayed.  It contains 2, 4, or 5 bytes, or it can be empty.  When any
field is omitted, all subsequent fields must also be omitted.

<pre>
   First_image: 2 bytes (nonzero unsigned integer).
   
   Last_image:  2 bytes  (nonzero unsigned integer).  This field can be
                omitted if the show_mode byte is also omitted.  If so,
                decoders must assume the default values, show_mode=0 and
                last_image=first_image.
   
   Show_mode:   1 byte (unsigned integer).
                  0:  Make the images potentially visible and display them
                      (set do_not_show=0).
                  1:  Make the images invisible (set do_not_show=1).
                  2:  Do not change do_not_show flag; display those that are
                      potentially visible.
                  3:  Mark images "potentially visible" (do_not_show=0), but
                      do not display them.
                  4:  Toggle do_not_show flag; display any that are
                      potentially visible after toggling.
                  5:  Toggle do_not_show flag, but do not display even if
                      potentially visible after toggling.
                  6:  Step through the images in the given range, making the
                      next image potentially visible (set do_not_show=0) and
                      display it.  Set do_not_show=1 for all other images in
                      the range.  Jump to the beginning of the range when
                      reaching the end of the range.  Perform one step for
                      each SHOW chunk (in reverse order
                      if last_image &lt; first_image).
                  7.  Make the next image in the range (cycle) potentially
                      visible (do_not_show=0), but do not display it.  Set
                      do_not_show=1 for the rest of the images in the range.
   
                This field can be omitted.  If so, decoders must assume the
                default, show_mode=0.
</pre>

<p>The decoder processes the objects (or images) named in the
<span class=cn>SHOW</span> chunk in the order <code class=expr>first_image</code> through
<code class=expr>last_image</code>, and resets the <code class=expr>do_not_show</code> flag for
each of the objects.  If <code class=expr>show_mode</code> is even-valued, it also
displays the images if they are potentially visible and are viewable
images.

<p>When the <span class=cn>SHOW</span> chunk is empty, the decoder displays
all existing potentially visible images, without changing their
<code class=expr>do_not_show</code> status.  The empty <span class=cn>SHOW</span> chunk is
equivalent to

<pre>
   SHOW 1 65535 2
</pre>

<p>If <code class=expr>last_image &lt; first_image</code> the images are processed in
reverse order.

<p>When <code class=expr>show_mode</code> is odd-valued, nothing is displayed
unless a subsequent <span class=cn>SHOW</span> chunk with an even-valued
<code class=expr>show_mode</code> appears.

<dl>

<dt><strong>Interactions with the framing mode</strong>

<dd>When <code class=expr>show_mode</code> is even-valued, each visible image that
is displayed generates a separate layer, even
if it is offscreen and no pixels are actually displayed.  In such cases,
the layer is totally transparent.  When <code class=expr>show_mode</code> is odd, or
when no image is potentially visible and <code class=expr>show_mode</code> is 2, 4, or
empty, no layer is generated.

<p>When <code class=expr>show_mode</code> is 1, 4, 5, 6, or 7, images can
be made invisible.  This is not permitted when the framing mode is 2 or 4
in the <span class=cn>FRAM</span> chunk and the images have already appeared in the
frame, because simple viewers will have already drawn them and have no
way to make them invisible again without redrawing the entire frame.

<p>

</dl>

<p>When <code class=expr>show_mode</code> is 6 or 7, the decoder must make the
next image in the "cycle" potentially visible and, if
<code class=expr>show_mode</code> is 6, generate a single layer.  To do this,
it must examine
the <code class=expr>do_not_show</code> flag for each image in the range
<code class=expr>first_image</code> through <code class=expr>last_image</code>, and make the next
one (the one with the next higher value of <code class=expr>image_id</code> that
exists and is "viewable") after the first visible one it finds
visible
and the rest invisible.  When <code class=expr>first_image &gt; last_image</code>,
the cycle is reversed, and the "next" image is the one with the next
lower value of <code class=expr>image_id</code>.  In either case, if the first
visible one found was <code class=expr>last_id</code>, or none were visible, it must make
<code class=expr>first_image</code> visible.  These modes are useful for manipulating
a group of sequential images that represent different views of an
animated icon.  See Example 8, <a href="#Examples">below (Chapter 18)</a>.
If no "viewable" object is in the specified range, an empty layer
must be generated.

<p>When <code class=expr>show_mode</code> is 0, 2, 4, or 6, separate layers will be
generated, each containing an instance of one visible image at the
location specified by the <span class=cn>DEFI</span>, <span class=cn>CLON</span>, or <span class=cn>MOVE</span>
chunk and clipped according to the boundaries specified by the
<span class=cn>CLIP</span> and <span class=cn>FRAM</span> chunks.  When the <span class=cn>MOVE</span> or
<span class=cn>CLON</span> chunk is used in the delta form, which will frequently be
the case, each image must be displaced from its previous position by the
values given in the <span class=cn>MOVE</span> or <span class=cn>CLON</span> chunk.

<p>Assuming a nonzero interframe delay, any of the following sequences
would cause the image identified by <code class=expr>object_id=6</code> in a
composite frame to blink:

<pre>
   LOOP 0 0 10
   FRAM 4       # Show background
   SHOW 1 10    # Show images 1 thru 10.
   FRAM         # Show background
   SHOW 1 5     # Show images 1 thru 5.
   SHOW 7 10    # Show images 7 thru 10.
   ENDL
   
   FRAM 4       # Show background
   LOOP 0 0 10
   SHOW 1 5     # Show images 1 thru 5.
   SHOW 6 6 4   # Toggle potential visibility of image 6
   SHOW 7 10    # and show it; show images 7 thru 10.
   FRAM
   ENDL
   
   FRAM 4       # Show background
   LOOP 0 0 10
   SHOW 6 6 5   # Toggle potential visibility of image 6.
   SHOW 1 10 2  # Show potentially visible images in 1
   FRAM         # through 10.
   ENDL
</pre>

<p>It is not necessary to follow an <span class=cn>IHDR-IEND</span>,
<span class=cn>JHDR-IEND</span>, <span class=cn>BASI-IEND</span>, or <span class=cn>DHDR-IEND</span>
sequence or <span class=cn>PAST</span> chunk with a <span class=cn>SHOW</span> chunk to
display the resulting image, if it was already caused to appear by
<code class=expr>do_not_show=0</code> in the <span class=cn>DEFI</span> chunk that introduced the
image.  Similarly, the <span class=cn>CLON</span> chunk need not be followed by a
<span class=cn>SHOW</span> chunk, if <code class=expr>do_not_show=0</code> in the <span class=cn>CLON</span>
chunk.

<p>It is not an error for the <span class=cn>SHOW</span> chunk to name
a nonviewable object or an object that
has not previously been defined.  In such cases, nothing is done to the
nonexistent object.
It is permitted to change the potential visibility of "frozen"
objects provided that another <span class=cn>SHOW</span> chunk resets them to their original
values prior to the end of the segment.



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

<p>The <span class=cn>SAVE</span> chunk marks a point in the datastream at which
objects are "frozen" and other chunk information
is "saved".  The
<span class=cn>SEEK</span> chunk marks positions in the MNG datastream where a
restart is possible, and where the decoder must restore the "saved"
information, if they have jumped or skipped to a <span class=cn>SEEK</span> point from
the interior of a segment.
They only need to restore information that they will use, e.g., a viewer
that processes <span class=cn>gAMA</span> and global <span class=cn>PLTE</span> and <span class=cn>tRNS</span>,
but ignores
<span class=cn>iCCP</span> and <span class=cn>sPLT</span>, need only restore the value of gamma
and the global <span class=cn>PLTE</span> and <span class=cn>tRNS</span> data from the prologue
segment but not the values of the <span class=cn>iCCP</span> and <span class=cn>sPLT</span> data.

<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, although it
is recommended that, for efficient use of memory, they at least mark
existing objects as "frozen" when the <span class=cn>SAVE</span> chunk is
processed and discard all "unfrozen" objects whenever
the <span class=cn>SEEK</span> or empty <span class=cn>DISC</span> chunk is processed.

<h4><a name="mng-SAVE">4.4.1. <span class=cn>SAVE </span>Save information</a></h4>

<p>The <span class=cn>SAVE</span> chunk marks a point in the datastream at which
objects are "frozen" and other
chunk information is "saved"; a decoder skipping
or jumping to a <span class=cn>SEEK</span> chunk from the interior of a segment
must restore the "saved"
chunk information if it has been redefined or discarded.  In addition,
the <span class=cn>SAVE</span> chunk can contain an optional index to the MNG
datastream.

<p>The <span class=cn>SAVE</span> chunk can be empty, or it can contain an index
consisting of the following:

<pre>
   Offset_size: 1 byte (unsigned integer).
                  4: Offsets and nominal start times are expressed as
                     32-bit integers.
                  8: Offsets and nominal start times are expressed as
                     64-bit integers.
</pre>

<p>plus zero or more of the following index entries:

<pre>
   Entry_type:  1 byte (unsigned integer).
                  0: Segment with nominal start time, nominal layer number,
                     and nominal frame number.
                  1: Segment.
                  2: Subframe.
                  3: Exported image.
   Offset:     4 or 8 bytes (unsigned integer).  Must be omitted if
                 entry_type &gt; 1, set equal to zero if the offset is
                 unknown.
   Nominal_start_time:
               4 or 8 bytes: (unsigned integer).  Start time of the segment,
                 measured in ticks from the beginning of the sequence,
                 assuming that all prior segments were played as intended on
                 an ideal player, ignoring any fPRI chunks.  Must be omitted
                 if entry_type &gt; 0.
   Nominal_layer_number:
              4 bytes (unsigned integer).  Sequence number of the first
                 layer in the segment, assuming that all prior segments were
                 played as intended on an ideal player, ignoring any fPRI
                 chunks; the first layer of the first segment being layer 0.
                 Must be omitted if entry_type &gt; 0.
   Nominal_frame_number:
             4 bytes (unsigned integer).  Sequence number of the first
                 frame in the segment, assuming that all prior segments were
                 played as intended on an ideal player, ignoring any fPRI
                 chunks; the first frame of the first segment being frame 0.
                 Must be omitted if entry_type &gt; 0.
   Name:       1-79 bytes (Latin-1 text).  Must be omitted for unnamed
                 segments.  The contents of this field must be the same as
                 the name field in the corresponding SEEK, FRAM, or eXPI
                 chunk.
   Separator:  1 byte (null) (must be omitted after the final entry).
</pre>

<p>The <span class=cn>SAVE</span> chunk must be present when the <span class=cn>SEEK</span>
chunk is present.  It appears after the set of chunks that define
information that must be retained for the remainder of the datastream.
These chunks, collectively referred to as the prologue segment, are no
different from chunks in other segments.  They can be chunks
that define objects, or they can be chunks that define other
information such as
<span class=cn>gAMA</span>, <span class=cn>cHRM</span>, and <span class=cn>sPLT</span>.  If any chunks appear
between the <span class=cn>SAVE</span> chunk and the first <span class=cn>SEEK</span> chunk, these
chunks also form a part of the prologue segment, but their contents become
undefined when the <span class=cn>SEEK</span> chunk appears.

<p>Only one instance of the <span class=cn>SAVE</span> chunk is permitted in a MNG
datastream.  It is not allowed anywhere after the first <span class=cn>SEEK</span>
chunk.

<p>It is not permitted, at any point beyond the <span class=cn>SAVE</span> chunk, to
modify or discard any object that was defined ahead of the <span class=cn>SAVE</span>
chunk.

<p>An object appearing ahead of the <span class=cn>SAVE</span> chunk can be the
subject of a <span class=cn>CLON</span> chunk.  If the clone is a partial clone,
modifying it is not permitted, because this would also modify the object
buffer that the original object points to.

<p>A chunk like <span class=cn>gAMA</span> that overwrites a single current value is
permitted after the <span class=cn>SAVE</span> chunk, even if the chunk has appeared
ahead of the <span class=cn>SAVE</span> chunk.  Decoders are responsible for saving a
copy of the chunk data (in any convenient form) when the <span class=cn>SAVE</span>
chunk is encountered and restoring it when skipping or jumping to a
<span class=cn>SEEK</span> chunk from the interior of a segment.  If no instance of
the chunk appeared ahead of the
<span class=cn>SAVE</span> chunk, the decoder must restore the chunk data to its
original "unknown" condition when it skips or jumps to
a <span class=cn>SEEK</span> chunk from the interior of a segment.

<p>It is the <em>encoder's</em> responsibility, if it changes or
discards any "saved" data, to restore it to
its "saved" condition (or
to nullify it, if it was unknown) prior to the end of the segment.  This
makes it safe for simple decoders to ignore the <span class=cn>SAVE/SEEK</span>
mechanism.

<p>Known chunks in this category include <span class=cn>DEFI</span>, <span class=cn>FRAM</span>,
<span class=cn>BACK</span>, <span class=cn>PLTE</span>, <span class=cn>cHRM</span>, <span class=cn>tRNS</span>,
<span class=cn>fPRI</span>, <span class=cn>gAMA</span>, <span class=cn>iCCP</span>, <span class=cn>bKGD</span>,
<span class=cn>sBIT</span>, <span class=cn>pHYg</span>, <span class=cn>pHYs</span>, and <span class=cn>sRGB</span>.
In addition, it is the responsibility of the encoder to include chunks
that restore the
potential visibility, location, and clipping boundaries of any
"frozen" objects to their "saved" condition.

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

<p>If an entry for a segment (entry type 0 or 1) appears in the optional
index, there must also be an entry for every segment, whether named or
not, except for the prologue segment, that precedes it.
All entries must appear in the index in the same order that they appear in
the MNG datastream.
There must never be a segment entry (type 0 or 1) for the prologue segment, but
there can be entries for named images or subframes in the prologue, placed
ahead of the first segment entry.
Only named images or subframes are permitted, and it is not
an error to omit any or all named images or subframes.  Nor is it an error to
omit a contiguous set of segments at the end of the datastream from the index.

<p>Offsets are calculated from the first byte of the MNG 8-byte
signature, which has offset=0.  This is true even if the MNG datastream
happens to be embedded in some other file and the signature bytes are
not actually present.

<p>Applications with direct access to the datastream can use the index
to find segments, subframes, and exported images quickly.  After
processing the prologue segment, they can jump directly to any segment
and then process the remaining datastream until the desired subframe,
image, or time is found.  Applications that have only streaming access
to the datastream can still use the index to decide whether to decode
the chunks in a segment or to skip over them.

<p>Only one instance of the <span class=cn>SAVE</span> chunk is permitted in a MNG
datastream.  If the <span class=cn>SEEK</span> chunk is present, the <span class=cn>SAVE</span>
chunk must be present, prior to the first <span class=cn>SEEK</span> chunk.  The
only chunks not allowed ahead of the <span class=cn>SAVE</span> chunk are the
<span class=cn>SEEK</span> chunk and the <span class=cn>MEND</span> chunk.  The <span class=cn>SAVE</span>
chunk must not appear inside a <span class=cn>LOOP-ENDL</span> pair.

<h4><a name="mng-SEEK">4.4.2. <span class=cn>SEEK </span>Seek point</a></h4>

<p>The <span class=cn>SEEK</span> chunk marks positions ("seek points")
in the MNG
datastream where a restart is possible, and where the decoder must restore
certain information to the condition that existed when the <span class=cn>SAVE</span> chunk
was processed, if it has skipped or jumped to the <span class=cn>SEEK</span> chunk from
the interior of a segment.

<p>The <span class=cn>SEEK</span> chunk can be empty, or it can contain a segment name.

<pre>
   Segment_name: 1-79 bytes (Latin-1 string).
</pre>

<p>The segment name is optional.  It 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.  There is no null byte terminator within the
segment name, nor is there a separate null byte terminator.  Segment
names are case-sensitive.  Use caution when printing or displaying
keywords (Refer to Security
considerations, <a href="#Security">below, Chapter 17</a>).  
No specific use for the
segment name is specified in this
document, but applications can use the segment name for such purposes
as constructing a menu of seek points for a slide-show viewer.
It can be included in the optional index that can appear in the <span class=cn>SAVE</span>
chunk.
It is recommended that the same name not appear in any other
<span class=cn>SEEK</span> chunk or in any <span class=cn>FRAM</span> or <span class=cn>eXPI</span> chunk.
Segment names should not begin with the case-insensitive strings
"CLOCK(", "FRAME(", or
"FRAMES(", which are reserved for use in URI
queries and fragments
(see Uniform Resource Identifier <a href="#URL">below</a>).

<p>Applications must not use any information preceding the <span class=cn>SEEK</span>
chunk, except for:

<ul>

<li>Data appearing in the <span class=cn>MHDR</span> chunk.

<li>Anything appearing ahead of the <span class=cn>SAVE</span> chunk.

</ul>

<p>They also must not depend on anything that has been drawn on the output
buffer or device.  Its contents become undefined when the <span class=cn>SEEK</span>
chunk is encountered.  Decoders that make random access to a seek
point from the interior of a segment must insert a background layer before
processing the segment.  Encoders must ensure that simple viewers do not
need to do this.

<p>When the <span class=cn>SEEK</span> chunk is encountered, the decoder can discard
any objects appearing after the <span class=cn>SAVE</span> chunk, as though an empty
<span class=cn>DISC</span> chunk were present.

<p>In addition to providing a mechanism for skipping frames or
backspacing over frames, the <span class=cn>SEEK</span> chunk provides a means
of dealing with a corrupted datastream.  The viewer would abandon
processing and simply look for the next <span class=cn>SEEK</span> chunk before
resuming.  Note that looking for a PNG <span class=cn>IHDR</span> chunk would not
be sufficient because the PNG datastream might be inside a loop or a
Delta-PNG datastream, or it might need data from preceding <span class=cn>MOVE</span>
or <span class=cn>CLIP</span> chunks.

<p>When a decoder jumps to a seek point from the interior of a segment, it must
restore the information that it saved when it processed the <span class=cn>SAVE</span>
chunk, and it must reset the object attributes and magnification factors for
object 0 to their default values.
When it encounters a <span class=cn>SEEK</span> chunk during normal sequential
processing of a MNG datastream, it need not restore anything,
because the encoder will have written chunks that restore all saved information.

<p>Multiple instances of the <span class=cn>SEEK</span> chunk are permitted.  The
<span class=cn>SEEK</span> chunk must not appear prior to the <span class=cn>SAVE</span>
chunk.  The <span class=cn>SAVE</span> chunk must also be present if the <span class=cn>SEEK</span>
chunk is present.  The <span class=cn>SEEK</span> chunk must not appear between a
<span class=cn>LOOP</span> chunk and its <span class=cn>ENDL</span> chunk.


<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
a viewable object (either concrete or abstract),
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 and MNG-VLC 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
with object_id=0
following the <span class=cn>eXPI</span> chunk.
When the
snapshot_id is nonzero, the snapshot is an already-defined object with that
object_id as it already exists when the <span class=cn>eXPI</span> chunk is encountered.

<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 specification, except that it can be included in
the optional index that can appear in the <span class=cn>SAVE</span> chunk.
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>
or <span class=cn>SEEK</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
or Delta-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-fPRI">4.5.2. <span class=cn>fPRI </span>Frame priority</a></h4>

<p>The <span class=cn>fPRI</span> chunk allows authors to assign a priority to a
portion of the MNG datastream.  Decoders can decide whether or not to
decode and process that part of the datastream based on its "priority"
compared to some measure of "cost".

<p>The <span class=cn>fPRI</span> chunk contains two bytes:

<pre>
   fPRI_delta_type:  1 byte (unsigned integer).
                       0: Priority is given directly.
                       1: Priority is determined by adding the fPRI
                          data to the previous value, modulo 256.
   
   Priority or delta_priority:
                     1 byte (signed integer).  Value to be assigned to
                       subsequent chunks until another fPRI chunk is
                       reached.
</pre>

<p>While 256 distinct values of <code class=expr>priority</code> are possible, it
is recommended that only the values 0 (low priority), 128 (medium
priority), and 255 (high priority) be used.  Viewers that can only
display a single image can look for one with <code class=expr>priority=255</code> and
stop after displaying it.  If the datastream contains a large number
of frames and includes periodic "initial" frames that do not contain
Delta-PNG datastreams, each "initial" frame could be preceded by a
<span class=cn>fPRI</span> with <code class=expr>priority=128</code> and followed by one with
<code class=expr>priority=0</code>, and the best representative initial frame could
be preceded by a <span class=cn>fPRI</span> chunk with <code class=expr>priority=255</code>.  Then
single-image viewers would just display the representative frame, slow
viewers would display just the "initial" frames, and fast viewers
would display everything.

<p>If a viewer has established a nonzero "cost", it must skip any
portion of the datastream whose priority is less than that "cost".
The "cost" must be established prior to processing the proloque
segment.  If the decoder changes its "cost" it must process again
according to the new "cost", unless it knows that there were
no <span class=cn>fPRI</span> chunks in the prologue segment.

<p>The <span class=cn>SAVE</span>, <span class=cn>SEEK</span>, and <span class=cn>MEND</span> chunks always
have <code class=expr>priority=255</code>; decoders must look for these chunks in
addition to the <span class=cn>fPRI</span> chunk while skipping a low-priority
portion of the datastream.

<p>It is not permissible for a portion of the datastream to depend on
any portion of the datastream having a lower value, because a decoder
might have skipped the lower value portion.  Use of the <span class=cn>fPRI</span>
chunk is illustrated in <a href="#example5">Example 5</a> 
and <a href="#example9">Example 9</a>.

<p>Viewers that care about the priority must assume
<code class=expr>priority=255</code> for any portion of the MNG datastream that is
processed prior to the first <span class=cn>fPRI</span> chunk.

<p>Multiple instances of the <span class=cn>fPRI</span> chunk are permitted.

<h4><a name="mng-nEED">4.5.3. <span class=cn>nEED </span>Resources needed</a></h4>

<p>The <span class=cn>nEED</span> chunk can be used to specify needed resources, to
provide a quick exit path for viewers that are not capable of displaying
the MNG datastream.

<p>The <span class=cn>nEED</span> chunk contains a list of keywords that the decoder
must recognize.  Keywords are typically private critical chunk names.

<pre>
   Keyword:   1-79 bytes.
   Separator: 1 byte (null).
   ...etc...
</pre>

<p>The <span class=cn>nEED</span> chunk should be placed early in the MNG datastream,
preferably very shortly after the <span class=cn>MHDR</span> chunk.

<p>The keywords are typically 4-character private critical chunk
names, but they could be any string that a decoder is required to
recognize.  No critical chunks defined in this specification or in the
PNG specification should be named in a <span class=cn>nEED</span> chunk, because
MNG-compliant decoders are required to recognize all of them, whether
they appear in a <span class=cn>nEED</span> chunk or not.  The purpose of the
<span class=cn>nEED</span> chunk is only to identify requirements that are above and
beyond the requirements of this document and of the PNG specification.

<p>Each keyword 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 keyword.  A null separator byte must appear after
each keyword in the <span class=cn>nEED</span> chunk except for the last one.

<p>Decoders that do not recognize a chunk name or keyword in the
list should abandon the MNG datastream or request user intervention.
The normal security precautions should be taken when displaying the
keywords.

<h4><a name="mng-phys">4.5.4. <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>

<li><span class=cn>sPLT</span>

<p>This PNG chunk is also defined at the MNG top
level.  It
provides a value that takes precedence over those that might be provided
in subsequent PNG or JNG datastreams and provides a value to be used
when it is not provided in subsequent PNG or JNG datastreams.
It also takes precedence over the
<span class=cn>PLTE</span> chunk in a subsequent PNG datastream when the
<span class=cn>PLTE</span> and <span class=cn>hIST</span> chunks are being used as a suggested
palette (i.e., <code class=expr>color_type != 3</code>).  This chunk can appear for
any color type.  There can be multiple <span class=cn>sPLT</span> chunks in a MNG
datastream.  If a <code class=expr>palette_name</code> is repeated, the previous
palette having the same <code class=expr>palette_name</code> is replaced.  It is
not permitted, at the MNG top level, to redefine a palette after the
<span class=cn>SAVE</span> chunk with the same <code class=expr>palette_name</code> as one that
appears ahead of the <span class=cn>SAVE</span> chunk.  It is permitted, however, to
define and redefine other palettes with other <code class=expr>palette_name</code>
fields.  A single empty <span class=cn>sPLT</span> chunk can be used to nullify all
<span class=cn>sPLT</span> chunks that have been previously defined in the MNG top
level, except for those that appeared ahead of the <span class=cn>SAVE</span> chunk,
when the <span class=cn>SAVE</span> chunk has been read.

<p>When a decoder needs to choose between a suggested palette
defined at the MNG level and a suggested palette defined in the PNG datastream
(either with the <span class=cn>sPLT</span> chunk, or with the <span class=cn>PLTE/hIST</span>
chunks for grayscale or truecolor images), it should give precedence to
the palette from the MNG level, to avoid spurious layer-to-layer color
changes.

<p>MNG editors that write PNG datastreams should ignore the
<span class=cn>sPLT</span> data from the MNG level and simply copy
any <span class=cn>sPLT</span> chunks appearing within the embedded PNG
datastreams.


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

<p>MNG-LC and MNG-VLC
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.

<p>Note: This specification depends on the PNG Portable Network Graphics
specification <span class=ref>[<a href="#PNG">PNG</a>]</span>.
The PNG specification is available at the PNG home page,

<pre>
   <a href="http://www.libpng.org/pub/png/">http://www.libpng.org/pub/png/</a>
</pre>

<p>A JNG datastream consists of a header chunk (<span class=cn>JHDR</span>),
<span class=cn>JDAT</span> chunks that contain a complete JPEG datastream,
optional <span class=cn>IDAT</span> chunks that contain a PNG-encoded grayscale
image that is to be used as an alpha mask, and an <span class=cn>IEND</span> chunk.
The alpha mask, if present, must have the same dimensions as the image
itself.  The <span class=cn>JDAT</span> and <span class=cn>IDAT</span> chunks can be interleaved.
Some of the PNG ancillary chunks are also recognized in JNG datastreams.

<p>While JNG is primarily intended for use as a sub-format within MNG, a
single-image JNG datastream can be written in a standalone file.  If so,
the JNG datastream begins with an 8-byte signature containing

<pre>
    139  74  78  71  13  10  26  10  (decimal)
     8b  4a  4e  47  0d  0a  1a  0a  (hexadecimal)
   \213   J   N   G  \r  \n \032 \n  (ASCII C notation)
</pre>

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

<p>We may at some future time register an Internet Media
Type for JNG files.  Until then, the interim media type
<code class=expr>image/x-jng</code> can be used.  It is recommended that the
file extension ".jng" (lower case preferred) be used.

<p>JNG is pronounced "Jing."

<h3><a name="JNG-crit">5.1. Critical JNG chunks</a></h3>

<p>This section specifies the critical chunks that are defined in the
JNG format.

<h4><a name="JNG-JHDR">5.1.1. <span class=cn>JHDR </span>JNG header</a></h4>

<p>The format of the <span class=cn>JHDR</span> chunk introduces a JNG datastream.
It contains:

<pre>
   Width:      4 bytes (unsigned integer, range 0..65535).
   Height:     4 bytes (unsigned integer, range 0..65535).
   Color_type: 1 byte
                 8: Gray (Y).
                10: Color (YCbCr).
                12: Gray-alpha (Y-alpha).
                14: Color-alpha (YCbCr-alpha).
   
   Image_sample_depth:
               1 byte
                 8: 8-bit samples and quantization tables.
                12: 12-bit samples and quantization tables.
                20: 8-bit image followed by a 12-bit image.
   
   Image_compression_method:
               1 byte
                 8: ISO-10918-1 Huffman-coded baseline JPEG.
   
   Image_interlace_method:
               1 byte.
                 0: Sequential JPEG, single scan.
                 8: Progressive JPEG.
   
   Alpha_sample_depth:
               1 byte.
                 0, 1, 2, 4, 8, or 16, if the Alpha compression method is 0
                   (PNG)
                 8, if the Alpha compression method is 8 (JNG).
   
   Alpha_compression_method:
               1 byte.
                 0: PNG grayscale IDAT format.
                 8: JNG 8-bit grayscale JDAA format.
   
   Alpha_filter_method:
               1 byte.
                 0: Adaptive PNG (see PNG spec) or not applicable (JPEG).
   
   Alpha_interlace_method:
               1 byte.
                 0: Noninterlaced PNG or sequential single-scan JPEG.
</pre>

<p>The width, height, image_sample_depth, image_compression_method,
and image_interlace_method fields are redundant because equivalent
information is also embedded in the <span class=cn>JDAT</span> datastream.  They
appear in the <span class=cn>JHDR</span> chunk for convenience.  Their values must be
identical to their equivalents embedded in the <span class=cn>JDAT</span> chunk.  We
use four bytes in the width and height fields for similarity to MNG and
PNG, and to leave room for future expansion, even though two bytes would
have been sufficient.

<p>When the <code class=expr>color_type</code> is 8 or 10 (no alpha channel), the
last four bytes, which describe the <span class=cn>IDAT</span> or <span class=cn>JDAA</span> data,
must be set to zero.  The <code class=expr>alpha_sample_depth</code> must be nonzero
when the alpha channel is present.

<h4><a name="JNG-JDAT">5.1.2. <span class=cn>JDAT </span>JNG image data</a></h4>

<p>A JNG datastream must contain one or more <span class=cn>JDAT</span> chunks, whose
data, when concatenated, forms a complete JNG JPEG datastream.
JNG decoders are required to read all baseline JNG JPEG and
eight-bit progressive JNG JPEG datastreams.  Twelve-bit capability is
not required.

<p><span class=cn>JDAT</span> chunks are like PNG <span class=cn>IDAT</span> chunks in that
there may be multiple <span class=cn>JDAT</span> chunks, the data from which
are concatenated to form a single datastream that can be sent to
the decompressor.  No chunks are permitted among the sequence of
<span class=cn>JDAT</span> chunks, except for interleaved <span class=cn>IDAT</span> chunks.
The ordering requirements of other ancillary chunks are the same
with respect to <span class=cn>JDAT</span> as they are in PNG with respect to the
<span class=cn>IDAT</span> chunk.

<p>A JNG JPEG is a baseline, extended-sequential, or progressive JPEG as
defined by JPEG Part 1
<span class=ref>[<a href="#I-10918-1">ISO/IEC-10918-1</a>]</span>.
JNG uses only JFIF-compatible
<span class=ref>[<a href="#JFIF">JFIF</a>]</span>
component interpretations, and imposes a few additional restrictions
that reflect limitations of many existing JPEG implementations.  In
particular, only Huffman entropy coding is permitted.

<p>Actually, a JNG may contain two separate JNG JPEG datastreams
(one eight-bit and one twelve-bit), each contained in a series
of <span class=cn>JDAT</span>
chunks, and separated by a <span class=cn>JSEP</span> chunk
(see the <span class=cn>JSEP</span> chunk specification <a href="#JNG-JSEP">below, Paragraph 5.1.5</a>).
Decoders that are unable to (or do not wish to) handle twelve-bit datastreams
are allowed to display the eight-bit datastream instead, if one is present.

<p>The core of the JNG JPEG definition is baseline JNG JPEG, which
is JPEG Part 1's definition of baseline JPEG further restricted by
JFIF restrictions and JNG-specific restrictions.  JNG JPEG also includes
progressive JPEG, which is also defined in JPEG Part 1 and has JNG-specific
restrictions.

<ul>

<li>Baseline JNG JPEG restrictions

<p>A baseline JPEG according to JPEG Part 1 is DCT-based
(lossy) sequential
JPEG, using 8-bit sample precision and Huffman entropy coding, with the
following further restrictions:

<ul>

<li>Quantization table precision must be 8 bits for baseline JPEG.

<li>Huffman code tables can have table numbers 0 and 1 only.

</ul>

<p>
The SOF marker type for baseline JPEG is SOF0.

<p>
JDAT datastreams must always follow "interchange JPEG" rules: all
necessary quantization and Huffman tables must be included in the
datastream; no tables can be omitted.<br>
&nbsp;

<li>JFIF-compatible restrictions

<p>The image data is always stored left-to-right, top-to-bottom.

<p>The encoded data shall have one of the two color space
interpretations allowed by the JFIF specification:

<ul>

<li>Grayscale: a single component representing luminance, ranging from 0
for black to 255 for white (or 0 to 4095 when dealing with twelve-bit data).
This component shall have JPEG component identifier 1.

<p>

<li>YCbCr: three components representing luminance, chroma blue, and
chroma red, in that order.  The components shall be assigned JPEG
component identifiers 1, 2, 3 respectively.  YCbCr is defined as a
linear transformation from RGB color space:

<pre>
   Y = Luma_red*R + Luma_green*G + Luma_blue*B
   Cb = (B - Y) / (2 - 2*Luma_blue) + Half_scale
   Cr = (R - Y) / (2 - 2*Luma_red)  + Half_scale
</pre>

<p>By convention, the luminance coefficients are always those
defined by CCIR Recommendation 601-1:

<pre>
   Luma_red   = 0.299
   Luma_green = 0.587
   Luma_blue  = 0.114
</pre>

<p>The constant Half_scale is 128 when dealing with eight-bit
data, 2048
for twelve-bit data.  With these equations, Y, Cb, and Cr all have the same
range as R, G, and B: 0 to 255 for eight-bit data, 0 to 4095 for twelve-bit
data.

<p>The JFIF convention for YCbCr differs from typical digital
television practice in that no headroom/footroom is reserved: the coefficient
values range over the full available 8 or 12 bits.

<p>Intercomponent sample alignment shall be such that the
first (upper
leftmost) samples of each component share a common upper left corner
position.  This again differs from common digital TV practice, in which
the first samples share a common center position.  The JFIF convention
is simpler to visualize: subsampled chroma samples always cover an
integral number of luminance sample positions, whereas with co-centered
alignment, chroma samples only partially overlap some luminance samples.

<p>

</ul>

<p>

<li>Additional JNG restrictions

<p>JNG imposes three additional restrictions not found in the
text of either JPEG Part 1 or the JFIF specification:

<ul>

<li>The sampling factors for YCbCr images must be one of these sets:

<ul>

<li>1h1v,1h1v,1h1v (also called 4:4:4 or 1x1 sampling)

<li>2h1v,1h1v,1h1v (also called 4:2:2 or 2x1 sampling)

<li>2h2v,1h1v,1h1v (also called 4:2:0 or 2x2 sampling)

<li>1h2v,1h1v,1h1v (also called 1x2 sampling)

</ul>

<p>In other words, the chroma components may be downsampled 2:1
or 1:2 horizontally or vertically relative to luminance, or they may be left
full size.  These four sampling ratios are the only ones supported by a
wide spectrum of implementations (1x2 is relatively uncommon, and is usually
the result of a lossless rotation of a 2x1 sampling).

<p>For grayscale images, the sampling factors are irrelevant
according to a strict reading of JPEG Part 1.  Hence decoder authors should
accept any sampling factors for grayscale.  However, we recommend that encoders
always emit sampling factors 1h1v for grayscale, since some decoders
have been observed to malfunction when presented with other sampling
factors.

<li>There must be only one scan in an image: that is, YCbCr images
must be fully interleaved.  There is little advantage to be gained by
encoding a baseline image in multiple scans, and many baseline decoders
do not support multiple scans at all.

<p>

<li>The DNL (Define Number of Lines) marker is prohibited.  The image
height must always be specified accurately in the SOFn marker and in the
<span class=cn>JHDR</span> chunk.

<p>

</ul>

<p>

<li>Recommended progressive JPEG subset

<p>For JNG progressive JPEG datastreams, the JPEG process is
progressive Huffman coding (SOF marker type SOF2) rather than baseline (SOF0).
All JNG-compliant decoders must support full progression, including both
spectral-selection and successive-approximation modes, with any sequence
of scan progression parameters allowed by the JPEG Part 1 standard.

<p>Otherwise, all the restrictions listed above apply, except
these:


<ul>

<li>Multiple-scan support is obviously required for progressive JPEG.

<p>

<li>Huffman table numbers up to 3 (the full JPEG limit) may be used,
since the baseline two-table limit is unlikely to be needed by any
decoder that can handle progressive JPEG.

<p>

</ul>

<p>We require full progression support since relatively little
code savings can be achieved by subsetting the JPEG progression features.
In particular, successive approximation offers significant gains in
the visual quality of early scans.  Omitting successive-approximation
support from a decoder does not save nearly enough code to justify
restricting JNG progressive encoders to spectral selection only.

<p>No particular progressive scan sequence is specified or
recommended by this specification.  Not enough experience has been gained with
progressive JPEG to warrant making such a recommendation.  To allow
for future experimentation with scan sequences, decoders are expected
to handle any JPEG-legal sequence.  Again, the code savings that might
be had by making restrictive assumptions are too small to justify a
limitation.

<p>When the <span class=cn>JSEP</span> chunk is present, both images must be
progressive if one of them is progressive.

<p>

<li>Recommended 12-bit JPEG subset

<p>JNG JPEGs may optionally use 12-bit sample precision as
defined in JPEG Part 1.

<p>For a sequential image, the SOF marker type must be SOF1
(extended sequential) not SOF0, and the baseline restriction of two Huffman
tables is removed.  Also, the encoder may use either 8-bit or 16-bit
quantization tables.  All other JNG baseline restrictions still apply.
It is recommended that JNG encoders not use extended-sequential mode
except to encode 12-bit data.

<p>For a progressive image, the only difference between
8-bit and 12-bit
modes is that the sample precision is 12 bits and the encoder may use
either 8-bit or 16-bit quantization tables.  All other JNG restrictions
still apply.

<p>

</ul>

<h4><a name="JNG-IDAT">5.1.3. <span class=cn>IDAT </span>JNG PNG-encoded alpha data</a></h4>

<p>This chunk is exactly like the <span class=cn>IDAT</span> chunk in a PNG grayscale
image, except that it is interpreted as an alpha mask to be applied to
the image data from the <span class=cn>JDAT</span> chunks,
when <code class=expr>alpha_compression_method=0</code>.  The alpha channel, if
present, can have sample depths 1, 2, 4, 8, or 16.
<p>The filter method can be any filter method that is defined for PNG
datastreams that are embedded in MNG datastreams.

The <span class=cn>IDAT</span>
chunks can be interleaved with the <span class=cn>JDAT</span> chunks
(see Recommendations for Encoders:
JNG interleaving <a href="#e-jng-int">below</a>).
No other chunk
type can appear among the sequence of <span class=cn>IDAT</span> and <span class=cn>JDAT</span>
chunks.  No other chunk type can appear between the sequences of
<span class=cn>IDAT</span> and <span class=cn>JDAT</span> chunks when they are not interleaved.
The samples in the IDAT must be presented in noninterlaced order, left
to right, top to bottom.  As in PNG, zero means fully transparent and
<code class=expr>2<sup>alpha_sample_depth</sup>-1</code> means fully opaque.

<p>The <span class=cn>IDAT</span> chunks must precede the <span class=cn>JSEP</span> chunk, if the
<span class=cn>JSEP</span> chunk is present.  Minimal viewers that ignore the twelve-bit
<span class=cn>JDAT</span> chunks must read the <span class=cn>IDAT</span> chunks and apply the
alpha samples to the eight-bit image that is contained in the <span class=cn>JDAT</span>
chunks that precede the <span class=cn>JSEP</span> chunk.
Viewers that skip the eight-bit
<span class=cn>JDAT</span> chunks must decode the <span class=cn>IDAT</span>
chunks that precede the <span class=cn>JSEP</span> chunk and apply the
alpha samples to the twelve-bit image that is contained in the <span class=cn>JDAT</span>
chunks that follow the <span class=cn>JSEP</span> chunk.

<h4><a name="JNG-JDAA">5.1.4. <span class=cn>JDAA </span>JNG JPEG-encoded alpha data</a></h4>

<p>This chunk is exactly like the <span class=cn>JDAT</span> chunk in a non-progressive
JNG 8-bit grayscale image, except that it is interpreted as an alpha mask to
be applied to the image data from the <span class=cn>JDAT</span> chunks,
when <code class=expr>alpha_compression_method=8</code>.  The alpha channel, if
present, can have only sample depth 8.  The <span class=cn>JDAA</span>
chunks can be interleaved with the <span class=cn>JDAT</span> chunks
(see Recommendations for Encoders:
JNG interleaving <a href="#e-jng-int">below</a>).

<p>Like <span class=cn>IDAT</span> chunks, the <span class=cn>JDAA</span> chunks must precede
the <span class=cn>JSEP</span> chunk, if the <span class=cn>JSEP</span> chunk is present, and are
handled similarly.

<h4><a name="JNG-JSEP">5.1.5. <span class=cn>JSEP</span> 8-bit/12-bit image separator</a></h4>

<p>JNG permits storage of both an 8-bit and a 12-bit JPEG datastream in a
single JNG file.  This feature allows an 8-bit image to be provided for
non-12-bit-capable decoders.  The <span class=cn>JSEP</span> chunk is used to separate
the two datastreams.

<p>The <span class=cn>JSEP</span> chunk is empty.

<p>A <span class=cn>JSEP</span> chunk must appear between the <span class=cn>JDAT</span>
chunks of an eight-bit datastream and those of a twelve-bit datastream, when
<code class=expr>image_sample_depth=20</code> in the <span class=cn>JHDR</span> chunk.  When
<code class=expr>image_sample_depth != 20</code>, the <span class=cn>JSEP</span> chunk must not
be present.  The eight-bit
datastream must appear first.  Both images must have the same width,
height, color type, compression method, and interlace method.  Viewers can
choose to display one or the other image, but not both.

<h4><a name="JNG-IEND">5.1.6. <span class=cn>IEND </span>End of JNG datastream</a></h4>

<p>The JNG <span class=cn>IEND</span> chunk is identical to its counterpart in
PNG.  Its data length is zero, and it serves to mark the end of the JNG
datastream.

<h3><a name="JNG-anc">5.2. Ancillary JNG chunks</a></h3>

<p>Some PNG ancillary chunks can also appear in JNG datastreams, and are
used for the same purposes as described in 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>.

<p>If the <span class=cn>bKGD</span> chunk is present, it must be written as if it
were written for a PNG datastream with sample_depth=8.  It has one
2-byte entry for grayscale JNGs and three 2-byte entries for color JNGs.
The first (most significant) byte of each entry must be 0.

<p>The following chunks have exactly the same meaning and have the same
syntax as given in the PNG specification: <span class=cn>cHRM</span>, <span class=cn>gAMA</span>,
<span class=cn>iCCP</span>, <span class=cn>sRGB</span>, <span class=cn>pHYs</span>, <span class=cn>oFFs</span>, <span class=cn>sCAL</span>.
If they are present, they must appear prior to the first <span class=cn>JDAT</span> chunk.
The following chunks also have the same meaning and syntax as in PNG:
<span class=cn>iTXt</span>, <span class=cn>tEXt</span>, <span class=cn>tIME</span>, and <span class=cn>zTXt</span>.  They
can appear prior to the first or after the last <span class=cn>JDAT</span> chunk.

<p>The PNG <span class=cn>PLTE</span>, <span class=cn>hIST</span>, <span class=cn>pCAL</span>, <span class=cn>sBIT</span>,
<span class=cn>sPLT</span>, <span class=cn>tRNS</span>, <span class=cn>fRAc</span>, and <span class=cn>gIF*</span> chunks are
not defined in JNG.

<p>When <span class=cn>cHRM</span>, <span class=cn>gAMA</span>, <span class=cn>iCCP</span>, or <span class=cn>sRGB</span>
are present, they provide information about the color space of the
decoded <span class=cn>JDAT</span> image, and they have no effect on the decoded
alpha samples from the <span class=cn>IDAT</span> or <span class=cn>JDAA</span> chunks.  Any viewer that
processes the <span class=cn>gAMA</span> chunk must also recognize and process the
<span class=cn>sRGB</span> chunk.  It can treat it as if it were a <span class=cn>gAMA</span>
chunk containing the value .45455 and it can ignore
its "intent" field.

<p>The chunk copying and ordering rules for JNG are the same as those in
PNG, except for the fact that the <span class=cn>JDAT</span> chunks and <span class=cn>IDAT</span>
or <span class=cn>JDAA</span> chunks can be interleaved.


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

<p>A Delta-PNG datastream describes a single image, by giving the
changes from a previous PNG (Portable Network Graphics) image or
nonviewable PNG-like object, a JNG (JPEG Network Graphics) image, or
another Delta-PNG image.

<p>No provision is made in this specification for storing a Delta-PNG
datastream as a standalone file.  A Delta-PNG datastream will normally
be found as a component of a MNG datastream.  Applications that need
to store a Delta-PNG datastream separately should use a different
file signature and filename extension, or they can wrap it in a MNG
datastream consisting of the MNG signature, the <span class=cn>MHDR</span> chunk, a
<span class=cn>BASI</span> chunk with the appropriate dimensions and an <span class=cn>IEND</span>
chunk, the Delta-PNG datastream, and the <span class=cn>MEND</span> chunk.

<p>The decoder must have available a parent (decoded) object
that has an object buffer from which
the original chunk data is known.  The parent object can be the result
of decoding a PNG, another Delta-PNG datastream, or it could have been
generated by a PNG-like datastream introduced by a <span class=cn>BASI</span> chunk.

<p>The child image is always of the same basic type (at present only
PNG and JNG are defined) as the parent object.  The child is always a
viewable image even if the parent is not.

<p>The decoder must not have modified the pixel data in the parent
object by applying output transformations such as <span class=cn>gAMA</span> or
<span class=cn>cHRM</span>, or by compositing the image against a background.
Instead, the decoder must make available to the Delta-PNG decoder the
unmodified pixel data along with the values for the <span class=cn>gAMA</span>,
<span class=cn>cHRM</span>, and any other recognized chunks from the parent object
datastream.

<p>A Delta-PNG datastream consists of a <span class=cn>DHDR</span> and <span class=cn>IEND</span>
enclosing other optional chunks (if there are no other chunks, the
decoder simply copies the parent image, and displays it if its
<code class=expr>do_not_show=0</code>).

<p>Chunk structure (length, name, CRC) and the chunk-naming system
are identical to those defined in the PNG specification.  Definitions
of <code class=expr>compression_method</code> and <code class=expr>interlace_method</code> are
also the same as defined in the PNG specification. The definition
of <code class=expr>filter_method</code> is the same as for PNG datastreams that
are embedded in MNG datastreams
(see the <span class=cn>IHDR</span> chunk specification, <a href="#mng-IHDR">above, Paragraph 4.2.3</a>).

<h3><a name="D-crit">6.1. Delta-PNG critical chunks</a></h3>

<p>This section describes critical Delta-PNG chunks.  MNG-compliant
decoders must recognize and process them.

<h4><a name="Delta-PNG-DHDR">6.1.1. <span class=cn>DHDR </span>Delta-PNG datastream header</a></h4>

<p>The <span class=cn>DHDR</span> chunk introduces a Delta-PNG datastream.
Subsequent chunks, through the next <span class=cn>IEND</span> chunk, are interpreted
according to the Delta-PNG format.

<p>The <span class=cn>DHDR</span> chunk can contain 4, 12, or 20 bytes:

<pre>
   Object_id:    2 bytes (nonzero unsigned integer).  Identifies the parent
                   object from which changes will be made.  This is also the
                   object_id of the child image, which can be used as the
                   parent image for a subsequent Delta-PNG.
   
   Image_type:   1 byte.
   
                   0: Image type is unspecified.  An IHDR, JHDR, IPNG, or
                      IJNG chunk must be present.  If JHDR or IJNG is
                      present, delta_type must not be 1, 3, 4, or 6.
   
                   1: Image type is PNG.  IHDR and IPNG can be omitted under
                      certain conditions.
   
                   2: Image type is JNG.  JHDR and IJNG can be omitted under
                      certain conditions.  Delta_type must not be 1, 3, 4,
                      or 6.
   
   Delta_type:   1 byte.
   
                   0: Entire image replacement.
   
                   1: Block pixel addition, by samples, modulo 2^sample_depth.
   
                   2: Block alpha addition, by samples, modulo 2^sample_depth.
                      Regardless of the color type of the parent image, the
                      IDAT data are written as a grayscale image (color type
                      0), but the decoded samples are used as deltas to the
                      alpha samples in the parent image.  The parent image
                      must have (or be promoted to via the PROM chunk) a
                      color type that has an alpha channel.
   
                   3: Block color addition.  Similar to delta type 1 except
                      that only the color channels are updated even when the
                      parent has an alpha channel.
   
                   4: Block pixel replacement.
   
                   5: Block alpha replacement.
   
                   6: Block color replacement.
   
                   7: No change to pixel data.
   
   Block_width:  4 bytes (unsigned integer).  This field must be omitted
                   when delta_type=7.
   
   Block_height: 4 bytes (unsigned integer).  This field must be omitted
                   when delta_type=7.
   
   Block_X_location:
                 4 bytes (unsigned integer), measured in pixels from the
                   left edge of the parent object.  This field must be
                   omitted when delta_type=0 or when delta_type=7.
   
   Block_Y_location:
                 4 bytes (unsigned integer), measured in pixels from the
                   top edge of the parent object.  This field must be
                   omitted when delta_type=0 or when delta_type=7.
</pre>

<p>The <code class=expr>object_id</code> must identify an existing object, and the
object must be a "concrete" object, i.e., it must have the property
<code class=expr>concrete_flag=1</code>.

<p>The <code class=expr>image_type</code>, whether given explicitly as 1 or 2
or implied by the presence of an <span class=cn>IHDR</span>, <span class=cn>IPNG</span>,
<span class=cn>JHDR</span>, or <span class=cn>IJNG</span> chunk, must be the same as that of the
parent object.

<p>When <code class=expr>delta_type=0</code>, the width and height of the child image
are given by the <code class=expr>block_width</code> and <code class=expr>block_height</code>
fields.

<p>For all other values of <code class=expr>delta_type</code>, the width and height
of the child image are inherited from the parent object.

<p>When <code class=expr>delta_type=1-6</code>, the <code class=expr>block_width</code>
and <code class=expr>block_height</code> fields give the size of the block of
pixels to be modified or replaced, and <code class=expr>block_X_location</code> and
<code class=expr>block_Y_location</code> give its location with respect to the top
left corner of the parent object.  The block must fall entirely within
the parent object.

<dl>

<dt><strong><a name="Delta-PNG-replacement">Entire image replacement</a></strong>

<dd>When <code class=expr>delta_type=0</code> in the <span class=cn>DHDR</span> chunk, the
pixel data in the <span class=cn>IDAT</span> chunks represent a completely new
image, with dimensions given by the <code class=expr>block_width</code> and
<code class=expr>block_height</code> fields of the <span class=cn>DHDR</span> chunk.  Data from
chunks other than <span class=cn>IDAT</span> or <span class=cn>JDAT</span> can be inherited from
the parent object.  If the <span class=cn>IHDR</span> or <span class=cn>JHDR</span> chunk is present,
all of its fields except <code class=expr>width</code> and <code class=expr>height</code>
(which must be ignored by decoders) provide
new values that are inherited by subsequent objects.  The "pixel
sample depth" and "alpha sample depth" are also reset
equal to the
<span class=cn>IHDR</span> <code class=expr>sample_depth</code> value (in the case of a JNG object,
the new "alpha sample depth" is taken from the <span class=cn>JHDR</span>
<code class=expr>alpha_sample_depth</code> field).  If the <span class=cn>IHDR</span> or <span class=cn>JHDR</span>
chunk is not present,
the <span class=cn>IDAT</span> chunks are decoded according to the parent object's
sample depth, and not according to the "pixel
sample depth" or "alpha sample depth" which are used for
decoding the <span class=cn>IDAT</span> chunks in subsequent Delta-PNG datastreams
when <code class=expr>delta_type</code> is nonzero.

<p>

<dt><strong><a name="Delta-PNG-update">Block pixel addition</a></strong>

<dd>When <code class=expr>delta_type=1</code> in the <span class=cn>DHDR</span> chunk, the pixel
data in the <span class=cn>IDAT</span> chunks represent deltas from the pixel data in
a parent object known to the decoder, including the alpha channel, if the
parent object has an alpha channel.

<p>The <span class=cn>IDAT</span> chunk data contains a filtered and perhaps
interlaced set of delta pixel samples.  The delta samples are presented
in the order specified by <code class=expr>interlace_method</code>, filtered
according to the <code class=expr>filter_method</code> and compressed according to
the <code class=expr>compression_method</code> given in the <span class=cn>IHDR</span> chunk.
The pixel data includes alpha
samples, if the parent object has an alpha channel.

<p>An encoder calculates the delta sample values from the samples
in the
parent object and those in the child image by subtracting the parent
object samples from the child image samples, modulo <code class=expr>2<sup>sample_depth</sup></code>.
When decoding the <span class=cn>IDAT</span> chunk, the child image bytes are
obtained by adding the delta bytes to the parent object bytes, modulo
<code class=expr>2<sup>sample_depth</sup></code>.  This is similar in operation to the PNG SUB filter,
except that it works by samples instead of working by bytes.

<p>Only the pixels
in the block defined by the block location and dimensions given in the
<span class=cn>DHDR</span> chunk are changed.  The size of the <span class=cn>IDAT</span> data
must correspond exactly to this rectangle.

<p>When the parent object has <code class=expr>color_type=3</code>, the
deltas are differences between index values, not between color samples.

<p>The color type must match that of the parent,
except that
when the parent has PNG <code class=expr>color_type=3</code>, the delta can have
<code class=expr>color_type=0</code>, and vice versa, since the contents of
the <span class=cn>IDAT</span> chunks of either color type are indistinguishable.

<p>If the
<a href="#Delta-PNG-decoding"><code class=expr>pixel_sample_depth</code></a>
does not match the
<code class=expr>object_sample_depth</code>, the delta must be scaled to the
<code class=expr>object_sample_depth</code> using the zero-fill or right-shift method
described in the PNG specification, before performing the pixel addition.

<p>When the <span class=cn>IHDR</span> chunk is present, the compression
method, filter method, and interlace method
need not be the same as those of the parent object.  The new
values are used in decoding the IDAT data, and the new values are
inherited by the child object.

<p>Whenever the sample depth differs from that of
the parent object, the resulting object inherits the original value from
the parent.  The value from the <span class=cn>IHDR</span> chunk is
only used for decoding the <span class=cn>IDAT</span> data in this and subsequent
Delta-PNGs.  Implicit in this is the requirement for decoders to remember
in the object buffer
not only the sample depth of the object but (separately) the
<a href="#Delta-PNG-decoding">"pixel sample depth"</a>
for use in decoding the <span class=cn>IDAT</span> chunks
of subsequent Delta-PNG datastreams that do not contain their own
<span class=cn>IHDR</span> chunk.
The parent object cannot have alpha samples that were carried in JPEG-encoded
<span class=cn>JDAA</span> chunks.

<p>

<dt><strong><a name="Delta-PNG-alpha-update">Block alpha addition</a></strong>

<dd>When <code class=expr>delta_type=2</code> in the <span class=cn>DHDR</span> chunk, the pixel
data in the <span class=cn>IDAT</span> chunks represent deltas from the alpha
data in a parent object known to the decoder.  The color samples
are not changed, and the updated alpha samples are calculated in
the same manner as the updated pixel samples are calculated when
<code class=expr>delta_type=1</code>.

<p>The <code class=expr>color_type</code> is 0 (grayscale), regardless of the
<code class=expr>color_type</code> of the parent object.  The parent object must have
an alpha channel or must have been promoted to a type that has an alpha
channel.  The compression method, filter method, and interlace method
need not be the same.  If they are different, the child object inherits
the new values, and the new values will be used in decoding the data in
any subsequent <span class=cn>IDAT</span> chunks.  Neither the parent object nor the
delta object can have alpha samples that were carried in JPEG-encoded
<span class=cn>JDAA</span> chunks.

<p>
The <code class=expr>sample_depth</code> value from the <span class=cn>IHDR</span> chunk is
interpreted as a new value of <code class=expr>alpha_sample_depth</code> and is
only used for decoding the <span class=cn>IDAT</span> data in this and subsequent
Delta-PNGs.  Implicit in this is the requirement for decoders to remember
in the object buffer not only the sample depth of the object
but (separately) the <code class=expr>alpha_sample_depth</code>
for use in decoding the <span class=cn>IDAT</span> chunks in any subsequent Delta-PNG
datastreams.

<p>If the
<a href="#Delta-PNG-decoding"><code class=expr>alpha_sample_depth</code></a>
does not match the
<code class=expr>object_sample_depth</code>, the delta must be scaled to the
<code class=expr>object_sample_depth</code>,
using the zero-fill or right-shift method described in the PNG specification,
before performing the pixel addition.

<p>

<dt><strong><a name="Delta-PNG-color-delta">Block color addition</a></strong>

<dd><code class=expr>delta_type=3</code> is similar to <code class=expr>delta_type=1</code>
except that the alpha channel is not included in the <span class=cn>IDAT</span>
pixels; the alpha channel is inherited from the parent object.
The color type of the parent must be one that has an alpha channel
(4 or 6) and the color type of the delta must be the corresponding color type
(0 or 2) that does not have an alpha channel.

<p>

<dt><strong><a name="Delta-PNG-replace">Block pixel replacement</a></strong>

<dd>When <code class=expr>delta_type=4</code> in the <span class=cn>DHDR</span> chunk, the pixel
data in the <span class=cn>IDAT</span> chunks represent replacement values for the
pixel samples in the rectangle given by the block location and dimension
fields in the <span class=cn>DHDR</span> chunk, including the alpha channel, if the
parent object has an alpha channel.

<p>If the <code class=expr>pixel_sample_depth</code> does not match
the <code class=expr>object_sample_depth</code>,
the pixel data must be scaled to the <code class=expr>object_sample_depth</code>
before making the replacements,
using the left bit replication method described in the PNG specification,
or by the right shift method in the unlikely event that the
<code class=expr>pixel_sample_depth</code> is larger than
the <code class=expr>object_sample_depth</code>.

<p>The color type must match that of the parent,
except for the cases mentioned for delta type 1, above.

<p>

<dt><strong><a name="Delta-PNG-alpha-replace">Block alpha replacement</a></strong>

<dd>When <code class=expr>delta_type=5</code> in the <span class=cn>DHDR</span> chunk, the pixel
data in the <span class=cn>IDAT</span> chunks represent replacement values of the
alpha samples in the rectangle given by the block location and dimension
fields in the <span class=cn>DHDR</span> chunk.  The sample depth of the
data (i.e. the "alpha sample depth") need not match the sample depth
of the parent object, and <code class=expr>color_type</code> is
0 (grayscale), regardless of the <code class=expr>color_type</code> of the parent
object.
If the sample depths differ, the samples must be scaled
to the <code class=expr>object_sample_depth</code>, using
the left bit replication method or right shift method described
in the PNG specification, depending on whether
the <code class=expr>alpha_sample_depth</code> is larger or smaller than
the <code class=expr>object_sample_depth</code>.
The parent object must have an alpha channel or must have been
promoted to a type that has an alpha channel.  The compression method,
filter method, and interlace method need not be the same.  If they
differ, the child object inherits the new values.

<p>It is permitted to use JPEG-encoded <span class=cn>JDAA</span> chunks to convey
the new alpha data.  If this is done, then the alpha channel of the object
can no longer be used as the parent for block-pixel-addition or
block-alpha-addition.

<p>

<dt><strong><a name="Delta-PNG-color-replace">Block color replacement</a></strong>

<dd><code class=expr>delta_type=6</code> is similar to <code class=expr>delta_type=4</code>
except that the alpha channel is not included in the <span class=cn>IDAT</span>
pixels; the alpha channel is inherited from the parent object.
The color type of the parent must be one that has an alpha channel
(4 or 6) and the color type of the delta must be the corresponding color type
(0 or 2) that does not have an alpha channel.

<p>

<dt><strong><a name="Delta-PNG-nochange">No change to pixel data</a></strong>

<dd>When <code class=expr>delta_type=7</code> in the <span class=cn>DHDR</span> chunk, there is
no change to the pixel data, and it is an error for
<span class=cn>IDAT</span>, <span class=cn>JDAT</span>, or <span class=cn>JDAA</span> to appear.  If the <span class=cn>IHDR</span>
or <span class=cn>JHDR</span> chunk appears, the width, height, and color_type fields are
ignored, the PNG sample depth
(or JNG alpha_sample_depth) is used to update the <code class=expr>pixel_sample_depth</code>
and <code class=expr>alpha_sample_depth</code>, and the data in the remaining fields
are inherited by the child object.

<p>

<dt><strong><a name="Delta-PNG-decoding">Pixel sample depth, alpha sample depth</a></strong>

<dd>As mentioned above, the sample depth of the deltas
is not necessarily the same as that of the object, when
<code class=expr>delta_type</code> is 0.  The decoder needs to remember the
<code class=expr>pixel_sample_depth</code> and <code class=expr>alpha_sample_depth</code> to use with each
object.  They are initialized to the <code class=expr>sample_depth</code> value
from the <span class=cn>IHDR</span> chunk that appears when the object is first
created but can be changed by the appearance of the <span class=cn>IHDR</span> chunk in
a Delta-PNG datastream that has a nonzero <code class=expr>delta_type</code>.
If the object is a JNG image, they are initialized from the value
of <code class=expr>alpha_sample_depth</code> from
the original <span class=cn>JHDR</span> chunk, and can be changed by the appearance
of the <span class=cn>JHDR</span> chunk in a Delta-PNG datastream that has
<code class=expr>delta_type != 0</code>.

<p>

</dl>

<h4><a name="DPNG-IDAT">6.1.2. <span class=cn>IDAT, JDAT</span>, and <span class=cn>JDAA </span> New pixel data</a></h4>

<p>In a Delta-PNG datastream, new pixel data is conveyed by <span class=cn>IDAT</span>,
<span class=cn>JDAT</span>, or <span class=cn>JDAA</span> chunks, depending on the image type and
delta type in the <span class=cn>DHDR</span> chunk.  Any remaining part of the Delta-PNG
datastream following these chunks must be interpreted as PNG or JNG chunks
and not as Delta-PNG chunks.  If the image type is 0 (i.e., unspecified),
the first <span class=cn>IDAT</span> or <span class=cn>JDAA</span> chunk must be preceded by
an <span class=cn>IHDR</span>, <span class=cn>JHDR</span>, <span class=cn>IPNG</span>, <span class=cn>IJNG</span>,
<span class=cn>PLTE</span>, or <span class=cn>PPLT</span> chunk that will serve to identify the image type.

<h4><a name="Delta-PNG-PROM">6.1.3. <span class=cn>PROM </span>Promotion of parent object</a></h4>

<p>This chunk is used to "promote" a parent object to a higher
bit depth or to add an alpha channel, before making changes to it.

<pre>
   New color type:   1 byte.
   New sample depth: 1 byte.
   Fill method:      1 byte.
                       0: Left-bit-replication
                       1: Zero fill
</pre>

<p>When a decoder encounters the <span class=cn>PROM</span> chunk, it must promote
the pixel data.  The cases are:

<dl>

<dt><strong>G -&gt; GA (<code class=expr>color_type 0 -&gt; 4</code>)</strong>

<dd>Do not change the gray values.  Set all the alpha values to fully
opaque, except for pixels marked transparent by cheap transparency--set
their alpha values to fully transparent.  Discard the cheap transparency
information (the PNG <span class=cn>tRNS</span> chunk data).

<p>

<dt><strong>RGB -&gt; RBGA (<code class=expr>color_type 2 -&gt; 6</code>)</strong>

<dd>Do not change the RGB values.  Convert the <span class=cn>tRNS</span> chunk data to
alpha values as in the G -&gt; GA promotion.

<p>

<dt><strong>G -&gt; RGB (<code class=expr>color_type 0 -&gt; 2</code>)</strong>

<dd>Set R, G, and B equal to the gray value.  Apply the same operation to
the cheap transparency data (if any).  Expand any <span class=cn>bKGD</span> or
<span class=cn>sBIT</span> data.

<p>

<dt><strong>GA -&gt; RGBA (<code class=expr>color_type 4 -&gt; 6</code>)</strong>

<dd>Set R, G, and B equal to the gray value.  Do not change the alpha
values.  Expand any <span class=cn>bKGD</span> or <span class=cn>sBIT</span> data.

<p>

<dt><strong>G -&gt; RGBA (<code class=expr>color_type 0 -&gt; 6</code>)</strong>

<dd>Set R, G, and B equal to the gray value.  Handle transparency as in
the G -&gt; GA promotion.  Expand any <span class=cn>bKGD</span> or <span class=cn>sBIT</span> data.

<p>

<dt><strong>indexed -&gt; RGB (<code class=expr>color_type 3 -&gt; 2</code>)</strong>

<dd>Set R, G, and B according to the palette entry corresponding to the
index.  Discard the cheap transparency information (if any).
Expand any <span class=cn>bKGD</span> or <span class=cn>sBIT</span> data.

<p>

<dt><strong>indexed -&gt; RGBA (<code class=expr>color_type 3 -&gt; 6</code>)</strong>

<dd>Set R, G, and B as in indexed -&gt; RGB.  Set the alpha value
according to the cheap transparency information (if any).  Discard the
cheap transparency information.
Expand any <span class=cn>bKGD</span> or <span class=cn>sBIT</span> data.

<p>

<dt><strong>JNG-G -&gt; JNG-C (<code class=expr>JNG color_type 8 -&gt; 10</code>)</strong>

<dd>Expand the gray values to color.  Expand any <span class=cn>bKGD</span> data.

<p>

<dt><strong>JNG-G -&gt; JNG-GA (<code class=expr>JNG color_type 8 -&gt; 12</code>)</strong>

<dd>Do not change the gray values.  Set all the alpha values to fully
opaque.  The given sample depth is the new sample depth for the alpha
channel.

<p>

<dt><strong>JNG-G -&gt; JNG-CA (<code class=expr>JNG color_type 8 -&gt; 14</code>)</strong>

<dd>Expand the gray values to color.  Set all the alpha values to fully
opaque.  The given sample depth is the new sample depth for the alpha
channel.  Expand any <span class=cn>bKGD</span> data.

<p>

<dt><strong>JNG-C -&gt; JNG-CA (<code class=expr>JNG color_type 10 -&gt; 14</code>)</strong>

<dd>Do not change the color values.  Set all the alpha values to fully
opaque.  The given sample depth is the new sample depth for the alpha
channel.

<p>

<dt><strong>JNG-GA -&gt; JNG-CA (<code class=expr>JNG color_type 12 -&gt; 14</code>)</strong>

<dd>Expand the gray values to color.  Do not change the alpha values.
Expand any <span class=cn>bKGD</span> data.

<p>

<dt><strong>No change in <code class=expr>color_type</code></strong>

<dd>Only the sample depth is changed.  The new sample depth must be
larger than the old one.

<p>

</dl>

<p>If the sample depth has been changed, the sample values must be
widened.  The decoder must use left-bit-replication or zero-fill
according to the specified <code class=expr>fill_method</code> to fill the additional
bits of each sample.  If cheap transparency information is present in a
grayscale or truecolor object, its sample values must also be widened in
the same manner.  If the image type is JNG, then the new sample depth
refers to the <code class=expr>alpha_sample_depth</code> and only the alpha channel
is affected, if one is present.  If the <code class=expr>color_type</code> has been
promoted from indexed-color, the original bit depth is always considered to be
8.  See the PNG specification <span class=ref>[<a href="#PNG">PNG</a>]</span> 
for
further information on these filling methods.  Any alpha channel added
in this manner is eligible to be updated by block-alpha-addition in this
or a subsequent Delta-PNG.

<p>If the basis object contains data from the PNG <span class=cn>bKGD</span> chunk,
this data must be promoted as well.  If a grayscale object is being
promoted to a truecolor object, the background RGB samples are set equal
to the grayscale background sample.  If the bit depth has been changed,
the background samples are widened in accordance with the specified
<code class=expr>fill_method</code>.  If the basis object is a JNG, the <span class=cn>bKGD</span>
chunk is not affected.

<p>If the basis object contains data from the PNG <span class=cn>sBIT</span> chunk,
this data must also be promoted.  If a grayscale object is being
promoted to a truecolor object, the new RGB bytes are set equal to the
grayscale byte.  When an alpha channel is added, the alpha byte is set
equal to the sample depth of the basis image.  If the sample depth has
been changed, the <span class=cn>sBIT</span> bytes do not change.

<p>The <span class=cn>PROM</span> chunk is not permitted to "demote" a parent
object to an object with a lesser bit depth or from one with an alpha channel
to one without an alpha channel.

<p>The <span class=cn>PROM</span> chunk must appear ahead of the <span class=cn>IHDR</span> chunk,
if <span class=cn>IHDR</span> is present, and ahead of any chunks that would have
followed <span class=cn>IHDR</span>, if <span class=cn>IHDR</span> is omitted.

<h4><a name="D-IHDR">6.1.4. <span class=cn>IHDR</span> PNG image header</a></h4>

<p>Inside a Delta-PNG datastream, the <span class=cn>IHDR</span> chunk introduces
an incomplete PNG (Portable Network Graphics) datastream.  The parent
object must be a PNG or PNG-based Delta-PNG.  The datastream can be
introduced by a complete PNG <span class=cn>IHDR</span> chunk or by an <span class=cn>IPNG</span>
chunk, which is empty.

<p>If the <span class=cn>IHDR</span> chunk is present, its <code class=expr>width</code>
and <code class=expr>height</code>
fields are ignored.  The values for these parameters are inherited from
the parent object or from the <span class=cn>DHDR</span> chunk.

<p>The <code class=expr>sample_depth</code>, <code class=expr>color_type</code>,
<code class=expr>compression_method</code>, <code class=expr>interlace_method</code>, and
<code class=expr>filter_method</code> fields, if different from those of the parent
object, are used in decoding any subsequent <span class=cn>IDAT</span> chunks, and
the new values will be inherited by any subsequent image that uses this
object as its parent.  These do not change the <code class=expr>sample_depth</code>
and <code class=expr>color_type</code> of the object itself; those can only be
changed by using the <span class=cn>PROM</span> chunk or by using <code class=expr>delta_type=0</code>.

<p>See the PNG specification
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.
The <code class=expr>filter_method</code> can be any <code class=expr>filter_method</code> that is
allowed in PNG datastreams that are embedded in a MNG datastream.
The
PNG datastream must contain at least <span class=cn>IHDR</span> and <span class=cn>IEND</span>
(whether actually present in the datastream or omitted and included
by implication, as described below), but can inherit other chunk data
from the parent object.  Except for <span class=cn>IDAT</span> and <span class=cn>PPLT</span>,
any chunks appearing between <span class=cn>IHDR</span> and <span class=cn>IEND</span> are always
treated as replacements or additions and not as deltas.

<h4><a name="D-IPNG">6.1.5. <span class=cn>IPNG</span> Incomplete PNG</a></h4>

<p>The <span class=cn>IPNG</span> chunk is empty.

<p>The <span class=cn>IPNG</span> chunk can be used instead of the <span class=cn>IHDR</span>
chunk if the <span class=cn>IHDR</span> chunk is not needed for resetting the
value of <code class=expr>compression_method</code>, <code class=expr>filter_method</code>, or
<code class=expr>interlace_method</code>.  The purpose of this chunk is to identify
the beginning of the PNG datastream, so decoders can start interpreting
PNG chunks instead of Delta-PNG chunks.  The decoder must treat this
datastream as though the <span class=cn>IHDR</span> chunk were present in the
location occupied by the <span class=cn>IPNG</span> chunk.

<p>The <span class=cn>IHDR</span> chunk can also be omitted when
<code class=expr>image_type=1</code> and the PNG datastream begins with a
<span class=cn>PLTE</span> chunk, a <span class=cn>PPLT</span> chunk, or an <span class=cn>IDAT</span> chunk.
In this case, no <span class=cn>IPNG</span> chunk is required, either.  The decoder
must treat this datastream as though the <span class=cn>IHDR</span> chunk were
present, immediately preceding the first PNG chunk.  If the first PNG
chunk is neither a <span class=cn>PLTE</span> chunk, a <span class=cn>PPLT</span> chunk, nor an
<span class=cn>IDAT</span> chunk, then either the <span class=cn>IPNG</span> or <span class=cn>IHDR</span> chunk
must be present to introduce the PNG datastream.

<h4><a name="D-PLTE">6.1.6. <span class=cn>PLTE</span> and <span class=cn>tRNS</span></a></h4>

<p>If the <span class=cn>PLTE</span> chunk is present, it need not have the same
length as that inherited from the parent object, but it must contain
the complete palette needed in the child image.  If it is shorter than
the palette of the parent object, decoders can discard the remaining
entries and the child image must not refer to them.  Decoders can also
truncate any <span class=cn>tRNS</span> data inherited from an indexed-color parent
object.  If the new palette is longer than the parent palette, and
a new <span class=cn>tRNS</span> chunk is not present in an indexed-color image,
the <span class=cn>tRNS</span> data must be extended with opaque entries.  The new
palette must not be longer than the object's <code class=expr>sample_depth</code>
would allow, and must not have more than 256 entries.

<p>When processing the <span class=cn>tRNS</span> chunk, if <code class=expr>color_type=3</code>
and <span class=cn>PLTE</span> is not supplied, then the number of allowable entries
is determined from the number of <span class=cn>PLTE</span> entries in the parent
object.  A <span class=cn>tRNS</span> chunk appearing in a Delta-PNG datastream is
always treated as a complete replacement for the <span class=cn>tRNS</span> chunk
data in the parent object.  All entries beyond those actually supplied
are overwritten with the "opaque" value (255).

<h4><a name="D-PPLT">6.1.7. <span class=cn>PPLT</span> Partial palette</a></h4>

<p>If it is desired only to overwrite or add palette entries,
the <span class=cn>PPLT</span> chunk can be used.  This might be useful for
palette-animation applications.  This chunk can also be used to
overwrite or add entries to the transparency (alpha) data from the
parent's <span class=cn>tRNS</span> chunk.

<p>The <span class=cn>PPLT</span> chunk contains a <code class=expr>delta_type</code> byte and one
or more groups of palette entries:

<pre>
   PPLT_delta_type: 1 byte.
                      0: Values are replacement RGB samples.
                      1: Values are delta RGB samples.
                      2: Values are replacement alpha samples.
                      3: Values are delta alpha samples.
                      4: Values are replacement RGBA samples.
                      5: Values are delta RGBA samples.
   First_index,
     first group:   1 byte.
   Last_index,
     first group:   1 byte.
   First set of
     samples:       1, 3, or 4 bytes.
   ...etc...
   Last set of
     samples:       1, 3, or 4 bytes.
   First index,
     second group:  1 byte.
   ...etc...
</pre>

<p>The <code class=expr>last_index</code> must be equal to or greater than
<code class=expr>first_index</code>.  The groups are not required to appear in
ascending order.  If any index of any group is beyond the end of the
parent object's palette, the palette and <span class=cn>tRNS</span> data must be
extended just as if a longer complete <span class=cn>PLTE</span> chunk had appeared.
If there are gaps in the resulting extended palette, the colors must be
filled with {0,0,0} and the alphas filled with 255.  If alpha samples
are supplied (<code class=expr>PPLT_delta_type &gt; 1</code>) and no <span class=cn>tRNS</span>
data is present in the parent object, a <span class=cn>tRNS</span> chunk must be
created in the child object as though a complete <span class=cn>tRNS</span> chunk
had appeared.  The new palette must not be longer than the object's
<code class=expr>sample_depth</code> would allow.

<p>When <code class=expr>PPLT_delta_type=0</code>, the values are replacements for
the existing samples in the palette.

<p>When <code class=expr>PPLT_delta_type=1</code>, the values are added to the
existing samples (modulo 256) to obtain the new samples.

<p>If the new entry is beyond the range of the original palette,
the values are simply appended, regardless of the contents of
<code class=expr>PPLT_delta_type</code>.

<h4><a name="D-JHDR">6.1.8. <span class=cn>JHDR</span> JNG image header</a></h4>

<p>Inside a Delta-PNG datastream, the <span class=cn>JHDR</span> chunk introduces an
incomplete JNG (JPEG Network Graphics) datastream.  The parent object
must be a JNG or JNG-based Delta-PNG.  The datastream is introduced by a
complete <span class=cn>JHDR</span> chunk.

<p>If the <span class=cn>JHDR</span> chunk is present, its <code class=expr>width</code>,
<code class=expr>height</code>, <code class=expr>image_sample_depth</code>,
<code class=expr>image_color_type</code>, <code class=expr>image_filter_method</code>, and
<code class=expr>image_interlace_method</code> fields are ignored.  The values for these
parameters are inherited from the parent object.

<p>The <code class=expr>alpha_compression_method</code>,
<code class=expr>alpha_interlace_method</code>, and <code class=expr>alpha_filter_method</code> fields,
if different from those of the parent object, are used in decoding any
subsequent <span class=cn>IDAT</span> chunks, and the new values will be inherited by
any subsequent image that uses this object as its parent.  If the
<code class=expr>alpha_sample_depth</code> differs, it will be used in decoding the
<span class=cn>IDAT</span> chunk data of the Delta-PNG and subsequent Delta-PNG
datastreams; but the child object itself will retain the original sample depth,
and must also retain the "alpha sample depth" for use in decoding
subsequent Delta-PNG datastreams.  The decoded alpha samples must be
scaled to the object's sample depth before the replacements or delta
calculations are done.

<p>See the JNG specification above for the format of the JNG
chunks.  The PNG datastream must contain at least <span class=cn>JHDR</span> and
<span class=cn>IEND</span>, but can inherit other chunk data from the parent
object.  Except for IDAT, any chunks appearing between <span class=cn>JHDR</span> and
<span class=cn>IEND</span> are always treated as replacements or additions and not as
deltas.

<h4><a name="D-IJNG">6.1.9. <span class=cn>IJNG</span> Incomplete JNG</a></h4>

<p>The <span class=cn>IJNG</span> chunk is empty.

<p>The <span class=cn>IJNG</span> chunk can be used instead of the <span class=cn>JHDR</span>
chunk if the <span class=cn>JHDR</span> chunk is not needed for resetting the value
of any of the <span class=cn>JHDR</span> fields.  The purpose of this chunk is to
identify the beginning of the JNG datastream, so decoders can start
interpreting JNG chunks instead of Delta-PNG chunks.  The decoder must
treat this datastream as though the <span class=cn>JHDR</span> chunk were present in
the location occupied by the <span class=cn>IJNG</span> chunk.

<p>The <span class=cn>JHDR</span> chunk can also be omitted when
<code class=expr>image_type=2</code> and the JNG datastream begins with a
<span class=cn>JDAT</span> or <span class=cn>JDAA</span> chunk.
In this case, no <span class=cn>IJNG</span>
chunk is required, either.  The decoder must treat this datastream as
though the <span class=cn>JHDR</span> chunk were present, immediately preceding
the first <span class=cn>JDAT</span> chunk.  If the first JNG chunk is not a
<span class=cn>JDAT</span> or <span class=cn>JDAA</span> chunk, then either the <span class=cn>IJNG</span>
or <span class=cn>JHDR</span> chunk must be present to introduce the JNG datastream.

<h4><a name="Delta-PNG-DROP">6.1.10. <span class=cn>DROP </span>Drop chunks</a></h4>

<p>All chunks in the parent object with the specified name are inhibited
from being copied into the child image.

<p>The <span class=cn>DROP</span> chunk contains a one or more 4-byte chunk names:

<pre>
   Chunk_name: 4 bytes (ASCII text).
   etc.
</pre>

<p>Multiple <span class=cn>DROP</span> chunks are permitted in a Delta-PNG datastream.

<p>If multiple names appear in the <span class=cn>DROP</span> chunk, it is shorthand
for multiple <span class=cn>DROP</span> chunks.

<h4><a name="Delta-PNG-DBYK">6.1.11. <span class=cn>DBYK </span>Drop chunks by keyword</a></h4>

<p>The <span class=cn>DBYK</span> chunk contains one or more sequences, each containing
a chunk name, polarity byte, and a keyword:

<pre>
   Chunk_name: 4 bytes (ASCII text).
   
   Polarity:   1 byte (unsigned integer).
                 0: Only.
                 1: All-but.
   
   Keywords (null-separated Latin-1 text strings).
   
   etc.
</pre>

<p>The chunk name must be the name of a chunk whose data begins with
a null-terminated text string.  Some parent object chunks with the
specified chunk name are inhibited from being copied into the child
image.  If polarity is &lt;only&gt;, then any parent chunk whose
keyword appears in the keywords list is inhibited.  If polarity is
&lt;all-but&gt;, then any parent object chunk whose keyword does not
appear in the keywords list is inhibited.

<p>The format of the keyword is the same as that specified for the
parent chunk.  Comparisons of keywords in the parent chunk and the
<span class=cn>DBYK</span> chunk are case sensitive.

<p>Use caution when printing or displaying keywords (Refer to Security
considerations, <a href="#Security">below, Chapter 17</a>).

<h4><a name="Delta-PNG-ORDR">6.1.12. <span class=cn>ORDR </span>Ordering restrictions</a></h4>

<p>The <span class=cn>ORDR</span> chunk informs the applier of the Delta-PNG of the
ordering restrictions for ancillary chunks.  It contains one or more
5-byte sequences:

<pre>
   Chunk_name: 4 bytes (ASCII text).
   Order_type: 1 byte.
                 0: Anywhere.
                 1: After IDAT and/or JDAT or JDAA.
                 2: Before IDAT and/or JDAT or JDAA.
                 3: Before IDAT but not before PLTE.
                 4: Before IDAT but not after PLTE.
   etc.
</pre>

<p>Critical chunk names must not appear in the <span class=cn>ORDR</span> chunk.  The
applier needs to know everything about them anyway.

<p>If a chunk name appears in the <span class=cn>ORDR</span> chunk, it is a promise
that any chunk of that name appearing in the parent object which is not
inhibited by <span class=cn>DROP/DBYK</span> will not be broken by this Delta-PNG,
and therefore the applier must copy it into the child image at a
location compatible with its ordering restrictions.

<p>If any ancillary chunk appears in the parent object, and it is not
inhibited, and its name does not appear in the <span class=cn>ORDR</span> chunk, then
the applier should copy it into the child only if it knows the chunk
well enough to be sure that it is consistent with the changes made by
the Delta-PNG, and knows where it can be placed in the child.  Those
conditions are always true of safe-to-copy chunks.

<p>If any critical chunk defined in neither this specification nor the
PNG specification appears in the parent object or in the Delta-PNG,
it is a fatal error unless the applier knows how to handle it.  The
specification of the critical chunk can include provisions for this
scenario.

<h3><a name="DPNG-anc">6.2. Ancillary Delta-PNG chunks</a></h3>

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

<h4><a name="D-col">6.2.1. <span class=cn>gAMA, cHRM, iCCP, sRGB</span> Color space chunks</a></h4>

<p>A <span class=cn>gAMA</span>, <span class=cn>cHRM</span>, <span class=cn>iCCP</span>, <span class=cn>sRGB</span> or
similar chunk existing in the parent object would not affect the pixel
data in a concrete object inherited by this Delta-PNG datastream
because they are not used in decoding the pixel data.  Applications
are responsible for ensuring that the pixel values that are inherited
from the parent object are the raw pixel data that existed prior to any
transformations that were applied while displaying the parent image.
These color transformations are applied to the resulting pixel data for
display purposes.

<h4><a name="DPNG-offs">6.2.2. <span class=cn>oFFs</span> and <span class=cn>pHYs</span></a></h4>

<p>MNG viewers must ignore <span class=cn>oFFs</span> and <span class=cn>pHYs</span> chunks that
appear inside a PNG or JNG datastream or are inherited from the MNG top
level.  MNG editors are expected to treat them as if they were unknown
copy-safe chunks.

<h4><a name="DPNG-other-anc">6.2.3. Other ancillary PNG chunks</a></h4>

<p>Any other ancillary PNG chunks that the decoder recognizes
when processing
a PNG datastream should also be recognized and handled when processing
a delta-PNG datastream.  Any chunks that it does not recognize should
be processed as instructed by the <span class=cn>ORDR</span>, <span class=cn>DROP</span>,
and <span class=cn>DBYK</span> chunks.  MNG
viewers are free to ignore any ancillary chunks, while MNG editors should
handle them in accordance with the copying rules.

<h4><a name="Delta-PNG-IEND">6.2.4. <span class=cn>IEND </span>End of Delta-PNG datastream</a></h4>

<p>End of Delta-PNG datastream.  An <span class=cn>IEND</span> chunk must be present
for each <span class=cn>DHDR</span> chunk in a MNG datastream.  A single <span class=cn>IEND</span>
terminates both the Delta-PNG datastream and any embedded PNG or JNG
datastream within it.

<p>The <span class=cn>IEND</span> chunk is empty.

<h3><a name="Delta-PNG-order">6.3. Chunk ordering requirements</a></h3>

<p>The PNG specification places ordering requirements on many chunks
with respect to the <span class=cn>PLTE</span> and <span class=cn>IDAT</span> chunks.  If neither
of these two chunks is present, and the <span class=cn>ORDR</span> chunk is not
present, known chunks (always including all standard chunks described in
the PNG specification) are considered to have appeared in their proper
order with respect to the critical chunks.  Unknown chunks are ordered
as described <a href="#Delta-PNG-ORDR">above (Paragraph 6.1.12)</a>.

<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 the same as those in PNG, except
that a MNG editor is not permitted to move unknown chunks across any of
the following chunks, or across any critical chunk in a future version
of this specification that creates or displays an image:

<ul>

<li><span class=cn>SAVE</span>

<li><span class=cn>SEEK</span>

<li><span class=cn>IHDR</span>

<li><span class=cn>JHDR</span>

<li><span class=cn>IEND</span>

<li><span class=cn>DHDR</span>

<li><span class=cn>BASI</span>

<li><span class=cn>CLON</span>

<li><span class=cn>PAST</span>

<li><span class=cn>SHOW</span>

<li><span class=cn>MAGN</span>

</ul>

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

<p>If an editor makes changes to the MNG datastream that render unknown
chunks unsafe-to-copy, this does not affect the copy-safe status of any
chunks beyond the next <span class=cn>SEEK</span> chunk or prior to the previous
one.  However, if it makes such changes prior the <span class=cn>SAVE</span> chunk,
this affects the copy-safe status of all top-level unknown chunks in the
entire MNG datastream.

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

<p>The <span class=cn>SAVE</span>, <span class=cn>SEEK</span>, and <span class=cn>TERM</span> chunks are not
considered to be a part of any segment.  Changes to the data in the
<span class=cn>SAVE</span> or <span class=cn>SEEK</span> chunks do not affect the copy-safe
status of any other chunks.  Adding or removing a <span class=cn>SEEK</span> chunk
affects the copy-safe status of unknown chunks in the newly-merged
or newly-separated segments.  Adding, removing, or changing the
<span class=cn>TERM</span> chunk has no effect on the copy-safe status of any chunk.

<p>As in PNG, unsafe-to-copy ancillary chunks in the top-level MNG
datastream can have ordering rules only with respect to critical chunks.
Safe-to-copy ancillary chunks in the top-level MNG datastream can have
ordering rules only with respect to the
<span class=cn>SAVE</span>, <span class=cn>SEEK</span>,
<span class=cn>SHOW</span>, and <span class=cn>PAST</span> chunks, <span class=cn>DHDR-IEND</span>, <span class=cn>BASI-IEND</span>,
<span class=cn>IHDR-IEND</span>, <span class=cn>JHDR-IEND</span>
sequences, or with respect to any other
critical "header-end" sequence
that might be defined in the future that could contain <span class=cn>IDAT</span> or
similar chunks.

<p>The copying rules for unknown chunks inside <span class=cn>IHDR-IEND</span>,
<span class=cn>BASI-IEND</span>, <span class=cn>DHDR-IEND</span>,
and <span class=cn>JHDR-IEND</span> sequences
are governed by the PNG and JNG specifications, and any changes inside
such sequences have no effect on the copy-safe status of any top-level
MNG chunks.

<p>The copy-safe status of chunks inside a <span class=cn>DHDR-IEND</span> sequence
depends on the copy-safe status of the chunks in its parent object.

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

<p>This section specifies the minimum level of support that is expected of
MNG, MNG-LC, or MNG-VLC-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>
<em>Anything less than this level of support requires subsetting.</em>
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 or MNG-VLC.
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
     0   0 1 1 1 0 1 1 1 1 1  479    MNG without stored object buffers
     0   1 1 1 1 0 0 1 1 1 1  975    MNG without JNG or Delta-PNG
     0   1 1 1 1 0 1 1 1 1 1  991    MNG without Delta-PNG
     0   1 1 1 1 1 0 1 1 1 1 1007    MNG without JNG
     0   1 1 1 1 1 1 1 1 1 1 1023 or 0  MNG
     0   1 1 1 1 1 1 1 1 1 1 1023 or 0  MNG with 12-bit JNG support
         | | | | | | | | | |
         | | | | | | | | | +- Validity
         | | | | | | | | +--- Simple MNG features
         | | | | | | | +----- Complex MNG features
         | | | | | | +------- Transparency
         | | | | | +--------- JNG
         | | | | +----------- Delta-PNG
         | | | +------------- Validity of bits 7,8, and 9
         | | +--------------- Semitransparency
         | +----------------- Background transparency
         +------------------- Stored objects
</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.
</ol>
<p>An equally reasonable development path might be
<ol>
<li>MNG-VLC with JNG,
<li>MNG-LC with JNG,
<li>MNG with JNG, but without stored object buffers,
<li>MNG.
</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".

<p>We are allowing conformant decoders to skip twelve-bit JNGs
because those are likely to be rarely encountered and used only for
special purposes.  There is no profile flag to indicate the presence
or absence of 12-bit JNGs.

<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>LOOP, ENDL</strong>

<dd>The <code class=expr>iteration_count</code> must be supported.  The
<code class=expr>nest_level</code> should be used as a sanity check but is not
required.  When <code class=expr>iteration_min=1</code> either explicitly or
when it is omitted and the <code class=expr>termination_condition</code> is not 0 or 4, the
<span class=cn>LOOP</span> chunk
and its <span class=cn>ENDL</span> chunk can be ignored (bit 2 of the simplicity profile
can be used to promise that this is true for all loops).

<p>

<dt><strong>DEFI, CLON</strong>

<dd>Must be fully supported.
All objects can be treated as "concrete" if
the decoder does not wish to take advantage of the distinction between
"abstract" and "concrete".
Bit 2 of the simplicity profile can be used to promise that the <span class=cn>CLON</span>
chunk is not present and that if the <span class=cn>DEFI</span> chunk is present it only
defines object 0, which does not have an object buffer that needs to be stored.
Bit 1 of the simplicity
profile can be used to promise that the <span class=cn>DEFI</span> chunk
is not present.

<p>

<dt><strong>BASI, BACK, MAGN, DISC, PAST</strong>

<dd>Must be fully supported.  Bit 2 of the simplicity profile can be used to
promise that the <span class=cn>BASI</span>, <span class=cn>DISC</span>, and <span class=cn>PAST</span> chunks are
not present, and that if the <span class=cn>BACK</span> chunk is present it does not
define a background image.  Bit 1 can be used to promise that
the <span class=cn>MAGN</span> chunk is not present.

<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>MOVE, CLIP, SHOW</strong>

<dd>Must be fully supported.  Bit 2 of the simplicity profile can be
used to promise that none of these chunks are present, and bit 9 of
the simplicity profile can be used to promise that the <span class=cn>SHOW</span>
chunk is not present.

<p>

<dt><strong>SAVE and SEEK</strong>

<dd>Partial support is required: All existing objects must be marked
"frozen" when the <span class=cn>SAVE</span> chunk is processed, so that
unneeded objects can be discarded when the <span class=cn>SEEK</span> chunk or an empty
<span class=cn>DISC</span> chunk is processed.  The <span class=cn>SEEK</span> chunk must be
processed as if it were an empty <span class=cn>DISC</span> chunk, as a minimum.
Chunk information need only be "saved" and "restored"
when the viewer
is able to skip or jump to random <span class=cn>SEEK</span> chunk locations from the
interior of a segment, such as when recovering from a corrupted datastream
or from a segment containing an unknown critical chunk, or when escaping
from a deterministic loop in response to a user request.  The
optional index can be ignored.  Slide-show controllers may wish to
support <span class=cn>SAVE</span> and <span class=cn>SEEK</span> fully.  Bit 2 of the simplicity
profile can be used to promise that the <span class=cn>SAVE</span> and <span class=cn>SEEK</span>
chunks can be ignored entirely (because there will be nothing to discard).

<p>

<dt><strong>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. Required 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-compliant decoders must support JNG, but
MNG-LC and MNG-VLC
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.
This can be done by processing the JNG as though a
viewable transparent <span class=cn>BASI</span> object had appeared:

<pre>
   BASI width height 1 4 0 0 0 0 00 00 00 00 1
   IEND
</pre>

<p>

</dl>

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

<p>MNG-compliant decoders are required to support Delta-PNG, but
MNG-LC and MNG-VLC decoders are not.  Bit 2 or 5 of the simplicity
profile can be used to promise that Delta-PNG datastreams are not
present.

<dl>

<dt><strong>DHDR, PROM, IHDR, IDAT, IPNG, PLTE, tRNS, IEND, PPLT</strong>

<dd>Must be fully supported if Delta-PNG is supported.

<p>

<dt><strong>JHDR, JDAT, JDAA, JSEP, IJNG</strong>

<dd>Must be fully supported if JNG is also supported outside of Delta-PNG
datastreams.  Bit 4 of the simplicity profile can be used to promise
that no JNG chunks are present.

<p>

<dt><strong>DROP, DBYK, ORDR</strong>

<dd>Can be recognized and ignored.  These are only of concern to MNG
editors and to MNG viewers that handle private chunks or chunks that can
be selected by keyword, such as <span class=cn>pCAL</span> and <span class=cn>iCCP</span>.  If you
decide to support such chunks, then you will also have to support these
three chunks.

<p>

<dt><strong>Ancillary chunks</strong>

<dd>Ancillary chunks appearing in Delta-PNG datastreams must be treated
in the same manner as if they appeared in a PNG or JNG datastream.  See
the recommendations, above.  Note that the PNG <span class=cn>tRNS</span> chunk must
be supported, despite its being an ancillary chunk in PNG.

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

<h3><a name="e-loops">10.4. Embedded images in LOOPs</a></h3>

<p>Embedded images should not be enclosed in loops unless absolutely
necessary.  It is better to store them ahead of time and then use
<span class=cn>SHOW</span> chunks inside the loops.  Otherwise, decoders will be
forced to repeatedly decode them.  See Examples 2, 8, 11, and 12,
<a href="#Examples">below (Chapter 18)</a>.

<h3><a name="e-index">10.5. Including optional index in SAVE chunk</a></h3>

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


<h3><a name="e-jng-int">10.6. Interleaving JDAT, JDAA, and IDAT chunks</a></h3>

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

<h3><a name="e-jng-jdaa">10.7. Use of the JDAA chunk</a></h3>

<p>It is recommended that the <span class=cn>JDAA</span> chunk be used only to convey
smoothly varying alpha channels and not to convey binary transparency
which is more precisely and efficiently conveyed in <span class=cn>IDAT</span> chunks.


<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="d-endl">11.2. ENDL without matching LOOP</a></h3>

<p>If a decoder reads an <span class=cn>ENDL</span> chunk for which the matching
<span class=cn>LOOP</span> chunk is missing, or has been skipped for some reason, any
active loops with a higher <code class=expr>nest_level</code> should be terminated,
and processing can resume after the next <span class=cn>SEEK</span> chunk.  Simple
viewers that do not process the <span class=cn>SAVE</span> chunk should abandon the
MNG datastream.  See <a href="#mng-ENDL">above</a>.

<h3><a name="compositing">11.3. Note on compositing</a></h3>

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

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

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

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

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

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

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

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

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

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

<h3><a name="retaining">11.4. Retaining object data</a></h3>

<p>The decoder must retain information about each object (except for
objects with <code class=expr>object_id=0</code>) for possible redisplay with the
<span class=cn>SHOW</span> chunk or for possible use as the parent object for a
subsequent Delta-PNG datastream.

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

<ul>

<li>The set of object attributes (potential visibility, location, clipping
boundary data from the <span class=cn>DEFI</span>, <span class=cn>MOVE</span>, <span class=cn>CLIP</span>, and
<span class=cn>SHOW</span> chunks, and pointer to an object buffer).

<p>

<li>The pixel data and the values associated with other recognized PNG
chunks such as <span class=cn>PLTE</span> and <span class=cn>gAMA</span>, subject to the chunk
copying rules and the <span class=cn>DROP/DBYK</span> chunks.  If the object is
"abstract", the data can be stored in any convenient form.  If it is
"concrete", it must be stored in an object buffer in a manner that would
permit the complete restoration of the original PNG or JNG file or its
equivalent.

<p>

<li>The most recent values of <code class=expr>target_x</code> and
<code class=expr>target_y</code>, if the object was the destination of a
<span class=cn>PAST</span> chunk.

<p>

</ul>

<p>When the encoder knows that data in the object buffer will not be
needed later, it help decoders operate more efficiently by
using <code class=expr>object_id=0</code> or by using the <span class=cn>DISC</span> or the
<span class=cn>SEEK</span> chunk.  Abstract images rather than concrete objects
should be used if the encoder knows that the data will not later be used
as the parent object for a Delta-PNG.  If no object buffer in the entire
datastream will be needed later, the "stored object buffers" flag
can be set appropriately in the simplicity profile field of the <span class=cn>MHDR</span>
chunk.

<h3><a name="errors">11.5. 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
that do not implement the
<span class=cn>SAVE/SEEK</span> mechanism
should simply abandon the MNG datastream.
More capable MNG viewers should attempt to recover gracefully by
abandoning processing of the segment and searching for a <span class=cn>SEEK</span>
chunk.  If such errors occur before the <span class=cn>SAVE</span> chunk is reached,
the viewer should abandon the MNG datastream.

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

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

<h3><a name="interlacing">11.6. 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.7. 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 <span class=cn>PLTE</span> or <span class=cn>PPLT</span> is present in a Delta-PNG
datastream, the new palette is used in displaying the image defined by
the Delta-PNG; if no <span class=cn>IDAT</span> chunk is present and the image type
is PNG indexed-color, then the resulting image is displayed using the
old pixel samples as indices into the new palette, which provides a
"palette animation" capability.

<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, unless one image
is a subsequent Delta-PNG that has no <span class=cn>PLTE</span> chunk and has been
declared by the <span class=cn>DHDR</span> <code class=expr>object_id</code> field to depend on 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.
Encoders can supply
a top-level <span class=cn>sPLT</span> chunk with a suggested reduced global palette,
to help decoders build an appropriate palette when necessary.

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

<p>Viewers that can only display a single frame must display the first
frame that they encounter.
It is strongly recommended that such viewers
understand the <span class=cn>fPRI</span> chunk <a href="#mng-fPRI">above (Paragraph 4.5.2)</a>, 
which
will enable them to find and display the best representative frame, if
the encoder has identified one.

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

<p>MNG provides four
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>This is the only type of clipping available in MNG-VLC
datastreams.

<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,
and display the background image if one has
been defined,
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.
See <a href="#example8">Example 8</a>, 
which displays a
large background image once, and then, in each frame, only redisplays
the portion of the background surrounding the moving sprite.

<p>

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

<dd>The image clipping boundaries are defined in the
<span class=cn>DEFI</span> and <span class=cn>CLIP</span> chunks.
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, to achieve
effects such as scrolling, panning, or gradual exposure.

<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 or CLIP chunk)
   Top_cb   &lt;= y &lt; bottom_cb
</pre>

<p>

<dt><strong><span class=cn>PAST</span> clipping boundaries</strong>

<dd>One type of clipping performed in <span class=cn>PAST</span> gives a fourth type that has
no dependencies on the other types, since the object <span class=cn>CLIP</span> data
is ignored and the <span class=cn>PAST</span> chunk defines its own clipping boundaries
within the destination object.
The left and top of this type of clipping is also inclusive, and the
right and bottom are exclusive.

<p>

<dt><strong>Clipping to <span class=cn>PAST</span> destination object dimensions</strong>

<dd>A second type of clipping performed in <span class=cn>PAST</span> gives a fifth
type that also has no dependencies on the other types.  The result of all
<span class=cn>PAST</span> operations is clipped to fall within the dimensions of the
destination object.
The left and top of this type of clipping is also inclusive, and the
right and bottom are exclusive.  After this internal clipping is completed,
the destination object is clipped in the same manner as other objects
when it is displayed.

<p>

</dl>

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


<h3><a name="editors-save">12.1. Editing datastreams with optional index</a></h3>

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

<p>The <span class=cn>SAVE</span> chunk is not considered to be in any MNG segment,
so changing it has no effect on the copy-safe status of unknown chunks
in any other part of the MNG datastream.

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

<h3><a name="editors-loops">12.2. Handling LOOP and TERM chunks</a></h3>

<p>Editors that create a series of PNG or JNG datastreams from a MNG datastream
should check the termination condition of any <span class=cn>LOOP</span> chunks and execute
loops only <code class=expr>iteration_min</code> times.  The loop created by the <span class=cn>TERM</span>
chunk should be executed only once.


<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 and MNG-VLC)
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.


<h3><a name="Media-type">13.2. Internet media type</a></h3>

<p>When and if the MNG format becomes finalized, the
MNG authors intend to register <code class=expr>video/mng</code>
as the Internet Media Type for
MNG <span class=ref>[<a href="#RFC-2045">RFC-2045</a>]</span>,
<span class=ref>[<a href="#RFC-2048">RFC-2048</a>]</span>.

At the date of this document, the media
type registration process had not been started.  It is recommended
that implementations also recognize the interim media type
<code class=expr>video/x-mng</code>.

<p>Although we define a standalone JNG format, we recommend that such
files be used only temporarily while compiling or disassembling MNG
datastreams.  We may at some future time register an Internet Media
Type for JNG files.  Until then, the interim media type
<code class=expr>image/x-jng</code> can be used.

<h3><a name="EBNF">13.3. EBNF Grammar for MNG, PNG, and JNG</a></h3>

<p>An Extended Backus-Naur Form (EBNF) description of the chunk ordering
in MNG, PNG, and JNG is being developed.  The
current draft, together with some supporting software, is available at
<span class=url><a href="ftp://swrinde.nde.swri.edu/pub/mng/documents/ebnf/"> ftp://swrinde.nde.swri.edu/pub/mng/documents/ebnf/</a></span>.

<h3><a name="URL">13.4. Uniform Resource Identifier (URI)</a></h3>

<p>Segments, subframes, and objects are externally accessible via named
<span class=cn>SEEK</span>, <span class=cn>eXPI</span>, and <span class=cn>FRAM</span> chunk names.  They can be
referred to by URI, as in

<pre>
   SRC=file.mng#segment_name
   SRC=file.mng#subframe_name
   SRC=file.mng#snapshot_name
   SRC=file.mng?segment_name#segment_name
   SRC=file.mng?snapshot_name#snapshot_name
</pre>

<p>When the URI specializer ("#" or "?")
is "#", and the fragment
identifier (the string following the specializer) is the name of a
segment, i.e., a named <span class=cn>SEEK</span> chunk, the viewer should display
the sequence from the beginning of the named segment up to the next
segment.  When it refers to a subframe or an image, i.e., a named
<span class=cn>FRAM</span> or <span class=cn>eXPI</span> chunk, it should display the single frame
(as it exists when the next <span class=cn>FRAM</span> chunk is encountered) or image
that is identified by the fragment identifier.
The client can find the needed segment quickly if the <span class=cn>SAVE</span>
chunk is present and contains the optional index.

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

<ul>

<li>all chunks prior to the <span class=cn>SAVE</span> chunk,

<li>an empty <span class=cn>SAVE</span> chunk,

<li>the <span class=cn>SEEK</span> chunk for the segment being returned,

<li>all chunks in the segment, and

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

</ul>

<p>If no <span class=cn>SAVE</span> chunk is present, the server must simply return
the entire MNG datastream.  Servers that are unwilling to parse the MNG
datastream and are unconcerned about bandwidth can return the entire MNG
datastream even when the SAVE chunk is present.  Authors should defend
against this behavior by including both a query and a fragment in the
URI even when a segment is being requested.

<p>The client can process this as a complete MNG datastream, either
displaying the entire segment, if no fragment identifier is present, or
extracting the segment, frame or image that is named in a fragment
identifier and displaying it, if a fragment identifier is present
(a fragment identifier must be present if a frame or image is being
requested).  To "extract a frame" means to decode
the returned datastream through the end of the frame that contains the
named subframe and to display the result as a single still image.  If
the layers of the named subframe do not cover the entire frame, pixels
from the background and from earlier subframes must be included in the
resulting composition.

<p>A part of the MNG datastream can also be requested by timecode, as in

<pre>
   SRC=file.mng#clock(10s-20s)
   SRC=file.mng#clock(0:00-0:15)
   SRC=file.mng?clock(0:00-0:15)#clock(0:00-0:15)
</pre>

<p>or by frame number, as in

<pre>
   SRC=file.mng#frame(10)
   SRC=file.mng#frames(30-60)
   SRC=file.mng?frames(30-60)#frames(30-60)
</pre>

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

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

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

<ul>

<li>the chunks preceding the <span class=cn>SAVE</span> chunk,

<li>the <span class=cn>SAVE</span> chunk itself with an optional index that gives
the starting time and starting frame number of the first <span class=cn>SEEK</span> chunk
that is sent, and

<li>the one or more consecutive sets of segments, with their
<span class=cn>SEEK</span> chunks, that contain the sequence beginning and ending at
the requested times, or frame numbers, at the proper framing rate.

</ul>

<p>If the server does not send the entire MNG datastream, and the first
segment after the <span class=cn>SAVE</span> chunk is not sent but a later segment
<em>is</em> sent, the optional index
must be written even if it does not exist in the source file.  The index
must contain at least one "type 0" entry that gives the nominal
start
time and frame number for the first segment that is sent after the
<span class=cn>SAVE</span> chunk.  The offset field can be set to zero and the segment
name can be omitted.

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

<p>MNG datastreams should not contain segment, subframe, or image
names that begin with the case-insensitive strings
"CLOCK(", "FRAME(", or "FRAMES(",
which are reserved for use in URI queries and
fragments (see Uniform Resource Identifier <a href="#URL">below</a>).

<p>See <span class=ref>[<a href="#RFC-2396">RFC-2396</a>]</span>
and the W3C SMIL recommendation
at <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.


<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>Changed the meaning of the <span class=cn>FRAM</span> timeout.  Instead of being
added to the interframe delay, it is a minimum or maximum value to which
the decoder can change the interframe delay.  This was approved by
consensus on December 23, 2000.

<li>Added a section on Extension and Registration.

<li>Minor editorial and formatting 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.


<li>Revised definition of magnification methods 3 and 4 and added method
5 for the <span class=cn>MAGN</span> chunk.
This was approved by consensus on November 11, 2000.

<li>Clarified that "saved" data need only be restored when a
decoder makes random access to a seek point after jumping from the interior
of a segment.
This was approved by consensus on October 28, 2000.

<li>Clarified that the background image must be potentially visible to
be displayed.
This was approved by consensus on October 28, 2000.

<li>When the sample depth in a delta-PNG is larger than the sample depth
of the parent object, right-shifting of the delta is specified.
This was approved by consensus on November 10, 2000.

<li>Clarified that the <span class=cn>MAGN</span> chunk can generate one or more
layers, when the existing objects being magnified are potentially
visible.

<li>Added a security recommendation to check for user input after each
loop iteration as well as after each complete frame, to avoid being stuck
in an infinite loop of subframes with zero interframe delay.

</ul>

<li>Clarifications
<ul>

<li>Added the <span class=cn>MAGN</span> and <span class=cn>CLON</span> chunks to the list of chunks
across which MNG editors cannot move unknown ancillary chunks.

<li>Added "foreground layer" terminology.

<li>Editorial changes to the FRAM chunk specification to clarify when
interframe delays and synchronization points occur.

<li>Added paragraph about object 0 in the introductory section on objects.

<li>Clarified that object attributes for object 0 become undefined
when a <span class=cn>SEEK</span> chunk appears, if they are different from the
default values at the end of any segment.  Made the treatment of magnification
data for object 0 consistent with the treatment of the other attributes.

<li>Removed statement in the <span class=cn>FRAM</span> chunk specification that a
subframe ends when a <span class=cn>SEEK</span> chunk is encountered.  This is inconsistent
with statements elsewhere in the specification that the <span class=cn>SEEK</span> chunk
can be treated as if it were an empty <span class=cn>DISC</span> chunk.

<li>Clarified that inserting a background layer ahead of a segment is only
necessary when the decoder jumps to a seek point from the interior of a
segment.

<li>Clarified that the empty <span class=cn>DISC</span> chunk only discards nonzero objects.


</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>Mentioned a fifth type of clipping: clipping the result of <span class=cn>PAST</span>
operations to the dimensions of the <span class=cn>PAST</span> destination object.


<li>Disallowed the <span class=cn>JSEP</span> chunk when <code class=expr>image_sample_depth != 20</code>


<li>Clarified some wording in the <span class=cn>SEEK</span> chunk specification, and
added a cross reference to the existing requirement to insert a background
layer when making random access to a segment.

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

<li>Clarified treatment of the alpha sample in the <span class=cn>BASI</span> chunk
when the color type is 0, 2, or 3, and clarified that the <span class=cn>BASI</span>
chunk inherits default <span class=cn>DEFI</span> values if no <span class=cn>DEFI</span> chunk
is present.

<li>Changed "repeat count" to "iteration count" in
the <span class=cn>LOOP</span> chunk specification, and "times to
repeat" to "times to execute" in the description of
the "iteration_max" field in the TERM chunk, and
added a statement about representing infinity.

<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.
<li>A new example was added.
</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.
This makes it possible to <span class=cn>MOVE</span> or <span class=cn>CLIP</span> objects whose
object buffer does not yet exist.

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

<li>Any attempt to display a nonviewable object must be ignored and not
treated as an error.  The restriction that a nonviewable object must
not be made potentially visible was removed.

<li>Any nonviewable object included in the list of
objects to be processed by the <span class=cn>SHOW</span> chunk must be ignored and
not treated as an error (in MNG-0.95 and earlier, the <span class=cn>SHOW</span> chunk
would change its visibility but not display it).

<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>The <code class=expr>termination_condition</code> byte of the <span class=cn>LOOP</span> chunk was
extended to include a "cacheable" bit.

<li>Revised wording of paragraph 3.3 to describe "viewable
objects" as well as "viewable object buffers".

<li>Clarified that an image is displayed immediately if it is the
subject of a <span class=cn>CLON</span> chunk with <span class=expr>do_not_show=0</span>.

<li>Revised Examples 6, 7, 9, 13 and 14.

<li>Changed "<code class=expr>JDAT_sample_depth</code>" to
"<code class=expr>image_sample_depth</code>" and
"<code class=expr>IDAT_sample_depth</code>" to
"<code class=expr>alpha_sample_depth</code>", etc.

<li>Started a Rationale section.

<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="I-10918-1">ISO/IEC-10918-1</a>]</strong>

<dd>International Organization for Standardization and International
Electrotechnical Commission,
"Digital Compression and Coding of Continuous-tone Still Images,
Part 1: Requirements and guidelines" ISO/IEC IS 10918-1, ITU-T T.81.<br>
<p>See also
Pennebaker, William B., and  Joan L. Mitchell,
"JPEG : Still Image Data Compression Standard"
Van Nostrand Reinhold, ISBN:0442012721, September&nbsp;1992

<p>

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

<dd>C-Cube Microsystems,
"JPEG File Interchange Format, Version 1.02",
September&nbsp;1992.

<p>

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

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

<dd>Berners-Lee, T., R. Fielding, U. C. Irvine, and L. Masinter,
"Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, MIT/LCS,
Xerox Corporation,
University of Minnesota, August&nbsp;1998.<br>
<span class=url><a href="ftp://ftp.isi.edu/in-notes/rfc2396.txt"> ftp://ftp.isi.edu/in-notes/rfc2396.txt</a></span>

<p>

</dl>

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

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

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

<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
        583       # Simplicity profile
   DEFI 1 0 0 IHDR ... IDAT ... IEND # Four PNG datastreams
   DEFI 2 0 0 IHDR ... IDAT ... IEND # are read and stored
   DEFI 3 0 0 IHDR ... IDAT ... IEND # and are displayed as
   DEFI 4 0 0 IHDR ... IDAT ... IEND # they are read.
   SAVE  # This is needed so we can place TERM before SEEK.
   TERM 3 0 120 10   # When done, repeat from TERM 10 times.
   SEEK
   SHOW
   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="example4">18.4. Example 4: A more storage-efficient slideshow</a></h3>

<p>This slideshow gives exactly the same output as Example 3, but the
storage in the datastream is more efficient (the IDAT chunks will be
smaller) while the memory requirements in the decoder are larger.  Image
ID 1 is used to store the ornate logos and frame design that appear on
every slide.  The DHDR-IEND datastreams only contain deltas due to the
text and other information that is unique to each slide.

<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 720 468     # Width and height.
        1 6 5 5 975 # 1 tick per second, complex, no JNG.
   DEFI 1 1 1       # Define image 1, invisible, concrete.
   IHDR ...  IDAT ...  IEND
   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"
   CLON 1 2 DHDR 2 ...  IDAT ...  IEND SHOW 2
   SEEK "Outline"
   CLON 1 2 DHDR 2 ...  IDAT ...  IEND SHOW 2
   SEEK "Our Vision"
   CLON 1 2 DHDR 2 ...  IDAT ...  IEND SHOW 2
   SEEK "Our Mission"
   CLON 1 2 DHDR 2 ...  IDAT ...  IEND SHOW 2
   SEEK "Downsizing Plans"
   CLON 1 2 DHDR 2 ...  IDAT ...  IEND SHOW 2
   MEND
</pre>


<h3><a name="example5">18.5. Example 5: A simple movie</a></h3>

<p>This movie is still fairly simple, but it capitalizes on
frame-to-frame similarities by use of Delta-PNG datastreams, and also
demonstrates the use of the <span class=cn>fPRI</span> chunk.

<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 720 468   # Width and height.
        30 6 5 15 # 30 ticks per second.
        975       # Delta-PNG, transparent, complex
   tEXtTitle\0Sample Movie
   fPRI 0 128     # Default frame priority is "medium".
   FRAM 1 0  2 0 0 0  3 # Set interframe_delay to 1/10 sec.
   DEFI 1 0 1       # Set default image to 1 (concrete).
   SAVE
   SEEK "start"
   
   IHDR 720 468 8 2 0 0 0   # DEFI 1 is implied.
   IDAT ...
   IEND
   
   DHDR 1 1 1 20 30 100 220   # A PNG-delta frame.
   IDAT ...       # The IDAT gives the 20x30 block
   IEND           # of deltas.
   
   DHDR 1 1 1 20 30 102 222   # Another PNG-delta frame.
   IDAT ...       # This time the deltas are in a 20 x 30
   IEND           # block at a slightly different location.
   
   SEEK "frame 3"  # OK to restart here because a
                   # complete PNG frame follows.
   fPRI 0 255      # This is the representative frame that
   IHDR 720 468 ...# will be displayed by single-frame
   IDAT ...        # viewers.
   IEND
   fPRI 0 128      # Return to medium frame priority.
   
   DHDR 1 1 1 720 468 0 0     # Another PNG-delta frame.
   IDAT ...   # The entire 720x468 rectangle changes
   IEND       # this time.
   
   SEEK "end"
   MEND            # End of MNG datastream.
</pre>


<h3><a name="example6">18.6. Example 6: A single composite frame</a></h3>

<p>Here is an example single-composite-frame MNG, with thumbnails, which
takes a grayscale image and draws it side-by-side with a false-color
version of the same image:

<pre>
   \212 M N G \r \n ^z \n # MNG signature.
   MHDR 1024 512 0 # Width, height, ticks per second
        4 1 0 1007 # Layers, frames, time, simplicity
   BACK 16448 16448 52800 1 # Must use sky blue background.
   
   PLTE ...     # Define global PLTE
   gAMA 50000   # Define global gAMA
   DEFI 1 1     # Define invisible abstract thumbnail image.
   IHDR 64 64 4 3 0 0 0 PLTE IDAT ... IEND # use global PLTE
   eXPI 1 "thumbnail 1"
   DEFI 1 1       # Also define a larger thumbnail.
   IHDR 96 96 4 3 0 0 0 PLTE IDAT ... IEND # use global PLTE
   eXPI 1 "thumbnail 2"
   DISC           # Discard the thumbnail image.
   
   FRAM 4 "Two views of the data"
   DEFI 1 0 1 6 6     # Define first (bottom) image.
   IHDR 500 500 16 0 .. # A 16-bit graylevel image.
   IDAT ...
   IEND                 # End of image.
   
   CLON 1 2 0 1 0 0 518 6 # Make full invisible concrete clone.
   SHOW 2 2 3           #  Mark it for immediate display during
                        #  the upcoming delta-PNG operation.
   DHDR 2 1 7           #  Modify it (no change to pixels).
   ORDR faLT 2          #  Establish chunk placement.
   gAMA 100000   # Local gamma value is 100000 (gamma=1.0).
   tEXtComment\0The faLT chunk is described in ftp://swrinde...
   faLT ...             # Apply pseudocolor to parent image.
   IEND                 # End of image.
   DEFI 3 0 0 900 400   # Overlay near lower right-hand corner.
   IHDR 101 101 2 3 ...
   PLTE ...             # Use a local PLTE and global gAMA.
   tRNS ...             # It is transparent (maybe a logo).
   IDAT ...             # Note that the color type can differ
   IDAT ...             # from that of the other images.
   IEND                 # End of image.
   
   MEND                 # End of MNG datastream.
</pre>


<h3><a name="example7">18.7. Example 7: A movie with sprites</a></h3>

<p>Here is another movie, illustrating the use of Delta-PNG datastreams
as sprites:

<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 512 512 30 0 0 0 1007 # Start of MNG datastream.
   FRAM 2 "frame 1" 0  2 0 0 0  3 # First frame
                    # sets interframe_delay=3 ticks.
   DEFI 1           # Define image 1 (abstract, LOCA 0 0).
   IHDR 512 512 ... # It is a full-display PNG image.
   etc              # Chunks according to PNG spec.
   IEND             # SHOW 1 is implied by DEFI 1.
   DEFI 2 0 1 300 200 # Define image 2, concrete.
   IHDR 32 32 ...   # It is a small PNG.
   gAMA 50000
   IDAT ...
   IEND
   FRAM 0 "frame 2"   # Start new frame.
                    # New location for image 1 is still 0,0.
   SHOW 1           # Display image 1 from previous frame.
   MOVE 2 2 1 10 5  # New (delta) location for image 2.
   SHOW 2           # Retrieve image 2 from previous frame,
   CLON 2 3 0 1 0   # make a full clone of it as image 3.
        0 400 500   # Location for image 3.
   DHDR 3 1 7 0 0 0 0 # Modify image 3 (no change to pixels).
   tRNS ...         # Make it semitransparent.
   IEND             # SHOW 3 is implied by CLON visibility.
   FRAM 0 "frame 3" # Next frame (repeat this FRAM-SHOW 1 3
                    #   sequence with different locations to
                    #   move the images around).
                    # New location for image 1 is still 0,0.
   MOVE 2 2 1 10 5  # New (delta) location for image 2.
   MOVE 3 3 1 5 -2  # New location for image 3.
   SHOW 1 3         # Show images 1 through 3.
   FRAM 0 "frame 4" # Another frame.
   etc.
   FRAM 0 "frame 99"
   etc.             # More frames.
   MEND             # End of MNG datastream.
</pre>


<h3><a name="example8">18.8. Example 8: A movie with an animated sprite</a></h3>

<p>This movie illustrates the use of several abstract images with
Show_mode=6 to describe an animated sprite, and the PAST chunk to turn
it around.  The sprite runs back and forth across the background ten
times.  The FRAM clipping boundaries restrict the screen updates to the
small region that changes, with a little "wiggle room" to make sure the
disturbed part of the background gets updated.

<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 512 512 30 0 0 0 975 # Start of MNG datastream.
   FRAM 2 "frame 1" 0  2 0 0 0  3 # First frame.
   DEFI 1 IHDR 512 512 ... # Background PNG image.
   etc ... IEND     # Chunks according to PNG spec.
   
   DEFI 10 1 0 x0 y0 # Static part of sprite.
   IHDR 64 64 ...  IDAT ...  IEND
   DEFI 11 1 0 x0 y1 # View 1 of animated part.
   IHDR 64 32 ...  IDAT ...  IEND # (y1=y0+64)
   DEFI 12 1 0 x0 y1 # View 2 of animated part.
   IHDR 64 32 ...  IDAT ...  IEND
   DEFI 13 1 0 x0 y1 # View 3 of animated part.
   IHDR 64 32 ...  IDAT ...  IEND
   
   FRAM 0  0  0 0 2 0  0 x0-dx x0+64+dx y0-dy y1+32+dy
   LOOP 0 0 10
   LOOP 1 0 150
   FRAM 0 "left-to-right" 0 0 2 0 1 dx dx dy dy
   MOVE 10 13 1 dx dy # Move animated icon {dx, dy}.
   SHOW  1 SHOW 10    # Show background and static part.
   SHOW 11 13 6       # Select the next view of the
   ENDL 1             # animated part and show it.
   
   FRAM SHOW 1
   PAST 10  0 0 0  10  1 4  0 0 0  0 0 64 64
   PAST 11  0 0 0  11  1 4  0 0 0  0 0 64 32
   PAST 12  0 0 0  12  1 4  0 0 0  0 0 64 32
   PAST 13  0 0 0  13  1 4  0 0 0  0 0 64 32
   LOOP 1 0 150
   FRAM 0 "right-to-left" 0 0 2 0 1 -dx -dx -dy -dy
   MOVE 10 13 1 -dx -dy # Move animated icon {-dx, -dy}.
   SHOW  1 SHOW 10    # Show background and static part.
   SHOW 11 13 6       # Select the next view of the
   ENDL 1             # animated part and show it.
   ENDL 0 FRAM
   MEND
</pre>


<h3><a name="example9">18.9. Example 9: "Fading in" a transparent image</a></h3>

<p>The opaque parts of this image will "fade in" gradually.  This
example also illustrates the use of the <span class=cn>PPLT</span> and <span class=cn>fPRI</span>
chunks.

<pre>
   \212 M N G \r \n ^z \n   # MNG signature.
   MHDR 64 64 30 0 0 0 1007 # Width, height, ticklength, ....
   BACK 52800 52800 52800   # "Browser gray" default background.
   
   FRAM 3 0  2 0 0 0  3 #  Set interframe_delay=3 ticks.  Use
               # framing mode 3 so background gets restored.
   DEFI 1 1 1  # Invisible and "concrete".
   IHDR ...    # PNG header.
   PLTE ...
   tRNS 0      # Entries are zero for the transparent (0)
               # color and 255 for the nontransparent ones.
   IDAT ...
   IEND
   fPRI 0 0    # Give the fade-in sequence a low priority.
   CLON 1 2    # Make a working concrete copy of the image
               # that will be modified during the low-priority
               # part of the datastream.  It is a full clone.
   DHDR 2 1 7  # No change to pixel data.
   tRNS 0 0 0 0 0 0 ...  # Make all pixels fully transparent.
   IEND
   SHOW 2 2 3  # Make it visible but do not show it now.
   
   LOOP 0 0 15
   DHDR 2 1 7  # A Delta-PNG.
               # Delta-type 7 means no change to pixels.
   PPLT 1 10 3 16 16 16 16 ... # Increment all alphas except
   IEND                        # for entry 0 by 16.
   SHOW 2
   ENDL 0      # Nontransparent pixel alpha=15, 31, ... 240.
   
   DISC 2      # Discard the working copy.
   fPRI 0 255  # Give the final frame the highest value
   FRAM 0 0  1 0 0 0  60 # Hold the last frame for at least
     # 60 ticks (2 sec).  Applications might show it longer.
   SHOW 1      # This copy still has alpha=255 for the
               # opaque pixels and alpha=0 for the others.
   MEND        # End of MNG.
</pre>


<h3><a name="example10">18.10. Example 10: Storing three-dimensional images</a></h3>

<p>In this example, we store a series of twenty-four 150 x 150 x 150
blocks of eight-bit voxels.  Each block is stored as a composite frame with
the first image being a PNG whose pixels represent the top layer of
voxels, which is followed by 149 Delta-PNG images representing the rest
of the layers of voxels.  Only one image is defined, through which the
parent image is passed along from PNG to Delta-PNG to Delta-PNG.  This
example also illustrates the use of unregistered ancillary chunks that
describe the x, y, and z scales and pixel calibration.

<pre>
   \212 M N G \r \n ^z \n # MNG signature.
   MHDR 150 150 1   # Width, height, ticklength.
        0 0 0 615   # Layers, frames, time, simplicity.
   tEXtTitle\0Weather modeling results
   tEXtComment\0The xxSC, yySC, zzSC, and ttSC chunks
    in this file are written according to the Proposed
    Chunk Specifications version 19970203 and Sci-Vis
    Chunks Specification version 19970203 available at
    ftp://swrinde.nde.swri.edu/pub/png-group/documents/
   xxSC kch\0 [sig\0] kilometers\0 0\0 150
   yySC kch\0 [sig\0] kilometers\0 0\0 150
   zzSC kch\0 [sig\0] Height (kilometers)\0 0\0 15
   ttSC kch\0 [sig\0] Time (hours)\0 0\0 24
   pCAL kch\0 0 255 0 2 Degrees Celsius\0 0\0 45
   DEFI 1 0 1       # All images will have image = 1
   SAVE             # and be visible and "concrete".
   SEEK
   FRAM 2      # Initial composite image.
   IHDR 150 150 16  # Width, height, bit depth for top layer.
        0 0 0 0     # Color, comp, filter, interlace.
   IDAT ...
   IEND             # No DEFI chunk, so it is image 0.
   DHDR 1 1 0       # Source=0, PNG, pixel addition,
        150 150 0 0 # Block is entire image.
   IDAT ...     # IHDR is omitted; everything matches top.
   IEND         # IEND is also omitted.
   etc.         # Repeat DHDR through IEND 148 more times.
   SEEK
   FRAM         # End of first block.
   etc.         # Repeat FRAM through SEEK 19 more times.
   SEEK
   MEND         # End of MNG.
</pre>


<h3><a name="example11">18.11. Example 11: Tiling</a></h3>

<p>Here is another composite frame, illustrating the use of the LOOP
syntax to tile a large (1024 by 768) image area with a small (128 by 64)
image.

<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 1024 768 0 # Start of MNG datastream.
        98 1 0 975 # Layers, frames, time, simplicity.
   FRAM 2
   DEFI 1 1 0 0 -64 # Set up an offscreen "abstract" copy
   IHDR 128 64 ... PLTE ... IDAT ... IEND  # of the tile.
   LOOP 0 0 12   # Y loop -- make 12 rows of tiles.
   MOVE 1 1 1 0 64 # Move the first copy down 64 rows.
   SHOW 1        # Display it.
   CLON 1 2 1    # Create a partial clone of the tile.
   LOOP 1 0 7    # X loop - 7 additional columns.
   MOVE 2 2 1 0 128 # Move it to the right 128 columns.
   SHOW 2        # Use the second copy.
   ENDL 1
   ENDL 0
   MEND
</pre>

<p>Here is a better approach, which creates a reusable tiled image by
means of the <span class=cn>PAST</span> chunk.

<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 1024 768 0 # Start of MNG datastream.
        3 1 0 975  # Layers, frames, time, simplicity.
   DEFI 1 1 # Set up an offscreen "abstract" copy
   IHDR 128 64 ...  PLTE ... IDAT ... IEND  # of the tile.
   DEFI 2        # The abstract, visible, viewable image to
   BASI 1024 768 8 2 0 0 0 0 0 0 0 1 #  be tiled.  Initially
   IEND          # all pixels are zero.
   PAST 2 0 0 0  # Destination and target location.
     # src mod orient  offset        clipping
        1   0    8     0   0 512   0 0 1024 0 768
     #  End of PAST chunk data.
   MEND
</pre>


<h3><a name="example12">18.12. Example 12: Scrolling</a></h3>

<p>Here is an example of scrolling a 3000-line-high image (perhaps an
image of some text, but could be anything) through a 256-line-high
window with an alpha-blended border.

<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 512 256 30   # Width, height, ticks per second
        6513 3257 3257 975 # Layers, frames, time, simplicity.
   BACK 50000 50000 50000 0 #  advisory gray background
   DEFI 1 1 0 0 256  # Define image 1 but do not display now.
                     # Initially it is offscreen, just
                     # below the 512 by 256 window.
   IHDR 512 3000 1 0 ... # A PNG datastream containing the
   PLTE ...          # text (or whatever) to be scrolled.
   IDAT ...
   IEND
   
   DEFI 2
   IHDR 512 256 8 6 ... # A PNG datastream containing some kind
   PLTE ...             # of alpha-blended border that is
   tRNS ...             # transparent in the center.
   IDAT ...
   IEND
   
   LOOP 0 0 3256
   MOVE 1 1 1 0 -1 # Jack image 1 up one scanline, 3256 times.
              # It ends up just above the 512 by 256 window.
              # The border does not move.
   FRAM 1  0  2 0 0 0  0 # Interframe_delay = 0 ticks.
              # We use Framing_mode=1 to avoid unnecessary
              # screen clearing between frames.
   SHOW 1     # Show first image and continue without delay.
   FRAM 1  0  2 0 0 0  1 # Interframe_delay = 1 tick.
   SHOW 2     # Composite second image over first, wait 1 tick.
   ENDL 0
   MEND
</pre>

<p>Alternatively, we can declare the scrolling object to be the
background and use framing-mode 3:

<pre>
                   (Same as above down to the LOOP chunk.)
   BACK 50000 50000 50000 2 1 #  Advisory gray background.
                              #  Mandatory image background.
   FRAM 3  0  2 0 0 0  1 # Interframe_delay = 1 tick.
   LOOP 0 0 3256
   MOVE 1 1 1 0 -1 # Jack background up one scanline, 3256 times.
   SHOW 2     # Composite the second image over it, wait 1 tick.
   ENDL 0
   MEND
</pre>



<h3><a name="example13">18.13. Example 13: Cycling animations</a></h3>

<p>This demonstrates the use of the <span class=cn>SHOW</span> chunk with
<code class=expr>show_mode=6</code> to create animations that cycle through
a series of ten objects.

<p>This will cycle through the ten objects in the forward direction,
100 times, unless terminated sooner by the user or the decoder.
<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 400 88 30  # Width, height, ticks per second
        11 1001 1001 583 # Layers, frames, time, simplicity.
   DEFI 1 ...
   etc.         # Define 10 objects.
   DEFI 10 ...
   LOOP 0 100 6 # 100 iterations, user-discretion, cacheable
   SHOW 1 10 6
   ENDL 0
   MEND
</pre>

<p>This will cycle through the ten objects, back and forth,
50 times, unless terminated sooner by the user or the decoder.
<pre>
   \212 M N G \r \n ^z \n  # MNG signature.
   MHDR 400 88 6  # Width, height, ticks per second
        11 901 901 583 # Layers, frames, time, simplicity.
   DEFI 1 ...
   etc.         # Define 10 objects.
   DEFI 10 ...
   CLON 11 9 1  # Make partial clones of objects 2-9
   etc.         # in reverse order, as objects 11-18.
   CLON 18 2 1
   
   LOOP 0 50 6 # 50 iterations, user-discretion, cacheable
   SHOW 1 18 6
   ENDL 0
   MEND
</pre>


<h3><a name="example14">18.14. Example 14: Converting a GIF animation</a></h3>

<p>Outline of a program to convert GIF animations to MNG format:

<pre>
   begin
       write "MHDR" chunk
       saved_images := 0; Interframe_delay := 0
       First_frame := TRUE
       if(loops&gt;1) "write TERM 3 0 0 loops" chunk
       write "BACK" chunk
       for subimage in gif89a file do
          if(interframe_delay != gif_duration) then
            interframe_delay := gif_duration
            write "FRAM 4 0 2 2 0 2 0 interframe_delay 0" chunk
            First_frame := FALSE
          else if(First_frame == TRUE)then
            write "FRAM 4" chunk
            First_frame := FALSE
          else
            write "FRAM" chunk
          endif
          if(X_loc == 0 AND Y_loc == 0) then
             write "DEFI saved_images 1 1" chunk
          else
             write "DEFI saved_images 1 1 X_loc Y_loc" chunk
          write "&lt;image&gt;"
          write "SHOW 0 saved_images" chunk
          if (gif_disposal_method == 0
             OR gif_disposal_method == 2) then
             /* (undefined or restore background) */
                write "DISC" chunk
                saved_images := 0
          else if (gif_disposal_method == 1) then
             /* (keep) */
             saved_images := saved_images + 1
          else if (gif_disposal_method == 3) then
             /* (restore previous) */
             write "DISC saved_images" chunk
          endif
       endfor
       write "FRAM" and "MEND" chunks
   end
</pre>

<p>Where "&lt;image&gt;" represents a PNG or Delta-PNG containing a GIF
frame 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="x15">18.15. 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.16. 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.17. 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>
<p>This is similar, but it uses Delta PNG datastreams to create modified
versions by replacing the palette.  This can be more storage-efficient,
but requires a full MNG decoder because of the presence of Delta PNG
datastreams.
<pre>
   MHDR 96 96 1 6 5 5 1007 # Profile 1007 is MNG without JNG
   sRGB 2                  # Global sRGB
   PLTE ...                # Global PLTE
   tRNS 0                  # Global tRNS
   eXPI 0 "thumbnail"
   IHDR 32 32 ... PLTE IDAT ... IEND
   SAVE
   &lt;index&gt;
   SEEK "left arrows"
   DEFI 1
   IHDR 96 96 ... PLTE IDAT ... IEND
   eXPI 1 "red left arrow"
   DHDR 1 1 7 PPLT ... IEND  # Change some palette entries.
   eXPI 1 "blue left arrow"
   SEEK "right arrows"
   IHDR 96 96 ... PLTE IDAT ... IEND
   eXPI 1 "red right arrow"
   DHDR 1 1 7 PPLT ... IEND
   eXPI 1 "blue right arrow"
   MEND
</pre>


<h3><a name="x18">18.18. 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.19. 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.

<li>X Window System is a trademark of the Massachusetts Institute of
Technology.

</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 Specification.</em></h2>

</body>

</html>
 
 
Close
loading
Please Confirm
Close