WebP Image Format Media Type Registration

2.7.1.1. Animation

An animation is controlled by ANIM and ANMF chunks.¶

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

 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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. Background color is also used when disposal method is 1.¶

Note:¶

• Background color MAY contain a transparency value (alpha), even if the Alpha flag in VP8X chunk (Section 2.7, Paragraph 9) 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. 0 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 SHOULD be ignored.¶

ANMF chunk:¶

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.¶

 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                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 the interpretation of frame duration of 0 (and often <= 10) is implementation defined. Many tools and browsers assign a minimum duration similar to GIF.¶

Reserved: 6 bits

MUST be 0.¶

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 10, Item 16.4.2). If the current frame does not have an alpha channel, assume alpha value of 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 background color. Fill the rectangle on the canvas covered by the current frame with background color specified in the ANIM chunk (Section 2.7.1.1, Paragraph 2).¶

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-bit, 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, sRGB is to be assumed. (Note that sRGB also needs to be linearized due to a gamma of ~2.2).¶

Frame Data: Chunk Size - 16 bytes

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).¶

Note: The 'ANMF' payload, Frame Data above, consists of individual padded chunks as described by the RIFF file format (Section 2.3).¶

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.¶

Pre-processing (P): 2 bits

These informative bits are used to signal the pre-processing that has been performed during compression. The decoder can use this information to e.g. dither the values or smooth the gradients prior to display.¶

• 0: no pre-processing¶
• 1: level reduction¶

Filtering method (F): 2 bits

The filtering method used:¶

• 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¶
• 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 left-most and top-most pixel positions:¶

• Top-left value at location (0,0) uses 0 as 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.¶

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

Compression method (C): 2 bits

The compression method used:¶

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

Alpha bitstream: Chunk Size - 1 bytes

Encoded alpha bitstream.¶

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

Rationale: The transparency information is already part of the 'VP8L' chunk.¶

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

• Raw data: 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 dimension width x height. That is, this image-stream does NOT contain any headers describing the image dimension.¶

  Rationale: the dimension is already known from other sources, so storing it again would be redundant and error-prone.¶

  Once the image-stream is decoded into 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.¶

  Rationale: the green channel is allowed extra transformation steps in the specification -- unlike the other channels -- that can improve compression.¶

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 tag or (ii) a VP8L chunk, using "VP8L" as its tag.¶

The formats of VP8 and VP8L chunks are as described in Section 2.5 and Section 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.6. Unknown Chunks

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

Rationale: Allowing unknown chunks gives a provision for future extension of the format, and also allows storage of any application-specific data.¶

A file MAY contain unknown chunks:¶

• At the end of the file as described in Section 2.7, Paragraph 9.¶
• 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.7.2.1. Decoding and Building the Prefix Codes

There are several steps in decoding the prefix codes.¶

This section describes how to read the prefix code lengths from the bitstream.¶

The prefix code lengths can be coded in two ways. The method used is specified by a 1-bit value.¶

• If this bit is 1, it is a simple code length code, and¶
• If this bit is 0, it is a normal code length code.¶

In both cases, there can be unused code lengths that are still part of the stream. This may be inefficient, but it is allowed by the format.¶

(i) Simple Code Length Code:¶

This variant is used in the special case when only 1 or 2 prefix symbols are in the range [0..255] with code length 1. All other prefix code lengths are implicitly zeros.¶

The first bit indicates the number of symbols:¶

int num_symbols = ReadBits(1) + 1;

Following are the symbol values. This first symbol is coded using 1 or 8 bits depending on the value of is_first_8bits. The range is [0..1] or [0..255], respectively. The second symbol, if present, is always assumed to be in the range [0..255] and coded using 8 bits.¶

int is_first_8bits = ReadBits(1);
symbol0 = ReadBits(1 + 7 * is_first_8bits);
code_lengths[symbol0] = 1;
if (num_symbols == 2) {
  symbol1 = ReadBits(8);
  code_lengths[symbol1] = 1;
}

Note: Another special case is when all prefix code lengths are zeros (an empty prefix code). For example, a prefix code for distance can be empty if there are no backward references. Similarly, prefix codes for alpha, red, and blue can be empty if all pixels within the same meta prefix code are produced using the color cache. However, this case doesn't need a special handling, as empty prefix codes can be coded as those containing a single symbol 0.¶

(ii) Normal Code Length Code:¶

The code lengths of the prefix code fit in 8 bits and are read as follows. First, num_code_lengths specifies the number of code lengths.¶

int num_code_lengths = 4 + ReadBits(4);

If num_code_lengths is > 18, the bitstream is invalid.¶

The code lengths are themselves encoded using prefix codes: lower level code lengths code_length_code_lengths first have to be read. The rest of those code_length_code_lengths (according to the order in kCodeLengthCodeOrder) are zeros.¶

int kCodeLengthCodes = 19;
int kCodeLengthCodeOrder[kCodeLengthCodes] = {
  17, 18, 0, 1, 2, 3, 4, 5, 16, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
};
int code_length_code_lengths[kCodeLengthCodes] = { 0 };  // All zeros.
for (i = 0; i < num_code_lengths; ++i) {
  code_length_code_lengths[kCodeLengthCodeOrder[i]] = ReadBits(3);
}

