WebP Image Format Media Type Registration
Google LLC
1600 Amphitheatre Parkway
Mountain View
CA
94043
United States of America
+1 650 253-0000
jzern@google.com
Google LLC
pascal.massimino@gmail.com
Google LLC
jyrki@google.com
General
Internet Engineering Task Force
VP8
WebP
This document provides the Media Type Registration for the subtype
image/webp.
Introduction
This document provides references for the WebP image format and
considerations for its use across platforms.
WebP is a Resource Interchange File Format
(RIFF) based image file format
() which supports lossless and lossy
compression as well as alpha (transparency) and animation. It covers use
cases similar to JPEG,
PNG and the
Graphics Interchange Format (GIF).
WebP consists of two compression algorithms used to reduce the size of
image pixel data, including alpha (transparency) information. Lossy
compression is achieved using VP8 intra-frame encoding . The lossless
algorithm stores and restores the pixel values exactly,
including the color values for zero alpha pixels. The format uses
subresolution images, recursively embedded into the format itself,
for storing statistical data about the images, such as the used
entropy codes, spatial predictors, color space conversion, and
color table. LZ77, prefix coding, and a color cache are
used for compression of the bulk data.
WebP Container Specification
Note this section is based on the documentation in the libwebp source repository at the time
of writing.
Introduction
WebP is an image format that uses either (i) the VP8 intra-frame
encoding to compress image data in a lossy
way, or (ii) the WebP lossless
encoding. These encoding schemes should make it more
efficient than currently used formats. It is optimized for fast
image transfer over the network (e.g., for websites). The WebP
format has feature parity (color profile, metadata, animation
etc) with other formats as well. This section describes the
structure of a WebP file.
The WebP container (i.e., RIFF container for WebP) allows feature
support over and above the basic use case of WebP (i.e., a file
containing a single image encoded as a VP8 key frame). The WebP
container provides additional support for:
- Lossless compression. An image can be
losslessly compressed, using the WebP Lossless Format.
- Metadata. An image may have metadata stored in
or formats.
- Transparency. An image may have transparency,
i.e., an alpha channel.
- Color Profile. An image may have an embedded
ICC profile.
- Animation. An image may have multiple frames
with pauses between them, making it an animation.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
Bit numbering in chunk diagrams starts at 0 for the most
significant bit ('MSB 0') as described in .
Terminology & Basics
A WebP file contains either a still image (i.e., an encoded matrix of
pixels) or an animation. Optionally,
it can also contain transparency information, color profile and
metadata. In case we need to refer only to the matrix of pixels, we
will call it the canvas of the image.
Below are additional terms used throughout this document:
- Reader/Writer
- Code that reads WebP files is referred to as a reader,
while code that writes them is referred to as a
writer.
- uint16
- A 16-bit, little-endian, unsigned integer.
- uint24
- A 24-bit, little-endian, unsigned integer.
- uint32
- A 32-bit, little-endian, unsigned integer.
- FourCC
- A FourCC (four-character code) is a uint32 created by
concatenating four ASCII characters in little-endian order.
- 1-based
- An unsigned integer field storing values offset by -1. e.g., Such
a field would store value 25 as 24.
RIFF File Format
The WebP file format is based on the RIFF (Resource Interchange File Format)
document format.
The basic element of a RIFF file is a chunk. It consists
of:
- Chunk FourCC: 32 bits
- ASCII four-character code used for chunk identification.
- Chunk Size: 32 bits (uint32)
- The size of the chunk not including this field, the chunk
identifier or padding.
- Chunk Payload: Chunk Size bytes
- The data payload. If Chunk Size is odd, a single
padding byte -- that SHOULD be 0 -- is added.
- ChunkHeader('ABCD')
- This is used to describe the FourCC and Chunk
Size header of individual chunks, where 'ABCD' is the FourCC
for the chunk. This element's size is 8 bytes.
Note: RIFF has a convention that all-uppercase
chunk FourCCs are standard chunks that apply to any RIFF file
format, while FourCCs specific to a file format are all lowercase.
WebP does not follow this convention.
WebP File Header
- 'RIFF': 32 bits
- The ASCII characters 'R' 'I' 'F' 'F'.
- File Size: 32 bits (uint32)
- The size of the file in bytes starting at offset 8. The maximum
value of this field is 2^32 minus 10 bytes and thus the size of the
whole file is at most 4GiB minus 2 bytes.
- 'WEBP': 32 bits
- The ASCII characters 'W' 'E' 'B' 'P'.
A WebP file MUST begin with a RIFF header with the FourCC 'WEBP'. The
file size in the header is the total size of the chunks that follow
plus 4 bytes for the 'WEBP' FourCC. The file SHOULD NOT
contain anything after it. As the size of any chunk is even, the
size given by the RIFF header is also even. The contents of
individual chunks will be described in the following sections.
Simple File Format (Lossy)
This layout SHOULD be used if the image requires lossy encoding and
does not require transparency or other advanced features provided by
the extended format. Files with this layout are smaller and supported
by older software.
Simple WebP (lossy) file format:
VP8 chunk:
- VP8 data: Chunk Size bytes
- VP8 bitstream data.
The VP8 bitstream format specification is described by . Note that the VP8 frame header contains the VP8
frame width and height. That is assumed to be the width and height of
the canvas.
The VP8 specification describes how to decode the image into Y'CbCr
format. To convert to RGB, Rec. 601 SHOULD
be used.
Simple File Format (Lossless)
Note: Older readers may not support files using the
lossless format.
This layout SHOULD be used if the image requires lossless encoding
(with an optional transparency channel) and does not require advanced
features provided by the extended format.
Simple WebP (lossless) file format:
VP8L chunk:
- VP8L data: Chunk Size bytes
- VP8L bitstream data.
The specification of the VP8L bitstream can be found in . Note that the VP8L header contains the
VP8L image width and height. That is assumed to be the width and
height of the canvas.
Extended File Format
Note: Older readers may not support files using the
extended format.
An extended format file consists of:
- A 'VP8X' chunk with information about features used in the
file.
- An optional 'ICCP' chunk with color profile.
- An optional 'ANIM' chunk with animation control data.
- Image data.
- An optional 'EXIF' chunk with Exif metadata.
- An optional 'XMP ' chunk with XMP metadata.
- An optional list of unknown
chunks.
For a still image, the image data consists of a
single frame, which is made up of:
- An optional alpha subchunk.
- A bitstream subchunk.
For an animated image, the image data consists of
multiple frames. More details about frames can be found in .
All chunks SHOULD be placed in the same order as listed above. If a
chunk appears in the wrong place, the file is invalid, but readers MAY
parse the file, ignoring the chunks that come too late.
Rationale: Setting the order of chunks should allow
quicker file parsing. For example, if an 'ALPH' chunk does not appear
in its required position, a decoder can choose to stop searching for
it. The rule of ignoring late chunks should make programs that need to
do a full search give the same results as the ones stopping early.
Extended WebP file header:
- Reserved (Rsv): 2 bits
- SHOULD be 0.
- ICC profile (I): 1 bit
- Set if the file contains an ICC profile.
- Alpha (L): 1 bit
- Set if any of the frames of the image contain transparency
information ("alpha").
- Exif metadata (E): 1 bit
- Set if the file contains Exif metadata.
- XMP metadata (X): 1 bit
- Set if the file contains XMP metadata.
- Animation (A): 1 bit
- Set if this is an animated image. Data in 'ANIM' and 'ANMF' chunks
should be used to control the animation.
- Reserved (R): 1 bit
- SHOULD be 0.
- Reserved: 24 bits
- SHOULD be 0.
- Canvas Width Minus One: 24 bits
- 1-based width of the canvas in pixels. The actual canvas
width is 1 + Canvas Width Minus One
- Canvas Height Minus One: 24 bits
- 1-based height of the canvas in pixels. The actual canvas
height is 1 + Canvas Height Minus One
The product of Canvas Width and Canvas Height MUST
be at most 2^32 - 1.
Future specifications MAY add more fields.
Chunks
Animation
An animation is controlled by ANIM and ANMF chunks.
ANIM Chunk:
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. 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 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.
- 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
- SHOULD 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.
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.
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:
- Alpha-blending SHOULD be done in linear color space, by
taking into account the color
profile 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
for the frame.
- A bitstream
subchunk for the frame.
- An optional list of unknown chunks.
Note: The 'ANMF' payload, Frame Data
above, consists of individual padded chunks as
described by the RIFF file
format.
Alpha
- Reserved (Rsv): 2 bits
- SHOULD 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:
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:
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 ) 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.
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 and respectively.
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 for details.
If this chunk is not present, sRGB SHOULD be assumed.
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. Also, a file may possibly contain both 'EXIF' and
'XMP ' chunks.
The chunks are defined as follows:
EXIF chunk:
- Exif Metadata: Chunk Size bytes
- image metadata in format.
XMP chunk:
- XMP Metadata: Chunk Size bytes
- image metadata in format.
Additional guidance about handling metadata can be found in the
Metadata Working Group's Guidelines for
Handling Metadata.
Unknown Chunks
A RIFF chunk (described in .) whose chunk tag is
different from any of the chunks described in this document, 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 .
- At the end of ANMF chunks as described in .
Readers SHOULD ignore these chunks. Writers SHOULD preserve them
in their original order (unless they specifically intend to modify
these chunks).
Assembling the Canvas from frames
Here we provide an overview of how a reader should assemble a
canvas in the case of an animated image. The notation
VP8X.field means the field in the 'VP8X' chunk with the same
description.
Displaying an animated image canvas MUST be equivalent to
the following pseudocode:
= frame_right
assert VP8X.canvasHeight >= frame_bottom
for subchunk in 'Frame Data':
if subchunk.tag == "ALPH":
assert alpha subchunks not found in 'Frame Data' earlier
frame_params.alpha = alpha_data
else if subchunk.tag == "VP8 " OR subchunk.tag == "VP8L":
assert bitstream subchunks not found in 'Frame Data' earlier
frame_params.bitstream = bitstream_data
render frame with frame_params.alpha and frame_params.bitstream on
canvas with top-left corner at (frame_params.frameX,
frame_params.frameY), using dispose method dispose_method.
canvas contains the decoded image.
Show the contents of the canvas for frame_params.frameDuration * 1ms.
]]>
Example File Layouts
A lossy encoded image with alpha may look as follows:
A losslessly encoded image may look as follows:
A lossless image with ICC profile and XMP metadata may look as
follows:
An animated image with Exif metadata may look as follows:
Specification for WebP Lossless Bitstream
Note this section is based on the documentation in the libwebp source repository at the time
of writing.
Abstract
WebP lossless is an image format for lossless compression of ARGB
images. The lossless format stores and restores the pixel values
exactly, including the color values for zero alpha pixels. The format
uses subresolution images, recursively embedded into the format
itself, for storing statistical data about the images, such as the
used entropy codes, spatial predictors, color space conversion, and
color table. LZ77, prefix coding, and a color cache are used for
compression of the bulk data. Decoding speeds faster than PNG have
been demonstrated, as well as 25% denser compression than can be
achieved using today's PNG format.
Nomenclature
- ARGB
- A pixel value consisting of alpha, red, green, and blue
values.
- ARGB image
- A two-dimensional array containing ARGB pixels.
- color cache
- A small hash-addressed array to store recently used colors, to be
able to recall them with shorter codes.
- color indexing image
- A one-dimensional image of colors that can be indexed using a
small integer (up to 256 within WebP lossless).
- color transform image
- A two-dimensional subresolution image containing data about
correlations of color components.
- distance mapping
- Changes LZ77 distances to have the smallest values for pixels in
2D proximity.
- entropy image
- A two-dimensional subresolution image indicating which entropy
coding should be used in a respective square in the image, i.e.,
each pixel is a meta prefix code.
- prefix code
- A classic way to do entropy coding where a smaller number of bits
are used for more frequent codes.
- LZ77
- Dictionary-based sliding window compression algorithm that either
emits symbols or describes them as sequences of past symbols.
- meta prefix code
- A small integer (up to 16 bits) that indexes an element in the
meta prefix table.
- predictor image
- A two-dimensional subresolution image indicating which spatial
predictor is used for a particular square in the image.
- prefix coding
- A way to entropy code larger integers that codes a few bits of the
integer using an entropy code and codifies the remaining bits raw.
This allows for the descriptions of the entropy codes to remain
relatively small even when the range of symbols is large.
- scan-line order
- A processing order of pixels, left-to-right, top-to-bottom,
starting from the left-hand-top pixel, proceeding to the right. Once
a row is completed, continue from the left-hand column of the next
row.
Introduction
This document describes the compressed data representation of a WebP
lossless image. It is intended as a detailed reference for WebP
lossless encoder and decoder implementation.
In this document, we extensively use C programming language syntax to
describe the bitstream, and assume the existence of a function for
reading bits, ReadBits(n). The bytes are read in the natural
order of the stream containing them, and bits of each byte are read
in least-significant-bit-first order. When multiple bits are read at
the same time, the integer is constructed from the original data in
the original order. The most significant bits of the returned
integer are also the most significant bits of the original data.
Thus the statement
is equivalent with the two statements below:
We assume that each color component (e.g. alpha, red, blue and
green) is represented using an 8-bit byte. We define the corresponding
type as uint8. A whole ARGB pixel is represented by a type called
uint32, an unsigned integer consisting of 32 bits. In the code showing
the behavior of the transformations, alpha value is codified in bits
31..24, red in bits 23..16, green in bits 15..8 and blue in bits 7..0,
but implementations of the format are free to use another
representation internally.
Broadly, a WebP lossless image contains header data, transform
information and actual image data. Headers contain width and height of
the image. A WebP lossless image can go through four different types
of transformation before being entropy encoded. The transform
information in the bitstream contains the data required to apply the
respective inverse transforms.
RIFF Header
The beginning of the header has the RIFF container. This consists of
the following 21 bytes:
- String "RIFF"
- A little-endian 32 bit value of the block length, the whole size
of the block controlled by the RIFF header. Normally this equals the
payload size (file size minus 8 bytes: 4 bytes for the 'RIFF'
identifier and 4 bytes for storing the value itself).
- String "WEBP" (RIFF container name).
- String "VP8L" (chunk tag for lossless encoded image data).
- A little-endian 32-bit value of the number of bytes in the
lossless stream.
- One byte signature 0x2f.
The first 28 bits of the bitstream specify the width and height of
the image. Width and height are decoded as 14-bit integers as
follows:
The 14-bit dynamics for image size limit the maximum size of a WebP
lossless image to 16384x16384 pixels.
The alpha_is_used bit is a hint only, and should not impact
decoding. It should be set to 0 when all alpha values are 255 in the
picture, and 1 otherwise.
The version_number is a 3 bit code that must be set to 0. Any other
value should be treated as an error.
Transformations
Transformations are reversible manipulations of the image data that
can reduce the remaining symbolic entropy by modeling spatial and
color correlations. Transformations can make the final compression
more dense.
An image can go through four types of transformation. A 1 bit
indicates the presence of a transform. Each transform is allowed to be
used only once. The transformations are used only for the main level
ARGB image: the subresolution images have no transforms, not even the
0 bit indicating the end-of-transforms.
Typically an encoder would use these transforms to reduce the Shannon
entropy in the residual image. Also, the transform data can be decided
based on entropy minimization.
If a transform is present then the next two bits specify the
transform type. There are four types of transforms.
The transform type is followed by the transform data. Transform data
contains the information required to apply the inverse transform and
depends on the transform type. Next we describe the transform data for
different types.
Predictor Transform
The predictor transform can be used to reduce entropy by exploiting
the fact that neighboring pixels are often correlated. In the
predictor transform, the current pixel value is predicted from the
pixels already decoded (in scan-line order) and only the residual
value (actual - predicted) is encoded. The prediction mode
determines the type of prediction to use. We divide the image into
squares and all the pixels in a square use same prediction mode.
The first 3 bits of prediction data define the block width and
height in number of bits. The number of block columns,
block_xsize, is used in indexing two-dimensionally.
The transform data contains the prediction mode for each block of
the image. All the block_width * block_height pixels of a
block use same prediction mode. The prediction modes are treated
as pixels of an image and encoded using the same techniques
described in .
For a pixel x, y, one can compute the respective filter
block address by:
> size_bits) * block_xsize +
(x >> size_bits);
]]>
There are 14 different prediction modes. In each prediction mode,
the current pixel value is predicted from one or more neighboring
pixels whose values are already known.
We choose the neighboring pixels (TL, T, TR, and L) of the current
pixel (P) as follows:
where TL means top-left, T top, TR top-right, L left pixel. At the
time of predicting a value for P, all pixels O, TL, T, TR and L have
been already processed, and pixel P and all pixels X are
unknown.
Given the above neighboring pixels, the different prediction modes
are defined as follows.
Average2 is defined as follows for each ARGB
component:
The Select predictor is defined as follows:
The functions ClampAddSubtractFull and
ClampAddSubtractHalf are performed for each ARGB component
as follows:
255) ? 255 : a;
}
int ClampAddSubtractFull(int a, int b, int c) {
return Clamp(a + b - c);
}
int ClampAddSubtractHalf(int a, int b) {
return Clamp(a + (a - b) / 2);
}
]]>
There are special handling rules for some border pixels. If there
is a prediction transform, regardless of the mode [0..13] for these
pixels, the predicted value for the left-topmost pixel of the image
is 0xff000000, L-pixel for all pixels on the top row, and T-pixel
for all pixels on the leftmost column.
Addressing the TR-pixel for pixels on the rightmost column is
exceptional. The pixels on the rightmost column are predicted by
using the modes [0..13] just like pixels not on the border, but the
leftmost pixel on the same row as the current pixel is instead used
as the TR-pixel.
Color Transform
The goal of the color transform is to decorrelate the R, G and B
values of each pixel. Color transform keeps the green (G) value as
it is, transforms red (R) based on green and transforms blue (B)
based on green and then based on red.
As is the case for the predictor transform, first the image is
divided into blocks and the same transform mode is used for all the
pixels in a block. For each block there are three types of color
transform elements.
The actual color transformation is done by defining a color
transform delta. The color transform delta depends on the
ColorTransformElement, which is the same for all the pixels
in a particular block. The delta is subtracted during color
transform. The inverse color transform then is just adding those
deltas.
The color transform function is defined as follows:
green_to_red_, green);
tmp_blue -= ColorTransformDelta(trans->green_to_blue_, green);
tmp_blue -= ColorTransformDelta(trans->red_to_blue_, red);
*new_red = tmp_red & 0xff;
*new_blue = tmp_blue & 0xff;
}
]]>
ColorTransformDelta is computed using a signed 8-bit
integer representing a 3.5-fixed-point number, and a signed 8-bit
RGB color channel (c) [-128..127] and is defined as follows:
> 5;
}
]]>
A conversion from the 8-bit unsigned representation
(uint8) to the 8-bit signed one (int8) is required
before calling ColorTransformDelta(). It should be performed using
8-bit two's complement (that is: uint8 range [128-255] is mapped
to the [-128, -1] range of its converted int8 value).
The multiplication is to be done using more precision (with at
least 16-bit dynamics). The sign extension property of the shift
operation does not matter here: only the lowest 8 bits are used from
the result, and there the sign extension shifting and unsigned
shifting are consistent with each other.
Now we describe the contents of color transform data so that
decoding can apply the inverse color transform and recover the
original red and blue values. The first 3 bits of the color
transform data contain the width and height of the image block in
number of bits, just like the predictor transform:
The remaining part of the color transform data contains
ColorTransformElement instances corresponding to each block
of the image. ColorTransformElement instances are treated
as pixels of an image and encoded using the methods described in
.
During decoding, ColorTransformElement instances of the
blocks are decoded and the inverse color transform is applied on the
ARGB values of the pixels. As mentioned earlier, that inverse color
transform is just subtracting ColorTransformElement values
from the red and blue channels.
green_to_red, green);
tmp_blue += ColorTransformDelta(trans->green_to_blue, green);
tmp_blue += ColorTransformDelta(trans->red_to_blue, tmp_red & 0xff);
*new_red = tmp_red & 0xff;
*new_blue = tmp_blue & 0xff;
}
]]>
Subtract Green Transform
The subtract green transform subtracts green values from red and
blue values of each pixel. When this transform is present, the
decoder needs to add the green value to both red and blue. There is
no data associated with this transform. The decoder applies the
inverse transform as follows:
This transform is redundant as it can be modeled using the color
transform, but it is still often useful. Since it can extend the
dynamics of the color transform and there is no additional data
here, the subtract green transform can be coded using fewer bits
than a full-blown color transform.
Color Indexing Transform
If there are not many unique pixel values, it may be more efficient
to create a color index array and replace the pixel values by the
array's indices. The color indexing transform achieves this. (In the
context of WebP lossless, we specifically do not call this a palette
transform because a similar but more dynamic concept exists in WebP
lossless encoding: color cache.)
The color indexing transform checks for the number of unique ARGB
values in the image. If that number is below a threshold (256), it
creates an array of those ARGB values, which is then used to replace
the pixel values with the corresponding index: the green channel of
the pixels are replaced with the index; all alpha values are set to
255; all red and blue values to 0.
The transform data contains color table size and the entries in the
color table. The decoder reads the color indexing transform data as
follows:
The color table is stored using the image storage format itself.
The color table can be obtained by reading an image, without the
RIFF header, image size, and transforms, assuming a height of one
pixel and a width of color_table_size. The color table is
always subtraction-coded to reduce image entropy. The deltas of
palette colors contain typically much less entropy than the colors
themselves, leading to significant savings for smaller images. In
decoding, every final color in the color table can be obtained by
adding the previous color component values by each ARGB component
separately, and storing the least significant 8 bits of the
result.
The inverse transform for the image is simply replacing the pixel
values (which are indices to the color table) with the actual color
table values. The indexing is done based on the green component of
the ARGB color.
If the index is equal or larger than color_table_size, the argb
color value should be set to 0x00000000 (transparent black).
When the color table is small (equal to or less than 16 colors),
several pixels are bundled into a single pixel. The pixel bundling
packs several (2, 4, or 8) pixels into a single pixel, reducing the
image width respectively. Pixel bundling allows for a more efficient
joint distribution entropy coding of neighboring pixels, and gives
some arithmetic coding-like benefits to the entropy code, but it can
only be used when there are a small number of unique values.
color_table_size specifies how many pixels are combined
together:
width_bits has a value of 0, 1, 2 or 3. A value of 0
indicates no pixel bundling to be done for the image. A value of 1
indicates that two pixels are combined together, and each pixel has
a range of [0..15]. A value of 2 indicates that four pixels are
combined together, and each pixel has a range of [0..3]. A value
of 3 indicates that eight pixels are combined together and each
pixel has a range of [0..1], i.e., a binary value.
The values are packed into the green component as follows:
- width_bits = 1: for every x value where x = 2k + 0, a
green value at x is positioned into the 4 least-significant bits
of the green value at x / 2, a green value at x + 1 is positioned
into the 4 most-significant bits of the green value at x / 2.
- width_bits = 2: for every x value where x = 4k + 0, a
green value at x is positioned into the 2 least-significant bits
of the green value at x / 4, green values at x + 1 to x + 3 in
order to the more significant bits of the green value at x /
4.
- width_bits = 3: for every x value where x = 8k + 0, a
green value at x is positioned into the least-significant bit of
the green value at x / 8, green values at x + 1 to x + 7 in order
to the more significant bits of the green value at x / 8.
Image Data
Image data is an array of pixel values in scan-line order.
Roles of Image Data
We use image data in five different roles:
- ARGB image: Stores the actual pixels of the image.
- Entropy image: Stores the meta prefix codes.
The red and green components of a pixel define the meta prefix
code used in a particular block of the ARGB image.
- Predictor image: Stores the metadata for Predictor Transform. The green
component of a pixel defines which of the 14 predictors is used
within a particular block of the ARGB image.
- Color transform image. It is created by
ColorTransformElement values (defined in Color Transform for different
blocks of the image. Each ColorTransformElement
'cte' is treated as a pixel whose alpha component is
255, red component is cte.red_to_blue, green
component is cte.green_to_blue and blue component is
cte.green_to_red.
- Color indexing image: An array of of size
color_table_size (up to 256 ARGB values) storing the
metadata for the Color
Indexing Transform. This is stored as an image of width
color_table_size and height 1.
Encoding of Image data
The encoding of image data is independent of its role.
The image is first divided into a set of fixed-size blocks
(typically 16x16 blocks). Each of these blocks are modeled using
their own entropy codes. Also, several blocks may share the same
entropy codes.
Rationale: Storing an entropy code incurs a cost.
This cost can be minimized if statistically similar blocks share an
entropy code, thereby storing that code only once. For example, an
encoder can find similar blocks by clustering them using their
statistical properties, or by repeatedly joining a pair of randomly
selected clusters when it reduces the overall amount of bits needed
to encode the image.
Each pixel is encoded using one of the three possible methods:
- prefix coded literal: each channel (green, red, blue and alpha)
is entropy-coded independently;
- LZ77 backward reference: a sequence of pixels are copied from
elsewhere in the image; or
- Color cache code: using a short multiplicative hash code (color
cache index) of a recently seen color.
The following sub-sections describe each of these in detail.
Prefix Coded Literals
The pixel is stored as prefix coded values of green, red, blue
and alpha (in that order). See for details.
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.
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).
Rationale: This approach reduces the storage
requirement for the entropy code. Also, large values are usually
rare, and so extra bits would be used for very few values in the
image. Thus, this approach results in a better compression
overall.
The following table denotes the prefix codes and extra bits used
for storing different range of values.
Note: The maximum backward reference length is limited to 4096.
Hence, only the first 24 prefix codes (with the respective extra
bits) are meaningful for length values. For distance values,
however, all the 40 prefix codes are valid.
The pseudocode to obtain a (length or distance) value from the
prefix code is as follows:
> 1;
int offset = (2 + (prefix_code & 1)) << extra_bits;
return offset + ReadBits(extra_bits) + 1;
]]>
Distance Mapping:
As noted previously, distance code is a number indicating the
position of a previously seen pixel, from which the pixels are to
be copied. This sub-section defines the mapping between a distance
code and the position of a previous pixel.
The distance codes larger than 120 denote the pixel-distance in
scan-line order, offset by 120.
The smallest distance codes [1..120] are special, and are
reserved for a close neighborhood of the current pixel. This
neighborhood consists of 120 pixels:
- Pixels that are 1 to 7 rows above the current pixel, and are
up to 8 columns to the left or up to 7 columns to the right of
the current pixel. [Total such pixels = 7 * (8 + 1 + 7) =
112].
- Pixels that are in same row as the current pixel, and are up
to 8 columns to the left of the current pixel. [8 such
pixels].
The mapping between distance code i and the neighboring
pixel offset (xi, yi) is as follows:
For example, distance code 1 indicates offset of (0,
1) for the neighboring pixel, that is, the pixel above the
current pixel (0-pixel difference in X-direction and 1 pixel
difference in Y-direction). Similarly, distance code 3
indicates left-top pixel.
The decoder can convert a distances code 'i' to a scan-line order
distance 'dist' as follows:
where 'distance_map' is the mapping noted above and
xsize is the width of the image in pixels.
Color Cache Coding
Color cache stores a set of colors that have been recently used
in the image.
Rationale: This way, the recently used colors
can sometimes be referred to more efficiently than emitting them
using other two methods (described in and ).
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:
color_cache_code_bits defines the size of the
color_cache by (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.
Entropy Code
Overview
Most of the data is coded using a canonical
prefix code. Hence, the codes are transmitted by sending the
prefix code lengths, as opposed to the actual prefix
codes.
In particular, the format uses spatially-variant prefix
coding. In other words, different blocks of the image can
potentially use different entropy codes.
Rationale: Different areas of the image may have
different characteristics. So, allowing them to use different
entropy codes provides more flexibility and potentially a better
compression.
Details
The encoded image data consists of several parts:
- Decoding and building the prefix codes
- Meta prefix codes
- Entropy-coded image data
Decoding and Building the Prefix Codes
There are several steps in decoding the prefix codes.
Decoding the Code
Lengths:
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:
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.
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.
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.
Next, if ReadBits(1) == 0, the maximum number of
different read symbols is num_code_lengths. Otherwise, it
is defined as:
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
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
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'.
where DIV_ROUND_UP is as defined in .
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:
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:
Given a pixel (x, y) in the ARGB image, we can obtain the
corresponding prefix codes to be used as follows:
> 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 .
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 -
1).
The interpretation of S depends on its value:
- if S < 256
- Use S as the green component
- Read red from the bitstream using prefix code #2
- Read blue from the bitstream using prefix code #3
- Read alpha from the bitstream using prefix code #4
- if S < 256 + 24 && S < 256 + 24
- Use S - 256 as a length prefix code
- Read extra bits for length from the bitstream
- Determine backward-reference length L from length prefix
code and the extra bits read.
- Read distance prefix code from the bitstream using prefix
code #5
- Read extra bits for distance from the bitstream
- Determine backward-reference distance D from distance
prefix code and the extra bits read.
- Copy the L pixels (in scan-line order) from the sequence of
pixels prior to them by D pixels.
- if S >= 256 + 24
- Use S - (256 + 24) as the index into the color cache.
- Get ARGB color from the color cache at that index.
Overall Structure of the Format
Below is a view into the format in Backus-Naur form. It does not
cover all details. End-of-image (EOI) is only implicitly coded into
the number of pixels (xsize * ysize).
Basic Structure
::=
::=
]]>
Structure of Transforms
::= (1-bit value 1; ) |
1-bit value 0
::= | | |
::= 2-bit value 0;
::= 3-bit sub-pixel code ;
::= 2-bit value 1;
::= 3-bit sub-pixel code ;
::= 2-bit value 2
::= 2-bit value 3;
::= 8-bit color count;
]]>
Structure of the Image Data
::=
::=
::= 1 bit value 0 |
(1-bit value 1; 4-bit value for color cache size)
::= 1-bit value 0 |
(1-bit value 1; )
::=
::= 3-bit subsample value;
::= |
::=
See "Interpretation of Meta Prefix Codes" to
understand what each of these five prefix codes are
for.
::= |
::= see "Simple code length code" for details
::= ; encoded code lengths
::= see section "Normal code length code"
::= (( | | )
) | ""
]]>
A possible example sequence:
1-bit value 1
1-bit value 11-bit value 01-bit value 0
]]>
Security Considerations
Security risks are similar to other media content and may include
integer overflows, out-of-bounds reads and writes to both heap and
stack, uninitialized data usage, null pointer references, resource
(disk, memory) exhaustion and extended resource usage (long running
time) as part of the demuxing and decoding process. These may cause
information leakage (memory layout and contents) or crashes and thereby
denial of service to an application using the format .
The format does not employ "active content", but does allow metadata
(, ) and custom chunks to be
embedded in a file. Applications that interpret these chunks may be
subject to security considerations for those formats.
Interoperability Considerations
The format is defined using little-endian byte ordering (see ), but demuxing and decoding are
possible on platforms using a different ordering with the appropriate
conversion.
The container is RIFF-based and allows extension via user defined
chunks, but nothing beyond the chunks defined by the container format
() are required for decoding of the image.
These have been finalized, but were extended in the format's early
stages so some older readers may not support lossless or animated image
decoding.
IANA Considerations
IANA has updated the "Image Media
Types" registry to include 'image/webp' as described in .
The 'image/webp' Media Type
This section contains the media type registration details as per .
Registration Details
Type name: image
Subtype name: webp
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: Binary. The Base64
encoding should be used on transports that cannot accommodate
binary data directly.
Security considerations: See .
Interoperability considerations: See .
Published specification:
Applications that use this media type: Applications that are used to
display and process images, especially when smaller image file sizes
are important.
Fragment identifier considerations: N/A
Additional information:
- Deprecated alias names for this type: N/A
- Magic number(s): The first 4 bytes are 0x52, 0x49, 0x46, 0x46
('RIFF'), followed by 4 bytes for the RIFF chunk size. The next 7
bytes are 0x57, 0x45, 0x42, 0x50, 0x56, 0x50, 0x38
('WEBPVP8').
- File extension(s): webp
- Apple Uniform Type Identifier: org.webmproject.webp conforms to
public.image
- Object Identifiers: N/A
Person & email address to contact for further information:
- Name: James Zern
- Email: jzern@google.com
Intended usage: COMMON
Restrictions on usage: N/A
Author:
- Name: James Zern
- Email: jzern@google.com
Change controller:
- Name: James Zern
- Email: jzern@google.com
- Name: Pascal Massimino
- Email: pascal.massimino@gmail.com
- Name: WebM Project
- Email: webmaster@webmproject.org
Provisional registration? (standards tree only): N/A
References
Normative References
BT.601: Studio encoding parameters of digital television for
standard 4:3 and wide screen 16:9 aspect ratios
ITU
WebP Lossless Bitstream Specification
Google LLC
WebP RIFF Container
Google LLC
Informative References
libwebp Security Issues
libwebp CVE List
Exchangeable image file format for digital still cameras:
Exif Version 2.3
Camera & Imaging Products Association
(CIPA), Japan Electronics and Information Technology
Industries Association (JEITA)
GIF89a Specification
A Method for the Construction of Minimum Redundancy
Codes
Media Types
Internet Assigned Numbers Authority
(IANA)
ICC Specification
International Color Consortium
JPEG Standard (JPEG ISO/IEC 10918-1 ITU-T Recommendation
T.81)
A Universal Algorithm for Sequential Data Compression
Guidelines For Handling Image Metadata
Metadata Working Group
Multimedia Programming Interface and Data Specifications
1.0
XMP Specification
Adobe Inc.