2.7.1.1. Animation

An animation is controlled by 'ANIM' and 'ANMF' Chunks.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ANIM')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Background Color                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Loop Count           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For an animated image, this chunk contains the global parameters of the animation.¶

Background Color: 32 bits (uint32)

The default background color of the canvas in [Blue, Green, Red, Alpha] byte order. This color MAY be used to fill the unused space on the canvas around the frames, as well as the transparent pixels of the first frame. The background color is also used when the Disposal method is 1.¶

Notes:¶

• The background color MAY contain a nonopaque alpha value, even if the Alpha flag in the 'VP8X' Chunk (Figure 7) is unset.¶
• Viewer applications SHOULD treat the background color value as a hint and are not required to use it.¶
• The canvas is cleared at the start of each loop. The background color MAY be used to achieve this.¶

Loop Count: 16 bits (uint16)

The number of times to loop the animation. If it is 0, this means infinitely.¶

This chunk MUST appear if the Animation flag in the 'VP8X' Chunk is set. If the Animation flag is not set and this chunk is present, it MUST be ignored.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ANMF')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Frame X                |             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...          Frame Y            |   Frame Width Minus One     ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...             |           Frame Height Minus One              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Frame Duration                |  Reserved |B|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                         Frame Data                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For animated images, this chunk contains information about a single frame. If the Animation flag is not set, then this chunk SHOULD NOT be present.¶

Frame X: 24 bits (uint24)

The X coordinate of the upper left corner of the frame is Frame X * 2.¶

Frame Y: 24 bits (uint24)

The Y coordinate of the upper left corner of the frame is Frame Y * 2.¶

Frame Width Minus One: 24 bits (uint24)

The 1-based width of the frame. The frame width is 1 + Frame Width Minus One.¶

Frame Height Minus One: 24 bits (uint24)

The 1-based height of the frame. The frame height is 1 + Frame Height Minus One.¶

Frame Duration: 24 bits (uint24)

The time to wait before displaying the next frame, in 1-millisecond units. Note that the interpretation of the Frame Duration of 0 (and often <= 10) is defined by the implementation. Many tools and browsers assign a minimum duration similar to GIF.¶

Reserved: 6 bits

MUST be 0. Readers MUST ignore this field.¶

Blending method (B): 1 bit

Indicates how transparent pixels of the current frame are to be blended with corresponding pixels of the previous canvas:¶

• 0: Use alpha-blending. After disposing of the previous frame, render the current frame on the canvas using alpha-blending (Section 2.7.1.1, Paragraph 8, Item 16.4.2). If the current frame does not have an alpha channel, assume the alpha value is 255, effectively replacing the rectangle.¶
• 1: Do not blend. After disposing of the previous frame, render the current frame on the canvas by overwriting the rectangle covered by the current frame.¶

Disposal method (D): 1 bit

Indicates how the current frame is to be treated after it has been displayed (before rendering the next frame) on the canvas:¶

• 0: Do not dispose. Leave the canvas as is.¶
• 1: Dispose to the background color. Fill the rectangle on the canvas covered by the current frame with the background color specified in the 'ANIM' Chunk (Figure 8).¶

Notes:¶

• The frame disposal only applies to the frame rectangle, that is, the rectangle defined by Frame X, Frame Y, frame width, and frame height. It may or may not cover the whole canvas.¶

• Alpha-blending:¶

  Given that each of the R, G, B, and A channels is 8 bits and the RGB channels are not premultiplied by alpha, the formula for blending 'dst' onto 'src' is:¶

  blend.A = src.A + dst.A * (1 - src.A / 255)
  if blend.A = 0 then
    blend.RGB = 0
  else
    blend.RGB =
        (src.RGB * src.A +
         dst.RGB * dst.A * (1 - src.A / 255)) / blend.A
  

  ¶
• Alpha-blending SHOULD be done in linear color space by taking into account the color profile (Section 2.7.1.4) of the image. If the color profile is not present, standard RGB (sRGB) is to be assumed. (Note that sRGB also needs to be linearized due to a gamma of ~2.2.)¶

Frame Data: Chunk Size bytes - 16

Consists of:¶

• An optional alpha subchunk (Section 2.7.1.2) for the frame.¶
• A bitstream subchunk (Section 2.7.1.3) for the frame.¶
• An optional list of unknown chunks (Section 2.7.1.6).¶

2.7.1.2. Alpha

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ALPH')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv| P | F | C |     Alpha Bitstream...                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved (Rsv): 2 bits

MUST be 0. Readers MUST ignore this field.¶

Preprocessing (P): 2 bits

