It is a proposal, and the format is subject to change.
Comments on this document can be sent to the PNG specification maintainers at one of the following addresses:
Distribution of this memo is unlimited.At present, the latest version of this document is available on the World Wide Web from
<URL:ftp://swrinde.nde.swri.edu/pub/mng/documents/>.
The MNG format provides a mechanism for reusing image data without having to retransmit it. Multiple images can be composed into a "frame" and a group of images can be used as an animated "sprite" that moves from one location to another in subsequent frames. "Palette animations" are also possible.
A MNG frame normally contains a two-dimensional image or a two-dimensional layout of smaller images. It could also contain three-dimensional "voxel" data arranged as a series of two-dimensional planes (or tomographic slices), each plane being represented by a PNG or Delta-PNG datastream.
A Delta-PNG datastream defines an image in terms of a parent PNG or Delta-PNG image and the differences from that image. This has been demonstrated to provide a much more compact way of representing subsequent images than using a complete PNG datastream for each.
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 valid PNG or JNG datastream is also a valid MNG datastream.
This document includes examples that demonstrate various capabilities of MNG including simple movies, composite frames, loops, fades, tiling, scrolling, storage of voxel data, and converting GIF animations to MNG format.
Note: This specification depends on the PNG (Portable Network Graphics) specification [PNG]. The PNG specification is available at the PNG home page,
<URL:http://www.cdrom.com/pub/png/>A MNG datastream describes a sequence of single frames, each of which can be composed of zero or more embedded images or directives to show previously defined images.
A typical MNG datastream consists of:
Images can be "concrete" or "abstract". The distinction allows decoders to use more efficient ways of manipulating images when it is not necessary to retain the image data in its original form or equivalent in order to show it properly on the target display system.
MNG is pronounced "Ming."
When a MNG datastream is stored in a file, it is recommended that ".mng" be used as the file suffix. In network applications, the Media Type "video/x-mng" can be used. Registration of the media type "video/mng" might be pursued at some future date.
The first eight bytes of a MNG datastream are
138 77 78 71 13 10 26 10(decimal) which is similar to the PNG signature with "\212 M N G" instead of "\211 P N G" in bytes 0-3.
MNG does not yet accommodate sound or complex sequencing information,
but these capabilities might be added
at a later date, in a backwards-compatible manner. These issues are being
discussed in the mpng-list@dworkin.wustl.edu mailing list.
Chunk structure (length, name, data, CRC) and the chunk-naming system are identical to those defined in the PNG specification. As in PNG, all integers that require more than one byte must be in network byte order.
The chunk copying rules for MNG employ the same mechanism as PNG,
but with rules that are explained more fully in Chapter 7, below.
A MNG editor is not permitted to move unknown chunks across the
Note that decoders are not required to follow any decoding models described in this specification nor to follow the instructions in this specification, as long as they produce results identical to those that could be produced by a decoder that did use this model and did follow the instructions.
Each chunk of the MNG datastream or of any embedded object is an independent entity, i.e., no chunk is ever enclosed in the data segment of another chunk.
An independent PNG or JNG datastream, with a PNG or JNG signature, is also a valid MNG datastream that must be recognized and decoded by MNG-compliant decoders. This kind of MNG datastream will contain only a single embedded image.
Because the embedded objects making up a MNG are normally in PNG format, MNG shares the good features of PNG:
The words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119, and 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.
An image whose pixels have a hidden 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.
An image produced by applying an image delta to a parent object.
File gamma and chromaticity values, or an sRGB rendering intent, iCCP profile, or whatever is involved in mapping between RGB values and colors.
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.
A concrete object or image that appears in-line in a MNG datastream.
A layout of a background and zero or more images that is to be displayed as a still frame or as part of an animation. An animation would ideally appear to a perfect observer (with an inhumanly fast visual system) as a sequence of still frames.
The portion of the display surface whose pixels are inside the
frame clipping boundaries as defined by the
The amount of time a frame should be visible when an animation is played. In reality, it takes a non-zero amount of time to display a frame. No matter which moment is picked as the "start" of the frame, the frame duration measures the time to the "start" of the next frame.
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 MOVE and CLIP values would still be measured from this offscreen origin.
An object whose object attributes set and whose object buffer are not allowed to be discarded, replaced, or modified.
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.
Shorthand for "the object with the object attribute set pointed to by `object_id=N'".
An image or a nonviewable basis object. The object_id is an unsigned sixteen-bit number that serves as the identifier of a set of object attributes.
Properties of an object such as its existence, potential visibility, location, clipping boundaries, and a pointer to an object buffer. See Object attributes below.
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 Object buffers below.
An object to which a delta is applied.
The first segment, when there is more than one segment.
Any segment other than the first (also the first segment, when there is only one).
A part of a MNG datastream starting with the
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.
A stored object that is capable of being made visible. An image is
viewable, while some objects resulting from decoding
a
Actually drawn on a display. If an object is visible, a person looking at the display can see it.
An "image" is a viewable object.
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".
All objects are initially "not frozen". Any objects in existence
(except for object 0) when the
The "potential visibility" of an object is determined by
the do_not_show
byte of the
The X and Y location of an object is determined by the
The clipping boundaries of an object are determined by the
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:
Any object that points to a viewable object buffer can be made potentially visible, but one that points to a nonviewable one cannot. Any attempt to do so must be ignored.
The data format can be:
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.
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.
All object buffers are initially "not frozen". Any object buffers in
existence when the
When an object buffer is first created, its reference count is set to 1.
When a partial clone is made of an object via the
When an object is discarded, the reference count of the object buffer that it points to is decremented, and the object buffer is also discarded if the resulting reference count is zero.
4 bytes: Frame_width (unsigned integer).
4 bytes: Frame_height (unsigned integer).
4 bytes: Ticks_per_second (unsigned integer).
This is the unit used by the FRAM chunk to
specify Frame_duration and Sync_timeout.
The frame_width and frame_height fields
give the intended display size (measured in pixels) and provide default
clipping boundaries (see Paragraph 4.3.4, below). It is strongly
recommended that these be set to zero if the MNG datastream contains no
visible images.
The ticks_per_second field must be nonzero if the datastream contains more than one frame. It is strongly recommended that this be set to zero if the datastream contains exactly one frame, so simple applications that only examine file headers can use this field to identify single-frame MNGs.
1 byte: Nest_level (unsigned integer).
1 byte: Termination_condition (unsigned integer).
0: Deterministic.
1: Decoder discretion.
2: User discretion.
3: External signal.
4 bytes: Repeat_count (unsigned integer), range
[0..2^31-1].
4 bytes: Iteration_min (unsigned integer). Omit
if Termination_condition=0.
4 bytes: Iteration_max (unsigned integer). Omit
if Termination_condition=0.
4 bytes: Signal_number (unsigned integer). Omit
if Termination_condition != 3.
4 bytes: Additional Signal_number. Omit if
Termination_condition != 3.
etc.
Decoders must treat the chunks enclosed in a loop exactly as if they had
been repeatedly spelled out. Therefore, during the first iteration
of the loop, the parent objects for any Delta-PNG datastreams in the loop are the
images in existence prior to entering the Simple decoders can ignore all fields except for the repeat_count.
When the
The termination condition specifies how the actual number of
iterations is determined. It is very similar to the termination
condition field of
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 stream, but can be used merely to preserve the author's intent.
The number of iterations can be chosen by the decoder, and must not be less than iteration_min nor more than iteration_max. If the decoder has no reason to choose its own value, it should use the iteration count. One example of a decoder wishing to choose its own value is a real-time streaming decoder hovering at a loop while waiting for its input buffer to fill to a comfortable level.
The number of iterations should be chosen by the user (e.g. by pressing the <escape> key), but the decoder must enforce the iteration_min and iteration_max limits. Some decoders might not be able to interact with the user, and many decoders will find that nested user-discretion loops present too great of a user-interface challenge, so the <user-discretion> condition will probably usually degenerate into the <decoder-discretion> condition.
The number of iterations must not be less than iteration_min and nor more than iteration_max but the exact number can be determined by the arrival of a signal whose number matches one of the signal_number fields. There can be any number of signal_number fields. signal_number = 0 is reserved to represent any input from a keyboard or pointing device, and 1-255 are reserved to represent the corresponding ASCII character, received from a keyboard or simulated keyboard, and values 256-1023 are reserved for future definition by this specification.
If repeat_count is zero, the loop is done zero times. Upon
encountering a
The signal_number can be omitted only if the termination condition is not <external-signal>. signal_number=0 is reserved to represent a user input from a keyboard or pointing device.
The
1 byte: Nest_level (unsigned integer),
range [0..255].
When the
When the
The
2 bytes: Object_id (unsigned integer) identifier
to be given to the objects that follow the
DEFI chunk.
1 byte: Do_not_show (unsigned integer)
0: Make the objects potentially visible.
1: Do not make the objects potentially visible.
This field can be omitted if the concrete_flag,
location, and clipping boundary fields
are also omitted. When it is omitted, the image
is potentially visible (do_not_show=0).
1 byte: Concrete_flag (unsigned integer)
0: Make the objects "abstract" (image can not
be the source for a Delta-PNG)
1: Make the objects "concrete" (object can be
modified by a Delta-PNG).
This field can be omitted if the location and
clipping boundary fields are also omitted.
When it is omitted, the object is made "abstract"
(concrete_flag=0).
4 bytes: X_location (signed integer).
The X_location and Y_location fields can be
omitted if the clipping boundaries are also
omitted. If so, decoders must assume default
values {X_location=0, Y_location=0}.
4 bytes: Y_location (signed integer).
4 bytes: Left_cb (signed integer). Left clipping
boundary. The left_cb, right_cb, top_cb, and
bottom_cb fields can be omitted as a group.
If so, decoders must assume default values
{0, frame_width, 0, frame_height}.
4 bytes: Right_cb (signed integer).
4 bytes: Top_cb (signed integer).
4 bytes: Bottom_cb (signed integer).
If the object number for an object is nonzero, subsequent
chunks can use this number to identify it.
When the object number for an object is zero, its object buffer can be discarded immediately after it has been processed, and it can be treated as an "abstract" image, regardless of the contents of the concrete_flag field.
Negative values are permitted for the X and Y location and clipping boundaries. The positive directions are downward and rightward from the frame origin.
Multiple
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
If object_id is an identifier that already exists when a
See the PNG specification [PNG] and the PNG Special Purpose Chunks document [PNG-EXT] for the format of the PNG chunks.
Any chunks between
If a global
If the PNG
If the PNG
When framing_mode != 1
and framing_mode != 4
from the MNG
The PNG
If do_not_show=0 for the image when
the
If object_id=0, there is no need to store the pixel data after displaying it.
If concrete_flag=1 and object_id != 0, 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 stream might want to modify it. If concrete_flag=0, the decoder can store the pixel data in any form that it chooses.
If an object already exists with the same object_id, the contents of its object buffer are replaced with the new data.
See the JNG specification below for the format of the JNG datastream.
Any chunks between
The remaining discussion in the previous paragraph about PNG datastreams also applies to JNG datastreams.
The first 13 bytes of the
4 bytes: Width (unsigned integer).
4 bytes: Height (unsigned integer).
1 byte: Sample_depth (unsigned integer).
1 byte: Color_type (unsigned integer).
1 byte: Compression_method (unsigned integer).
1 byte: Filter_type (unsigned integer).
1 byte: Interlace_type (unsigned integer).
2 bytes: Red_sample (unsigned integer).
2 bytes: Green_sample (unsigned integer).
2 bytes: Blue_sample (unsigned integer)
2 bytes: Alpha_sample (unsigned integer).
1 byte: Viewable (unsigned integer).
0: Basis object is not viewable.
1: Basis object is viewable.
The alpha_sample can be omitted if the viewable field is also
omitted.
If so, and the color_type is
one that requires alpha, the alpha value corresponding to an opaque pixel
will be used. If the color samples are omitted, zeroes will be used.
The decoder is responsible for converting the color and alpha samples to the
appropriate format and sample depth for the specified color_type.
When color_type=3, the decoder must generate a palette of
length 2^sample_depth, whose first entry contains the
given {red_sample, green_sample, blue_sample} triple, and whose
remaining entries are filled with
zeroes. If the viewable field is omitted, the object is
not viewable.
The color and alpha samples are written as four sixteen-bit samples regardless of the color_type and sample_depth. When the sample_depth is less than sixteen, the least significant bits are used and the remaining bits must be zero filled. When color_type=3, the least significant byte of each color sample is used and the upper byte must be zero.
The
The permitted deviations from the PNG format are:
A
If an object already exists with the same object_id, the contents of its object buffer are replaced with the new data.
Top-level
No provision is made in this specification for storing a BASI datastream
as a standalone file. A
2 bytes: Source_id (nonzero unsigned integer) identifier
of the parent object to be cloned.
2 bytes: Clone_id (nonzero unsigned integer) identifier
to be given to the clone (new copy) to serve as
the object_id of the new object.
1 byte: Clone_type (unsigned integer).
0: Full clone of the object attributes set and
the object buffer.
1: Partial clone; only object attributes set
(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").
This field can be omitted if the
do_not_show field is also omitted.
If it is omitted, the clone_type defaults to
zero (full clone).
1 byte: Do_not_show (unsigned integer).
0: Make the clone potentially visible.
1: Do not make the clone potentially visible.
This field can be omitted if the concrete_flag and
location fields are also omitted. When it is
omitted, the object retains the potential
visibility of the parent object.
1 byte: Concrete_flag (unsigned integer).
0: Concrete_flag is the same as that of the parent
image.
1: Make the clone "abstract" (concrete_flag=0).
This field can be omitted if the location fields
are also omitted. When it is omitted, the object
retains the concrete_flag of the parent object.
1 byte: Loca_delta_type (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. When they
are omitted, the clone has the same location
as the parent object.
4 bytes: X_location or delta_X_location
(signed integer).
4 bytes: Y_location or delta_Y_location
(signed integer).
The source_id must be an existing object identifier, and
the clone_id must not be an existing object identifier.
Negative values are permitted for the X and Y position. The positive directions are downward and rightward from the frame origin.
The clone is
initially identical to the parent object except for the location
and potential visibility. It has the same clipping boundaries as the
parent object. Subsequent
Subsequent chunks can modify, show, or discard a full clone or modify its potential visibility, location and clipping boundaries without affecting the parent object, or they can modify, show, or discard the parent object or modify its object attribute set without affecting the clone.
The concrete_flag byte must be zero when the clone_type byte is nonzero.
If an object has partial clones, and the data in the object buffer of a parent object or any of its partial clones is modified, the parent object and all of its partial clones are changed. Decoders must take care that when the parent object or any partial clone is discarded, the object buffer is not discarded until the last remaining one of them is discarded. Only the location, potential visibility, and clipping boundaries can be changed independently for each partial clone.
See Chapter 6, The Delta-PNG Format, below, for the format of
the Delta-PNG datastream.
Any chunks between
The
2 bytes: Destination_id (unsigned integer).
1 byte: Target_delta_type (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 immediately
preceding PAST chunk regardless of its
destination_id.
4 bytes: Target_x (signed integer), measured
rightward from the left edge of the
destination image.
4 bytes: Target_y (signed integer), measured
downward from the top edge of the
destination image.
2 bytes: Source_id (unsigned nonzero integer).
An image to be pasted in.
1 byte: Composition_mode (unsigned integer).
0: Composite_over.
1: Replace .
2: Composite_under.
1 byte: Orientation (unsigned integer).
The source image, which contains a
graphic symbol "p" in these examples,
is flipped to another orientation.
0: Same as source image (p->p).
2: Flipped left-right, then up-down (p->d).
4: Flipped left-right (p->q).
6: Flipped up-down (p->b).
8: Tiled with source image, to fill the
clipping boundaries. The upper left
corner of the assembly is positioned
according to the prescribed offsets.
p -> pppp
pppp
1 byte: Offset_delta_type (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.
4 bytes: Xoffset or delta xoffset (signed integer).
4 bytes: Xoffset or delta yoffset (signed integer).
1 byte: Boundary_delta_type (unsigned integer).
0: Boundaries are measured from the {0,0} pixel
in the destination image.
1: Boundaries are measured from the
{target_x,target_y} pixel in the destination
image.
4 bytes: Left_pb or delta_left_pb (signed integer).
4 bytes: Right_pb or delta_right_pb (signed integer).
4 bytes: Top_pb or delta_top_pb (signed integer).
4 bytes: Bottom_pb or delta_bottom_pb (signed integer).
etc.
The destination image must have the "abstract" property
(concrete_flag=0). When destination_id=0,
the resulting image is "write-only" and therefore only
"composite-over" (composition_mode=0) operations are permitted.
The source images can be "abstract" or "concrete" and have any color_type and sample_depth. They must have the "viewable" property. The number of source images is ((chunk_length-11)/30).
The x_offset and y_offset distances and the clipping
boundaries are measured,
in pixels, positive rightward and downward from either the {0,0}
pixel of the destination image or the {target_x, target_y}
position in the destination image. They do not necessarily have to fall
within the destination image. Only those pixels of the source image that
fall within the destination image and also within the specified clipping
boundaries will be copied into the destination image. Note that 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
When composition_mode=0, any non-opaque pixels in the source image are combined with those of the destination image. If the destination pixel is also non-opaque, the resulting pixel will be non-opaque.
When composition_mode=1, all pixels simply replace those in the destination image. This mode can be used to make a transparent hole in an opaque image.
When composition_mode=2, any non-opaque pixels in the destination image are combined with those of the source image. If the source pixel is also non-opaque, the resulting pixel will be non-opaque.
The order of composition is the same as the order that the source_id's appear in the list (but a decoder can do the composition in any order it pleases, or all at once, provided that the resulting destination image is the same as if it had actually performed each composition in the specified order). Decoders must be careful when the destination image equals the source image--the pixels to be drawn are the ones that existed before the drawing operation began.
The
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.
2 bytes: Discard_id (nonzero unsigned integer) identifier
of object that can be discarded. All
information pertaining to the corresponding
object can be discarded.
etc.
If the When an object is discarded, any location, potential visibility, and clipping boundary data associated with it is also discarded.
It is not an error to include an object_id in the discard_id list, when no such object has been stored, or when the object has already been discarded.
It is an error to name explicitly any "frozen" object in the
When the object is a partial clone or is the source of a partial clone that has not been discarded, only the object attribute set (location, potential visibility, and clipping boundaries) can be discarded. The data in the object buffer must be retained until the last remaining partial clone is discarded.
2 bytes: Red_background (unsigned integer).
2 bytes: Green_background (unsigned integer).
2 bytes: Blue_background (unsigned integer).
1 byte: Mandatory_background (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
background_image_id is also omitted; if so, the
background color is advisory.
2 bytes: Background_image_id (unsigned nonzero integer).
Object_id of an image that is to be displayed
as the background of each frame. If it is
not full-frame, the remainder of the frame
is filled with the background color. This
field can be omitted; if so, no background
image is defined, and the background image
from a previous BACK chunk becomes undefined.
1 byte: Background_tiling (unsigned integer).
0: Do not tile the background.
1: Tile the background with the background
image. This field can be omitted; if so,
background_tile=0.
Viewers are expected to composite every frame in the MNG datastream
against a fresh copy of the background. The images and the background are
both clipped to the frame boundaries given in the It is not an error to specify a background_image_id when such an image does not exist or ceases to exist for some reason. Viewers must be prepared to fall back to using the background color in this event. They also must be prepared for the contents, location, and clipping boundaries of the background image to change, just like any other object, if it has not been "frozen".
The three
The colorspace of the background image, if one is used, is determined in the same manner as the colorspace of any other image.
When the
Multiple instances of the
The
In practice, most applications that use MNG as part of a larger
composition should ignore the
An empty
1 byte: Framing_mode.
0: Don't change framing_mode.
1: Each image is an individual frame; the
frame area background is restored
before displaying each image and an
interframe delay occurs after each image.
This is the default framing_mode.
2: The group of images appearing prior to
the next "FRAM" chunk form a composite
frame. Images are caused to appear with
explicit or implied "SHOW" chunks. The
level, or stacking order, of each image
is given by its order of appearance in the
datastream. The frame area background is
restored prior to displaying the first
image, and no interframe delay occurs
between the images.
3: The group of "n" images appearing prior to
the next "FRAM" chunk define "n" frames as
they accumulate, and an interframe delay
occurs after each image is defined or
appears in a "SHOW" chunk. The frame area
background is only restored prior to
displaying the first image. Images appear
one by one and remain visible after being
explicitly caused to appear. The level,
or stacking order, of each image is given
by its order of appearance in the datastream.
4: This is the same as framing_mode=1, except
the frame area background is not restored
prior to displaying each image. Use this
mode to avoid unnecessary clearing of the
display when the first image covers the
entire frame area, when the sequence
consists of a series of full-frame opaque
images, and when a subsequent frame is
created by overlaying a smaller, opaque
image over the existing frame.
5: This is the same as framing_mode=2, except
the frame area background is not restored
prior to displaying the frame.
n bytes: Frame_name (Latin-1 Text). Can be
omitted; if so, the frame is nameless.
1 byte: Zero-byte separator. Must be omitted
if all remaining fields are also omitted.
1 byte: Change_interframe_delay.
0: No.
1: Yes, for the next frame only.
2: Yes, also reset default.
This field and the next three must be omitted
as a group if no frame parameters other than
the framing_mode are changed.
1 byte: Change_sync_timeout_and_termination.
0: No.
1: Deterministic, for the next frame only.
2: Deterministic, also reset default.
3: Decoder-discretion, for the next frame only.
4: Decoder-discretion, also reset default.
5: User-discretion, for the next frame only.
6: User-discretion, also reset default.
7: External-signal, for the next frame only.
8: External-signal, also reset default.
1 byte: Change_frame_clipping_boundaries.
0: No.
1: Yes, for the next frame only.
2: Yes, also reset default.
1 byte: Change_sync_id_list.
0: No.
1: Yes, for this frame only.
2: Yes, also reset default list.
4 bytes: Interframe_delay (unsigned integer). Must
be omitted if change_interframe_delay=0.
The range is [0..2^31-1] ticks.
4 bytes: Sync_timeout (unsigned integer). Omit if
change_sync_timeout=0. The range is
[0..2^31-1]. The value 2^31-1 (0x7fffffff)
ticks represents an infinite timeout period.
1 byte: Fb_delta_type (unsigned integer).
0: Frame clipping boundary values are given
directly.
1: Frame clipping boundaries are determined by
adding the FRAM data to their previous
values.
This and the following four fields must be
omitted if change_frame_clipping_boundaries=0.
4 bytes: Left_fb or delta_left_fb (signed integer).
4 bytes: Right_fb or delta_right_fb (signed integer).
4 bytes: Top_fb or delta_top_fb (signed integer).
4 bytes: Bottom_fb or delta_bottom_fb (signed
integer).
4 bytes: Sync_id (unsigned integer). Omit if
change_sync_id_list=0 or if the new list is
empty; repeat until all sync_id's have been
listed. The range is [0..2^31-1].
When the Framing_modes:
When framing_mode=1, each image that appears is a separate
frame.
The following events trigger the display of a frame:
For example (assuming that objects 1 through 5 are all viewable objects), the sequence
FRAM 1 SHOW 1 5will result in the display of five frames, each containing one of the images against the background according to its location and
When framing_mode=2, viewers are expected to display all
of the images at
once, if possible, or as fast as can be managed, clearing the frame
and restoring the background before displaying the first image, but
without clearing the display and restoring the background between images.
Clearing the frame is also triggered by the appearance of the next
For example, the sequence
FRAM 2 SHOW 1 5 (shows images 1, 2, 3, 4, and 5) FRAMwill result in a single frame containing five images, each displayed according to its location and
When images in a frame overlap, viewers are expected to composite the later images against the partially completed frame that includes all earlier images.
This framing_mode is fundamentally declarative; it describes the elements that go into an individual frame. It is up to the decoder to work out an efficient way of making the screen match the desired composition. Simple decoders can handle it as if it were procedural, compositing the images into the frame 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.
When framing_mode=3, a frame boundary occurs after each
image appears,
but only clearing the frame area and restoring the background between frames
when the next
When multiple images are caused to appear with a single
FRAM 3 SHOW 1 5 (shows images 1, 2, 3, 4, and 5) FRAMwould result in five frames being displayed, the first with only image 1, the second with images 1 and 2, etc., and the fifth frame with all five images visible. The resulting output is exactly equivalent to what would have been accomplished (but perhaps less efficiently) with
FRAM 2 SHOW 1 FRAM SHOW 1 2 (shows images 1 and 2) FRAM SHOW 1 3 (shows images 1, 2, and 3) FRAM SHOW 1 4 (shows images 1, 2, 3, and 4) FRAM SHOW 1 5 (shows images 1, 2, 3, 4, and 5) FRAM
When framing_mode=4, a frame boundary occurs after each
image appears, without clearing the frame area and restoring the background
between frames. Otherwise,
framing_mode=4 is identical to framing_mode=1.
Frames are triggered
by the same events that trigger a frame when framing_mode=1.
A frame is also triggered by the appearance of the next
When framing_mode=5, a frame boundary occurs only when the
next
The framing_mode also affects the way decoders handle the
The frame_name must conform to the same formatting rules
as those for a
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.
The sync_timeout field can be a number or <infinity>.
The termination condition given in the change_sync_timeout_and_termination field specifies how much longer, after the normal interframe delay has elapsed, the frame will endure. It can take the following values:
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
The decoder can lengthen the duration of the frame, but by no more than the timeout. A streaming decoder could take the opportunity to wait for its input buffer to fill to a comfortable level.
The decoder should wait for permission from the user (e.g., via a keypress) before proceeding, but must wait no longer than the timeout. If the decoder cannot interact with the user, this condition degenerates into "decoder-discretion".
The decoder should wait for the arrival of a signal whose number matches a sync_id, but must wait no longer than the timeout.
When the sync_id list is changed, the number of sync_id entries is determined by the remaining length of the chunk data, divided by four. This number can be zero, which either inactivates the existing sync_id list for one frame or deletes it.
The initial values of the
Framing_mode = 1 Frame_name = <empty string> Interframe_delay = 0 Left_fb = 0 Right_fb = frame_width Top_fb = 0 Bottom_fb = frame_height termination = deterministic Sync_timeout = 0x7fffffff (infinite) Sync_id = <empty list>The
The frame_duration field gives the duration of display, which is
the minimum time that must elapse from the beginning of displaying one frame
until the beginning of displaying the next (or between images, when
framing_mode=1). It is measured in "ticks" using
the tick length determined from ticks_per_second defined in
the
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.
The sync_id list provides a point at which the processor must wait for all pending processes to reach the synchronization point having the same sync_id 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 frame_duration and the sync_timeout fields elapses, processing can resume even though the processor has not received an indication that other processes have reached the synchronization point.
Note that the synchronization point does not occur immediately, but at
the end of the frame that follows the
FRAM 4 0 1 1 0 1 0000 sync_timeout sync_id FRAM 0 name
The identifier sync_id=0 is reserved to represent synchronization with a user input from a keyboard or pointing device. The sync_id 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 sync_id list.
The
The chunk's contents are:
2 bytes: First_object (nonzero unsigned integer).
2 bytes: Last_object (nonzero unsigned integer).
1 byte: Loca_delta_type (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.
4 bytes: X_location or delta_X_location
(signed integer).
4 bytes: Y_location or delta_Y_location
(signed integer).
The new location applies to a single object,
if first_object=last_object,
or to a group of consecutive object_ids, if they are different.
Last_object must not be less than first_object.
Negative values are permitted for the X and Y location. The
positive directions are downward and rightward from the frame origin.
The
It is not an error for the
When an object is discarded, its object attribute set,
which includes the
2 bytes: First_object (nonzero unsigned integer).
2 bytes: Last_object (nonzero unsigned integer).
1 byte: Clip_delta_type (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_id.
4 bytes: Left_cb or delta_left_cb (signed integer).
4 bytes: Right_cb or delta_right_cb (signed integer).
4 bytes: Top_cb or delta_top_cb (signed integer).
4 bytes: Bottom_cb or delta_bottom_cb (signed
integer).
The new clipping boundaries apply to a single object,
if first_object=last_object,
or to a group of consecutive objects, if they are different.
Last_object must not be less than first_object.
The clipping boundaries are expressed in pixels, measured rightward and downward from the frame origin.
The left and top clipping boundaries are inclusive and the right and bottom clipping boundaries are exclusive, i.e., the pixel located at {x,y} is only displayed if the pixel falls within the physical limits of the display hardware and all of the following are true:
0 <= x < frame_width (from the MHDR chunk) 0 <= y < frame_height Left_fb <= x < right_fb (from the FRAM chunk) Top_fb <= y < bottom_fb Left_cb <= x < right_cb (from the CLIP chunk) Top_cb <= y < bottom_cbIt is not an error for the
When an object is discarded, its object attribute set, which
includes the
2 bytes: First_image (nonzero unsigned integer).
2 bytes: Last_image (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.
1 byte: Show_mode (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: Don't 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. Cycle back 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 < 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.
The decoder processes the objects (or images) named in the
When the
If last_image < first_image the images are processed in reverse order.
When show_mode is odd-valued, nothing is displayed unless a
subsequent
When show_mode=1, 4, 5, 6, or 7, images can be made invisible.
This is not permitted when framing_mode != 1
in the
When show_mode=6 or 7, the decoder must make the next image in the "cycle" visible. To do this, it must examine the do_not_show flag for each image in the range first_image through last_image, and make the next one (the one with the next higher value of image_id that exists and is "viewable") after the first visible one it finds visible and the rest invisible. When first_image > last_image, the cycle is reversed, and the "next" image is the one with the next lower value of image_id. In either case, if the first visible one was last_id, or none were visible, it must make first_image visible. These modes are useful for manipulating a group of sequential images that represent different views of an animated icon. See Example 8 in Chapter 16, below.
When show_mode=0, 2, 4, or 6,
an instance of each visible image will be displayed at the location
specified by the
Any of the following sequences would cause the image identified by object_id=6 in a composite frame to blink:
LOOP 0 0 10 FRAM 2 SHOW 1 10 # Show images 1 thru 10. FRAM SHOW 1 5 # Show images 1 thru 5. SHOW 7 10 # Show images 7 thru 10. ENDL LOOP 0 0 10 FRAM 2 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 LOOP 0 0 10 FRAM 2 SHOW 6 6 5 # Toggle potential visibility of image 6. SHOW 1 10 2 # Show potentially visible images in 1 FRAM # through 10. ENDLIt is not necessary to follow an
It is not an error for the
If a nonviewable object is named, its do_not_show flag
is changed, but it is not displayed even if the
Simple decoders that only read MNG datastreams
sequentially can safely ignore the
The
1 byte: Offset_size (unsigned integer).
4: Offsets and nominal start times are
expressed as 32-bit integers.
8: Offsets and nominal start times are
expressed as 64-bit integers.
plus zero or more of the following index entries:
1 byte: Entry_type (unsigned integer).
0: Segment with nominal start time and
nominal frame number.
1: Segment.
2: Frame.
3: Exported image.
4 or 8 bytes: Offset (unsigned integer). Omit if
entry_type > 1, set equal to zero
if the offset is unknown.
4 or 8 bytes: Nominal_start_time (unsigned
integer). Start time of the segment,
measured in ticks from the beginning of
the animation, assuming that all prior
segments were played as intended on
an ideal player, ignoring any "fPRI"
chunks. Omit if entry_type > 0.
4 bytes: Nominal_frame_number (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. Omit if
entry_type > 0.
n bytes: Name (Latin-1 text). Omit for unnamed
segments.
1 byte: Zero-byte separator (must be omitted from
the last entry).
The
Only one instance of the
It is not permitted, at any point beyond the
An object appearing ahead of the
A chunk like
It is the encoder's responsibility, if it changes or discards any
"saved" data, to restore it to its "saved" condition (or nullifying it, if
it was unknown) prior to the
end of the segment. This makes it safe for simple decoders to ignore
the
Known chunks in this category include
In the case of
chunks like
If the optional index is present, every segment, whether named or not, except for the prologue segment, must be listed in it. All entries must appear in the index in the same order that they appear in the MNG datastream. Only named images or frames are permitted, and it is not an error to omit any or all named images or frames from the index.
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.
Applications with direct access to the datastream can use the index to find segments, frames, 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 frame, image, or time is found. Applications that have only streaming access to the datastream can still use the index to decide whether to decode the chunks in a segment or to skip over them.
Only one instance of the
The
n bytes: Keyword (Latin-1 string).The keyword is optional. The keyword must follow the format of a
Applications must not use any information preceding the
In addition to providing a mechanism for skipping frames or backspacing over
frames, the
When the
Multiple instances of the
The chunk contains an object identifier and a name:
2 bytes: Snapshot_id (unsigned nonzero integer). n bytes: Snapshot_name (Latin-1 text).Note that the snapshot_name is associated with the snapshot, not with the snapshot_id nor its future contents; discarding the image identified by snapshot_id will not affect the snapshot. The snapshot_name means nothing inside the scope of the MNG specification, except that it can be included in the optional index that can appear in the
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.
The snapshot_name
string must follow the format of a
Multiple instances of the
1 byte: fPRI_delta_type (unsigned integer).
0: Priority is given directly.
1: Priority is determined by adding
the fPRI data to the previous
value, modulo 256.
1 byte: Priority or delta_priority (signed
integer). Value to be assigned to
subsequent frames until another fPRI
chunk is reached.
While 256 distinct values of priority 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 priority=255 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 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, and it cannot be changed unless the prologue segment is processed again according to the new "cost."
The
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
Viewers that care about the priority must assume priority=255
for any portion of the MNG
datastream that is processed prior to the first
Multiple instances of the
The
n bytes: Keyword. 1 byte: Null separator. etc.The
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
Each keyword
string must follow the format of a
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.
-[During the draft phase of the development of this specification, to specify that the datastream is written in accordance with a certain draft version of MNG, you can use "nEEDdraft nn".]
1 byte: Termination_action (unsigned integer)
0: Show the last frame indefinitely.
1: Cease displaying anything.
2: Discard all "nonfrozen" objects and repeat
the animation starting immediately after
the SAVE chunk (or immediately after the
MHDR chunk, if a SAVE chunk is not present).
3: Repeat the animation starting immediately
after the last SEEK chunk in the datastream.
If no SEEK chunk is present, repeat the
animation starting immediately after the
SAVE chunk (or immediately after the MHDR
chunk, if a SAVE chunk is not present).
4: Reset the decoder to its initial state,
retaining only the MHDR data, and repeat
the entire animation starting immediately
after the MHDR chunk.
1 byte: Action_after_iterations
0: Show the last frame indefinitely after
Iteration_max iterations have been done.
1: Cease displaying anything.
This and the remaining fields must be
omitted if termination_action<=1, and
must be present otherwise.
4 bytes: Delay (unsigned integer) delay, in ticks,
before repeating the animation.
4 bytes: Iteration_max (unsigned integer) maximum
number of times to repeat the animation.
The loop created by processing a
The MNG top-level
The following 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.
The following 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:
When a decoder needs to chose between a suggested palette defined at
the MNG level and a suggested palette defined in the PNG datastream (either
with the
MNG editors that write PNG datastreams should ignore the
JNG (JPEG Network Graphics) is the lossy sub-format for MNG objects.
Note: This specification depends on the PNG Portable Network Graphics specification [PNG]. The PNG specification is available at the PNG home page,
<URL:http://www.cdrom.com/pub/png/>A JNG datastream consists of a header chunk (
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 first eight bytes of a JNG datastream are
139 80 78 74 13 10 26 10(decimal) which is similar to the PNG signature with "\213 J N G" instead of "\211 P N G" in bytes 0-3.
JNG is pronounced "Jing."
4 bytes: Width (unsigned integer, range 0..65535).
4 bytes: Height (unsigned integer, range 0..65535).
1 byte: Color_type
8: Gray (Y).
10: Color (YCbCr).
12: Gray-alpha (Y-alpha).
14: Color-alpha (YCbCr-alpha).
1 byte: JDAT_sample_depth.
8: 8-bit sample and quantization table data
12: 12-bit sample and quantization table.
20: 12-bit image followed by an eight-bit image.
1 byte: JDAT_compression_method.
8: ISO-10918-1 Huffman-coded baseline JPEG.
1 byte: JDAT_interlace_method.
0: Sequential JPEG, single scan.
8: Progressive JPEG.
1 byte: IDAT_sample_depth.
0, 1, 2, 4, 8, or 16.
1 byte: IDAT_compression_method.
0: Zlib DEFLATE.
1 byte: IDAT_filter_method.
0: Adaptive (see PNG spec).
1 byte: IDAT_interlace_method.
0: Not interlaced.
The width, height, JDAT_sample_depth, JDAT_compression_method, and
JDAT_interlace_method fields are redundant because equivalent information
is also embedded in the
When the color_type is 8 or 10 (no alpha channel),
the last four bytes, which describe the
A JNG baseline JPEG is a baseline JPEG as defined by JPEG Part 1 (ISO IS 10918-1), using only JFIF-compatible component interpretations, with a few additional restrictions that reflect limitations of many existing JPEG implementations.
A baseline JPEG according to Part 1 is DCT-based (lossy) sequential JPEG, using Huffman entropy encoding, with the following further restrictions:
The SOF marker type for baseline JPEG is SOF0.
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.
The image data is always stored left-to-right, top-to-bottom, ie, only the default SPIFF orientation is permissible.
The encoded data shall have one of the two colorspace interpretations allowed by the JFIF specification:
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_scaleBy convention, the luminance coefficients are always those defined by CCIR Recommendation 601-1:
Luma_red = 0.299, Luma_green = 0.587, Luma_blue = 0.114The constant Half_scale is 128 when dealing with 8-bit data, 2048 for 12-bit data. With these equations, Y, Cb, and Cr all have the same range as R, G, and B: 0 to 255 for 8-bit data, 0 to 4095 for 12-bit data.
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.
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.
JNG imposes three additional restrictions not found in the text of either JPEG Part 1 or the JFIF specification:
In other words, the chroma components may be downsampled 2:1 or 1:2 horizontally relative to luminance, and optionally also 2:1 vertically; 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 new, and is usually the result of a lossless rotation of a 2x1 sampling).
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.
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.
Otherwise, all the restrictions listed above apply, except these:
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.
When the
The
If the
The following chunks have exactly the same meaning and have the same format
as given in the PNG specification:
The PNG
When
The chunk copying and ordering rules for JNG are the same as those in PNG,
except for the fact that
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
The decoder must have available a parent (decoded) object 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
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.
The decoder must not have modified the pixel data in the parent object
by applying output transformations such as
A Delta-PNG datastream consists of a
Chunk structure (length, name, CRC) and the chunk-naming system are identical to those defined in the PNG specification. Definitions of compression_type, filter_type, and interlace_type are also the same as defined in the PNG specification.
The
2 bytes: Object_id (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.
1 byte: Image_type.
0: Image type is unspecified. An IHDR or IPNG
chunk must be present.
1: Image type is PNG. IHDR and IPNG can be
omitted under certain conditions.
2: Image type is JNG. Delta_type must not
be 1 or 3.
1 byte: Delta_type.
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)
color type 4 or color type 6.
3: Block pixel replacement.
4: Block alpha replacement.
5: No change to pixel data.
4 bytes: Block_width (unsigned integer). Omit when
delta_type=5.
4 bytes: Block_height (unsigned integer). Omit when
delta_type=5.
4 bytes: Block_X_location (unsigned integer),
measured in pixels from the left edge of
the parent object. Omit when delta_type=0
or when delta_type=5.
4 bytes: Block_Y_location (unsigned integer),
measured in pixels from the top edge of
the parent object. Omit when delta_type=0
or when delta_type=5.
The object_id must identify an existing object, and the object
must be a "concrete" object, i.e., it must have the
property concrete_flag=1.
The image_type, whether given explicitly as 1 or 2
or implied by the presence of an
When delta_type=0, the width and height of the child image are given by the block_width and block_height fields.
For all other values of delta_type, the width and height of the child image are inherited from the parent object.
When delta_type=1, 2, 3, or 4, the block_width and block_height fields give the size of the block of pixels to be modified or replaced, and block_X_location and block_Y_location give its location with respect to the top left corner of the parent object. The block must fall entirely within the parent object.
When delta_type=0 in the
When delta_type=1 in the
The compression method, filter method, and interlace method need not be the same as those of the parent object.
The
An encoder calculates the new 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 2^sample_depth. When decoding
the
When color_type=3, the deltas are differences between index values, not between color samples.
When delta_type=2 in the
The sample_depth of the data must match that of the parent object, and color_type is 0 (grayscale), regardless of the color_type 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.
When delta_type=3 in the
The sample_depth and color_type of the data must match that of the parent object. The compression method, filter method, and interlace method need not be the same.
When delta_type=4 in the
When delta_type=5 in the
The
1 byte: New color_type.
1 byte: New sample_depth.
1 byte: Fill_method
0: Left-bit-replication
1: Zero fill
When a decoder encounters the
Don't 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
Don't change the RGB values. Convert the
Set R, G, and B equal to the gray value. Apply the same operation to the cheap transparency data (if any).
Set R, G, and B equal to the gray value. Don't change the alpha values.
Set R, G, and B equal to the gray value. Handle transparency as in the G -> GA promotion.
Set R, G, and B according to the palette entry corresponding to the index. Discard the cheap transparency information (if any).
Set R, G, and B as in indexed -> RGB. Set the alpha value according to the cheap transparency information (if any). Discard the cheap transparency information.
Don't 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.
Don't 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.
Only the sample depth is changed. The new sample depth must be larger than the old one.
If the basis object contains data from the PNG
If the basis object contains data from the PNG
The
The
If the
The compression_method,
interlace_type, and filter_type fields, if different from
those of the parent object, are used in decoding any subsequent
See the PNG specification for the format of the PNG chunks.
The PNG datastream must contain at least
The
The
When processing the
The
1 byte: PPLT_delta_type.
0: Values are replacement RGB samples.
1: Values are delta RGB samples.
2: Values are replacement alphas.
3: Values are delta transparencies.
4: Values are replacement RGBA samples.
5: Values are delta RGBA samples.
1 byte: First_index, first group.
1 byte: Last_index, first group.
1, 3, or 4 bytes: First set of samples.
etc.
1, 3, or 4 bytes: Last set of samples.
1 byte: First_index, second group.
etc.
The last_index must be equal to or greater
than first_index.
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 When PPLT_delta_type=0, the values are replacements for the existing samples in the palette.
When PPLT_delta_type=1, the values are added to the existing samples (modulo 256) to obtain the new samples.
If the new entry is beyond the range of the original palette, the values are simply appended, regardless of the contents of PPLT_delta_type.
If the
The IDAT_compression_method,
IDAT_interlace_type, and IDAT_Filter_type fields,
if different from
those of the parent object, are used in decoding any subsequent
See the JNG specification above for the format of the JNG chunks.
The PNG datastream must contain at least
-[Is it worthwhile defining an IJNG chunk to perform a similar function to IPNG for JNG, when the JHDR data isn't needed?]
4 bytes: Chunk name (ASCII text). etc.If multiple names appear in the
4 bytes: Chunk name (ASCII text).
1 byte: Polarity (unsigned integer).
0: Only.
1: All-but.
Keywords (null-separated Latin-1 text strings).
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 <only>, then any parent chunk whose keyword appears in
the keywords list is inhibited. If polarity is <all-but>, then any
parent object chunk whose keyword does not appear in the keywords list is
inhibited.
The format of the keyword is the same as that specified for the parent
chunk. Comparisons of keywords in the parent chunk and the
Use caution when printing or displaying keywords (Refer to Security considerations, Chapter 15, below).
4 bytes: Chunk_name.
1 byte: Order_type.
0: Anywhere.
1: After IDAT and/or JDAT.
2: Before IDAT and/or JDAT.
3: Before IDAT, but not before PLTE.
4: Before IDAT, but not after PLTE.
etc.
Critical chunk names must not appear in the
If a chunk name appears in the
If any ancillary chunk appears in the parent object, and it is not inhibited,
and its name does not appear in the
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.
The copy-safe status of an unknown chunk is determined from the chunk name, just as in PNG. If bit 5 of the first byte of the name is 0 (Normally corresponding to an uppercase ASCII letter), the unknown chunk is critical and cannot be processed or copied. If it is 1 (usually corresponding to a lowercase ASCII letter), the unknown chunk is ancillary and its copy-safe status is determined by bit 5 of the fourth byte of the name, 0 meaning copy-unsafe and 1 meaning copy-safe.
If an editor makes changes to the MNG datastream that render unknown chunks
unsafe-to-copy, this does not affect the copy-safe status of any chunks
beyond the next
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 stream can have ordering rules only
with respect to the
The copying rules for unknown chunks inside
The copy-safe status of chunks inside a
Anything less than this level of support would require subsetting. We are allowing minimal decoders to skip 12-bit JNGs because those are likely to be rarely encountered and used only for special purposes.
All PNG critical chunks must be fully supported. All values of color_types, bit_depth, compression_method, filter_method and interlace_method must be supported (interlacing, as in PNG, need not necessarily be displayed on-the-fly; the image can be displayed after it is fully decoded). The alpha-channel must be supported, at least to the degree that fully opaque pixels are opaque and fully transparent ones are transparent. It is recommended that alpha be fully supported.
The PNG
Ancillary chunks other than PNG
It is highly recommended that decoders support at least
the
All JNG critical chunks must be fully supported. All values of color_type, bit_depth, compression_method, filter_method and interlace_method must be supported (interlacing, as in PNG, need not necessarily be displayed on-the-fly; the image can be displayed after it is fully decoded). The alpha-channel must be supported, at least to the degree that fully opaque pixels are opaque and fully transparent ones are transparent. It is recommended that alpha be fully supported.
All JNG ancillary chunks can be ignored, and do not even have to be recognized.
Only sample_depth=8 must be supported. The
Ticks_per_second must be supported by animation viewers.
The
The repeat_count must be supported. The nest_level should be used as a sanity check but is not required.
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".
Need not be supported, but support is recommended to conserve memory.
Must be fully supported.
The framing_mode and clipping parameters must be supported. The interframe_delay must be supported except by single-frame viewers. The sync_id and sync_timeout data can be ignored.
Must be fully supported.
Can be ignored. It is recommended that objects be marked "frozen"
when the
Must be fully supported.
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
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
Pixels in PNG images are represented using gamma-encoded RGB (or gray) samples along with a linear alpha value. Alpha processing can only be performed on linear samples. This chapter assumes that R, G, B, and A values have all been converted to real numbers in the range [0..1], and that any gamma encoding has been undone.
For a top pixel {Rt,Gt,Bt,At} and a bottom pixel {Rb,Gb,Bb,Ab}, the composite pixel {Rc,Gc,Bc,Ac} is given by:
Ac = 1 - (1 - At)(1 - Ab) if (Ac != 0) then s = At / Ac t = (1 - At) Ab / Ac else s = 0.0 t = 1.0 endif Rc = s Rt + t Rb Gc = s Gt + t Gb Bc = s Bt + t BbWhen the bottom pixel is fully opaque (Ab = 1.0), the function reduces to:
Ac = 1 Rc = At Rt + (1 - At) Rb Gc = At Gt + (1 - At) Gb Bc = At Bt + (1 - At) BbWhen the bottom pixel is not fully opaque, the function is much simpler if premultiplied alpha is used. A pixel that uses non-premultiplied alpha can be converted to premultiplied alpha by multiplying R, G, and B by A.
For a premultiplied top pixel {Rt,Gt,Bt,At} and a premultiplied bottom pixel {Rb,Gb,Bb,Ab}, the premultiplied composite pixel {Rc,Gc,Bc,Ac} is given by:
Ac = 1 - (1 - At)(1 - Ab) Rc = Rt + (1 - At) Rb Gc = Gt + (1 - At) Gb Bc = Bt + (1 - At) BbAs mentioned in the PNG specification, the equations become much simpler when no pixel has an alpha value other than 0.0 or 1.0, and the RGB samples need not be linear in that case.
The following information must be retained, for each nonzero object that is defined and not subsequently discarded:
When the encoder knows that data in the object buffer will not be needed
by subsequent frames, it can make life easier for decoders by
using object_id=0 or by using the
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.
MNG editors, on the other hand, should be more strict and reject any datastream with errors unless the user intervenes.
If
If a frame contains two or more images, the
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
The frame_width and frame_height are defined in
the
Decoders can use these parameters to establish the size of a window in which to display the MNG frames. When the frame_width or frame_height exceeds the physical dimensions of the display hardware, the contents of the area outside those dimensions is undefined. If a viewer chooses, it can create "scroll bars" or the like, to enable persons to pan and scroll to the offscreen portion of the frame. If this is done, then the viewer is responsible for maintaining and updating the offscreen portion of the frame.
In the case of a MNG
datastream that consists of a PNG (or JNG) datastream, with the PNG
(or JNG) signature, the frame_width and frame_height are
defined by the width and height fields of the
The frame clipping boundaries are optionally defined in the
The frame clipping boundaries are defined in the
The
When the
Although we define a standalone JNG format, we recommend that such files be used only temporarily while compiling or disassembling MNG datastreams. We do not intend to register an Internet Media Type for JNG files.
See [RFC-1738], Uniform Resource Locators (URL) and the W3C SMIL recommendation.
Boutell, T., et. al.,
PNG (Portable Network Graphics Format Version 1.0),
RFC 2083,
<URL:ftp://ds.internic.net/rfc/rfc2083.txt>
also available at
<URL:ftp://swrinde.nde.swri.edu/pub/png/documents/>.
This specification has also been published as a W3C Recommendation, which
is available at
<URL:http://www.w3.org/TR/REC-png.html>.
PNG Special-Purpose Public Chunks,
<URL:ftp://swrinde.nde.swri.edu/pub/png/documents/>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119/BCP 14, Harvard University, March 1997.
Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, Innosoft, First Virtual, November 1996.
<URL:ftp://ds.internic.net/rfc/rfc2045.txt>.
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 1996.
<URL:ftp://ds.internic.net/rfc/rfc2048.txt>
Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource Locators (URL)",
RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994.
<URL:ftp://ds.internic.net/rfc/rfc1738.txt>
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 sync_id with a long sync_timeout value.
Therefore a decoder should always provide a simple method for users to
escape out of a loop or delay, either by abandoning the MNG entirely or just
proceeding to the next
No known additional security concerns are raised by this format.
copy file.png file.mngThe resulting MNG file looks like:
\211 P N G \r \n ^z \n # PNG signature. IHDR 720 468 8 0 0 0 0 # Width and Height, etc. IDAT ... IEND
\212 M N G \r \n ^z \n # MNG signature.
MHDR 256 300 # Width and height.
30 # 30 ticks per second.
tERm 2 0 120 10 # When done, repeat from SAVE 10 times.
FRAM 4 0 2 0 0 0 30 # Set framing_mode=4 (because the
# images are opaque) and frame_duration to 1 sec.
DEFI 1 IHDR ... IDAT ... IEND # Eight PNG datastreams
DEFI 2 IHDR ... IDAT ... IEND # are read and stored as
DEFI 3 IHDR ... IDAT ... IEND # abstract images, and
DEFI 4 IHDR ... IDAT ... IEND # are displayed as they
DEFI 5 IHDR ... IDAT ... IEND # are read.
DEFI 6 IHDR ... IDAT ... IEND
DEFI 7 IHDR ... IDAT ... IEND
DEFI 8 IHDR ... IDAT ... IEND
SAVE
SHOW 1 8
MEND
\212 M N G \r \n ^z \n # MNG signature.
MHDR 720 468 # Width and height.
1 # 1 tick per second.
FRAM 4 0 2 2 0 2 0 600 0 # Set frame_duration to 0,
# sync_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
\212 M N G \r \n ^z \n # MNG signature.
MHDR 720 468 # Width and height.
1 # 1 tick per second.
DEFI 1 1 1 # Define image 1, invisible, concrete.
IHDR ... IDAT ... IEND
FRAM 4 0 2 2 0 2 0 600 0 # set frame_duration to 0,
# sync_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
\212 M N G \r \n ^z \n # MNG signature.
MHDR 720 468 # Width and height.
30 # 30 ticks per second.
tEXtTitle\0Sample Movie
fPRI 0 128 # Default frame priority is "medium".
FRAM 1 0 2 0 0 0 3 # Set frame_duration 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.
\212 M N G \r \n ^z \n # MNG signature. MHDR 1024 512 1 # Width, height, ticklength. BACK 16448 16448 52800 1 # Must use sky blue background. DEFI 1 1 # Define invisible abstract thumbnail image. IHDR 64 64 4 3 0 0 0 IDAT IEND eXPI 1 "thumbnail 1" DEFI 1 1 # Also define a larger thumbnail. IHDR 96 96 4 3 0 0 0 IDAT IEND eXPI 1 "thumbnail 2" DISC # Discard the thumbnail image. FRAM 2 "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. gAMA 50000 IDAT ... IEND # End of image. CLON 1 2 0 0 1 0 518 6 # Make a full "concrete" clone. DHDR 2 1 5 # Modify it (no change to pixels). ORDR faLT 2 # Establish chunk placement. gAMA 100000 # 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 ... gAMA 50000 # We need a new gAMA because PLTE ... # this is not a Delta-PNG datastream. 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.
\212 M N G \r \n ^z \n # MNG signature.
MHDR 512 512 30 # Start of MNG datastream.
FRAM 2 "frame 1" 0 2 0 0 0 3 # First frame
# sets frame_duration=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 0 1 # make a full clone of it as image 3.
0 400 500 # Location for image 3.
DHDR 3 1 3 0 0 0 0 # Modify image 3.
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.
\212 M N G \r \n ^z \n # MNG signature.
MHDR 512 512 30 # 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
\212 M N G \r \n ^z \n # MNG signature.
MHDR 64 64 30 # Width, height, ticklength.
BACK 52800 52800 52800 # "Browser gray" default background.
FRAM 1 0 2 0 0 0 3 # Set frame_duration=3 ticks.
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 1 # 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 5 # 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 don't show it now.
LOOP 0 0 15
DHDR 2 1 5 # An image delta.
# Delta-type is 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.
\212 M N G \r \n ^z \n # MNG signature.
MHDR 150 150 1 # Width, height, ticklength.
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 subtraction,
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.
\212 M N G \r \n ^z \n # MNG signature. MHDR 1024 768 1 # Start of MNG datastream. 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 MENDHere is a better approach, which creates a reusable tiled image by means of the
\212 M N G \r \n ^z \n # MNG signature.
MHDR 1024 768 1 # Start of MNG datastream.
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
\212 M N G \r \n ^z \n # MNG signature.
MHDR 512 256 30 # Width and height on screen.
BACK 50000 50000 50000 0 # advisory gray background
DEFI 1 1 0 0 256 # Define image 1 but don't 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 4 0 2 0 0 0 0 # Frame_duration = 0 ticks.
# We use Framing_mode=4 to avoid unnecessary
# screen clearing between frames.
SHOW 1 # Show first image and continue without delay.
FRAM 4 0 2 0 0 0 1 # Frame_duration = 1 tick.
SHOW 2 # Composite second image over first, wait 1 tick.
ENDL 0
MEND
Alternatively, we can declare the scrolling object to
be the background:
(Same as above down to the LOOP chunk.)
BACK 50000 50000 50000 2 1 # Advisory gray background.
# Mandatory image background.
FRAM 1 0 2 0 0 0 1 # Frame_duration = 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
begin
write "MHDR" and "BACK" chunks
saved_images := 0
Frame_duration := 0
First_frame := TRUE
if(loops>1) "write tERm 2 0 0 loops" chunk
for subimage in gif89a file do
if(Frame_duration != gif_duration) then
Frame_duration := gif_duration
write "FRAM 2 0 2 2 0 2 0 Frame_duration 0" chunk
First_frame := FALSE
else if(First_frame == TRUE)then
write "FRAM 2" 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 "<image>"
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
Where "<image>" represents a PNG or Delta-PNG containing a
GIF frame converted to PNG format.
Caution: if you write such a program, you might have to pay royalties in order to convey it to anyone else.
Phone: (410) 278-6554
EMail: randeg@alumni.rpi.edu
End of MNG Specification. Expires 11 Mar 1999