https://wiki.mozilla.org/api.php?action=feedcontributions&feedformat=atom&user=Andrew 2026-10-19T03:06:30Z User contributions MediaWiki 1.39.10 https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=210889 2010-03-24T23:08:07Z

<p>Andrew: </p> <hr /> <div>APNG 1.0<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith16@littlesvr.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [http://www.w3.org/TR/PNG/ PNG] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [http://www.w3.org/Graphics/GIF/spec-gif89a.txt GIF] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corners of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order with the range 0 to (2^16)-1; a &quot;byte&quot; shall be an 8-bit unsigned integer with the range 0 to (2^8)-1.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [http://www.w3.org/TR/PNG/ PNG Specification], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described below.<br /> <br /> Conceptually, at the beginning of each play the output buffer must be completely initialized to a fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks, which have the same structure as `IDAT` chunks, except preceded by a sequence number. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose ordering restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> (none) `acTL`<br /> 0 `fcTL` first frame<br /> (none) `IDAT` first frame / default image<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> (none) `acTL`<br /> (none) `IDAT` default image<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the time to display the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound.<br /> <br /> Frame timings should be independent of the time required for decoding and display of each frame, so that animations will run at the same rate regardless of the performance of the decoder implementation.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> If the first `fcTL` chunk uses a `dispose_op` of APNG_DISPOSE_OP_PREVIOUS it should be treated as APNG_DISPOSE_OP_BACKGROUND.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that the second variation of the sample code is applicable.<br /> <br /> Note that for the first frame the two blend modes are functionally equivalent due to the clearing of the output buffer at the beginning of each play.<br /> <br /> The `fcTL` chunk corresponding to the default image, if it exists, has these restrictions:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, the output buffer must be completely initialized to fully transparent black at the beginning of each play. This is to ensure that each play of the animation will be identical. Decoders are free to avoid an explicit clear step as long as the result is guaranteed to be identical. For example, if the default image is included in the animation, and uses a `blend_op` of APNG_BLEND_OP_SOURCE, clearing is not necessary because the entire output buffer will be overwritten.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> At least one `fdAT` chunk is required for each frame. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is the complete pixel data of a PNG image, including the filter byte at the beginning of each scanline, similar to the uncompressed data of all the `IDAT` chunks. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> == From 0.10 ==<br /> <br /> * No changes<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> *Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> *An encoder (open source) is available in Mozilla versions newer than alpha 4.<br /> *An application (open source) using the Mozilla encoder to assemble APNGs available here: http://littlesvr.ca/apng/apngedit.html<br /> <br /> = A. References =<br /> <br /> *http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> *http://pmt.sourceforge.net/specs/png-1.2-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> *http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> *http://www.animatedpng.com &quot;APNG Project - official Site&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=Canvas:3D&diff=103990 2008-08-13T18:37:19Z

<p>Andrew: link for source code</p> <hr /> <div>The Canvas 3D project aims to add support for low-level hardware accelerated (where possible) 3D rendering via the HTML &lt;tt&gt;canvas&lt;/tt&gt; element. Some of the original ideas and thoughts surrounding the 3D canvas are available on [[Canvas:3D/Historical|historical notes page]], and more recent thoughts and plans are at various other documents below.<br /> <br /> The Canvas 3D context(s) will be delivered in the form of a Firefox addon, with the possibility of shipping by default with Firefox 3. Please see the Roadmap for schedule and release plans. Discussion around both the development of the canvas 3D addon as well as for applications taking advantage of the 3D capabilities can take place at the [https://labs.mozilla.com/forum/index.php/board,9.0.html|Canvas 3D Discussion Forum at Mozilla Labs].<br /> <br /> == Contents ==<br /> <br /> * [https://labs.mozilla.com/forum/index.php/board,9.0.html Canvas 3D Discussion Forum at Mozilla Labs]<br /> * [[Canvas:3D/Roadmap|Roadmap]]<br /> * [[Canvas:3D/DevDayBoston0307|Notes from 3D session at Boston Developer Day, March 2007]]<br /> * [[Canvas:3D/Historical|Historical notes (original Canvas 3D documentation)]]<br /> * [http://www.c3dl.org/ JavaScript library implementation work]<br /> * [http://hg.mozilla.org/users/vladimir_mozilla.com/canvas3d/ Firefox extension source code]<br /> <br /> == Related Links ==<br /> <br /> * [http://www.opengl.org/ OpenGL Home Page]<br /> * [http://khronos.org/opengles/ OpenGL ES Home Page and Specifications]</div>

Andrew https://wiki.mozilla.org/index.php?title=Canvas:3D&diff=94101 2008-05-22T03:40:37Z

<p>Andrew: /* Contents */</p> <hr /> <div>The Canvas 3D project aims to add support for low-level hardware accelerated (where possible) 3D rendering via the HTML &lt;tt&gt;canvas&lt;/tt&gt; element. Some of the original ideas and thoughts surrounding the 3D canvas are available on [[Canvas:3D/Historical|historical notes page]], and more recent thoughts and plans are at various other documents below.<br /> <br /> The Canvas 3D context(s) will be delivered in the form of a Firefox addon, with the possibility of shipping by default with Firefox 3. Please see the Roadmap for schedule and release plans. Discussion around both the development of the canvas 3D addon as well as for applications taking advantage of the 3D capabilities can take place at the [https://labs.mozilla.com/forum/index.php/board,9.0.html|Canvas 3D Discussion Forum at Mozilla Labs].<br /> <br /> == Contents ==<br /> <br /> * [https://labs.mozilla.com/forum/index.php/board,9.0.html Canvas 3D Discussion Forum at Mozilla Labs]<br /> * [[Canvas:3D/Roadmap|Roadmap]]<br /> * [[Canvas:3D/DevDayBoston0307|Notes from 3D session at Boston Developer Day, March 2007]]<br /> * [[Canvas:3D/Historical|Historical notes (original Canvas 3D documentation)]]<br /> * [http://www.c3dl.org/ JavaScript library implementation work]<br /> <br /> == Related Links ==<br /> <br /> * [http://www.opengl.org/ OpenGL Home Page]<br /> * [http://khronos.org/opengles/ OpenGL ES Home Page and Specifications]</div>

Andrew https://wiki.mozilla.org/index.php?title=Canvas:3D&diff=84285 2008-02-21T03:22:53Z

<p>Andrew: added link</p> <hr /> <div>The Canvas 3D project aims to add support for low-level hardware accelerated (where possible) 3D rendering via the HTML &lt;tt&gt;canvas&lt;/tt&gt; element. Some of the original ideas and thoughts surrounding the 3D canvas are available on [[Canvas:3D/Historical|historical notes page]], and more recent thoughts and plans are at various other documents below.<br /> <br /> The Canvas 3D context(s) will be delivered in the form of a Firefox addon, with the possibility of shipping by default with Firefox 3. Please see the Roadmap for schedule and release plans. Discussion around both the development of the canvas 3D addon as well as for applications taking advantage of the 3D capabilities can take place at the [https://labs.mozilla.com/forum/index.php/board,9.0.html|Canvas 3D Discussion Forum at Mozilla Labs].<br /> <br /> == Contents ==<br /> <br /> * [https://labs.mozilla.com/forum/index.php/board,9.0.html Canvas 3D Discussion Forum at Mozilla Labs]<br /> * [[Canvas:3D/Roadmap|Roadmap]]<br /> * [[Canvas:3D/DevDayBoston0307|Notes from 3D session at Boston Devloper Day, March 2007]]<br /> * [[Canvas:3D/Historical|Historical notes (original Canvas 3D documentation)]]<br /> * [http://littlesvr.ca/canvas3d/blog/ JavaScript library implementation work]<br /> <br /> == Related Links ==<br /> <br /> * [http://www.opengl.org/ OpenGL Home Page]<br /> * [http://khronos.org/opengles/ OpenGL ES Home Page and Specifications]</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=69225 2007-09-24T07:20:16Z

<p>Andrew: </p> <hr /> <div>APNG 1.0<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@littlesvr.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corners of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order with the range 0 to (2^16)-1; a &quot;byte&quot; shall be an 8-bit unsigned integer with the range 0 to (2^8)-1.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described below.<br /> <br /> Conceptually, at the beginning of each play the output buffer must be completely initialized to a fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks, which have the same structure as `IDAT` chunks, except preceded by a sequence number. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose ordering restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> (none) `acTL`<br /> 0 `fcTL` first frame<br /> (none) `IDAT` first frame / default image<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> (none) `acTL`<br /> (none) `IDAT` default image<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the time to display the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound.<br /> <br /> Frame timings should be independent of the time required for decoding and display of each frame, so that animations will run at the same rate regardless of the performance of the decoder implementation.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> If the first `fcTL` chunk uses a `dispose_op` of APNG_DISPOSE_OP_PREVIOUS it should be treated as APNG_DISPOSE_OP_BACKGROUND.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that the second variation of the sample code is applicable.<br /> <br /> Note that for the first frame the two blend modes are functionally equivalent due to the clearing of the output buffer at the beginning of each play.<br /> <br /> The `fcTL` chunk corresponding to the default image, if it exists, has these restrictions:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, the output buffer must be completely initialized to fully transparent black at the beginning of each play. This is to ensure that each play of the animation will be identical. Decoders are free to avoid an explicit clear step as long as the result is guaranteed to be identical. For example, if the default image is included in the animation, and uses a `blend_op` of APNG_BLEND_OP_SOURCE, clearing is not necessary because the entire output buffer will be overwritten.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> At least one `fdAT` chunk is required for each frame. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is the complete pixel data of a PNG image, including the filter byte at the beginning of each scanline, similar to the uncompressed data of all the `IDAT` chunks. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> == From 0.10 ==<br /> <br /> * No changes<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> An encoder (open source) is available in Mozilla versions newer than alpha 4.<br /> <br /> An application (open source) using the Mozilla encoder to assemble APNGs available here: http://littlesvr.ca/apng/apngedit.html<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://pmt.sourceforge.net/specs/png-1.2-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=69069 2007-09-20T21:43:14Z

<p>Andrew: </p> <hr /> <div>APNG 1.0<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@littlesvr.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corners of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described below.<br /> <br /> Conceptually, at the beginning of each play the output buffer must be completely initialized to a fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks, which have the same structure as `IDAT` chunks, except preceded by a sequence number. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose ordering restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the time to display the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound.<br /> <br /> Frame timings should be independent of the time required for decoding and display of each frame, so that animations will run at the same rate regardless of the performance of the decoder implementation.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> If the first `fcTL` chunk uses a `dispose_op` of APNG_DISPOSE_OP_PREVIOUS it should be treated as APNG_DISPOSE_OP_BACKGROUND.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> Note that for the first frame the two blend modes are functionally equivalent due to the clearing of the output buffer at the beginning of each play.<br /> <br /> The `fcTL` chunk corresponding to the default image, if it exists, has these restrictions:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, the output buffer must be completely initialized to fully transparent black at the beginning of each play. This is to ensure that each play of the animation will be identical. Decoders are free to avoid an explicit clear step as long as the result is guaranteed to be identical. For example, if the default image is included in the animation, and uses a `blend_op` of APNG_BLEND_OP_SOURCE, clearing is not necessary because the entire output buffer will be overwritten.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> At least one `fdAT` chunk is required for each frame. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is the complete pixel data of a PNG image, including the filter byte at the beginning of each scanline, similar to the uncompressed data of all the `IDAT` chunks. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> == From 0.10 ==<br /> <br /> * No changes<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> An encoder (open source) is available in Mozilla versions newer than alpha 4.<br /> <br /> An application (open source) using the Mozilla encoder to assemble APNGs available here: http://littlesvr.ca/apng/apngedit.html<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=AUS&diff=65567 2007-08-16T20:54:21Z

<p>Andrew: </p> <hr /> <div>AUS stands for Application Update Service<br /> <br /> = Project Pages =<br /> * [[AUS:Requirements|AUS Requirements]]<br /> * [[AUS:Roadmap|AUS Roadmap]]<br /> * [[AUS:Manual|AUS Manual]]<br /> * [[Software_Update:Nightly_update_infrastructure|AUS Walkthrough (nightly focus)]]<br /> * [[Software_Update:updates.xml_Format|AUS XML format definition]]<br /> * [[AUS:Tests|AUS Testing]]<br /> * [http://lxr.mozilla.org/mozilla/source/webtools/aus AUS Source]<br /> ** [http://lxr.mozilla.org/mozilla/source/webtools/aus/xml/ AUS XML source]<br /> ** [http://lxr.mozilla.org/mozilla/source/webtools/aus/sanity/ AUS Sanity script]<br /> ** [http://lxr.mozilla.org/mozilla/source/webtools/aus/tests/ AUS Acceptance tests]<br /> * [http://lxr.mozilla.org/mozilla/source/testing/release/ AUS/Release Verification scripts]<br /> <br /> = Contacts =<br /> * XML portion - morgamic<br /> * Patcher - build team</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=64503 2007-08-03T20:42:47Z

<p>Andrew: </p> <hr /> <div>APNG 1.0<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corners of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described below.<br /> <br /> Conceptually, at the beginning of each play the output buffer must be completely initialized to a fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks, which have the same structure as `IDAT` chunks, except preceded by a sequence number. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose ordering restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the time to display the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound.<br /> <br /> Frame timings should be independent of the time required for decoding and display of each frame, so that animations will run at the same rate regardless of the performance of the decoder implementation.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> If the first `fcTL` chunk uses a `dispose_op` of APNG_DISPOSE_OP_PREVIOUS it should be treated as APNG_DISPOSE_OP_BACKGROUND.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> Note that for the first frame the two blend modes are functionally equivalent due to the clearing of the output buffer at the beginning of each play.<br /> <br /> The `fcTL` chunk corresponding to the default image, if it exists, has these restrictions:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, the output buffer must be completely initialized to fully transparent black at the beginning of each play. This is to ensure that each play of the animation will be identical. Decoders are free to avoid an explicit clear step as long as the result is guaranteed to be identical. For example, if the default image is included in the animation, and uses a `blend_op` of APNG_BLEND_OP_SOURCE, clearing is not necessary because the entire output buffer will be overwritten.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> At least one `fdAT` chunk is required for each frame. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is the complete pixel data of a PNG image, including the filter byte at the beginning of each scanline, similar to the uncompressed data of all the `IDAT` chunks. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> == From 0.10 ==<br /> <br /> * No changes<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> An encoder (open source) is available in Mozilla versions newer than alpha 4.<br /> <br /> An application (open source) using the Mozilla encoder to assemble APNGs available here: http://littlesvr.ca/apng/apngedit.html<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=Bookmarks_Use_Cases&diff=60472 2007-06-26T01:08:11Z

<p>Andrew: /* Favorites on the Start menu */</p> <hr /> <div>This page is meant for describing particular behaviours you would like to see in a revamped Bookmark system.<br /> <br /> == Reintroduction of a Necessary feature==<br /> &lt;ol&gt;<br /> &lt;li&gt;why can't you use Alt-Enter to access the properties of a bookmark? &lt;/li&gt;<br /> <br /> &lt;li&gt;I really like Firefox but I find that it is missing one key feature for me to transition from Mozilla 1.7.12 to Firefox 1.5.0.4, that is the lack of the same Mozilla &quot;Bookmark This &lt;u&gt;G&lt;/u&gt;roup of Tabs&quot; feature in Firefox. <br /> <br /> Now I know that Firefox has a &quot;Bookmark All Tabs...&quot; option but unlike Mozilla it creates a folder just like any other and has an option to &quot;open in tabs&quot; at the bottom of the folder. I can see why they did this and it would be nice to be able to enter a bookmark group to access only one tab... Yet it is something that is really rarely needed and could be done by hovering over the tab group for a short while.<br /> <br /> Now this might seam like a minor gripe considering all the other positives Firefox has over Mozilla, Yet I am truly addicted to the bookmark group in Mozilla and there are a few main reasons behind this:<br /> *it looks different than the other folders and is easy to distinguish<br /> *one simple click on the bookmark group to open it<br /> *The &quot;Bookmark This &lt;u&gt;G&lt;/u&gt;roup of Tabs&quot; defaults to show you the file tree (for lack of a better term) giving you a quicker way to save the bookmark group.<br /> <br /> Now I have been unable to find any extention that would allow me to use the same Mozilla bookmark group functions inside of Firefox. Is it possable that this could be included? Pretty please! &lt;/li&gt;<br /> &lt;/ol&gt;<br /> I REALLY would LOVE a solution to this Please help.... Thanks! -- [[User:UKPhoenix79|UKPhoenix79]] 23:21, 13 July 2006 (PDT)<br /> <br /> == Smart Folders and Tagging ==<br /> <br /> I would like to be able to sort my bookmarks into &quot;Smart Folders,&quot; and have those folders contain bookmarks based on various criteria, including by way of a user-definable &quot;tagging&quot; system.<br /> <br /> For example, let's say I have a few dozen bookmarks. Some tagged with &quot;News,&quot; some with &quot;Games&quot; and others with &quot;Ottawa.&quot; Some of these bookmarks are Live Bookmarks, and others are just regular old bookmarks. I would like to have one Smart Folder that contains all of the &quot;News&quot; + &quot;Ottawa&quot; bookmarks, another with &quot;News&quot; + &quot;Games,&quot; another with just &quot;Games,&quot; a fourth with just &quot;News,&quot; and a final with all the Live Bookmarks, regardless of tagging or other criteria.<br /> <br /> === Basically already available ===<br /> <br /> You can create a bookmark to a url like [find:datasource=rdf:bookmarks&amp;match=http://home.netscape.com/NC-rdf#Name&amp;method=contains&amp;text=Mozilla].<br /> <br /> This will give you a &quot;folder&quot; with all bookmarks containing &quot;Mozilla&quot; in their name, dynamically generated. I don't really know how flexible this can be used and where you can find more documentation about it, but the basic functionality is available.<br /> :Um... how do you do this?<br /> <br /> == More on Smart Folders ==<br /> <br /> Smart Folders are sounding a lot like vfolders/iTunes Smart Playlists/stored queries. Some other cool things that could be done with smart folders: &quot;All bookmarks I've visited in the last week&quot;, &quot;Top 10 Bookmarks I've most frequently visited&quot;. More complex stuff maybe? &quot;All bookmarks I've visited and spent more than 10 min on the page&quot;. (How do you track how long you spend on a page?)<br /> <br /> Another cool thing: When bookmarking, have it check del.icio.us and then return a dialog that goes something like this: <br /> &quot;This page has been tagged accordingly:<br /> [x] web [x] css [x]news [ ] html<br /> Add own tags: [............]&quot;<br /> This feature would save quite a lot of people a lot of tagwork.<br /> <br /> (Perhaps just the framework for such integration could be put in place. It seems to me that integration with del.icio.us or any other non-mozilla site should be an extension, not part of the core code.)<br /> <br /> == Add Bookmark Dialog ==<br /> <br /> The &quot;Add Bookmark&quot; dialog should have some way to add comments or tags. And these comments or tags should be searchable from the side bar. Just a small dialog box below the &quot;Create In&quot; dropdown would be great.<br /> <br /> == Add/Edit Bookmark in Sidebar –�Information Management ==<br /> <br /> Bookmarks could become an active workspace when the �Add Bookmark�? form would be placed in the sidebar and when the same form in the sidebar would be used to show all saved tags and descriptions simultaneously with the opened website. The Flat Bookmark Extension is a good example of improved usability within the bookmark manager because it avoids the extra step to open the dialog every time a note needs to be changed. Unfortunately, it is not yet integrated in the sidebar nor associated with the opened website. The flat editing of tags, annotations, citations, notes, etc. in the sidebar every time the website is loaded would make it to an information management because it can recall information and changes are easy to enter. Direct access to the description field and to the tags of a bookmark could be a major step forward and improve the usability of web browsers.<br /> <br /> == Keyword Option for Bookmark Folders ==<br /> <br /> What about adding keywords to bookmark folders like we have for bookmarks? That would be smooth. Then you can open a folder from the search bar. This would be very useful for opening a group of bookmarks in a subfolder, instead of accessing from the bookmarks toolbar. The keyword should trigger the &quot;open in tabs&quot; command.<br /> <br /> See: [https://bugzilla.mozilla.org/show_bug.cgi?id=213402 bug 213402]<br /> <br /> ''Don't like surprises, just want the keywords added to folders, bring up bookmarks sidebar if and only if needed, but not the<br /> opening of all bookmarks in that folder.'' <br /> <br /> I like typing in a single letter within a folder on the personal toolbar to get to the area I want (actually usually one letter beyond what I want) and if there is only one bookmark beginning with that letter it goes to that bookmark, I add a fake bookmark for such cases to stop that from happening so I can examine my choices. To open an entire folder of bookmarks; likewise, is going to open<br /> up a can of worms -- would not like 500 bookmarks opened up into tabs. There<br /> is a suggestion elsewhere to add use of Ctrl select to select individual<br /> bookmarks but is dependent upon bookmarks not disappearing once a selection is made and that would be further jeopardy if all bookmarks in a folder are automatically opened.<br /> <br /> == Keyword Shortcuts in Sidebar ==<br /> <br /> The &lt;b&gt;[https://addons.mozilla.org/firefox/1043/ KeywordBar]&lt;/b&gt; Extension<br /> (for sidebar)<br /> including double-click to place keyword shortcut onto the location bar,<br /> and the &lt;b&gt;<br /> [https://addons.mozilla.org/firefox/622 Locate in Bookmarkfolders]&lt;/b&gt; Extension to locate the folder of the keyword<br /> or other bookmark within the Bookmarks Manager should be incorporated into Firefox. These inclusions would give the keyword shortcuts (%S) a much more deserving prominence in Firefox.<br /> <br /> == Unread Items in Live Bookmarks ==<br /> <br /> For me to use Live Bookmarks instead of just defaulting to my RSS reader, the &quot;new&quot; or simply &quot;unread&quot; bookmark items would need to be differentiated from &quot;old&quot; or &quot;read&quot; items. If I could just visually and quickly scan for new items, I would be much more likely to use Live Bookmarks.<br /> <br /> It would be nice if bookmarks supported the CSS ''':visited''' pseudo-class, which would be an elegant way of solving this enchantment and would probably be useful in general.<br /> <br /> If live bookmark items were marked &quot;read&quot; or &quot;unread&quot; as described above, I'd love to have a button on the toolbar called &quot;Next unread&quot; to jump between all the new items. If the button showed a count of the unread items, that would be even better.<br /> <br /> == LiveBookmarks Homepage ==<br /> <br /> I'd like to click in a LiveBookmark Folder and go to the feed's homepage, e.g. If the feed url is http://www.mozilla.org/rss.xml clicking in the LiveBookmark folder should lead to http://www.mozilla.org/<br /> <br /> == Aggregated Live Bookmarks in a Smart Folder ==<br /> <br /> I'd like to be able to designate a Smart Folder for Live Bookmarks that would display all items (possibly even only the &quot;new&quot; or &quot;unread&quot; items) contained by that set of Live Bookmarks at once (instead of having to open each Live Bookmark individually).<br /> <br /> For example, I have three Live Bookmarks, each of which contains 10 items in total. The first has three new items, the second has 2 new items, and the third has 6 new items. If I designate a Smart Folder to display all &quot;new&quot; Live bookmark items, it would look something like this:<br /> <br /> &lt;pre&gt;<br /> &gt; My Super Smart Folder Name<br /> &gt; Bookmark 1 New Item 1<br /> &gt; Bookmark 1 New Item 2<br /> &gt; Bookmark 1 New Item 3<br /> &gt; Bookmark 2 New Item 1<br /> &gt; Bookmark 2 New Item 2<br /> &gt; Bookmark 3 New Item 1<br /> &gt; Bookmark 3 New Item 2<br /> &gt; Bookmark 3 New Item 3<br /> &gt; Bookmark 3 New Item 4<br /> &gt; Bookmark 3 New Item 5<br /> &gt; Bookmark 3 New Item 6<br /> &lt;/pre&gt;<br /> <br /> Being able to specify how those items are sorted as part of the Smart Folder properties would be an extra bonus (e.g., by date, by site, alphabetically, or whatever).<br /> <br /> == Bookmarks Combined From Several Files ==<br /> <br /> Currently all bookmarks for a user (well, profile) are stored in ''bookmarks.html''. It is possible to share that file with others (by doing things that Firefox remains blissfully unaware of, such as using symlinks or synching the file), but that only works for sharing the ''entire'' bookmarks; I've encountered several situations where I wish to share just some of my bookmarks, a subtree of them say:<br /> <br /> * I use Firefox at both home and work. Generally, I do different things in each place, so they have different bookmarks: at work, I have lots of prominent links to internal systems, which I hardly ever need to access from home. However, there are some bookmark folders I'd like to have in both places, such as those with links to technical reference material like the W3C specs.<br /> <br /> * Everybody in the team at work needs bookmarks (with keywords for URL searches) to the same internal systems. We've all had to accumulate these individually. It would be nice just to have them in one place, so we know they are all exactly the same (and new people can easily be given them, too).<br /> <br /> * Sometimes, I give presentations using Firefox for rendering HTML slides. I have a separate profile for that, with settings more appropriate for use in front of an audience on a big screen, but it'd be nice to have a subset of my normal bookmarks available.<br /> <br /> Obviously, this wouldn't be trivial to do, and is very hard to do well. At the moment, I don't think it's possible at all. The bare minimum support that I think is needed from Firefox is the ability to combine bookmark subtrees from different sources. That is, that at some point in ''bookmarks.html'' there can be a 'linked folder' which renders just like an ordinary folder but whose content is stored in a separate file; ''bookmarks.html'' just contains the folder's label and the path to that file.<br /> <br /> Then all the synching can be managed outside Firefox (or with extensions or whatever) —�so long as the basic 'subtree combining' feature is there (even if it requires manually setting up) other things can be added on top of it.<br /> <br /> This could be done in conjuntion with tagging. Create an option to export either subfolders or bookmarks with certain tags into a portable XML file that can then be imported elsewhere.<br /> <br /> == Remote Bookmarks ==<br /> <br /> Building on Live Bookmarks, it would be great to be able to store your bookmarks on a server, but be able to interact with them through the normal bookmarks manager. <br /> Adding and deleting bookmarks should work as usual, but with the results being stored remotely, on a server (such as http://del.icio.us).<br /> <br /> I agree! I use different computers at home, work, and school, and love having access to one respository of &quot;bookmarks,&quot; stored online. Having a slick interface to such a repository would be an excellent, often-used feature.<br /> <br /> This is the one reason that I have abandoned traditional bookmarks in favor of a web-based solution, [http://www.myhq.com myhq.com]. <br /> Another option is to use a third-party toolbar such as http://toolbar.a9.com/<br /> <br /> Building on this idea further: There are some bookmarks that I would want to share with others. It would be nice to syndicate them with RSS and display them on a website as a feed or formatted with CSS. This could be through a service or via a plugin for blogging software.<br /> <br /> The other point here is that there are cases where I don't want to share my bookmarks. E.g. links to financial information, services like my web host and my flickr login. I keep these in a separate folder so I would only need to exclude that folder from export.<br /> <br /> On the synchronization of bookmarks, you might want to check out how that is handled in [http://mirror.open-xchange.org/ox/EN/community/ Open-Xchange.]<br /> <br /> I would love to be able to get rid of bookmarks folders altogether with tagging. As such I wouldn't want to have to keep private bookmarks in a different folder than public/shared bookmarks<br /> <br /> I, too agree with this. Have a simple xml file (hopefully hosted by mozilla, but of course with its limits... maybe google could help out ;) ). When you load firefox, firefox would check for any changes to the file on the server. If none are found, it stops. If changes are found, it downloads them.<br /> <br /> Saving bookmarks could either be instantly (this may cause a small wait period for slower users), when the bookmark list is not being used, or 'onClose' if that even exists.<br /> <br /> Using [http://www.opml.org/ OPML] might be a win for this over RSS. OPML allows for hierarchical data like bookmark folders. Also bookmarks are more of a list type thing than a feed type thing. Of course you could have both.<br /> <br /> Including features found in: [http://sourceforge.net/projects/bookmarksync bookmarksync] would be great. This is a big issue for me, too. - and being able to edit and change the hosting server as a preference would be great. thx.<br /> Looks like [http://www.sync2it.com/b2/index.php synch2it] has done more development on the client and server side, too - features from here should give good ideas. The #1 most important bookmarking feature for me is when I need to synch bookmarks between my home computers, my work computers, and my laptop, and extra nice if I can get to them when I'm an internet cafe.<br /> <br /> Being able to specify a particular bookmark folder to point to a particular file on a WebDAV server would be useful. The code would seem to be around as part of the Sunbird project where it is used to sync up local and remote ical files. That would make it easy to share a sub-tree of your bookmarks between locations/computers/people and give some control over who gets to add/change and who gets to read only.<br /> <br /> The first post pretty much had it! You should be able to edit your bookmarks through Firefox as per usual, and then an extension or something would silently sync your bookmarks with a server somewhere. This way no matter where you go you could always have your same bookmarks available to you. Also, on the idea of making your bookmarks publicly available, all you would need to do is add a little locked/unlocked button besides each bookmark to control which ones are public and private.<br /> <br /> == Relative Bookmarks ==<br /> Provide Relative Bookmark features for '''profile''', '''chrome''', '''cache''' folders, and portable device '''drive letter''' (Firefox Portable), along with user assigned folders to provide better access from any computer and with various portable devices. <br /> <br /> profile://. (for the profile folder itself)<br /> profile://.. (up one level from the profile folder)<br /> profile://bookmarks.html (simple way to locate bookmarks)<br /> cache://. (experienced users may move the cache file)<br /> <br /> This would greatly simplify locating these folders for user browsing and editing as needed, and identifying the profile actually in use.&amp;nbsp;<br /> <br /> === Additional Relative Bookmarks features for Portability ===<br /> For a presentation file:///c:\big\pathname\file.htm#relativebookmarks might be referred to by that name on the c: drive and on a portable device have part of filename given a shortcut type descriptor <br /> presentation://file.htm#relativebookmarks<br /> which would facilitate use of existing keyword shortcuts <br /> presentation://%S<br /> presentation://chapter4/%S <br /> Note %S currently provides for fragment id (file.htm#id); and %s currently does not. <br /> <br /> The means of bookmarking a string reference to a relative tag, so existing<br /> bookmarks remain as they are but could be treated differently on a portable device. Any bookmark starting with c:/site could also be found with the '''portable://''' prefix.<br /> <br /> presentation = file:///c:/big/pathname/<br /> portable = file:///c:/site<br /> portable2 = http://www.example.com/user3/<br /> <br /> And specifically to address reassignments when using USB devices used in such implementations as Firefox Portable (http://portableapps.com/apps/internet/firefox_portable) one must<br /> currently use SUBST to alias a drive or a pathname in a command<br /> window external to both Firefox and Firefox bookmarks.<br /> <br /> To alias a drive letter to a path on the active drive (external to Firefox)<br /> SUBST W: \firefoxportable\data\profile <br /> <br /> To alias a drive letter to the current drive letter (external to Firefox)<br /> SUBST X: \<br /> <br /> This assumes that you would be able to have specific drive letters not assigned (W: and X:) so that you can create aliases. <br /> <br /> The above usage implementation suggestions should not conflict with the use of user defined keyword shortcuts of portable:, presentation:, presentation:b, which when used as keyword shortcuts have a space immediately after the shortcut. The use of colons in all my keyword shortcuts has proved very advantageous to me.<br /> <br /> == Meta Description ==<br /> <br /> The default description for a bookmark should be filled in with the description provided by the meta tag.<br /> <br /> It would also be useful when looking through the bookmarks list if the description for a bookmark were displayed when a user pauses on the bookmark (i.e. alt text). The only time one sees a bookmark's description is in the bookmarks manager. This should be integrated as standard, and would be very simple to implement as well.<br /> <br /> == Richer Links ==<br /> <br /> Right now, the only relationships possible between bookmarks are ordinal (they can be in a series) and hierarchical. Only the title and description may be specified by the user. The meaningful relationships between two sites/bookmarks are not constrained to this set. Allowing the user (or website providing the link) to provide additional information would allow bookmarking to more accurately represent the mental relationships the user has between sites.<br /> <br /> Propositionally, support for bookmarking xlinks would provide the informational basis for these enriched relationships.<br /> <br /> Examples of user interaction possible with interrelationships:<br /> <br /> A user drags a link to a bookmark region, which expands to show a &quot;space&quot; of bookmarks. The user places the bookmark in a rhizomatic relationship to another bookmark. That information is stored in the bookmark as it is saved.<br /> <br /> A laptop user bookmarks a page &quot;within 250 feet of this location.&quot; in the future, whenever she is in that physical region, the bookmark moves to the top of her bookmarks list.<br /> <br /> A website designer could specify the relationships between her pages using xlink; when bookmarked, a user could navigate the site from the bookmark without loading the site.<br /> <br /> == Editing and Synchronization ==<br /> <br /> Mainly, my largest issue now is that I always keep a very close watch on my bookmarks, and when editing them, I find the two-pane navigation helpful, but ineffective. The reason I need two panes is because when moving bookmarks from a temp folder to its final location, I need to see both folders at once - I hate having to drag and drop while waiting for auto-scrolling. If the two panes would both be expandable to view folders and bookmarks it would be much more useful!<br /> <br /> Right now the left pane is useless to me, because I can already see the folder structure in the right pane. <br /> <br /> My bookmarks file has been organized and reorganized for almost four years now, and at 300k I don't have time to clean it out all of the time. I would love a field on each bookmark to either show the last date I edited it, or the last date I visited that address. Then I could see which bookmarks I have not seen in a long time, and then delete those as I obviously don't need them. That would be an amazing feature!<br /> <br /> I use the bookmarks synchronizer extension all of the time, so I still need to have that ability.<br /> <br /> I have a large number of bookmarks that point to a mirror server. If that server goes down or its domain changes (this has happened more than once), I can open my bookmarks file in an ASCII editor and globally change the domain of all affected bookmarks to another mirror. PLEASE do not change the format of the bookmarks file in a way that will prevent me from doing this without at least adding a global change capability to the Bookmarks Manager.<br /> <br /> == &quot;Bookmark current site here&quot; ==<br /> <br /> When the user opens the Bookmarks-menu and ''right-clicks'' on a '''Bookmark folder''', the '''&quot;Bookmark current site here&quot;''' option could appear in the popped up '''context menu'''. (Or is &quot;Add Bookmark here&quot; better?)<br /> <br /> This is a very simple suggestion, but I want to record it here anyway, so it won't be forgotten. I used to like the &quot;Add bookmark here&quot;-extension (though I don't know if it's still maintained). It'd be cool to have it built in by default ( -- perhaps with a modification: In the extension, the option appeared ''among/below'' the actual bookmarks, but doesn't that clutter up the menus too much?)<br /> <br /> Currently (using a Nighly from the Deer Park trunk -- Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050705 Firefox/1.0+), when right-clicking on a Bookmark folder, the '''New Bookmark''' option appears in the popped up context menu. The user can fill in a new Name, Location, Keyword and Description. <br /> <br /> Something like this is what I'm looking for -- though I would want the Name, Location etc of the '''current site''' to be '''pre-filled in as default values'''.<br /> <br /> Bookmark Synchronization API - I would love to see a simple API for adding new bookmarks and deleting existing bookmarks via an external application. Two simple functions that would greatly simplify cross-browser synchronization.<br /> <br /> == Standard Extensibility from Chrome ==<br /> <br /> Having looked up a bookmark node by ID/URL/etc., found it via iteration, whatever... an extension should be able to watch for onclick events, et al (the addObserver notes imply bookmark changes only, not events).<br /> <br /> Bookmark context menus should be extensible via normal XUL overlays. <br /> <br /> This is an area where the current code is just terrifying.<br /> <br /> == Visual Bookmarks ==<br /> <br /> Visual bookmarks are a screen shot of a bookmarked webpage created the last time it was visited or when the bookmark is created. The idea is that visually oriented people --aka designers-- would likely remember a website more by it's design and appearance than the name or current title of the website that they saw for the split second while they click '''OK''' on the '''Add Bookmark''' Window. Another reason for visual bookmarks is when people are use to a website for it's design and have stopped visiting it regularly for a while, and when they are fumbling through their bookmarks looking for it again it may have changed it's design. With '''Visual Bookmarks''', a screen capture could be made of the old design to help them realize that what they are looking for well, isn't anymore. <br /> <br /> To implement it there should be an array of options like file format, screenshot dimensions, history, and update interval. File format/saving options are self explanitory and really a high quality JPEG or PNG would be best. The dimensions of the screenshot would be equivilent to setting the inner part of the window to exactly 900x900 or 3600x800 and taking the inner screenshot from there; assuming they entered 900x900 or 3600x800, it could be anything. It is important that they are NOT setting the window size as menu bars etc would be variable between clients and frivilous. A screenshot history option are how many out of date screenshots to keep, perhaps a redesign locator which could compare screen shot similarities to detect a design change, but that is probably FAR to ambitious. The update interval would be the frequency screenshots are to be updated, set globally and per screenshot.<br /> <br /> The output of these screenshots would appear perhaps when a bookmark is hovered over or in the '''Manage Bookmarks...''' window.<br /> <br /> <br /> === Color in bookmarks ===<br /> I'd like to also see the possibility of color in bookmarks, so it becomes easy to for instance separate bookmarks for hotel sites from bookmarks from airlines sites in a travel bookmark folder<br /> <br /> == Automatic Grouping of Bookmarks ==<br /> <br /> I would love to see a system that would allow automatic grouping of similar bookmarks, being too lazy to keep my ever growing bookmarks properly categorized.<br /> <br /> In another section someone has suggested tagging for categorization. I have situations where a site I visit is both a source of news and a source of reviews for instance. How cool would it be if you typed a bookmark tag into the address bar and it opened, in tabs, all the bookmarks that had that tag?<br /> <br /> How about mozilla learning how you categorize your bookmarks? Say you have a bookmark folder of all your css design tips. After a while, mozilla would smarten up, and the next time you bookmark a similar site, it would offer to automatically put that site into your css design tips folder. Could this be done with some bayesian filtering?<br /> <br /> == Search Behavior ==<br /> <br /> I rarely resort to search except when I can't find a bookmark. Move, Properties and Rename are currently &quot;grayed out&quot; in bookmark search (filtered) results. I've found the bookmark, but it's clumsy to manage it. The only way I've found is to copy the URL, Delete the bookmark and then bookmark it again. Enabling those options, or at least the &quot;Move&quot; option would be a big help in keeping large collections of bookmarks tidy.<br /> <br /> In general it would be nice to access bookmarks by a search field (not in bookmark manager) - could even be in the bookmark toolbar, optional.<br /> <br /> <br /> == Shortcut to Bookmarks Manager ==<br /> <br /> Need a shortcut key to the Bookmarks Manager (&quot;Manage Bookmarks...&quot;)<br /> would affect additions to keywords in HELP, Bookmarks menu and View menu. Bookmarks (Ctrl+B) is not the same as Bookmaks Manager.<br /> <br /> Also a means of referencing Bookmarks Manager or a specific webpage<br /> on starting up Firefox from the desktop (shortcut url) as there are <br /> many that seem to think a Favorites folder on the system desktop (Windows desktop) is where to start off from.<br /> <br /> == Enhanced Bookmark Search ==<br /> Enhanced Bookmark Search (Extension) could use some improvement in filtering capability (AND logic), but should be incorporated into Firefox.<br /> <br /> == Shortcuts ==<br /> <br /> It would be nice to be able to assign shortcuts to bookmarks and bookmark folders.<br /> <br /> If &quot;shortcuts&quot; means virtual bookmarks that point to other bookmarks such that, when the target bookmark is changed, the shortcut is automatically changed too, this is [https://bugzilla.mozilla.org/show_bug.cgi?id=34059 bug #34059]. At least part of this was a capability in Netscape 4 and should definitely be implemented. Note that the [http://pyxml.sourceforge.net/topics/xbel/ XBEL] standard supports the old Netscape aliasing of bookmarks.<br /> <br /> The ability to open external programs and documents (like Windows shortcuts) on the computer would be very useful. There are some extensions currently that do similar things to this.<br /> <br /> A strong second on this suggestion. The ability to import MSIE Favorites is crippled without this.<br /> <br /> == Bookmark Maintenance ==<br /> Over the long term, the bookmarks list becomes less useful as it becomes weighed down with the cruft of bookmarks that have lost usefulness for various reasons including:<br /> * The page is gone (404)<br /> * The page has moved somewhere else (301/302)<br /> * The information has fallen out of date<br /> * The user has forgotten why the page was worth bookmarking<br /> * The user lost track of the original bookmark, making redundant bookmarks<br /> (no doubt this list can be expanded)<br /> <br /> :: The GNOME Epiphany browser detects when a link has moved and offers to update the bookmark location. That's pretty handy.<br /> :: [[User:Mikelward|Mikelward]] 03:14, 7 June 2007 (PDT)<br /> <br /> Eventually it becomes easier to Google for the links anew rather than hunt through the unweildy bookmark list. Faciliating management of these issues would be very helpful for maintaining a streamlined, functional list. Some possibilities:<br /> <br /> === Live Collections Using Advanced Metadata ===<br /> Similar to the Live Folders concept mentioned above, but allow bookmarks to be automatically collected based on metadata ''other than'' just tags (such as server-provided data).<br /> <br /> For instance, periodically do HTTP HEAD requests to bookmarked addresses, and flag those that return statuses other than 200 OK. Collected into live folders based on their status codes, the user would be able to easily cull dead links and decide whether to update the moved ones.<br /> <br /> Likewise, allow bookmarks to be grouped based on criteria such as last access date (to cull, or rediscover, links you never use anymore), the page's Last-Modified date (to identify resources that have grown irrelevant), and duplicate/similar addresses (including those that have obviously different URLs but would become redundant based on a 301/302 status update).<br /> <br /> If the client-side metadata (such as last access) could be shared across workstations (i.e. between work and home computers), that would also be cool.<br /> <br /> === Visual Cues in Bookmarks Menu ===<br /> Favicons and screenshot previews are helpful visual cues about a bookmark. Extend this concept to other metadata. For instance, maybe the user would want 404s to be grayed out, and recently-visited links to be bolded. Or certain tags might be asssociated with small graphics similar to favicons, so the user can quickly skim down a long list, identify the few bookmarks that meet his/her criteria (ex. &quot;IE + hacks + 4stars&quot;)--even through he doesn't recall their titles.<br /> <br /> This could also be done through the use of super-imposed mini-icons over the favicon. It would be similar to the shortcut arrow that windows and mac users are familiar with. Perhaps a tiny '''(X)''' in the bottom right side of the favicon for a bookmark that was a 404, or a colored star system for the rating, etc.<br /> <br /> === Bookmarks Menu Sorting===<br /> Allow user-defined sorting of the Bookmarks menu. Chronological order quickly becomes non-meaningful in a long list. Allow sorting by title, domain, or date, etc. <br /> <br /> A pair of persistent no-sort options too, please, on a folder by folder basis. No sort folder contents only, no sort entire folder substructure. I often do not want particular folders sorted, particularly when exporting bookmarks to edit them into a web page. If you also increased the size of the manager's description form, I could go back to using the bookmarks tools as a handy outliner like I did in Mozilla. A related enhancement: enable separate exporting of bookmarks folder substructures with a templating capability so users and developers can more easily define export formats, and add export to clipboard (rather than a file) as an option. Fore some ideas on implementation, see the CopyURL-Plus extension, the handiest browser extension on my desktop.--Marbux<br /> <br /> It would also be useful to be able to sort the folders/subfolders separately from the individual pages. (naowro)<br /> <br /> === Mac-Compatibile Shortcuts in Bookmark Manager ===<br /> Add support for command-deleting (the standard Mac shortcut for &quot;delete selection&quot;) of bookmarks and folders in Bookmark Manager.<br /> <br /> == Sorting ==<br /> <br /> I like to keep my bookmarks (mostly) sorted alphabetically (by Name), per folder. Right now, I need to do this sorting manually! The Bookmark Manager provides for a sorted *View* but this does not actually sort the bookmarks themselves. They still appear unsorted in the Bookmarks menu. What I would like to do is make any selection of bookmarks in the Manager, and be able to sort them alphabetically, once and for all, Sorted view or not. Being able to sort an entire folder without first having to make a (rather huge, in some cases) selection would also help, but this alone is not enough. Sometimes I keep several sections in a folder using Separators, and I want each section sorted separately.<br /> <br /> We already do Sorting with View, so it seems simple enough to go the extra mile and save the sort result to disk again. Actually I'm surprised no one has come up with this before, I've wanted it for a long time, and sorting is a basic function of any information management system.<br /> <br /> In addition to saving the sorting with a view to disk (for both the manager and the bookmarks view itself), the ability to apply differing sorting algorithms (alphabetically, last visited date etc.)<br /> <br /> == Multiple Keywords == <br /> <br /> Having a keyword for a bookmark is great. Sometimes however, there are sites for which multiple keywords would make sense, and I can never remember the one that I actually used. It would greatly help if the Keywords field would accept multiple keywords, perhaps separated by a space or a comma.<br /> <br /> [New &quot;I&quot;] A feature that I would find useful would be a cross-referencing indexing system-- Keywords would be entered for each bookmark (or Tag). The bookmark would be added automatically to folders titled with each keyword. For example-- if a bookmark had keywords of {photos, winter, camping, cooking}, it would appear in folders Photos, Winter, Camping, -and- Cooking.<br /> <br /> This would NOT duplicate the bookmark, but just add it to an additional index. That way, a change under one folder would appear under all folders. [Yes, I've just designed in a database.] And deleting one entry would remove it from all folders it appeared in (with a suitable warning about removing an entry from multiple folders).<br /> <br /> Within each folder I could sort the accumulated entries according to any attributes of the original entry.<br /> <br /> == More on sorting ==<br /> <br /> Sorting should be as flexible as possible: in addtion to the existing sorting, you should be able to sort folders by one specific criteria, or just a group of selected folders or bookmarks within one folder (by doing CTRL+item selection and then right click + &quot;sort selected items by...&quot;)<br /> <br /> Related firefox bug:<br /> [https://bugzilla.mozilla.org/show_bug.cgi?id=265401]<br /> has been closed as WONTFIX. Please vote for this bug to get this resolved.<br /> <br /> == More on bookmark maintenance ==<br /> <br /> Having an automatic checking of bookmarks option would be nice, so you could get a warning if one URL you have bookmarked is now re-directed or is no longer available.<br /> <br /> <br /> == &quot;Open in tabs&quot; option improvement ==<br /> <br /> In addition to the existing option, it should be possible to open selected items (bookmarks or entire folders) in tabs (by doing CTRL+item selection and then right click + &quot;open selected items in tabs&quot;). This option should be available through the Bookmarks Manager too.<br /> <br /> <br /> == Bookmarks access ==<br /> <br /> Would it be possible to have the &quot;Bookmark this page&quot; and &quot;Manage Bookmarks&quot; items from the Bookmarks menu always fixed, so they don't disappear when scrolling down the Bookmarks menu?<br /> <br /> <br /> == Temporary/Time Based Bookmarks ==<br /> I think many of us frequently need to save websites we wish to return but don't want to keep them bookmarked forever. For instance when I comment on blogs I often like to return to reply to the discussion later but if I kept every article I'd commented on in my bookmarks it would rapidly grow unwieldy. An earlier contributor uses bookmarks for keeping a 'to visit' list and would like to be reminded about the contents of the list when non-empty. Similar use cases would be remembering items you are comparing to purchase, funny pages you want to show friends, long articles you are reading, remembering conferences or other events that will lose relevance shortly, and remembering stories to write a blog entry about.<br /> <br /> In firefox 2 this sort of use is very cumbersome. With 'add bookmark here' bookmarks can be added efficently enough but every time one wants to remove bookmarks you need to go to the manage bookmark's screen. Some more efficent means of removing temporary bookmarks is needed, perhaps several. The following features all seem good:<br /> <br /> 1) Expiration times for bookmarks, when created you can specify a date on which the bookmark will be deleted/become invisible.<br /> <br /> 2) Folder based expiration times, particular folders could time out bookmarks when they age past a certain date.<br /> <br /> 3) Most recently used display with bookmarks disappearing after they fall below some threshold.<br /> <br /> 4) The above but at the user's request.<br /> <br /> 5) Easy option to delete without entering the organize bookmarks page.<br /> <br /> Of course all of these really need appropriate sort option.<br /> <br /> :: How about a special tag called &quot;temp&quot; that only keeps things for one or two days?<br /> :: How about a tag &quot;new&quot; that is removed as soon as you click on it?<br /> :: How about per-tag expiry rules?<br /> :: [[User:Mikelward|Mikelward]] 03:12, 7 June 2007 (PDT)<br /> <br /> == POST bookmarks ==<br /> Some website searches dumbly use POST instead of GET so you can't just associate a simple keyword and smart bookmark. Making it possible to store POST requests would prevent me from writing boring javascript bookmarklets.<br /> <br /> <br /> == Links to other bookmarks and folders ==<br /> It would be nice to be able to create the equivalent of symlinks for individual bookmarks and folders. A use for this would be to include a current bookmark or folder on the Bookmarks Toolbar Folder without having to make another copy of it. This would close<br /> [https://bugzilla.mozilla.org/show_bug.cgi?id=298009 bug #298009].<br /> <br /> == Offline readable ==<br /> In the bookmark properties dialog, I'd like to see a check box asking me if the page should be offline readable. This would be similar to the &quot;Select this folder for offline use&quot; option in Thunderbird. As far as I know, other browsers like IE (sorry) have had this feature for quite a while.<br /> This option should not only be present in the properties dialog of an individual bookmark but also in the properties dialog of a bookmark folder.<br /> <br /> == Personal Toolbar Folder / Bookmarks Toolbar ==<br /> I like to keep a large number of items in the Personal Toolbar Folder, but I remove the &quot;Name&quot; from the properties, leaving only the favicon. However, when I hover over the favicon, only the URL is shown in the tooltips text. I'd like to be able to have the name of the site in the tooltip text, but not next to the item in the toolbar. Perhaps this could be achieved by having a &quot;Show?&quot; checkbox next to the Name in the Properties window?<br /> <br /> === Display of Folders on the Personal Toolbar ===<br /> Kind of the opposite approach of the above, but can be worked in together with options.<br /> <br /> Space on the Personal Toolbar is too valuable to waste on individual bookmarks,<br /> so would like the ability to show folder names without folder icon, and they<br /> must be distinguishable from adjacent folder names even if the name contains spaces, and must be distinguishable from individual bookmarks. I give all<br /> folders that show on the Personal Toolbar short names. So if they could appear in a small variable width box that would be ideal. For example everything in my &quot;K&quot; folder actually also has a keyword shortcut. Some like blogs have additional<br /> subfolders, several of which are groups of bookmarklets. My bookmarks Toolbar looks something like: (the first two have leading spaces to maintain sort order)<br /> &lt;br&gt;&amp;nbsp; [ HOME] [ View] [Blogs] [Design] [Effects] [G] [I] [ID] [K] [R] [T] [zA] ...<br /> <br /> There are actually individual bookmarks on far right, all of which are on the extended toolbar, perhaps with more space the favicon only might get some of them on the primary portion of the toolbar.<br /> <br /> == Bookmark Display == <br /> <br /> In a [http://www.mozillazine.org/talkback.html?article=5444 poll] conducted by MozillaZine last year about home pages, a number of respondents indicated they use their bookmarks file as their home page. The ability to do this should not only be preserved but enhanced. One enhancement would be to fix [https://bugzilla.mozilla.org/show_bug.cgi?id=234831 bug #234831], to recognize line breaks the Description portion of a bookmark. Another would be to implement [https://bugzilla.mozilla.org/show_bug.cgi?id=255274 bug #255274], to have the capability of having a style-sheet control the display format (e.g., line spacing, margins, font size). Of course, all this should include making the bookmarks file a valid HTML file, including a &lt;!DOCTYPE&gt; declaration. <br /> <br /> Another display bug that should be fixed is [https://bugzilla.mozilla.org/show_bug.cgi?id=245934 #245934]. The Bookmarks Manager normalized window size is forgotten if the window was maximized when it was closed.<br /> <br /> == Bookmark Added Already Message ==<br /> <br /> I would be happy to have a function that can check if the Bookmark I'm adding now isn't added already (in any section of Bookmark folder). Well, I know there might be a confusion because of dynamic URIs for example but could save some doubled Bookmarks...<br /> <br /> <br /> == More on Search ==<br /> And please include a field or property that shows where a bookmark is in the bookmark folder tree. This is needed when your re-grouping bookmarks. Currently, if you search on a bookmark and find a few related ones, there's no way to tell where they are on the bookmark tree and if they need to be moved/re-grouped to a more rational structure.<br /> <br /> In addition, please have a look at the bookmark manager<br /> of the old Netscape Communicator 4.78. In contrast to Firefox, <br /> the old bookmark editor of Netscape Communicator is very fast <br /> and convenient. Moving and copying bookmarks between <br /> (sub)folders is much faster than with Firefox and Mozilla,<br /> in particular, on Sun Solaris. Please learn from the old editors!<br /> <br /> In particular, I have hundreds of folders and subfolders<br /> with thousands of bookmarks. And the function <br /> &quot;Find in Bookmarks&quot; of Netscape Communicator <br /> allows to search for text in bookmarks as well as <br /> in folder/subfolder titles and to jump from one <br /> search hit to the next search hit within the tree.<br /> <br /> Example: Using the search string &quot;Java&quot;, it is very useful <br /> to find all subfolders titled &quot;Java applications/programming/etc.&quot; <br /> contained in diverse folders named &quot;applications&quot; and &quot;programming&quot;. <br /> <br /> To sum up, make the folder titles and bookmarks<br /> searchable at the same time! The resulting list <br /> should return folders and bookmarks that contain the<br /> search string anywhere in their title/name/location/description/tags. <br /> Alternatively, the user should be able to jump from<br /> one hit to the next hit in the bookmark tree<br /> as it is implemented in the Netscape Communicator.<br /> <br /> If some user does not want to find folder titles,<br /> then the user should be able to turn this off.<br /> But I prefer to find not only bookmarks, but also<br /> folders containing my text in the title.<br /> <br /> == Projects ==<br /> I think it would be a very useful feature to be able to create projects with the Bookmarks tool. A project would be similar to a folder, only clicking that project folder would open all associated web pages, a page with relevant live bookmark feeds, and any programs or documents used in the project.<br /> <br /> <br /> == Favorites on the Start menu ==<br /> <br /> Since a part of firefox's appeal is its ability to run on older OSs, it would be nice if Firefox bookmarks could be put into the Favorites menu on the start menu.<br /> <br /> == Copying bookmarks to pasteboard ==<br /> <br /> This might be more appropriate as a Firefox extension, but as a web researcher/writer, I have often wished for an option in the context menu to copy and paste bookmarks to my text editor with the HTML markup intact. Perhaps even with options to include the bookmark's keywords, description, or other properties enabled through the planned conversion to database bookmarks storage? The [http://copyurlplus.mozdev.org/index.html CopyUrlPlus] extension is somewhat like I'm looking for, although it only works with web pages rather than bookmarks, and it would benefit from submenuing capability.<br /> <br /> ==Duplicate Handling==<br /> It would be nice if Firefox warned you about adding a bookmark that matches one with the same URL.<br /> <br /> I have a large list of bookmarks, e.g. 200+ with 30+ folders. Sometimes I bookmark the same page more than once (mainly by accident). it should deal with this intelligently, e.g., don't just add another entry, but preferably add any new description/tags to the old location, so that you don't have the same page bookmarked multiple times.<br /> <br /> Added thought: It would be nice to have a &quot;duplicate bookmark <br /> warning&quot;, with the options |add new one here|copy existing|cancel|<br /> <br /> ==Tagging and sharing==<br /> <br /> An interesting read is this blog entry:<br /> http://www.contentious.com/archives/2005/04/20/furl-delicious-almost-perfect-together<br /> which discusses one user's method of tagging and sharing. It has some good usages that should be considered for a new system.<br /> <br /> == Extend %s Hack ==<br /> <br /> Currently, the %s hack provides a tremendous degree of freedom for customization and is extremly powerful. But it could become more flexible when it would respond to the three cases: keyword only = empty string (and not %s), keyword with option = option string, and keyword only but marked text in the website = marked text (the option string should have a higher priority than marked text). This would extent all the wonderful search options to the text within the website so that copy and paste can be avoided.<br /> <br /> == Dynamic Bookmarks Search -- LiveFolders ==<br /> <br /> Adding input options to chrome URLs or a similar mechanisms would allow to bookmark dynamic search lists or &quot;LiveFolders&quot; and open them with keywords, e.g. <br /> chrome://browser/content/bookmarks/bookmarksManager.xul?search=rediscover<br /> <br /> == Favorites and Web Index in Two Different Interfaces ==<br /> <br /> The redesign of graphical interfaces for bookmarks must address two different purposes. One is a menu for quick access to websites and the other is a personal index of marked websites. Both concepts are important for the interaction with the web and have been kept in one interface over time. But it may be better to have two separate interfaces.<br /> <br /> The menu's purpose is fast access to frequently visited websites, also referred to as FAVORITES. In principle, its function is similar to program menus or to sidebars with a small number of items. In contrast to the function of favorites, there is a large number of bookmarks that have been saved because they were interesting or valuable. This personal WEB INDEX is a &quot;permanent history&quot; of marked websites. Searching this INDEX can provide pre-selected information very quickly. Tagging seems a perfect tool to categorize these bookmarks for the WEB INDEX in a very flexible, quick, and simple way.<br /> For more details please see: http://tdot.blog-city.com/rethinking_bookmarks_ui.htm<br /> <br /> == Machine-readable/processible bookmarks ==<br /> <br /> Bookmarks should be stored in some kind of XML format (e.g. RDF / RSS / Atom / whatever) so that they can be parsed automatically by scripts or other utilities. The existing format is very difficult (if not impossible) to parse, except for Firefox itself.<br /> <br /> == Exporting Bookmarks ==<br /> <br /> When we export bookmarks, it would be nice to have a property on each category and bookmark that could make them private and so, not exportable. This is important because if we want to share our bookmarks there are always bookmarks that should not be shared.<br /> <br /> If there was some automatism that would export public bookmarks to a server that also would be very interesting.<br /> <br /> == Exporting Folder(s) for Documentation ==<br /> <br /> Would like to be able to export a folder (with subfolders and bookmarks) as HTML <br /> retaining HREF, TITLE, SHORTCUTURL the and ability to discard timestamps and information not<br /> usually relevent to documentation (ADD_DATE, LAST_MODIFIED, LAST_CHARSET, ICON, generated ID). <br /> &lt;p&gt;<br /> Also see a need for a Bookmarks Documentation bookmarklet with the ability to do the same working from a selection within bookmarks.html to extract source to<br /> the clipboard.<br /> <br /> == Old style netscape bookmarks ==<br /> <br /> Bookmarks should be displayed in multiple columns side by side like the old netscape used to. Or at least there should be an option to do so. I have like, 2000 entries in my bookmark file. I don't sort them, nor group them. That way I always can go to the bottom of the list and reconstruct a chronological order. So if I want to know when I visited a site, I can do so. It is very time consuming to have to scroll down through all of these. In the old netscape 4.1 they would be displayed in columns like the program list is in windows 2000. That is my single biggest gripe about firefox. How do you make firefox do this?<br /> <br /> == Integrate bookmark backup into Firefox ==<br /> <br /> After reading enough reports in mozilla.feedback, bugzilla, etc., it is clear to me that it would be useful to incorporate some sort of bookmark backup within the browser. This needs to be something fairly simple - just an easy one touch way to backup their bookmarks so that all is not lost in the event something happens during update, etc. As bookmarks are the lifeblood of many users, I think this is a useful thing to consider. And I realize there are extensions available to do this, but many users either do not know about them or aren't willing to go the extra length to install an extension.<br /> <br /> == Sort entries in a live bookmark alphabetically instead of chronologically ==<br /> <br /> I use live bookmarks to display my bookmark collection from a social bookmarking service. However inside a single live bookmark, moazilla displays the entries (each entry being a different bookmarked url) in the order in which I added them on the social bookmarking service. I would like the option to make them appear sorted alphabetically, instead of sorted by time of addition.</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=59877 2007-06-19T20:41:52Z

<p>Andrew: removed notice about renaming chunks</p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corners of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described below.<br /> <br /> Conceptually, at the beginning of each play the output buffer must be completely initialized to a fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks, which have the same structure as `IDAT` chunks, except preceded by a sequence number. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose ordering restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the time to display the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound.<br /> <br /> Frame timings should be independent of the time required for decoding and display of each frame, so that animations will run at the same rate regardless of the performance of the decoder implementation.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> If the first `fcTL` chunk uses a `dispose_op` of APNG_DISPOSE_OP_PREVIOUS it should be treated as APNG_DISPOSE_OP_BACKGROUND.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> Note that for the first frame the two blend modes are functionally equivalent due to the clearing of the output buffer at the beginning of each play.<br /> <br /> The `fcTL` chunk corresponding to the default image, if it exists, has these restrictions:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, the output buffer must be completely initialized to fully transparent black at the beginning of each play. This is to ensure that each play of the animation will be identical. Decoders are free to avoid an explicit clear step as long as the result is guaranteed to be identical. For example, if the default image is included in the animation, and uses a `blend_op` of APNG_BLEND_OP_SOURCE, clearing is not necessary because the entire output buffer will be overwritten.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> At least one `fdAT` chunk is required for each frame. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is the complete pixel data of a PNG image, including the filter byte at the beginning of each scanline, similar to the uncompressed data of all the `IDAT` chunks. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> An encoder (open source) is available in Mozilla versions newer than alpha 4.<br /> <br /> An application (open source) using the Mozilla encoder to assemble APNGs available here: http://littlesvr.ca/apng/apngedit.html<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=59169 2007-06-11T14:19:54Z

<p>Andrew: /* Test Encoder and Sample Images */</p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corners of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described below.<br /> <br /> Conceptually, at the beginning of each play the output buffer must be completely initialized to a fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks, which have the same structure as `IDAT` chunks, except preceded by a sequence number. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose ordering restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the time to display the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound.<br /> <br /> Frame timings should be independent of the time required for decoding and display of each frame, so that animations will run at the same rate regardless of the performance of the decoder implementation.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> If the first `fcTL` chunk uses a `dispose_op` of APNG_DISPOSE_OP_PREVIOUS it should be treated as APNG_DISPOSE_OP_BACKGROUND.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> Note that for the first frame the two blend modes are functionally equivalent due to the clearing of the output buffer at the beginning of each play.<br /> <br /> The `fcTL` chunk corresponding to the default image, if it exists, has these restrictions:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, the output buffer must be completely initialized to fully transparent black at the beginning of each play. This is to ensure that each play of the animation will be identical. Decoders are free to avoid an explicit clear step as long as the result is guaranteed to be identical. For example, if the default image is included in the animation, and uses a `blend_op` of APNG_BLEND_OP_SOURCE, clearing is not necessary because the entire output buffer will be overwritten.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> At least one `fdAT` chunk is required for each frame. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is the complete pixel data of a PNG image, including the filter byte at the beginning of each scanline, similar to the uncompressed data of all the `IDAT` chunks. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> An encoder (open source) is available in Mozilla versions newer than alpha 4.<br /> <br /> An application (open source) using the Mozilla encoder to assemble APNGs available here: http://littlesvr.ca/apng/apngedit.html<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=54049 2007-04-05T19:17:58Z

<p>Andrew: /* Structure */</p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corners of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described below.<br /> <br /> Conceptually, at the beginning of each play the output buffer must be completely initialized to a fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks, which have the same structure as `IDAT` chunks, except preceded by a sequence number. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose ordering restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the time to display the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound.<br /> <br /> Frame timings should be independent of the time required for decoding and display of each frame, so that animations will run at the same rate regardless of the performance of the decoder implementation.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> If the first `fcTL` chunk uses a `dispose_op` of APNG_DISPOSE_OP_PREVIOUS it should be treated as APNG_DISPOSE_OP_BACKGROUND.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> Note that for the first frame the two blend modes are functionally equivalent due to the clearing of the output buffer at the beginning of each play.<br /> <br /> The `fcTL` chunk corresponding to the default image, if it exists, has these restrictions:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, the output buffer must be completely initialized to fully transparent black at the beginning of each play. This is to ensure that each play of the animation will be identical. Decoders are free to avoid an explicit clear step as long as the result is guaranteed to be identical. For example, if the default image is included in the animation, and uses a `blend_op` of APNG_BLEND_OP_SOURCE, clearing is not necessary because the entire output buffer will be overwritten.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> At least one `fdAT` chunk is required for each frame. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is the complete pixel data of a PNG image, including the filter byte at the beginning of each scanline, similar to the uncompressed data of all the `IDAT` chunks. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=54037 2007-04-05T17:55:30Z

<p>Andrew: </p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corners of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described below.<br /> <br /> Logically, at the beginning of each play the output buffer must be completely initialized to a fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks, which have the same structure as `IDAT` chunks, except preceded by a sequence number. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose ordering restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the time to display the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound.<br /> <br /> Frame timings should be independent of the time required for decoding and display of each frame, so that animations will run at the same rate regardless of the performance of the decoder implementation.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> If the first `fcTL` chunk uses a `dispose_op` of APNG_DISPOSE_OP_PREVIOUS it should be treated as APNG_DISPOSE_OP_BACKGROUND.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> Note that for the first frame the two blend modes are functionally equivalent due to the clearing of the output buffer at the beginning of each play.<br /> <br /> The `fcTL` chunk corresponding to the default image, if it exists, has these restrictions:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, the output buffer must be completely initialized to fully transparent black at the beginning of each play. This is to ensure that each play of the animation will be identical. Decoders are free to avoid an explicit clear step as long as the result is guaranteed to be identical. For example, if the default image is included in the animation, and uses a `blend_op` of APNG_BLEND_OP_SOURCE, clearing is not necessary because the entire output buffer will be overwritten.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> At least one `fdAT` chunk is required for each frame. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is the complete pixel data of a PNG image, including the filter byte at the beginning of each scanline, similar to the uncompressed data of all the `IDAT` chunks. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=53593 2007-03-31T23:14:50Z

<p>Andrew: </p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation, and the output buffer must be completely initialized to a fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk, at the beginning of each play.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks containing almost the same structure of content as `IDAT` chunks. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose ordering restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after displaying the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> The first `fcTL` chunk has these restrictions:<br /> * `blend_op` must be APNG_BLEND_OP_SOURCE<br /> * `dispose_op` must not be APNG_DISPOSE_OP_PREVIOUS <br /> <br /> The `fcTL` chunk corresponding to the default image has additional restrictions, if it exists:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, if a `fcTL` chunk does not precede `IDAT`, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each play.<br /> <br /> Together these requirements serve to ensure that each play of the animation will be identical.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> Each frame must contain at least one `fdAT` chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `oFFs` chunk is present, it supplies offsets of the canvas that are in addition to the frame's `x_offset` and `y_offset`.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=53509 2007-03-30T02:39:30Z

<p>Andrew: clarified that hidden frame still counted in num_frames</p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk, at the beginning of each play.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks containing almost the same structure of content as `IDAT` chunks. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. Even if the default image is not part of the animation it is still counted in num_frames. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after displaying the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> The first `fcTL` chunk has these restrictions:<br /> * `blend_op` must be APNG_BLEND_OP_SOURCE<br /> * `dispose_op` must not be APNG_DISPOSE_OP_PREVIOUS <br /> <br /> The `fcTL` chunk corresponding to the default image has additional restrictions, if it exists:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, if a `fcTL` chunk does not precede `IDAT`, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each play.<br /> <br /> Together these requirements serve to ensure that each play of the animation will be identical.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> Each frame must contain at least one `fdAT` chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `oFFs` chunk is present, it supplies offsets of the canvas that are in addition to the frame's `x_offset` and `y_offset`.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=53469 2007-03-29T18:56:48Z

<p>Andrew: iterations-&gt;plays</p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk, at the beginning of each play.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks containing almost the same structure of content as `IDAT` chunks. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each play, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_plays (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_plays` indicates the number of times that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last play.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after displaying the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> The first `fcTL` chunk has these restrictions:<br /> * `blend_op` must be APNG_BLEND_OP_SOURCE<br /> * `dispose_op` must not be APNG_DISPOSE_OP_PREVIOUS <br /> <br /> The `fcTL` chunk corresponding to the default image has additional restrictions, if it exists:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, if a `fcTL` chunk does not precede `IDAT`, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each play.<br /> <br /> Together these requirements serve to ensure that each play of the animation will be identical.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> Each frame must contain at least one `fdAT` chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `oFFs` chunk is present, it supplies offsets of the canvas that are in addition to the frame's `x_offset` and `y_offset`.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=53468 2007-03-29T17:37:26Z

<p>Andrew: </p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black rectangle, with width and height dimensions from the `IHDR` chunk, at the beginning of each iteration.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks containing almost the same structure of content as `IDAT` chunks. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each iteration, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last iteration. The number of iterations includes the first time the sequence is displayed.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after displaying the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> The first `fcTL` chunk has these restrictions:<br /> * `blend_op` must be APNG_BLEND_OP_SOURCE<br /> * `dispose_op` must not be APNG_DISPOSE_OP_PREVIOUS <br /> <br /> The `fcTL` chunk corresponding to the default image has additional restrictions, if it exists:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, if a `fcTL` chunk does not precede `IDAT`, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each iteration.<br /> <br /> Together these requirements serve to ensure that each iteration of the animation will be identical.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> Each frame must contain at least one `fdAT` chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `oFFs` chunk is present, it supplies offsets of the canvas that are in addition to the frame's `x_offset` and `y_offset`.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=53467 2007-03-29T17:23:01Z

<p>Andrew: clarified num_iterations</p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each iteration.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks containing almost the same structure of content as `IDAT` chunks. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each iteration, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last iteration. The number of iterations includes the first time the sequence is displayed.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after displaying the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> The first `fcTL` chunk has these restrictions:<br /> * `blend_op` must be APNG_BLEND_OP_SOURCE<br /> * `dispose_op` must not be APNG_DISPOSE_OP_PREVIOUS <br /> <br /> The `fcTL` chunk corresponding to the default image has additional restrictions, if it exists:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, if a `fcTL` chunk does not precede `IDAT`, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each iteration.<br /> <br /> Together these requirements serve to ensure that each iteration of the animation will be identical.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> Each frame must contain at least one `fdAT` chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `oFFs` chunk is present, it supplies offsets of the canvas that are in addition to the frame's `x_offset` and `y_offset`.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=53466 2007-03-29T17:20:32Z

<p>Andrew: added note about frames looking same each iteration</p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each iteration.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks containing almost the same structure of content as `IDAT` chunks. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> Each frame is identical for each iteration, therefore it is safe for applications to cache the frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last iteration.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after displaying the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> The first `fcTL` chunk has these restrictions:<br /> * `blend_op` must be APNG_BLEND_OP_SOURCE<br /> * `dispose_op` must not be APNG_DISPOSE_OP_PREVIOUS <br /> <br /> The `fcTL` chunk corresponding to the default image has additional restrictions, if it exists:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, if a `fcTL` chunk does not precede `IDAT`, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each iteration.<br /> <br /> Together these requirements serve to ensure that each iteration of the animation will be identical.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> Each frame must contain at least one `fdAT` chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `oFFs` chunk is present, it supplies offsets of the canvas that are in addition to the frame's `x_offset` and `y_offset`.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=53465 2007-03-29T17:14:50Z

<p>Andrew: increased restriction for blend_op and dispose_op</p> <hr /> <div>APNG 0.10 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to ignore the APNG-specific chunks and display a single image.<br /> <br /> == Terminology ==<br /> <br /> The &quot;default image&quot; is the image described by the standard `IDAT` chunks, and is the image that is displayed by decoders that do not support APNG.<br /> <br /> The &quot;canvas&quot; is the area on the output device on which the frames are to be displayed. The contents of the canvas are not necessarily available to the decoder. As per the PNG Specification, if a `bKGD` chunk exists it may be used to fill the canvas if there is no preferrable background.<br /> <br /> The &quot;output buffer&quot; is a pixel array with dimensions specified by the width and height parameters of the PNG `IHDR` chunk. Conceptually, each frame is constructed in the output buffer before being composited onto the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> &quot;Fully transparent black&quot; means red, green, blue and alpha components are all set to zero.<br /> <br /> For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Error Handling ==<br /> <br /> APNG is designed to allow incremental display of frames before the entire image has been read. This implies that some errors may not be detected until partway through the animation. It is strongly recommended that when any error is encountered decoders should discard all subsequent frames, stop the animation, and revert to displaying the default image. A decoder which detects an error before the animation has started should display the default image. An error message may be displayed to the user if appropriate.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. <br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> The default image may be included as the first frame of the animation by the presence of a single `fcTL` chunk before `IDAT`. Otherwise, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each iteration.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks containing almost the same structure of content as `IDAT` chunks. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> The boundaries of the entire animation are specified by the width and height parameters of the PNG `IHDR` chunk, regardless of whether the default image is part of the animation. The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first `fcTL` chunk must contain sequence number 0, and the sequence numbers in the remaining `fcTL` and `fdAT` chunks must be in order, with no gaps or duplicates.<br /> <br /> The tables below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk.<br /> <br /> If the default image is the first frame:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame (before `IDAT`)<br /> 1 `fcTL` second frame<br /> 2 first `fdAT` for second frame<br /> 3 second `fdAT` for second frame<br /> ....<br /> <br /> If the default image is not part of the animation:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` first frame<br /> 1 first `fdAT` for first frame<br /> 2 second `fdAT` for first frame<br /> ....<br /> <br /> Decoders must treat out-of-order APNG chunks as an error. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. If this value does not equal the actual number of frames it should be treated as an error.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final frame at the end of the last iteration.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the default image, if a `fcTL` chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the first frame excluding the default image (which may be either the first or second frame), the `fcTL` chunk must appear after all `IDAT` chunks and before the `fdAT` chunks for the frame.<br /> * For all subsequent frames, the `fcTL` chunk for frame N must appear after the `fdAT` chunks from frame N-1 and before the `fdAT` chunks for frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between `fdAT` chunks.<br /> <br /> Exactly one `fcTL` chunk is required for each frame.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by `x_offset`, `y_offset`, `width`, and `height`. The offsets must be non-negative, the dimensions must be positive, and the region may not fall outside of the default image.<br /> <br /> Constraints on frame regions:<br /> <br /> `x_offset` &gt;= 0<br /> `y_offset` &gt;= 0<br /> `width` &gt; 0<br /> `height` &gt; 0<br /> `x_offset` + `width` &lt;= `IHDR` width<br /> `y_offset` + `height` &lt;= `IHDR` height<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after displaying the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, `delay_num` then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> `dispose_op` specifies how the output buffer should be changed at the end of the delay (before rendering the next frame).<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 0 APNG_DISPOSE_OP_NONE<br /> 1 APNG_DISPOSE_OP_BACKGROUND<br /> 2 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; the contents of the output buffer are left as is.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region of the output buffer is to be cleared to fully transparent black before rendering the next frame.<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region of the output buffer is to be reverted to the previous contents before rendering the next frame.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer.<br /> <br /> Valid values for `blend_op` are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> The first `fcTL` chunk has these restrictions:<br /> * `blend_op` must be APNG_BLEND_OP_SOURCE<br /> * `dispose_op` must not be APNG_DISPOSE_OP_PREVIOUS <br /> <br /> The `fcTL` chunk corresponding to the default image has additional restrictions, if it exists:<br /> * The `x_offset` and `y_offset` fields must be 0.<br /> * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.<br /> <br /> As noted earlier, if a `fcTL` chunk does not precede `IDAT`, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each iteration.<br /> <br /> Together these requirements serve to ensure that each iteration of the animation will be identical.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same structure as an `IDAT` chunk, except preceded by a sequence number.<br /> <br /> Each frame must contain at least one `fdAT` chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAT` chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the default image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk.<br /> <br /> If the PNG `oFFs` chunk is present, it supplies offsets of the canvas that are in addition to the frame's `x_offset` and `y_offset`.<br /> <br /> If the PNG `pHYs` chunk is present, the APNG images and their `x_offset` and `y_offset` values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dispose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> == From 0.9 ==<br /> <br /> * Split render_op into dispose_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=52725 2007-03-22T23:08:43Z

<p>Andrew: </p> <hr /> <div>APNG 0.9 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> An `fcTL` chunk may also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0. If there is no fcTL chunk before IDAT, then frame 0 is intialized to RGBA(0,0,0,0) and the IDAT chunks are not used.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Terminology ==<br /> <br /> The &quot;canvas&quot; 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.<br /> <br /> The &quot;output buffer&quot; 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 output buffer and then written to the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first fcTL chunk must contain sequence number 0, and the sequence numbers in the remaining fcTL and fdAT chunks must be in order, with no gaps or duplicates.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` describing frame 0<br /> 1 `fcTL` describing frame 1<br /> 2 first `fdAT` for frame 1<br /> 3 second `fdAT` for frame 1<br /> ....<br /> <br /> or, when frame 0 is implicitly a transparent black frame:<br /> <br /> Sequence number Chunk<br /> 0 fcTL describing frame 1<br /> 1 first fdAT for frame 1<br /> 2 second fdAT for frame 1<br /> ....<br /> <br /> APNG viewers must abandon the APNG chunks in a datastream with out-of-order APNG chunks and display frame 0 instead. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, if the fcTL chunk is present it must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the second frame, the `fcTL` chunk must appear after the `IDAT` chunks from the first frame and before the fdAT chunks for the second frame.<br /> * For any subsequent frames, the `fcTL` chunk for the frame N must appear after the `fdAT` chunks from the frame N-1 and before the fdAT chunks for the frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between fdAT chunks.<br /> <br /> The fcTL chunk is mandatory for every frame except for frame 0. When it is present for frame 0, decoders must render frame 0 from the data in the IDAT chunks. When it is not present for frame 0, frame 0 is a transparent black frame (all pixels are RGBA(0,0,0,0)) and the IDAT chunks are ignored. More than one fcTL chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTL`, and the width and height from the `IHDR` chunk.<br /> <br /> The width and height must be greater than zero and must not be bigger than (respectively) the width and height specified in the IHDR chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the area defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 1 APNG_DISPOSE_OP_NONE<br /> 2 APNG_DISPOSE_OP_BACKGROUND<br /> 4 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; its contents are left on the output buffer. This is the default.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region is to be cleared to the background color. If no bKGD chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region is to be reverted to the previous contents.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer. Valid `blend_op` values are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> APNG_BLEND_OP_OVER is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> `blend_op` must be APNG_BLEND_OP_SOURCE for frame 0.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> Each frame must contain at least one fdAT chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the fdAT chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the main image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> If the PNG oFFs chunk is present, it supplies offsets of the canvas that are in addition to the frame's &quot;x_offset&quot; and &quot;y_offset&quot;.<br /> <br /> If the PNG pHYs chunk is present, the APNG images and their &quot;x_offset&quot; and &quot;y_offset&quot; values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> * Split dispose_op into render_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=52723 2007-03-22T23:03:46Z

<p>Andrew: </p> <hr /> <div>APNG 0.9 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> An `fcTL` chunk may also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0. If there is no fcTL chunk before IDAT, then frame 0 is intialized to RGBA(0,0,0,0) and the IDAT chunks are not used.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Terminology ==<br /> <br /> The &quot;canvas&quot; 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.<br /> <br /> The &quot;output buffer&quot; 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 output buffer and then written to the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first fcTL chunk must contain sequence number 0, and the sequence numbers in the remaining fcTL and fdAT chunks must be in order, with no gaps or duplicates.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` describing frame 0<br /> 1 `fcTL` describing frame 1<br /> 2 first `fdAT` for frame 1<br /> 3 second `fdAT` for frame 1<br /> ....<br /> <br /> or, when frame 0 is implicitly a transparent black frame:<br /> <br /> Sequence number Chunk<br /> 0 fcTL describing frame 1<br /> 1 first fdAT for frame 1<br /> 2 second fdAT for frame 1<br /> ....<br /> <br /> APNG viewers must abandon the APNG chunks in a datastream with out-of-order APNG chunks and display frame 0 instead. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTL` chunk must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the second frame, the `fcTL` chunk must appear after the `IDAT` chunks from the first frame and before the fdAT chunks for the second frame.<br /> * For any subsequent frames, the `fcTL` chunk for the frame N must appear after the `fdAT` chunks from the frame N-1 and before the fdAT chunks for the frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between fdAT chunks.<br /> <br /> The fcTL chunk is mandatory for every frame except for frame 0. When it is present for frame 0, decoders must render frame 0 from the data in the IDAT chunks. When it is not present for frame 0, frame 0 is a transparent black frame (all pixels are RGBA(0,0,0,0)) and the IDAT chunks are ignored. More than one fcTL chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTL`, and the width and height from the `IHDR` chunk.<br /> <br /> The width and height must be greater than zero and must not be bigger than (respectively) the width and height specified in the IHDR chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the area defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 1 APNG_DISPOSE_OP_NONE<br /> 2 APNG_DISPOSE_OP_BACKGROUND<br /> 4 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_OP_NONE: no disposal is done on this frame before rendering the next; its contents are left on the output buffer. This is the default.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region is to be cleared to the background color. If no bKGD chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region is to be reverted to the previous contents.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer. Valid `blend_op` values are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> APNG_BLEND_OP_OVER is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> `blend_op` must be APNG_BLEND_OP_SOURCE for frame 0.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> Each frame must contain at least one fdAT chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the fdAT chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the main image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> If the PNG oFFs chunk is present, it supplies offsets of the canvas that are in addition to the frame's &quot;x_offset&quot; and &quot;y_offset&quot;.<br /> <br /> If the PNG pHYs chunk is present, the APNG images and their &quot;x_offset&quot; and &quot;y_offset&quot; values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> * Split dispose_op into render_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=52677 2007-03-22T20:21:41Z

<p>Andrew: </p> <hr /> <div>APNG 0.9 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTL -&gt; aCTL, fcTL -&gt; fCTL, fdAT -&gt; fDAT<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> An `fcTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0. If there is no fCTl chunk before IDAT, then frame 0 is intialized to RGBA(0,0,0,0) and the IDAT chunks are not used.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTL` chunks. The full layout of `fdAT` and `fcTL` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Terminology ==<br /> <br /> The &quot;canvas&quot; 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.<br /> <br /> The &quot;output buffer&quot; 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 output buffer and then written to the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTL` and `fdAT` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first fCTl chunk must contain sequence number 0, and the sequence numbers in the remaining fCTl and fDAt chunks must be in order, with no gaps or duplicates.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAT` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTL` describing frame 0<br /> 1 `fcTL` describing frame 1<br /> 2 first `fdAT` for frame 1<br /> 3 second `fdAT` for frame 1<br /> ....<br /> <br /> or, when frame 0 is implicitly a transparent black frame:<br /> <br /> Sequence number Chunk<br /> 0 fCTl describing frame 1<br /> 1 first fDAt for frame 1<br /> 2 second fDAt for frame 1<br /> ....<br /> <br /> APNG viewers must abandon the APNG chunks in a datastream with out-of-order APNG chunks and display frame 0 instead. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAT` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTL` chunk must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For the second frame, the `fcTL` chunk must appear after the `IDAT` chunks from the first frame and before the fdAT chunks for the second frame.<br /> * For any subsequent frames, the `fcTL` chunk for the frame N must appear after the `fdAT` chunks from the frame N-1 and before the fdAT chunks for the frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between fDAt chunks. Decoders must ignore such chunks.<br /> <br /> The fCTl chunk is mandatory for every frame except for frame 0. When it is present for frame 0, decoders must render frame 0 from the data in the IDAT chunks. When it is not present for frame 0, frame 0 is a transparent black frame (all pixels are RGBA(0,0,0,0)) and the IDAT chunks are ignored. More than one fCTl chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 dispose_op (byte) Type of frame area disposal to be done after rendering this frame<br /> 25 blend_op (byte) Type of frame area rendering for this frame <br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTL`, and the width and height from the `IHDR` chunk.<br /> <br /> The width and height must be greater than zero and must not be bigger than (respectively) the width and height specified in the IHDR chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the area defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value<br /> 1 APNG_DISPOSE_OP_NONE<br /> 2 APNG_DISPOSE_OP_BACKGROUND<br /> 4 APNG_DISPOSE_OP_PREVIOUS<br /> <br /> * APNG_DISPOSE_NONE: no disposal is done on this frame before rendering the next; its contents are left on the output buffer. This is the default.<br /> * APNG_DISPOSE_OP_BACKGROUND: the frame's region is to be cleared to the background color. If no bKGD chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * APNG_DISPOSE_OP_PREVIOUS: the frame's region is to be reverted to the previous contents.<br /> <br /> `blend_op` specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer. Valid `blend_op` values are:<br /> <br /> value<br /> 0 APNG_BLEND_OP_SOURCE<br /> 1 APNG_BLEND_OP_OVER<br /> <br /> If `blend_op` is APNG_BLEND_OP_SOURCE all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [PNG-1.2]. Note that Variation 2 of the sample code is applicable.<br /> <br /> APNG_BLEND_OP_OVER is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> `blend_op` must be APNG_BLEND_OP_SOURCE for frame 0.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> Each frame must contain at least one fDAt chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the fDAt chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the main image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> If the PNG oFFs chunk is present, it supplies offsets of the canvas that are in addition to the frame's &quot;x_offset&quot; and &quot;y_offset&quot;.<br /> <br /> If the PNG pHYs chunk is present, the APNG images and their &quot;x_offset&quot; and &quot;y_offset&quot; values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> == From 0.8 ==<br /> <br /> * Removed CRCs for IHDR and PLTE from acTl<br /> <br /> * The acTL fcTL and adAT are now not copy safe, renamed them to acTL, fcTL and adAT<br /> <br /> * Split dispose_op into render_op and blend_op<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=52553 2007-03-21T13:32:26Z

<p>Andrew: </p> <hr /> <div>APNG 0.8 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTl -&gt; aCTl, fcTl -&gt; fCTl, fdAt -&gt; fDAt<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0. If there is no fCTl chunk before IDAT, then frame 0 is intialized to RGBA(0,0,0,0) and the IDAT chunks are not used.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Terminology ==<br /> <br /> The &quot;canvas&quot; 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.<br /> <br /> The &quot;output buffer&quot; 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 output buffer and then written to the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first fCTl chunk must contain sequence number 0, and the sequence numbers in the remaining fCTl and fDAt chunks must be in order, with no gaps or duplicates.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> or, when frame 0 is implicitly a transparent black frame:<br /> <br /> Sequence number Chunk<br /> 0 fCTl describing frame 1<br /> 1 first fDAt for frame 1<br /> 2 second fDAt for frame 1<br /> ....<br /> <br /> APNG viewers must abandon the APNG chunks in a datastream with out-of-order APNG chunks and display frame 0 instead. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is 3 (indexed-color), and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear after the `IDAT` chunks from the first frame and before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear after the `fdAt` chunks from the frame N-1 and before the fdAt chunks for the frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between fDAt chunks. Decoders must ignore such chunks.<br /> <br /> The fCTl chunk is mandatory for every frame except for frame 0. When it is present for frame 0, decoders must render frame 0 from the data in the IDAT chunks. When it is not present for frame 0, frame 0 is a transparent black frame (all pixels are RGBA(0,0,0,0)) and the IDAT chunks are ignored. More than one fCTl chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of output buffer area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR` chunk.<br /> <br /> The width and height must be greater than zero and must not be bigger than (respectively) the width and height specified in the IHDR chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the area defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-----------------|---|---|---|-+<br /> | +---+---+------ bits 0-2: dispose_op<br /> |<br /> +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> <br /> <br /> Bits 4 through 7 are reserved and must be 0.<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value bit<br /> 1 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 2 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 4 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the output buffer. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is 0, all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If the APNG_RENDER_OP_BLEND_FLAG is not 0 the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [pngspec]. Note<br /> that Variation 2 of the sample code is applicable.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> APNG_RENDER_OP_BLEND_FLAG must be 0 for frame 0.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> Each frame must contain at least one fDAt chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the fDAt chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the main image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> If the PNG oFFs chunk is present, it supplies offsets of the canvas that are in addition to the frame's &quot;x_offset&quot; and &quot;y_offset&quot;.<br /> <br /> If the PNG pHYs chunk is present, the APNG images and their &quot;x_offset&quot; and &quot;y_offset&quot; values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=52515 2007-03-21T05:49:36Z

<p>Andrew: </p> <hr /> <div>APNG 0.8 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> We are currently waiting on the PNG group to approve our use of our chunks as public chunks (i.e. 2nd letter is capitalized.) Once they have approved the chunk names only the public chunk names will be valid and APNGs created before that point will become invalid.<br /> <br /> acTl -&gt; aCTl, fcTl -&gt; fCTl, fdAt -&gt; fDAt<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0. If there is no fCTl chunk before IDAT, then frame 0 is intialized to RGBA(0,0,0,0) and the IDAT chunks are not used.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Terminology ==<br /> <br /> The &quot;canvas&quot; 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.<br /> <br /> The &quot;output buffer&quot; 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 output buffer and then written to the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first fCTl chunk must contain sequence number 0, and the sequence numbers in the remaining fCTl and fDAt chunks must be in order, with no gaps or duplicates.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> or, when frame 0 is implicitly a transparent black frame:<br /> <br /> Sequence number Chunk<br /> 0 fCTl describing frame 1<br /> 1 first fDAt for frame 1<br /> 2 second fDAt for frame 1<br /> ....<br /> <br /> APNG viewers must abandon the APNG chunks in a datastream with out-of-order APNG chunks and display frame 0 instead. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is 3 (indexed-color), and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear after the `IDAT` chunks from the first frame and before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear after the `fdAt` chunks from the frame N-1 and before the fdAt chunks for the frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between fDAt chunks. Decoders must ignore such chunks.<br /> <br /> The fCTl chunk is mandatory for every frame except for frame 0. When it is present for frame 0, decoders must render frame 0 from the data in the IDAT chunks. When it is not present for frame 0, frame 0 is a transparent black frame (all pixels are RGBA(0,0,0,0)) and the IDAT chunks are ignored. More than one fCTl chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of output buffer area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR` chunk.<br /> <br /> The width and height must be greater than zero and must not be bigger than (respectively) the width and height specified in the IHDR chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the area defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current output buffer content, or whether it should completely replace its region in the output buffer. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-----------------|---|---|---|-+<br /> | +---+---+------ bits 0-2: dispose_op<br /> |<br /> +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> <br /> <br /> Bits 4 through 7 are reserved and must be 0.<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value bit<br /> 1 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 2 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 4 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the output buffer. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is 0, all color components of the frame, including alpha, overwrite the current contents of the frame's output buffer region. If the APNG_RENDER_OP_BLEND_FLAG is not 0 the frame should be composited onto the output buffer based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [pngspec]. Note<br /> that Variation 2 of the sample code is applicable.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> APNG_RENDER_OP_BLEND_FLAG must be 0 for frame 0.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is not 0, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or is explicitly disabled by the user, the viewer should display frame 0 even if `APNG_RENDER_OP_SKIP_FRAME` is not 0 on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> Each frame must contain at least one fDAt chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the fDAt chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the main image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> If the PNG oFFs chunk is present, it supplies offsets of the canvas that are in addition to the frame's &quot;x_offset&quot; and &quot;y_offset&quot;.<br /> <br /> If the PNG pHYs chunk is present, the APNG images and their &quot;x_offset&quot; and &quot;y_offset&quot; values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=52292 2007-03-20T02:58:54Z

<p>Andrew: </p> <hr /> <div>APNG 0.8 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> The chunk names in this specification will be changed to aCTl, fCTl and fDAt. Please consider any APNGs with acTl, fcTl and fdAt to be useless after that change happens.<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0. If there is no fCTl chunk before IDAT, then frame 0 is intialized to RGBA(0,0,0,0) and the IDAT chunks are not used.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Terminology ==<br /> <br /> The &quot;canvas&quot; 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.<br /> <br /> The &quot;output buffer&quot; 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 output buffer and then written to the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first fCTl chunk must contain sequence number 0, and the sequence numbers in the remaining fCTl and fDAt chunks must be in order, with no gaps or duplicates.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> or, when frame 0 is implicitly a transparent black frame:<br /> <br /> Sequence number Chunk<br /> 0 fCTl describing frame 1<br /> 1 first fDAt for frame 1<br /> 2 second fDAt for frame 1<br /> ....<br /> <br /> APNG viewers must abandon the APNG chunks in a datastream with out-of-order APNG chunks and display frame 0 instead. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is 3 (indexed-color), and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear after the `IDAT` chunks from the first frame and before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear after the `fdAt` chunks from the frame N-1 and before the fdAt chunks for the frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between fDAt chunks. Decoders must ignore such chunks.<br /> <br /> The fCTl chunk is mandatory for every frame except for frame 0. When it is present for frame 0, decoders must render frame 0 from the data in the IDAT chunks. When it is not present for frame 0, frame 0 is a transparent black frame (all pixels are RGBA(0,0,0,0)) and the IDAT chunks are ignored. More than one fCTl chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR` chunk.<br /> <br /> The width and height must be greater than zero and must not be bigger than (respectively) the width and height specified in the IHDR chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the area defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-----------------|---|---|---|-+<br /> | +---+---+------ bits 0-2: dispose_op<br /> |<br /> +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> <br /> <br /> Bits 4 through 7 are reserved and must be 0.<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value bit<br /> 1 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 2 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 4 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is 0, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the APNG_RENDER_OP_BLEND_FLAG is not 0 the frame should be composited onto the canvas based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [pngspec]. Note<br /> that Variation 2 of the sample code is applicable.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> APNG_RENDER_OP_BLEND_FLAG must be 0 for frame 0.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is not 0, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or is explicitly disabled by the user, the viewer should display frame 0 even if `APNG_RENDER_OP_SKIP_FRAME` is not 0 on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> Each frame must contain at least one fDAt chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the fDAt chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the main image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> If the PNG oFFs chunk is present, it supplies offsets of the canvas that are in addition to the frame's &quot;x_offset&quot; and &quot;y_offset&quot;.<br /> <br /> If the PNG pHYs chunk is present, the APNG images and their &quot;x_offset&quot; and &quot;y_offset&quot; values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=52291 2007-03-20T02:58:26Z

<p>Andrew: </p> <hr /> <div>APNG 0.7 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Big Important Note =<br /> <br /> The chunk names in this specification will be changed to aCTl, fCTl and fDAt. Please consider any APNGs with acTl, fcTl and fdAt to be useless after that change happens.<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0. If there is no fCTl chunk before IDAT, then frame 0 is intialized to RGBA(0,0,0,0) and the IDAT chunks are not used.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Terminology ==<br /> <br /> The &quot;canvas&quot; 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.<br /> <br /> The &quot;output buffer&quot; 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 output buffer and then written to the canvas. The contents of the output buffer are available to the decoder. The corner pixels of the output buffer are mapped to the corners of the canvas.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The first fCTl chunk must contain sequence number 0, and the sequence numbers in the remaining fCTl and fDAt chunks must be in order, with no gaps or duplicates.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> or, when frame 0 is implicitly a transparent black frame:<br /> <br /> Sequence number Chunk<br /> 0 fCTl describing frame 1<br /> 1 first fDAt for frame 1<br /> 2 second fDAt for frame 1<br /> ....<br /> <br /> APNG viewers must abandon the APNG chunks in a datastream with out-of-order APNG chunks and display frame 0 instead. APNG-aware PNG editors should restore them to correct order using the sequence numbers.<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is 3 (indexed-color), and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear after the `IDAT` chunks from the first frame and before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear after the `fdAt` chunks from the frame N-1 and before the fdAt chunks for the frame N.<br /> * Other ancillary chunks are allowed to appear among the APNG chunks, including between fDAt chunks. Decoders must ignore such chunks.<br /> <br /> The fCTl chunk is mandatory for every frame except for frame 0. When it is present for frame 0, decoders must render frame 0 from the data in the IDAT chunks. When it is not present for frame 0, frame 0 is a transparent black frame (all pixels are RGBA(0,0,0,0)) and the IDAT chunks are ignored. More than one fCTl chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR` chunk.<br /> <br /> The width and height must be greater than zero and must not be bigger than (respectively) the width and height specified in the IHDR chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the area defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-----------------|---|---|---|-+<br /> | +---+---+------ bits 0-2: dispose_op<br /> |<br /> +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> <br /> <br /> Bits 4 through 7 are reserved and must be 0.<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value bit<br /> 1 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 2 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 4 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is 0, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the APNG_RENDER_OP_BLEND_FLAG is not 0 the frame should be composited onto the canvas based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [pngspec]. Note<br /> that Variation 2 of the sample code is applicable.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> APNG_RENDER_OP_BLEND_FLAG must be 0 for frame 0.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is not 0, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or is explicitly disabled by the user, the viewer should display frame 0 even if `APNG_RENDER_OP_SKIP_FRAME` is not 0 on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> Each frame must contain at least one fDAt chunk. The compressed datastream is then the concatenation of the contents of the data fields of all the fDAt chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the main image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> If the PNG oFFs chunk is present, it supplies offsets of the canvas that are in addition to the frame's &quot;x_offset&quot; and &quot;y_offset&quot;.<br /> <br /> If the PNG pHYs chunk is present, the APNG images and their &quot;x_offset&quot; and &quot;y_offset&quot; values must be scaled in the same way as the main image. Conceptually, such scaling occurs while mapping the output buffer onto the canvas.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> == From 0.7 ==<br /> <br /> * Removed 'hidden' flag, instead only the first frame can be hidden and it is signaled with a missing fcTl<br /> <br /> * IDAT, fcTl and fdAt are no longer required to have no other chunks in between them<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=51304 2007-03-09T16:22:32Z

<p>Andrew: </p> <hr /> <div>APNG 0.7 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> Sequence numbers must start at 0 and increment by one.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> If a decoder detects that the chunks are in the wrong order it must either treat the condition as an error or correct the order using the sequence numbers.<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream. If the color type of the image is 3 (indexed-color) the `acTl` chunk must appear after the `PLTE` chunk.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is 3 (indexed-color), and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear immediately after the `IDAT` chunks from the first frame and immediately before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear immediately after the `fdAt` chunks from the frame N-1 and immediately before the fdAt chunks for the frame N.<br /> <br /> The `fcTl` chunk is mandatory for every frame. More than one `fcTl` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR`.<br /> <br /> The width and height cannot be bigger than (respectively) the width and height specified in the `IHDR` chunk. The value of both the width and the height must be greater than 0.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the canvas defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be 0.<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value bit<br /> 1 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 2 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 4 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is 0, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the APNG_RENDER_OP_BLEND_FLAG is not 0 the frame should be composited onto the canvas based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [pngspec]. Note<br /> that Variation 2 of the sample code is applicable.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is not 0, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or is explicitly disabled by the user, the viewer should display frame 0 even if `APNG_RENDER_OP_SKIP_FRAME` is not 0 on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> Each frame must contain at least one fDAt chunk. There may be multiple `fdAt` chunks for any one frame; if so, they shall appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the fDAt chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline.<br /> <br /> It utilizes the same bit depth, color type, compression method, filter<br /> method, interlace method, and palette (if any) as the main image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> If the PNG oFFs chunk is present, it supplies offsets of the canvas that are in addition to the frame's &quot;x_offset&quot; and &quot;y_offset&quot;.<br /> <br /> If the PNG pHYs chunk is present, the APNG images and their &quot;x_offset&quot; and &quot;y_offset&quot; values must be scaled in the same way as the main image.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=51302 2007-03-09T16:17:39Z

<p>Andrew: </p> <hr /> <div>APNG 0.7 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> Sequence numbers must start at 0 and increment by one.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> If a decoder detects that the chunks are in the wrong order it must either treat the condition as an error or correct the order using the sequence numbers.<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream. If the color type of the image is 3 (indexed-color) the `acTl` chunk must appear after the `PLTE` chunk.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is 3 (indexed-color), and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear immediately after the `IDAT` chunks from the first frame and immediately before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear immediately after the `fdAt` chunks from the frame N-1 and immediately before the fdAt chunks for the frame N.<br /> <br /> The `fcTl` chunk is mandatory for every frame. More than one `fcTl` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR`.<br /> <br /> The width and height cannot be bigger than (respectively) the width and height specified in the `IHDR` chunk. The value of both the width and the height must be greater than 0.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the canvas defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be 0.<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value bit<br /> 1 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 2 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 4 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is 0, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the APNG_RENDER_OP_BLEND_FLAG is not 0 the frame should be composited onto the canvas based on its alpha, using a simple OVER operation as described in the &quot;Alpha Channel Processing&quot; section of the PNG specification [pngspec].<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is not 0, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or is explicitly disabled by the user, the viewer should display frame 0 even if `APNG_RENDER_OP_SKIP_FRAME` is not 0 on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> Each frame must contain at least one fDAt chunk. There may be multiple `fdAt` chunks for any one frame; if so, they shall appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the fDAt chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline.<br /> <br /> It utilizes the same bit depth, color type, compression method, filter<br /> method, interlace method, and palette (if any) as the main image.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=51197 2007-03-08T18:10:24Z

<p>Andrew: </p> <hr /> <div>APNG 0.7 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> Sequence numbers must start at 0 and increment by one.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> If a decoder detects that the chunks are in the wrong order it must either treat the condition as an error or correct the order using the sequence numbers.<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream. If the color type of the image is 3 (indexed-color) the `acTl` chunk must appear after the `PLTE` chunk.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is 3 (indexed-color), and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear immediately after the `IDAT` chunks from the first frame and immediately before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear immediately after the `fdAt` chunks from the frame N-1 and immediately before the fdAt chunks for the frame N.<br /> <br /> The `fcTl` chunk is mandatory for every frame. More than one `fcTl` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR`.<br /> <br /> The width and height cannot be bigger than (respectively) the width and height specified in the `IHDR` chunk. The value of both the width and the height must be greater than 0.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the canvas defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be 0.<br /> <br /> Valid values for `dispose_op` are:<br /> <br /> value bit<br /> 1 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 2 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 4 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is 0, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the APNG_RENDER_OP_BLEND_FLAG is not 0 the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is not 0, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or is explicitly disabled by the user, the viewer should display frame 0 even if `APNG_RENDER_OP_SKIP_FRAME` is not 0 on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> There may be multiple `fdAt` chunks for any one frame; if so, they shall appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAt` chunks.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=51180 2007-03-08T16:16:36Z

<p>Andrew: </p> <hr /> <div>APNG 0.7 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> Sequence numbers must start at 0 and increment by one.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> If a decoder detects that the chunks are in the wrong order it must either treat the condition as an error or correct the order using the sequence numbers.<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream. If the color type of the image is 3 (indexed-color) the `acTl` chunk must appear after the `PLTE` chunk.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is 3 (indexed-color), and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear immediately after the `IDAT` chunks from the first frame and immediately before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear immediately after the `fdAt` chunks from the frame N-1 and immediately before the fdAt chunks for the frame N.<br /> <br /> The `fcTl` chunk is mandatory for every frame. More than one `fcTl` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR`.<br /> <br /> The width and height cannot be bigger than (respectively) the width and height specified in the `IHDR` chunk. The value of both the width and the height must be greater than 0.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the canvas defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is 0, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the APNG_RENDER_OP_BLEND_FLAG is not 0 the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is not 0, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or is explicitly disabled by the user, the viewer should display frame 0 even if `APNG_RENDER_OP_SKIP_FRAME` is not 0 on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> There may be multiple `fdAt` chunks for any one frame; if so, they shall appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAt` chunks.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=51177 2007-03-08T16:03:57Z

<p>Andrew: </p> <hr /> <div>APNG 0.7 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order limited to the range 0 to (2^31)-1; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be an 8-bit unsigned integer.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> Sequence numbers must start at 0 and increment by one.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream. If the color type of the image is 3 (indexed-color) the `acTl` chunk must appear after the `PLTE` chunk.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is 3 (indexed-color), and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear immediately after the `IDAT` chunks from the first frame and immediately before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear immediately after the `fdAt` chunks from the frame N-1 and immediately before the fdAt chunks for the frame N.<br /> <br /> The `fcTl` chunk is mandatory for every frame. More than one `fcTl` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR`.<br /> <br /> The width and height cannot be bigger than (respectively) the width and height specified in the `IHDR` chunk. The value of both the width and the height must be greater than 0.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. No part of the region may fall outside the canvas defined by frame 0.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is 0, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the APNG_RENDER_OP_BLEND_FLAG is not 0 the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is not 0, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or is explicitly disabled by the user, the viewer should display frame 0 even if `APNG_RENDER_OP_SKIP_FRAME` is not 0 on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> There may be multiple `fdAt` chunks for any one frame; if so, they shall appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAt` chunks.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=51174 2007-03-08T15:44:47Z

<p>Andrew: </p> <hr /> <div>APNG 0.7 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == Chunk Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream. If the color type of the image is 3 (indexed-color) the `acTl` chunk must appear after the `PLTE` chunk.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is 3 (indexed-color), and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear immediately after the `IDAT` chunks from the first frame and immediately before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear immediately after the `fdAt` chunks from the frame N-1 and immediately before the fdAt chunks for the frame N.<br /> <br /> The `fcTl` chunk is mandatory for every frame. More than one `fcTl` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR`.<br /> <br /> The width and height cannot be bigger than (respectively) the width and height specified in the `IHDR` chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. Should parts of the region fall outside the canvas defined by frame 0, rendering may be clipped to that canvas or the condition may be treated as an error.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is 0, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the APNG_RENDER_OP_BLEND_FLAG is not 0 the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is not 0, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or is explicitly disabled by the user, the viewer should display frame 0 even if `APNG_RENDER_OP_SKIP_FRAME` is not 0 on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> There may be multiple `fdAt` chunks for any one frame; if so, they shall appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAt` chunks.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=50945 2007-03-06T10:02:48Z

<p>Andrew: /* From 0.6 */</p> <hr /> <div>APNG 0.7 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == Chuck Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream. If the color type of the image is PNG_COLOR_TYPE_PALETTE the `acTl` chunk must appear after the `PLTE` chunk.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is PNG_COLOR_TYPE_PALETTE, and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear immediately after the `IDAT` chunks from the first frame and immediately before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear immediately after the `fdAt` chunks from the frame N-1 and immediately before the fdAt chunks for the frame N.<br /> <br /> The `fcTl` chunk is mandatory for every frame. More than one `fcTl` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR`.<br /> <br /> The width and height cannot be bigger than (respectively) the width and height specified in the `IHDR` chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. Should parts of the region fall outside the canvas defined by frame 0, rendering may be clipped to that canvas or the condition may be treated as an error.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> There may be multiple `fdAt` chunks for any one frame; if so, they shall appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAt` chunks.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Removed the feND chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=50944 2007-03-06T09:55:23Z

<p>Andrew: /* From .6 */</p> <hr /> <div>APNG 0.7 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == Chuck Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream. If the color type of the image is PNG_COLOR_TYPE_PALETTE the `acTl` chunk must appear after the `PLTE` chunk.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is PNG_COLOR_TYPE_PALETTE, and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear immediately after the `IDAT` chunks from the first frame and immediately before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear immediately after the `fdAt` chunks from the frame N-1 and immediately before the fdAt chunks for the frame N.<br /> <br /> The `fcTl` chunk is mandatory for every frame. More than one `fcTl` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR`.<br /> <br /> The width and height cannot be bigger than (respectively) the width and height specified in the `IHDR` chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. Should parts of the region fall outside the canvas defined by frame 0, rendering may be clipped to that canvas or the condition may be treated as an error.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> There may be multiple `fdAt` chunks for any one frame; if so, they shall appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAt` chunks.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From 0.6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=50943 2007-03-06T09:54:28Z

<p>Andrew: </p> <hr /> <div>APNG 0.7 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> * Andrew Smith &lt;asmith15@learn.senecac.on.ca&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with three additional chunk types describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks containing almost the same structure of content as IDAT chunks. Information for each frame about placement and rendering is stored in `fcTl` chunks. The full layout of `fdAt` and `fcTl` chunks is described below.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == Chuck Sequence Numbers ==<br /> <br /> The `fcTl` and `fdAt` chunks have a 4 byte sequence number. Both chunk types share the sequence. The purpose of this number is to detect (and optionally correct) sequence errors in an Animated PNG, since the PNG specification does not impose orderng restrictions on ancillary chunks.<br /> <br /> The table below illustrates the use of sequence numbers for images with more than one frame and more than one `fdAt` chunk:<br /> <br /> Sequence number Chunk<br /> 0 `fcTl` describing frame 0<br /> 1 `fcTl` describing frame 1<br /> 2 first `fdAt` for frame 1<br /> 3 second `fdAt` for frame 1<br /> ....<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream. If the color type of the image is PNG_COLOR_TYPE_PALETTE the `acTl` chunk must appear after the `PLTE` chunk.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is PNG_COLOR_TYPE_PALETTE, and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the `IDAT` or `fdAt` chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For the second frame, the `fcTl` chunk must appear immediately after the `IDAT` chunks from the first frame and immediately before the fdAt chunks for the second frame.<br /> * For any subsequent frames, the `fcTl` chunk for the frame N must appear immediately after the `fdAt` chunks from the frame N-1 and immediately before the fdAt chunks for the frame N.<br /> <br /> The `fcTl` chunk is mandatory for every frame. More than one `fcTl` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 width (unsigned int) Width of the following frame<br /> 8 height (unsigned int) Height of the following frame<br /> 12 x_offset (unsigned int) X position at which to render the following frame<br /> 16 y_offset (unsigned int) Y position at which to render the following frame<br /> 20 delay_num (unsigned short) Frame delay fraction numerator<br /> 22 delay_den (unsigned short) Frame delay fraction denominator<br /> 24 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The frame must be rendered within the region defined by the `width`, `height`, `x_offset` and `y_offset` from the `fcTl`, and the width and height from the `IHDR`.<br /> <br /> The width and height cannot be bigger than (respectively) the width and height specified in the `IHDR` chunk.<br /> <br /> For frame 0 the width and height fields must equal the width and height from the `IHDR` chunk. Also for frame 0 the `x_offset` and `y_offset` fields must be 0. Should parts of the region fall outside the canvas defined by frame 0, rendering may be clipped to that canvas or the condition may be treated as an error.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk has the same purpose as an `IDAT` chunk. It has the same data structure as an `IDAT` chunk, except a sequence number is appended in the beginning.<br /> <br /> There may be multiple `fdAt` chunks for any one frame; if so, they shall appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the `fdAt` chunks.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the animation chunk, starting from 0<br /> 4 frame_data X bytes Frame data for this frame<br /> <br /> Each frame inherits every property except the width and the height specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> = Revisions to this Specification =<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> == From .6 ==<br /> <br /> * The fdAt chunk is no longer a container for other chunks, but rather a replacement for an IDAT chunk<br /> <br /> * Added a sequence number field to fdAt<br /> <br /> * Reintroduced the width and height fields in fcTl<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=48557 2007-02-08T08:08:47Z

<p>Andrew: </p> <hr /> <div>APNG 0.6 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTl` chunk must appear in the stream before any `IDAT` chunks. The `acTl` structure is described in the next section.<br /> <br /> An `fcTl` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAt` chunks, containing information about placement and rendering of a frame in `fcTl` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `fdAt` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == `acTl`: The Animation Control Chunk ==<br /> <br /> The `acTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream. If the color type of the image is PNG_COLOR_TYPE_PALETTE the `acTl` chunk must appear after the `PLTE` chunk.<br /> <br /> The `acTl` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> 8 IHDR_crc (unsigned int) CRC of the IHDR chunk.<br /> 12 PLTE_crc (unsigned int) CRC of the PLTE chunk or 0.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of fdAt chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> `IHDR_crc` must contain a copy of the CRC from the IHDR chunk. If the two checksums do not match, any further frames must be discarded.<br /> <br /> `PLTE_crc` must contain a copy of the CRC from the PLTE chunk if the color type for the PNG is PNG_COLOR_TYPE_PALETTE, and 0 otherwise. If the two checksums do not match, any further frames must be discarded.<br /> <br /> == `fcTl`: The Frame Control Chunk ==<br /> <br /> The `fcTl` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTl` chunk must appear before the first `IDAT` chunk. Position relative to the `acTl` chunk is not specified.<br /> * For any subsequent frames, the `fcTl` chunk must be first in the data part of the `fdAt` chunk.<br /> <br /> The `fcTl` chunk is mandatory for every frame. More than one `fcTl` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `fdAt` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fcTl`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal operations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAt`: The Frame Data Chunk ==<br /> <br /> The `fdAt` chunk contains one frame for the animation. Any `fdAt` chunks must follow any `IDAT` chunks. All `fdAt` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `fdAt` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fcTl` chunk 29 bytes `fcTl` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `feND` chunk 12 bytes `feND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `fdAt` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `fdAt` is fixed.<br /> <br /> The frame data within the `fdAt` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `feND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `feND` chunk is a mandatory last chunk in the data part of the `fdAt` chunk. Only one `feND` per `fdAt` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`fdAt`) and every chunk within (`fcTl`, `IDAT`s, `feND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> = Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> == From 0.5 ==<br /> <br /> * Added the IHDR and PLTE CRCs to the acTl chunk<br /> <br /> * The acTL fcTL and adAT are now copy safe, renamed them to acTl, fcTl and adAt<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> Sample images are available from the APNG implementation page at http://littlesvr.ca/apng/<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=34799 2006-09-26T00:01:40Z

<p>Andrew: </p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `acTL` chunk must appear in the stream before any `IDAT` chunks. The `acTL` structure is described in the next section.<br /> <br /> An `fcTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `fdAT` chunks, containing information about placement and rendering of a frame in `fcTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `fdAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == `acTL`: The Animation Control Chunk ==<br /> <br /> The `acTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `acTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of fdAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == `fcTL`: The Frame Control Chunk ==<br /> <br /> The `fcTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fcTL` chunk must appear before the first `IDAT` chunk. Position relative to the `acTL` chunk is not specified.<br /> * For any subsequent frames, the `fcTL` chunk must be first in the data part of the `fdAT` chunk.<br /> <br /> The `fcTL` chunk is mandatory for every frame. More than one `fcTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `fdAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fcTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `fdAT`: The Frame Data Chunk ==<br /> <br /> The `fdAT` chunk contains one frame for the animation. Any `fdAT` chunks must follow any `IDAT` chunks. All `fdAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `fdAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fcTL` chunk 29 bytes `fcTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `feND` chunk 12 bytes `feND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `fdAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `fdAT` is fixed.<br /> <br /> The frame data within the `fdAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `feND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `feND` chunk is a mandatory last chunk in the data part of the `fdAT` chunk. Only one `feND` per `fdAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`fdAT`) and every chunk within (`fcTL`, `IDAT`s, `feND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> = Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `fdAT`, `fcTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fcTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> * Renamed aCTL to acTL, fCTL to fcTL, aDAT to fdAT and fEND to feND to comply with the PNG spec chunk naming requirements<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=30439 2006-08-02T05:17:41Z

<p>Andrew: /* Revisions to this Specification = */</p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `aCTL` chunk must appear in the stream before any `IDAT` chunks. The `aCTL` structure is described in the next section.<br /> <br /> An `fCTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `aDAT` chunks, containing information about placement and rendering of a frame in `fCTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `aDAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == `aCTL`: The Animation Control Chunk ==<br /> <br /> The `aCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `aCTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of aDAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == `fCTL`: The Frame Control Chunk ==<br /> <br /> The `fCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fCTL` chunk must appear before the first `IDAT` chunk. Position relative to the `aCTL` chunk is not specified.<br /> * For any subsequent frames, the `fCTL` chunk must be first in the data part of the `aDAT` chunk.<br /> <br /> The `fCTL` chunk is mandatory for every frame. More than one `fCTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `aDAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fCTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `aDAT`: The Animation Data Chunk ==<br /> <br /> The `aDAT` chunk contains one frame for the animation. Any `aDAT` chunks must follow any `IDAT` chunks. All `aDAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `aDAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fCTL` chunk 29 bytes `fCTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `fEND` chunk 12 bytes `fEND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `aDAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `aDAT` is fixed.<br /> <br /> The frame data within the `aDAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `fEND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `fEND` chunk is a mandatory last chunk in the data part of the `aDAT` chunk. Only one `fEND` per `aDAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`aDAT`) and every chunk within (`fCTL`, `IDAT`s, `fEND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> = Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `aDAT`, `fCTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fCTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> == From 0.4 ==<br /> <br /> * Reintroduced num_frames into aCTL<br /> <br /> * Moved sequence_number from aDAT into fCTL<br /> <br /> * Changed contents of aDAT to fCTL+IDATs+fEND<br /> <br /> * Added clarifications on what's allowed and what isn't<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=30438 2006-08-02T05:12:59Z

<p>Andrew: /* 5. Test Encoder and Sample Images */</p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `aCTL` chunk must appear in the stream before any `IDAT` chunks. The `aCTL` structure is described in the next section.<br /> <br /> An `fCTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `aDAT` chunks, containing information about placement and rendering of a frame in `fCTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `aDAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == `aCTL`: The Animation Control Chunk ==<br /> <br /> The `aCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `aCTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of aDAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == `fCTL`: The Frame Control Chunk ==<br /> <br /> The `fCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fCTL` chunk must appear before the first `IDAT` chunk. Position relative to the `aCTL` chunk is not specified.<br /> * For any subsequent frames, the `fCTL` chunk must be first in the data part of the `aDAT` chunk.<br /> <br /> The `fCTL` chunk is mandatory for every frame. More than one `fCTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `aDAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fCTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `aDAT`: The Animation Data Chunk ==<br /> <br /> The `aDAT` chunk contains one frame for the animation. Any `aDAT` chunks must follow any `IDAT` chunks. All `aDAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `aDAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fCTL` chunk 29 bytes `fCTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `fEND` chunk 12 bytes `fEND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `aDAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `aDAT` is fixed.<br /> <br /> The frame data within the `aDAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `fEND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `fEND` chunk is a mandatory last chunk in the data part of the `aDAT` chunk. Only one `fEND` per `aDAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`aDAT`) and every chunk within (`fCTL`, `IDAT`s, `fEND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> = Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `aDAT`, `fCTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fCTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> = Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=30437 2006-08-02T05:12:44Z

<p>Andrew: /* 4. Revisions to this Specification = */</p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `aCTL` chunk must appear in the stream before any `IDAT` chunks. The `aCTL` structure is described in the next section.<br /> <br /> An `fCTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `aDAT` chunks, containing information about placement and rendering of a frame in `fCTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `aDAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == `aCTL`: The Animation Control Chunk ==<br /> <br /> The `aCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `aCTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of aDAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == `fCTL`: The Frame Control Chunk ==<br /> <br /> The `fCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fCTL` chunk must appear before the first `IDAT` chunk. Position relative to the `aCTL` chunk is not specified.<br /> * For any subsequent frames, the `fCTL` chunk must be first in the data part of the `aDAT` chunk.<br /> <br /> The `fCTL` chunk is mandatory for every frame. More than one `fCTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `aDAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fCTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `aDAT`: The Animation Data Chunk ==<br /> <br /> The `aDAT` chunk contains one frame for the animation. Any `aDAT` chunks must follow any `IDAT` chunks. All `aDAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `aDAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fCTL` chunk 29 bytes `fCTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `fEND` chunk 12 bytes `fEND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `aDAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `aDAT` is fixed.<br /> <br /> The frame data within the `aDAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `fEND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `fEND` chunk is a mandatory last chunk in the data part of the `aDAT` chunk. Only one `fEND` per `aDAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`aDAT`) and every chunk within (`fCTL`, `IDAT`s, `fEND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> = Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `aDAT`, `fCTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fCTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> = 5. Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=30436 2006-08-02T05:12:16Z

<p>Andrew: /* 2.3 `aDAT`: The Animation Data Chunk */</p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `aCTL` chunk must appear in the stream before any `IDAT` chunks. The `aCTL` structure is described in the next section.<br /> <br /> An `fCTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `aDAT` chunks, containing information about placement and rendering of a frame in `fCTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `aDAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == `aCTL`: The Animation Control Chunk ==<br /> <br /> The `aCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `aCTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of aDAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == `fCTL`: The Frame Control Chunk ==<br /> <br /> The `fCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fCTL` chunk must appear before the first `IDAT` chunk. Position relative to the `aCTL` chunk is not specified.<br /> * For any subsequent frames, the `fCTL` chunk must be first in the data part of the `aDAT` chunk.<br /> <br /> The `fCTL` chunk is mandatory for every frame. More than one `fCTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `aDAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fCTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == `aDAT`: The Animation Data Chunk ==<br /> <br /> The `aDAT` chunk contains one frame for the animation. Any `aDAT` chunks must follow any `IDAT` chunks. All `aDAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `aDAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fCTL` chunk 29 bytes `fCTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `fEND` chunk 12 bytes `fEND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `aDAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `aDAT` is fixed.<br /> <br /> The frame data within the `aDAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `fEND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `fEND` chunk is a mandatory last chunk in the data part of the `aDAT` chunk. Only one `fEND` per `aDAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`aDAT`) and every chunk within (`fCTL`, `IDAT`s, `fEND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> = 4. Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `aDAT`, `fCTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fCTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> = 5. Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=30435 2006-08-02T05:12:05Z

<p>Andrew: /* 2.2 `fCTL`: The Frame Control Chunk */</p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `aCTL` chunk must appear in the stream before any `IDAT` chunks. The `aCTL` structure is described in the next section.<br /> <br /> An `fCTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `aDAT` chunks, containing information about placement and rendering of a frame in `fCTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `aDAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == `aCTL`: The Animation Control Chunk ==<br /> <br /> The `aCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `aCTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of aDAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == `fCTL`: The Frame Control Chunk ==<br /> <br /> The `fCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fCTL` chunk must appear before the first `IDAT` chunk. Position relative to the `aCTL` chunk is not specified.<br /> * For any subsequent frames, the `fCTL` chunk must be first in the data part of the `aDAT` chunk.<br /> <br /> The `fCTL` chunk is mandatory for every frame. More than one `fCTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `aDAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fCTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == 2.3 `aDAT`: The Animation Data Chunk ==<br /> <br /> The `aDAT` chunk contains one frame for the animation. Any `aDAT` chunks must follow any `IDAT` chunks. All `aDAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `aDAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fCTL` chunk 29 bytes `fCTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `fEND` chunk 12 bytes `fEND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `aDAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `aDAT` is fixed.<br /> <br /> The frame data within the `aDAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `fEND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `fEND` chunk is a mandatory last chunk in the data part of the `aDAT` chunk. Only one `fEND` per `aDAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`aDAT`) and every chunk within (`fCTL`, `IDAT`s, `fEND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> = 4. Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `aDAT`, `fCTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fCTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> = 5. Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=30434 2006-08-02T05:11:51Z

<p>Andrew: /* 2.1. `aCTL`: The Animation Control Chunk */</p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `aCTL` chunk must appear in the stream before any `IDAT` chunks. The `aCTL` structure is described in the next section.<br /> <br /> An `fCTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `aDAT` chunks, containing information about placement and rendering of a frame in `fCTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `aDAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == `aCTL`: The Animation Control Chunk ==<br /> <br /> The `aCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `aCTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of aDAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == 2.2 `fCTL`: The Frame Control Chunk ==<br /> <br /> The `fCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fCTL` chunk must appear before the first `IDAT` chunk. Position relative to the `aCTL` chunk is not specified.<br /> * For any subsequent frames, the `fCTL` chunk must be first in the data part of the `aDAT` chunk.<br /> <br /> The `fCTL` chunk is mandatory for every frame. More than one `fCTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `aDAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fCTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == 2.3 `aDAT`: The Animation Data Chunk ==<br /> <br /> The `aDAT` chunk contains one frame for the animation. Any `aDAT` chunks must follow any `IDAT` chunks. All `aDAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `aDAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fCTL` chunk 29 bytes `fCTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `fEND` chunk 12 bytes `fEND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `aDAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `aDAT` is fixed.<br /> <br /> The frame data within the `aDAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `fEND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `fEND` chunk is a mandatory last chunk in the data part of the `aDAT` chunk. Only one `fEND` per `aDAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`aDAT`) and every chunk within (`fCTL`, `IDAT`s, `fEND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> = 4. Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `aDAT`, `fCTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fCTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> = 5. Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=30433 2006-08-02T05:11:28Z

<p>Andrew: /* 2. Structure */</p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `aCTL` chunk must appear in the stream before any `IDAT` chunks. The `aCTL` structure is described in the next section.<br /> <br /> An `fCTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `aDAT` chunks, containing information about placement and rendering of a frame in `fCTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `aDAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == 2.1. `aCTL`: The Animation Control Chunk ==<br /> <br /> The `aCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `aCTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of aDAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == 2.2 `fCTL`: The Frame Control Chunk ==<br /> <br /> The `fCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fCTL` chunk must appear before the first `IDAT` chunk. Position relative to the `aCTL` chunk is not specified.<br /> * For any subsequent frames, the `fCTL` chunk must be first in the data part of the `aDAT` chunk.<br /> <br /> The `fCTL` chunk is mandatory for every frame. More than one `fCTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `aDAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fCTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == 2.3 `aDAT`: The Animation Data Chunk ==<br /> <br /> The `aDAT` chunk contains one frame for the animation. Any `aDAT` chunks must follow any `IDAT` chunks. All `aDAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `aDAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fCTL` chunk 29 bytes `fCTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `fEND` chunk 12 bytes `fEND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `aDAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `aDAT` is fixed.<br /> <br /> The frame data within the `aDAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `fEND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `fEND` chunk is a mandatory last chunk in the data part of the `aDAT` chunk. Only one `fEND` per `aDAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`aDAT`) and every chunk within (`fCTL`, `IDAT`s, `fEND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> = 4. Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `aDAT`, `fCTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fCTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> = 5. Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=30432 2006-08-02T05:11:08Z

<p>Andrew: /* 1. Overview */</p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = 2. Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `aCTL` chunk must appear in the stream before any `IDAT` chunks. The `aCTL` structure is described in the next section.<br /> <br /> An `fCTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `aDAT` chunks, containing information about placement and rendering of a frame in `fCTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `aDAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == 2.1. `aCTL`: The Animation Control Chunk ==<br /> <br /> The `aCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `aCTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of aDAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == 2.2 `fCTL`: The Frame Control Chunk ==<br /> <br /> The `fCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fCTL` chunk must appear before the first `IDAT` chunk. Position relative to the `aCTL` chunk is not specified.<br /> * For any subsequent frames, the `fCTL` chunk must be first in the data part of the `aDAT` chunk.<br /> <br /> The `fCTL` chunk is mandatory for every frame. More than one `fCTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `aDAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fCTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == 2.3 `aDAT`: The Animation Data Chunk ==<br /> <br /> The `aDAT` chunk contains one frame for the animation. Any `aDAT` chunks must follow any `IDAT` chunks. All `aDAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `aDAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fCTL` chunk 29 bytes `fCTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `fEND` chunk 12 bytes `fEND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `aDAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `aDAT` is fixed.<br /> <br /> The frame data within the `aDAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `fEND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `fEND` chunk is a mandatory last chunk in the data part of the `aDAT` chunk. Only one `fEND` per `aDAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`aDAT`) and every chunk within (`fCTL`, `IDAT`s, `fEND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> <br /> <br /> = 4. Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `aDAT`, `fCTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fCTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> = 5. Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=30431 2006-08-02T05:10:50Z

<p>Andrew: /* 3. Interaction with other PNG chunks */</p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = 1. Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = 2. Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `aCTL` chunk must appear in the stream before any `IDAT` chunks. The `aCTL` structure is described in the next section.<br /> <br /> An `fCTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `aDAT` chunks, containing information about placement and rendering of a frame in `fCTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `aDAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == 2.1. `aCTL`: The Animation Control Chunk ==<br /> <br /> The `aCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `aCTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of aDAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == 2.2 `fCTL`: The Frame Control Chunk ==<br /> <br /> The `fCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fCTL` chunk must appear before the first `IDAT` chunk. Position relative to the `aCTL` chunk is not specified.<br /> * For any subsequent frames, the `fCTL` chunk must be first in the data part of the `aDAT` chunk.<br /> <br /> The `fCTL` chunk is mandatory for every frame. More than one `fCTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `aDAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fCTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == 2.3 `aDAT`: The Animation Data Chunk ==<br /> <br /> The `aDAT` chunk contains one frame for the animation. Any `aDAT` chunks must follow any `IDAT` chunks. All `aDAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `aDAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fCTL` chunk 29 bytes `fCTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `fEND` chunk 12 bytes `fEND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `aDAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `aDAT` is fixed.<br /> <br /> The frame data within the `aDAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `fEND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `fEND` chunk is a mandatory last chunk in the data part of the `aDAT` chunk. Only one `fEND` per `aDAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`aDAT`) and every chunk within (`fCTL`, `IDAT`s, `fEND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> <br /> <br /> = 4. Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `aDAT`, `fCTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fCTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> = 5. Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew https://wiki.mozilla.org/index.php?title=APNG_Specification&diff=30430 2006-08-02T05:09:08Z

<p>Andrew: /* 2. Structure */</p> <hr /> <div>APNG 0.4 &lt;i&gt;[DRAFT]&lt;/i&gt;<br /> <br /> Authors:<br /> * Stuart Parmenter &lt;pavlov@pavlov.net&gt;<br /> * Vladimir Vukicevic &lt;vladimir@pobox.com&gt;<br /> <br /> = 1. Overview =<br /> <br /> APNG is an extension of the [PNG][pngspec] format, adding support for animated images. It is intended to be a replacement for simple animated images that have traditionally used the [GIF][gifspec] format, while adding support for 24-bit images and 8-bit transparency. APNG is a simpler alternative to MNG, providing a spec suitable for the most common usage of animated images on the Internet.<br /> <br /> APNG is backwards-compatible with PNG; any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG.<br /> <br /> = 2. Structure =<br /> <br /> An APNG stream is a normal PNG stream as defined in the [PNG Specification][pngspec], with four additional chunks describing the animation and providing additional frame data. The first frame of an animation, frame 0, is encoded as a normal PNG. This frame is what decoders that do not understand the APNG chunks will display.<br /> <br /> The size of the first frame defines the boundaries of the entire animation; hence, if extra space will be needed for later frames that is unused in the first frame, the first frame should be appropriately padded with fully transparent regions.<br /> <br /> To be recognized as an APNG, an `aCTL` chunk must appear in the stream before any `IDAT` chunks. The `aCTL` structure is described in the next section.<br /> <br /> An `fCTL` chunk must also appear before `IDAT`, providing frame information for the first frame encoded in the PNG stream's `IDAT` chunks, known as frame 0.<br /> <br /> Subsequent frames are encoded in `aDAT` chunks, containing information about placement and rendering of a frame in `fCTL` chunks, as well as frame data encoded as normal PNG streams. The full layout of the `aDAT` chunk is described in section 2.3.<br /> <br /> Note: For purposes of chunk descriptions, an &quot;unsigned int&quot; shall be a 32-bit unsigned integer in network byte order; a &quot;signed int&quot; shall be a 32-bit signed integer in network byte order; an &quot;unsigned short&quot; shall be a 16-bit unsigned integer in network byte order; a &quot;byte&quot; shall be a 8-bit unsigned integer.<br /> <br /> == 2.1. `aCTL`: The Animation Control Chunk ==<br /> <br /> The `aCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the first `IDAT` chunk within a valid PNG stream.<br /> <br /> The `aCTL` chunk contains:<br /> <br /> byte<br /> 0 num_frames (unsigned int) Number of frames<br /> 4 num_iterations (unsigned int) Number of times to loop this APNG. 0 indicates infinite looping.<br /> <br /> `num_frames` indicates the total number of frames in the animation, that is the first frame plus the number of aDAT chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. In case this number does not match the actual number of frames, behaviour of the implementation is not specified.<br /> <br /> `num_iterations` indicates the number of iterations that this animation should play; if it is 0, the animation should play indefinitely. If nonzero, the animation should come to rest on the final non-skipped frame at the end of the last iteration.<br /> <br /> == 2.2 `fCTL`: The Frame Control Chunk ==<br /> <br /> The `fCTL` chunk is an ancillary chunk as defined in the PNG Specification. It must appear before the IDAT chunks of the frame to which it applies, specifically:<br /> <br /> * For the first frame, the `fCTL` chunk must appear before the first `IDAT` chunk. Position relative to the `aCTL` chunk is not specified.<br /> * For any subsequent frames, the `fCTL` chunk must be first in the data part of the `aDAT` chunk.<br /> <br /> The `fCTL` chunk is mandatory for every frame. More than one `fCTL` chunk per frame is not allowed.<br /> <br /> Format:<br /> <br /> byte<br /> 0 sequence_number (unsigned int) Sequence number of the frame, starting from 0<br /> 4 x_offset (unsigned int) X position at which to render this frame<br /> 8 y_offset (unsigned int) Y position at which to render this frame<br /> 12 delay_num (unsigned short) Frame delay fraction numerator<br /> 14 delay_den (unsigned short) Frame delay fraction denominator<br /> 16 render_op (byte) Type of canvas area disposal to be done after rendering this frame<br /> <br /> The `sequence_number` shall begin with 0 for the first `aDAT` in the PNG stream, and increase by one with each subsequent frame.<br /> <br /> The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fCTL`, and the width and height from this frame's `IHDR`. For frame 0, the `x_offset` and `y_offset` fields must be 0. Should parts<br /> of the region fall outside the canvas defined by frame 0, rendering is to be clipped to that canvas.<br /> <br /> The `delay_num` and `delay_den` parameters together specify a fraction indicating the delay after the current frame, in seconds. If the denominator is 0, it is to be treated as if it were 100 (that is, delay_num then specifies 1/100ths of a second). If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay.<br /> <br /> The `render_op` parameter contains flags describing how the frame is to be disposed before rendering the next frame; it also specifies whether the frame is to be alpha blended into the current canvas content, or whether it should completely replace its region in the canvas. Valid render_op flags are:<br /> <br /> bit<br /> +-------------------------------+<br /> | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br /> +-------------|---|---|---|---|-+<br /> | | +---+---+------ bits 0-2: dispose_op<br /> | |<br /> | +------------------ bit 3: APNG_RENDER_OP_BLEND_FLAG<br /> |<br /> +---------------------- bit 4: APNG_RENDER_OP_SKIP_FRAME<br /> <br /> Bits 5 through 7 are reserved and must be set to 0. Valid values for `dispose_op` are:<br /> <br /> value:<br /> 0 APNG_RENDER_OP_DISPOSE_NONE<br /> 1 APNG_RENDER_OP_DISPOSE_BACKGROUND<br /> 2 APNG_RENDER_OP_DISPOSE_PREVIOUS<br /> <br /> * `APNG_RENDER_OP_DISPOSE_NONE`: no disposal is done on this frame before rendering the next; its contents are left on the canvas. This is the default.<br /> * `APNG_RENDER_OP_DISPOSE_BACKGROUND`: the frame's region is to be cleared to the background color. If no `bKGD` chunk is specified, the result is fully transparent black (r, g, b, and a all 0).<br /> * `APNG_RENDER_OP_DISPOSE_PREVIOUS`: the frame's region is to be reverted to the previous contents.<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` may be added to any of the above disposal perations. If this flag is not set, all color components of the frame, including alpha, overwrite the current contents of the frame's canvas region. If the BLEND_FLAG is set the frame should be composited onto the canvas based on its alpha, using a simple OVER operation:<br /> <br /> Csrc - component of pixel in the frame<br /> Asrc - alpha component of a pixel in the frame<br /> Cdst - component of pixel in the canvas region<br /> C - resulting component value to be rendered in the canvas region<br /> <br /> C = Csrc * Asrc + Cdst * (1 - Asrc)<br /> <br /> `APNG_RENDER_OP_BLEND_FLAG` is not valid for color types 0 (greyscale without alpha) or 2 (truecolor without alpha). It is valid for type 3 (indexed) images; however, the resulting pixel values may not be present in the specified palette. It is always valid for type 4 (greyscale with alpha) and type 6 (truecolor with alpha) images.<br /> <br /> If `APNG_RENDER_OP_SKIP_FRAME` is present, then the decoder should not render the current frame as part of the animation. Though this flag can be set on any frame and must be honored, it is most useful for frame 0, to prevent the frame that would be visible to PNG viewers not supporting animation from being part of the animated frame set. If animation in the viewer is not desired or explicitly disabled by the user, the viewer should display frame 0 even if `SKIP_FRAME` is set on frame 0. This provides content authors with a means to provide a still image to be used in lieu of the full animation.<br /> <br /> == 2.3 `aDAT`: The Animation Data Chunk ==<br /> <br /> The `aDAT` chunk contains one frame for the animation. Any `aDAT` chunks must follow any `IDAT` chunks. All `aDAT` chunks must be adjacent in the PNG stream. Should a decoder receive an APNG stream with missing or out of order `aDAT` chunks, it is under no obligation to attempt to reorder the chunks and may treat that case as an error condition.<br /> <br /> Format:<br /> <br /> byte<br /> 0 `fCTL` chunk 29 bytes `fCTL` chunk for this frame<br /> 29 `IDAT` chunks X bytes Frame data for this frame<br /> 29+X `fEND` chunk 12 bytes `fEND` chunk to mark the end of the frame data<br /> <br /> Each of the chunks contained in the data section of the `aDAT` must follow all the rules in section 5 of the PNG specification, except 5.6 Chunk Ordering. The order of chunks within the `aDAT` is fixed.<br /> <br /> The frame data within the `aDAT` consists of a series of `IDAT` chunks, following the rules from section 11.2.4 of the PNG Specification.<br /> <br /> The `fEND` is an ancillary, zero-length data field chunk, used to mark the end of the frame data. The `fEND` chunk is a mandatory last chunk in the data part of the `aDAT` chunk. Only one `fEND` per `aDAT` is allowed.<br /> <br /> Each frame inherits every property specified by any critical or ancillary chunks before the first IDAT in the file.<br /> <br /> Note: both the container chunk (`aDAT`) and every chunk within (`fCTL`, `IDAT`s, `fEND`) must specify the length of its own data field and the CRC over its own chunk name + chunk data as required by section 5.3 of the PNG Specification.<br /> <br /> = 3. Interaction with other PNG chunks =<br /> <br /> == 3.1. `PLTE` and `tRNS` chunks ==<br /> <br /> Should `PLTE` or `tRNS` chunks be valid for the PNG stream's color type, any `PLTE` or `tRNS` specified in the enclosing stream is to be treated as a global palette or transparency, and applied to each frame. Individual frames may override the global values by including their own `PLTE` or `tRNS` between<br /> their `IHDR` and `IDAT` chunks; such a local palette or transparency only applies to the frame where it is specified.<br /> <br /> A local palette or transparency should have no effect on any content in the canvas other than the frame currently being rendered. Specifically, palette<br /> animation is not supported -- the RGBA values of previously rendered content still visible on the canvas are not to be changed by a local palette.<br /> <br /> == 3.2. Colour space chunks ==<br /> <br /> Colour space chunks, as defined in section 11.3.3 of the PNG specification, shall only be valid in the enclosing stream and apply to all the frames within the stream. Any Colour space chunks within individual frames should be ignored by a decoder.<br /> <br /> == 3.3. Other chunks ==<br /> <br /> Chunks other than those specifically mentioned here should apply to the overall stream's canvas area, including chunks such as `bKGD`, `hIST`, `oFFs`, etc.<br /> <br /> = 4. Revisions to this Specification ==<br /> <br /> == From 0.1 ==<br /> <br /> * Renamed chunks to `anIm` and `frAm` to comply with chunk naming conventions in the PNG spec.<br /> <br /> * Added a more detailed explanation of APNG structure in Section 2.<br /> <br /> * Added information for png interaction with other chunks in section 3.2.<br /> <br /> * Changed `frAm` chunk offsets and delay into signed integers.<br /> <br /> == From 0.2 ==<br /> <br /> * Changed `frAm` chunk to `afRa` to avoid conflict with MNG `FRAM` chunk.<br /> <br /> * Changed format: instead of sequences of IHDR..IDAT..IEND, frames other than frame 0 are stored in `afRa` chunks.<br /> <br /> * Added `start_frame` to `anIm` to indicate which frame the animation should start on.<br /> <br /> * Removed `num_frames` from `anIm` chunk<br /> <br /> == From 0.3 ==<br /> <br /> * Added `aCTL`, `aDAT`, `fCTL` chunk descriptions as per the latest png-list discussion<br /> <br /> * Added section 4, &quot;Interactions with other PNG chunks&quot;; described global and local palettes and<br /> transparency<br /> <br /> * Changed `oFFs` chunk section to refer to more general chunks<br /> <br /> * Updated `aDAT` description to indicate that all frames must either be in a single chunk, or that the first<br /> chunk must have empty data.<br /> <br /> * Added notice that each frame's region (x,y,width,height) must lie completely within the parent PNG canvas<br /> <br /> * Fixed dispose_op description (after, not before)<br /> <br /> * Changed dipose_op to render_op; added disposal description; added BLEND flag<br /> <br /> * Changed delay_time to a delay numerator and denominator, for specifying delays that don't into integer<br /> numbers of milliseconds.<br /> <br /> * Added note to clarify that palette animation is not supported.<br /> <br /> * Removed start_frame from aCTL; require fCTL for frame 0; added SKIP_FRAME fCTL flag.<br /> <br /> = 5. Test Encoder and Sample Images =<br /> <br /> _Coming soon_<br /> <br /> = A. References =<br /> <br /> [pngspec]: http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> * http://www.w3.org/TR/PNG/ &quot;Portable Network Graphics (PNG) Specification (Second Edition)&quot;<br /> <br /> [pngext]: http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> * http://www.libpng.org/pub/png/spec/register/pngext-1.2.0-pdg.html &quot;Extensions to the PNG Specification, Version 1.2.0&quot;<br /> <br /> [gifspec]: http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;<br /> * http://www.w3.org/Graphics/GIF/spec-gif89a.txt &quot;Graphics Interchange Format 89a&quot;</div>

Andrew