File: png-mpng-proposal-20070321 It is proposed to register an animated PNG (MPNG) chunk: mPNG. In this proposal, the new chunk name is shown in its public form (second letter uppercase). Until the proposal is approved, the private form (second letter lowercase) 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 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 width and height parameters of the PNG IHDR 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 Chunk structure The mPNG chunk contains 14 bytes giving the width and height of the frames, num_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 (unsigned int) X offset of tile destination 20 y_offset (unsigned 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 There are no disposal methods in mPNG. Composition must be performed by alpha composition taking account of any pixels in the frame defined by previous tiles in the same frame, and never anything from the previous 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 0 marks the end of the frame. The decoder should display the frame after handling this tile and leave the frame displayed for a delay equal to (delay_num/delay_den) seconds. If delay_den is 0, the delay is indefinite regardless of the value of delay_num. 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 (delay_num/delay_den) seconds 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 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 frame is terminated by the IEND chunk and the 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, whether terminated by a nonzero delay or by the IEND chunk 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 it has been decoded. It can be composited on the canvas, which is the same 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 place the frame on the canvas. D. Add to the Appendix: Revision History * 30 April 2007 (version 1.4.0): * Added the mPNG animation chunk.