Animated Portable Network Graphics

Animated Portable Network Graphics

An animated PNG featuring a bouncing ball (requires recent versions of common web browsers)
Filename extension	.png
Type of format	animated PNG
Extended from	PNG

The Animated Portable Network Graphics (APNG) file format is an unofficial extension to the Portable Network Graphics (PNG) specification. It allows for animated PNG files that work similarly to animated GIF files, while supporting 24-bit images and 8-bit transparency not available for GIFs. It also retains backward compatibility with non-animated PNG files. Its main purpose is said to be in GUI and XUL application usage, but open usage on the Web is also expected.^{[citation needed]}

The first frame of an APNG file is stored as a normal PNG stream, and so most old PNG decoders will be able to display the first frame of an APNG file. The frame speed data and extra animation frames are stored in extra chunks (as provided for by the original PNG specification).

APNG competes with Multiple-image Network Graphics (MNG), a powerful format for bitmapped animations created by the same team as PNG. APNG's advantage is the smaller library size and compatibility with older PNG implementations.

History

The APNG specification was created in 2004 by Stuart Parmenter and Vladimir Vukicevic of the Mozilla Corporation. APNG support was added to the ubiquitous libpng by a Seneca College student during the Google Summer of Code in 2006. Mozilla Firefox eventually added support for APNG in Firefox 3 trunk builds on 23 March 2007.^[1] Iceweasel 3 does not support APNG^[2].

The PNG group officially rejected APNG as an official extension on April 20, 2007.^[3] There have been several subsequent proposals for a simple animated graphics format based on PNG using several different approaches.^[4] Among the maintainers of the PNG and MNG formats, APNG was not received well for several reasons. MNG provides all the features APNG provides, but is not supported at all by PNG-only decoders. APNG uses a technically feasible solution for storing any frames except the first, but the majority of the PNG group thinks this conflicts with the purpose of the PNG format – which is to store a single image. APNG would be compatible to this vision with alterations to its signature and intended MIME type, but these would break the desired backwards compatibility.

Application support

• KSquirrel as of version 0.7.2 (October 3, 2007)
• XnView as of version 1.92 (December 19, 2007)
• Opera as of version 9.5 (June 12, 2008)^[5]
• Mozilla Firefox as of version 3 (June 17, 2008)

Technical details

A PNG file consists of the PNG Signature (8 special bytes), followed by a series of so called chunks. A chunk consists of four parts: Length (4 bytes), Chunk type (4 bytes), Chunk data (length bytes) and CRC (Cyclic Redundancy Code / Checksum, 4 bytes).

Structure of a single PNG chunk

There are about 20 different chunk types, but for a minimal PNG, only 3 are required: The IHDR (image header) chunk, one or more IDAT (image data) chunks and the IEND (image end) chunk.

Structure of a very simple PNG file

The next graphic shows the contents of such a minimal PNG file, representing just one red pixel. The PNG signature bytes and the individual chunks are marked with colors. On the left side, the byte values are shown in hex format, on the right side in the ANSI charset. This dual display is common for hex editors. Note that the chunks are easy to identify because of their human readable 4-byte type names (in this example IHDR, IDAT & IEND).

Hex view of a very simple PNG file, representing a single red pixel

The APNG specification introduces three new chunks: The animation control chunk (acTL), the frame control chunk (fcTL) and the frame data chunk (fdAT). The animation control chunk is a kind of 'marker' chunk, telling the parser that this is an animated png. It contains information about how many frames the animation consists of and how many times the animation should play before coming to rest. The frame control chunk contains several bits of information, the most important of which is the display time of the following frame. The frame data chunks have the same structure as the IDAT chunks, except preceded by a sequence number.

A program wanting to assemble several individual PNG files to an animated PNG could proceed as follows: (1) Take the whole first PNG file as a building basis. (2) Insert an animation control (acTL) chunk after the image header (IHDR) chunk. (3) Then for each of the remaining frames, insert a frame control (fcTL) and a frame data (fdAT) chunk before the image end (IEND) chunk. The frame data (fdAT) chunks contain a copy of the image data (IDAT) chunk data. The next diagram illustrates this process.

Diagram illustrating a possible way to assemble an animated png from 3 individual PNG files

The PNG specification was designed with future extensions in mind. An application reading a PNG file is supposed to simply ignore any chunks which it does not understand. This is the reason why APNG is 'backwards compatible'. Existing applications just recognize the first frame and ignore the additional animation chunks.

References

External links

• The APNG specification at mozilla.org’s Wiki
• Mozilla's APNG Demo Site
• Animated PNG Portal Site
• Implementation work
• converter from Animated SVG to APNG as a Firefox extension
• Gif to Apng Converter
• APNG tests for browsers supporting APNG 1.0