These informative bits are used to signal the preprocessing that has been performed during compression. The decoder can use this information to, for example, dither the values or smooth the gradients prior to display.¶

• 0: No preprocessing.¶
• 1: Level reduction.¶

Decoders are not required to use this information in any specified way.¶

Filtering method (F): 2 bits

The filtering methods used are described as follows:¶

• 0: None.¶
• 1: Horizontal filter.¶
• 2: Vertical filter.¶
• 3: Gradient filter.¶

For each pixel, filtering is performed using the following calculations. Assume the alpha values surrounding the current X position are labeled as:¶

 C | B |
---+---+
 A | X |

We seek to compute the alpha value at position X. First, a prediction is made depending on the filtering method:¶

• Method 0: predictor = 0¶
• Method 1: predictor = A¶
• Method 2: predictor = B¶
• Method 3: predictor = clip(A + B - C)¶

where clip(v) is equal to:¶

• 0 if v < 0,¶
• 255 if v > 255, or¶
• v otherwise.¶

The final value is derived by adding the decompressed value X to the predictor and using modulo-256 arithmetic to wrap the [256..511] range into the [0..255] one:¶

alpha = (predictor + X) % 256

¶

There are special cases for the left-most and top-most pixel positions.¶

For example, the top-left value at location (0, 0) uses 0 as the predictor value. Otherwise:¶

• For horizontal or gradient filtering methods, the left-most pixels at location (0, y) are predicted using the location (0, y-1) just above.¶
• For vertical or gradient filtering methods, the top-most pixels at location (x, 0) are predicted using the location (x-1, 0) on the left.¶

Compression method (C): 2 bits

The compression method used:¶

• 0: No compression.¶
• 1: Compressed using the WebP lossless format.¶

Alpha bitstream: Chunk Size bytes - 1

Encoded alpha bitstream.¶

This optional chunk contains encoded alpha data for this frame. A frame containing a 'VP8L' Chunk SHOULD NOT contain this chunk.¶

The alpha channel data is stored as uncompressed raw data (when the compression method is '0') or compressed using the lossless format (when the compression method is '1').¶

• Raw data: This consists of a byte sequence of length = width * height, containing all the 8-bit transparency values in scan order.¶

• Lossless format compression: The byte sequence is a compressed image-stream (as described in Section 3) of implicit dimensions width x height. That is, this image-stream does NOT contain any headers describing the image dimensions.¶

• Once the image-stream is decoded into Alpha, Red, Green, Blue (ARGB) color values, following the process described in the lossless format specification, the transparency information must be extracted from the green channel of the ARGB quadruplet.¶

2.7.1.3. Bitstream (VP8/VP8L)

This chunk contains compressed bitstream data for a single frame.¶

A bitstream chunk may be either (i) a 'VP8 ' Chunk, using 'VP8 ' (note the significant fourth-character space) as its FourCC, or (ii) a 'VP8L' Chunk, using 'VP8L' as its FourCC.¶

The formats of' VP8 ' and 'VP8L' Chunks are as described in Sections 2.5 and 2.6, respectively.¶

2.7.1.4. Color Profile

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ICCP')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                       Color Profile                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Color Profile: Chunk Size bytes

ICC profile.¶

This chunk MUST appear before the image data.¶

There SHOULD be at most one such chunk. If there are more such chunks, readers MAY ignore all except the first one. See the ICC specification [ICC] for details.¶

If this chunk is not present, sRGB SHOULD be assumed.¶

2.7.1.5. Metadata

Metadata can be stored in 'EXIF' or 'XMP ' Chunks.¶

There SHOULD be at most one chunk of each type ('EXIF' and 'XMP '). If there are more such chunks, readers MAY ignore all except the first one.¶

The chunks are defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('EXIF')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        Exif Metadata                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Exif Metadata: Chunk Size bytes

Image metadata in [Exif] format.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('XMP ')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        XMP Metadata                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

XMP Metadata: Chunk Size bytes

Image metadata in [XMP] format.¶

Additional guidance about handling metadata can be found in the Metadata Working Group's "Guidelines For Handling Image Metadata" [MWG].¶

2.7.1.6. Unknown Chunks

A RIFF chunk (described in Section 2.3) whose FourCC is different from any of the chunks described in this section is considered an unknown chunk.¶

A file MAY contain unknown chunks:¶

• at the end of the file, as described in Section 2.7, or¶
• at the end of 'ANMF' Chunks, as described in Section 2.7.1.1.¶

Readers SHOULD ignore these chunks. Writers SHOULD preserve them in their original order (unless they specifically intend to modify these chunks).¶