Next, if ReadBits(1) == 0, the maximum number of different read symbols is num_code_lengths. Otherwise, it is defined as:¶

int length_nbits = 2 + 2 * ReadBits(3);
int max_symbol = 2 + ReadBits(length_nbits);

A prefix table is then built from code_length_code_lengths and used to read up to max_symbol code lengths.¶

• Code [0..15] indicates literal code lengths.¶

  • Value 0 means no symbols have been coded.¶
  • Values [1..15] indicate the bit length of the respective code.¶
• Code 16 repeats the previous non-zero value [3..6] times, i.e., 3 + ReadBits(2) times. If code 16 is used before a non-zero value has been emitted, a value of 8 is repeated.¶
• Code 17 emits a streak of zeros [3..10], i.e., 3 + ReadBits(3) times.¶
• Code 18 emits a streak of zeros of length [11..138], i.e., 11 + ReadBits(7) times.¶

Once code lengths are read, a prefix code for each symbol type (A, R, G, B, distance) is formed using their respective alphabet sizes:¶

• G channel: 256 + 24 + color_cache_size¶
• other literals (A,R,B): 256¶
• distance code: 40¶

3.7.2.2. Decoding of Meta Prefix Codes

As noted earlier, the format allows the use of different prefix codes for different blocks of the image. Meta prefix codes are indexes identifying which prefix codes to use in different parts of the image.¶

Meta prefix codes may be used only when the image is being used in the role (Section 3.6.1) of an ARGB image.¶

There are two possibilities for the meta prefix codes, indicated by a 1-bit value:¶

• If this bit is zero, there is only one meta prefix code used everywhere in the image. No more data is stored.¶
• If this bit is one, the image uses multiple meta prefix codes. These meta prefix codes are stored as an entropy image (described below).¶

Entropy image:¶

The entropy image defines which prefix codes are used in different parts of the image, as described below.¶

The first 3-bits contain the prefix_bits value. The dimensions of the entropy image are derived from 'prefix_bits'.¶

int prefix_bits = ReadBits(3) + 2;
int prefix_xsize = DIV_ROUND_UP(xsize, 1 << prefix_bits);
int prefix_ysize = DIV_ROUND_UP(ysize, 1 << prefix_bits);

where DIV_ROUND_UP is as defined in Section 3.5.1.¶

Next bits contain an entropy image of width prefix_xsize and height prefix_ysize.¶

Interpretation of Meta Prefix Codes:¶

For any given pixel (x, y), there is a set of five prefix codes associated with it. These codes are (in bitstream order):¶

• prefix code #1: used for green channel, backward-reference length and color cache¶
• prefix code #2, #3 and #4: used for red, blue and alpha channels respectively.¶
• prefix code #5: used for backward-reference distance.¶

From here on, we refer to this set as a prefix code group.¶

The number of prefix code groups in the ARGB image can be obtained by finding the largest meta prefix code from the entropy image:¶

int num_huff_groups = max(entropy image) + 1;

where max(entropy image) indicates the largest prefix code stored in the entropy image.¶

As each prefix code groups contains five prefix codes, the total number of prefix codes is:¶

int num_huff_codes = 5 * num_huff_groups;

Given a pixel (x, y) in the ARGB image, we can obtain the corresponding prefix codes to be used as follows:¶

int position = (y >> prefix_bits) * prefix_xsize + (x >> prefix_bits);
int meta_huff_code = (entropy_image[pos] >> 8) & 0xffff;
PrefixCodeGroup huff_group = prefix_code_groups[meta_huff_code];

where, we have assumed the existence of PrefixCodeGroup structure, which represents a set of five prefix codes. Also, prefix_code_groups is an array of PrefixCodeGroup (of size num_huff_groups).¶

The decoder then uses prefix code group huff_group to decode the pixel (x, y) as explained in Section 3.7.2.3.¶

3.7.2.3. Decoding Entropy-coded Image Data

For the current position (x, y) in the image, the decoder first identifies the corresponding prefix code group (as explained in the last section). Given the prefix code group, the pixel is read and decoded as follows:¶

Read next symbol S from the bitstream using prefix code #1. Note that S is any integer in the range 0 to (256 + 24 + color_cache_size (Section 3.6.2.3) - 1).¶

The interpretation of S depends on its value:¶

1. if S < 256¶

   1. Use S as the green component¶
   2. Read red from the bitstream using prefix code #2¶
   3. Read blue from the bitstream using prefix code #3¶
   4. Read alpha from the bitstream using prefix code #4¶

2. if S < 256 + 24 && S < 256 + 24¶

   1. Use S - 256 as a length prefix code¶
   2. Read extra bits for length from the bitstream¶
   3. Determine backward-reference length L from length prefix code and the extra bits read.¶
   4. Read distance prefix code from the bitstream using prefix code #5¶
   5. Read extra bits for distance from the bitstream¶
   6. Determine backward-reference distance D from distance prefix code and the extra bits read.¶
   7. Copy the L pixels (in scan-line order) from the sequence of pixels prior to them by D pixels.¶

3. if S >= 256 + 24¶

   1. Use S - (256 + 24) as the index into the color cache.¶
   2. Get ARGB color from the color cache at that index.¶