File: png-mpng-proposal-20070323

It is proposed to register an animated PNG (MPNG) chunk: mpNG.

In this proposal, the new chunk name is shown in its private form (second
letter lowercase).  Until the proposal is approved, the private form
must be used in any test implementations.

It is proposed to document the mpNG chunk in the
Extensions to the PNG 1.2 Specification, Version 1.3.0, as follows:

A. Change document version to 1.4.0.

B. Add to the chunk ordering table:

      mpNG    No      Before IDAT

C. Add paragraph 4 and renumber subsequent paragraphs

4. mpNG Animation Chunk

4.1 Overview

The mpNG chunk contains a "play list" which provides instructions to
the decoder for constructing animation frames from pieces of the main
PNG image.  A viewer that does not recognize the mpNG chunk will simply
display the entire PNG image which will have the appearance of a montage
of tiles.

4.1 Terminology

The "canvas" is the area on the output device on which the images
are to be written.  The contents of the canvas are not available
to the decoder.

The "frame" is a pixel array with dimensions specified by
the "frame_width" and "frame_height" parameters of the mpNG chunk.
Conceptually, the images are constructed in the frame and then written
to the canvas.  The contents of the frame are available to the decoder.
The corner pixels of the frame are mapped to the corners of the
canvas.

4.2 MIME type and file extension

Since a PNG with the mpNG chunk meets the PNG file syntax
specification, authors can present them as "image/png" and use
the ".png" extension.  Authors who wish to distinguish clearly
between static images and animations can use MIME type
"video/x-mng" and file extension ".mng" for MPNGs.

4.3 mpNG Chunk structure

The mpNG chunk contains 14 bytes giving the width and height of the 
frames, number of iterations, compression flag, compression method and
followed by one or more 28-byte tile structures:

       byte
        0   frame_width  (unsigned int)    Width of frames
        4   frame_height (unsigned int)    Height of frames
        8   num_iterations (unsigned int)  Number of times to loop this 
                                           animation.  0: infinite looping
        12  compression_flag (byte)        0: uncompressed; 1: compressed
        13  compression_method (byte)      0: deflate
        14  tile_structure_array[n]       (n > 0; n * 28 bytes)   First
                                          tile structure

Each frame is a montage of one or more tiles which are combined
to form a frame of size (frame_width, frame_height).  This frame
may then be displayed by an mpNG capable decoder.  Each frame is
initialized to a transparent black (RGBA(0,0,0,0)) rectangle of
dimensions frame_width by frame_height.

A tile is a structure of 28 bytes:

       byte
        0    x         (unsigned int)   Left of tile pixels
        4    y         (unsigned int)   Top of tile pixels
        8    width     (unsigned int)   Width of tile pixels
       12    height    (unsigned int)   Height of tile pixels
       16    x_offset  (signed int)     X offset of tile destination
       20    y_offset  (signed int)     Y offset of tile destination
       24    delay_num (unsigned short) Frame delay numerator
       26    delay_den (unsigned short) Frame delay denominator

The tile data identifies a rectangle (x,y,width,height) in the PNG
image containing pixels of the tile.  This rectangle is composited
on the frame at top left position (x_offset, y_offset).  Any part of the
tile outside the PNG image must be treated as transparent.  Any
part of the tile which extends outside the frame must be ignored.

4.4 Composition and delays

Composition must be performed by alpha composition taking account of
any pixels in the frame defined by previous tiles in the same frame.
Notice that this may result
in pixels with partial alpha (neither 0 nor 1); the composition must
take this into account and is expected to interpret the color space
chunks (in particular gAMA) correctly when doing this.

The first tile with delay_num different from zero marks the end of the frame.
The decoder should display the frame after handling this tile and leave
the frame displayed for a frame delay equal to (delay_num/delay_den) seconds.
If delay_den is zero, the frame delay is infinite regardless of the value of
delay_num.

If possible, viewers should make the frame delay interruptible by a user input.
When a delay is interrupted, the decoder can give the user a choice of
advancing to the next frame, quitting, or other options.

If composition of the next frame takes longer than the frame delay
from the previous frame the decoder should display
the next frame immediately.  This frame should, itself, be displayed for 
a duration given by its own frame delay.   That is to say a decoder should not
catch up delays in preceding frames.

If the final tile described has a zero delay, then the tile marks the end
of the final frame, and that frame is not shown if the display is
iterating.  This frame must be displayed after the final iteration, when
the animation comes to rest.  Decoders should use the final frame
for any purpose where a static image is desired instead of an animation.

Once the frame has been constructed, it be handled in the same manner as
a regular PNG image after decoding.  It can be composited on the canvas,
which is the same physical size as the frame and is opaque.  Information
from the pHYs chunk may be used in this step, when the canvas pixels and
the frame pixels are not the same size.  Information from the oFFs chunk
may be used to locate the frame on the canvas.


D. Add to the Appendix: Revision History

       * 30 April 2007 (version 1.4.0):

             * Added the mpNG animation chunk.