3.6.2.1. Prefix-Coded Literals

The pixel is stored as prefix-coded values of green, red, blue, and alpha (in that order). See Section 3.7.2.3 for details.¶

3.6.2.2. LZ77 Backward Reference

Backward references are tuples of length and distance code:¶

• Length indicates how many pixels in scan-line order are to be copied.¶
• Distance code is a number indicating the position of a previously seen pixel, from which the pixels are to be copied. The exact mapping is described below (Section 3.6.2.2.1).¶

The length and distance values are stored using LZ77 prefix coding.¶

LZ77 prefix coding divides large integer values into two parts: the prefix code and the extra bits. The prefix code is stored using an entropy code, while the extra bits are stored as they are (without an entropy code).¶

The following table denotes the prefix codes and extra bits used for storing different ranges of values.¶

The pseudocode to obtain a (length or distance) value from the prefix code is as follows:¶

if (prefix_code < 4) {
  return prefix_code + 1;
}
int extra_bits = (prefix_code - 2) >> 1;
int offset = (2 + (prefix_code & 1)) << extra_bits;
return offset + ReadBits(extra_bits) + 1;

(0, 1),  (1, 0),  (1, 1),  (-1, 1), (0, 2),  (2, 0),  (1, 2),
(-1, 2), (2, 1),  (-2, 1), (2, 2),  (-2, 2), (0, 3),  (3, 0),
(1, 3),  (-1, 3), (3, 1),  (-3, 1), (2, 3),  (-2, 3), (3, 2),
(-3, 2), (0, 4),  (4, 0),  (1, 4),  (-1, 4), (4, 1),  (-4, 1),
(3, 3),  (-3, 3), (2, 4),  (-2, 4), (4, 2),  (-4, 2), (0, 5),
(3, 4),  (-3, 4), (4, 3),  (-4, 3), (5, 0),  (1, 5),  (-1, 5),
(5, 1),  (-5, 1), (2, 5),  (-2, 5), (5, 2),  (-5, 2), (4, 4),
(-4, 4), (3, 5),  (-3, 5), (5, 3),  (-5, 3), (0, 6),  (6, 0),
(1, 6),  (-1, 6), (6, 1),  (-6, 1), (2, 6),  (-2, 6), (6, 2),
(-6, 2), (4, 5),  (-4, 5), (5, 4),  (-5, 4), (3, 6),  (-3, 6),
(6, 3),  (-6, 3), (0, 7),  (7, 0),  (1, 7),  (-1, 7), (5, 5),
(-5, 5), (7, 1),  (-7, 1), (4, 6),  (-4, 6), (6, 4),  (-6, 4),
(2, 7),  (-2, 7), (7, 2),  (-7, 2), (3, 7),  (-3, 7), (7, 3),
(-7, 3), (5, 6),  (-5, 6), (6, 5),  (-6, 5), (8, 0),  (4, 7),
(-4, 7), (7, 4),  (-7, 4), (8, 1),  (8, 2),  (6, 6),  (-6, 6),
(8, 3),  (5, 7),  (-5, 7), (7, 5),  (-7, 5), (8, 4),  (6, 7),
(-6, 7), (7, 6),  (-7, 6), (8, 5),  (7, 7),  (-7, 7), (8, 6),
(8, 7)

(xi, yi) = distance_map[distance_code - 1]
dist = xi + yi * image_width
if (dist < 1) {
  dist = 1
}

3.6.2.3. Color Cache Coding

Color cache stores a set of colors that have been recently used in the image.¶

Color cache codes are stored as follows. First, there is a 1-bit value that indicates if the color cache is used. If this bit is 0, no color cache codes exist, and they are not transmitted in the prefix code that decodes the green symbols and the length prefix codes. However, if this bit is 1, the color cache size is read next:¶

int color_cache_code_bits = ReadBits(4);
int color_cache_size = 1 << color_cache_code_bits;

color_cache_code_bits defines the size of the color cache (1 << color_cache_code_bits). The range of allowed values for color_cache_code_bits is [1..11]. Compliant decoders MUST indicate a corrupted bitstream for other values.¶

A color cache is an array of size color_cache_size. Each entry stores one ARGB color. Colors are looked up by indexing them by (0x1e35a7bd * color) >> (32 - color_cache_code_bits). Only one lookup is done in a color cache; there is no conflict resolution.¶

In the beginning of decoding or encoding of an image, all entries in all color cache values are set to zero. The color cache code is converted to this color at decoding time. The state of the color cache is maintained by inserting every pixel, be it produced by backward referencing or as literals, into the cache in the order they appear in the stream.¶