RFC 9649
WebP Image Format
RFC 9649: WebP Image Format 🎀
Part 1 of 10 🦋
Okay bestie, first the paperwork, but make it cute 💅. This is RFC 9649 from the Internet Engineering Task Force (IETF), and it's called WebP Image Format ✨
It was written by J. Zern, P. Massimino, and J. Alakuijala, all from Google LLC. It's an Informational doc, so it's not a standards track thing, fr fr. It's dated November 2024 and has ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so no drama there 🙈
Abstract 🌸
This document defines the WebP image format and registers a media type supporting its use.
Status of This Memo 🧚
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9649.
Copyright Notice 💜
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents 🗺️
1. Introduction
2. WebP Container Specification
2.1. Introduction (from "WebP Container Specification")
2.2. Terminology & Basics
2.3. RIFF File Format
2.4. WebP File Header
2.5. Simple File Format (Lossy)
2.6. Simple File Format (Lossless)
2.7. Extended File Format
2.7.1. Chunks
2.7.1.1. Animation
2.7.1.2. Alpha
2.7.1.3. Bitstream (VP8/VP8L)
2.7.1.4. Color Profile
2.7.1.5. Metadata
2.7.1.6. Unknown Chunks
2.7.2. Canvas Assembly from Frames
2.7.3. Example File Layouts
3. Specification for WebP Lossless Bitstream
3.1. Abstract (from "Specification for WebP Lossless Bitstream")
3.2. Introduction (from "Specification for WebP Lossless
Bitstream")
3.3. Nomenclature
3.4. RIFF Header
3.5. Transforms
3.5.1. Predictor Transform
3.5.2. Color Transform
3.5.3. Subtract Green Transform
3.5.4. Color Indexing Transform
3.6. Image Data
3.6.1. Roles of Image Data
3.6.2. Encoding of Image Data
3.6.2.1. Prefix-Coded Literals
3.6.2.2. LZ77 Backward Reference
3.6.2.3. Color Cache Coding
3.7. Entropy Code
3.7.1. Overview
3.7.2. Details
3.7.2.1. Decoding and Building the Prefix Codes
3.7.2.2. Decoding of Meta Prefix Codes
3.7.2.3. Decoding Entropy-Coded Image Data
3.8. Overall Structure of the Format
3.8.1. Basic Structure
3.8.2. Structure of Transforms
3.8.3. Structure of the Image Data
4. Security Considerations
5. Interoperability Considerations
6. IANA Considerations
6.1. The 'image/webp' Media Type
6.1.1. Registration Details
7. References
7.1. Normative References
7.2. Informative References
Authors' Addresses1. Introduction ✨
WebP is an image file format based on the Resource Interchange File Format (RIFF) [RIFF-spec] (Section 2) that supports lossless and lossy compression as well as alpha (transparency) and animation. It covers use cases similar to JPEG [JPEG-spec], PNG [RFC2083], and the Graphics Interchange Format (GIF) [GIF-spec].
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 [RFC6386]. The lossless algorithm (Section 3) stores and restores the pixel values exactly, including the color values for fully transparent pixels. A universal algorithm for sequential data compression [LZ77], prefix coding [Huffman], and a color cache are used for compression of the bulk data.
2. WebP Container Specification 📦
Note that this section is based on the documentation in the libwebp source repository [webp-riff-src].
2.1. Introduction (from "WebP Container Specification") 🎀
WebP is an image format that uses either (i) the VP8 intra-frame encoding [RFC6386] to compress image data in a lossy way or (ii) the WebP lossless encoding (Section 3). These encoding schemes should make it more efficient than older formats, such as JPEG, GIF, and PNG. It is optimized for fast image transfer over the network (for example, 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 (that is, the RIFF container for WebP) allows feature support over and above the basic use case of WebP (that is, a file containing a single image encoded as a VP8 key frame). The WebP container provides additional support for the following:
- Lossless Compression: An image can be losslessly compressed, using the WebP lossless format.
- Metadata: An image may have metadata stored in Exchangeable Image File Format [Exif] or Extensible Metadata Platform [XMP] format.
- Transparency: An image may have transparency, that is, an alpha channel.
- Color Profile: An image may have an embedded ICC profile (ICCP) [ICC].
- Animation: An image may have multiple frames with pauses between them, making it an animation.
2.2. Terminology & Basics 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
A WebP file contains either a still image (that is, an encoded matrix of pixels) or an animation (Section 2.7.1.1). Optionally, it can also contain transparency information, a color profile, and metadata. We refer to the matrix of pixels as the canvas of the image.
Bit numbering in chunk diagrams starts at 0 for the most significant bit ('MSB 0'), as described in [RFC1166].
Below are additional terms used throughout this section:
- 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 four-character code (FourCC) is a uint32 created by concatenating four ASCII characters in little-endian order. This means 'aaaa' (0x61616161) and 'AAAA' (0x41414141) are treated as different FourCCs.
- 1-based: An unsigned integer field storing values offset by -1, for example, such a field would store value 25 as 24.
- ChunkHeader('ABCD'): 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.
2.3. RIFF File Format 🧩
The WebP file format is based on the RIFF [RIFF-spec] document format.
The basic element of a RIFF file is a chunk. It consists of:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk FourCC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Chunk Payload :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: 'RIFF' Chunk Structure
- Chunk FourCC: 32 bits: ASCII four-character code used for chunk identification.
- Chunk Size: 32 bits (uint32): The size of the chunk in bytes, 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 -- which MUST be 0 to conform with RIFF [RIFF-spec] -- is added.
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.
2.4. WebP File Header 🌷
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'R' | 'I' | 'F' | 'F' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| File Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'W' | 'E' | 'B' | 'P' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: WebP File Header Chunk
- '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 4 GiB 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 any data after the data specified by File Size. Readers MAY parse such files, ignoring the trailing data. As the size of any chunk is even, the size given by the RIFF header is also even. The contents of individual chunks are described in the following sections.
2.5. Simple File Format (Lossy) 🎀
bestie, this layout SHOULD be used if the image needs lossy encoding and doesn't need transparency or any of the fancy extended features 💖 Files with this layout are smaller and older software can read them too ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| WebP file header (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 'VP8 ' Chunk :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Simple WebP (Lossy) File 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('VP8 ') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: VP8 data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: 'VP8 ' Chunk 🌸
VP8 data: Chunk Size bytes VP8 bitstream data.
Note that the fourth character in the 'VP8 ' FourCC is an ASCII space (0x20). Easy to miss, so don't sleep on it 🙈
The VP8 bitstream format specification is described in [RFC6386].
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, Recommendation 601 [REC601] SHOULD be used. Applications MAY use another conversion method, but visual results may differ among decoders. Lowkey a vibe-check situation 💅
2.6. Simple File Format (Lossless) 🍓
Note: Older readers may not support files using the lossless format. 💀
This layout SHOULD be used if the image needs lossless encoding (with an optional transparency channel) and doesn't need the advanced features of the extended 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| WebP file header (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 'VP8L' Chunk :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Simple WebP (Lossless) File 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('VP8L') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: VP8L data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: 'VP8L' Chunk 💜
VP8L data: Chunk Size bytes VP8L bitstream data.
The specification of the VP8L bitstream can be found in Section 3. 📖
Note that the VP8L header contains the VP8L image width and height. That is assumed to be the width and height of the canvas. 🧚
2.7. 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 a 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 (Section 2.7.1.6).
For a still image, the image data is a single frame, made up of:
- An optional alpha subchunk (Section 2.7.1.2).
- A bitstream subchunk (Section 2.7.1.3).
For an animated image, the image data is multiple frames. More details about frames can be found in Section 2.7.1.1. 🎞️
All chunks necessary for reconstruction and color correction, that is, 'VP8X', 'ICCP', 'ANIM', 'ANMF', 'ALPH', 'VP8 ', and 'VP8L', MUST appear in the order described earlier. Readers SHOULD fail when chunks necessary for reconstruction and color correction are out of order. Order matters, no debate 😤
Metadata (Section 2.7.1.5) and unknown chunks (Section 2.7.1.6) MAY appear out of order. 🫶
Rationale: The chunks necessary for reconstruction should appear first in the file to allow a reader to begin decoding an image before receiving all of the data. An application may benefit from varying the order of metadata and custom chunks to suit the implementation. The main character here is loading speed 🚀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| WebP file header (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('VP8X') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv|I|L|E|X|A|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Canvas Width Minus One | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Canvas Height Minus One |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Extended WebP File Header 🎀
Reserved (Rsv): 2 bits MUST be 0. Readers MUST ignore this field.
ICC profile (I): 1 bit Set if the file contains an 'ICCP' Chunk.
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 MUST be 0. Readers MUST ignore this field.
Reserved: 24 bits MUST be 0. Readers MUST ignore this field.
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. That's the size ceiling, periodt 💅
Future specifications may add more fields. Unknown fields MUST be ignored. Not me hoarding unknown fields 🌸
2.7.1. Chunks ✨
2.7.1.1. Animation 🎬
okay so animations are run by two chunks, 'ANIM' and 'ANMF' 💖 the 'ANIM' one holds the global settings for the whole thing, and 'ANMF' is for one frame at a time ✨
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: 'ANIM' Chunk
okay so for an animated image, this chunk holds the global parameters of the whole 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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: 'ANMF' Chunk
okay and for animated images, this chunk holds info 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. 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). 🧩
Note: The 'ANMF' payload, Frame Data, 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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: 'ALPH' Chunk
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 |Figure 11: Pixels Used in Alpha Filtering
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) % 256There 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. 🙅♀️
Rationale: The transparency information is already part of the 'VP8L' 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. 🧠
Rationale: The dimensions are already known from other sources, so storing them again would be redundant and prone to errors.
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. 💚
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) 🎞️
okay this chunk holds the 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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: 'ICCP' Chunk
Color Profile: Chunk Size bytes
ICC profile.
okay so this chunk MUST show up before the image data, no exceptions bestie 🫶
There SHOULD be at most one of these chunks 💅 If there are more, readers MAY ignore all except the first one. For the full scoop on ICC, check out the ICC specification [ICC] ✨
If this chunk isn't there at all, 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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: 'EXIF' Chunk
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: 'XMP ' Chunk
XMP Metadata: Chunk Size bytes
Image metadata in [XMP] format.
Note that the fourth character in the 'XMP ' FourCC is an ASCII space (0x20). 👀
Extra tips on handling metadata live 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 🕵️♀️
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, or
- at the end of
ANMFChunks, 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 💅
2.7.2. Canvas Assembly from Frames 🎞️
Here's the overview of how a reader MUST assemble a canvas for an animated image, bestie ✨
It all starts by making a canvas with the dimensions from the VP8X Chunk: Canvas Width Minus One + 1 pixels wide by Canvas Height Minus One + 1 pixels high 🖼️ The Loop Count field from the ANIM Chunk controls how many times the animation repeats. That's Loop Count - 1 for nonzero Loop Count values, or infinite if the Loop Count is zero 🔁
At the start of each loop iteration, the canvas gets filled with the background color from the ANIM Chunk, or an application-defined color 🎨
ANMF Chunks hold the individual frames, in display order. Before rendering each frame, the previous frame's Disposal method gets applied 🧹
Rendering the decoded frame begins at the Cartesian coordinates (2 * Frame X, 2 * Frame Y), with the top-left corner of the canvas as the origin 📍 Frame Width Minus One + 1 pixels wide by Frame Height Minus One + 1 pixels high get drawn onto the canvas using the Blending method 🌸
The canvas is shown for Frame Duration milliseconds. This keeps going until every frame in the ANMF Chunks has been displayed. Then a new loop iteration starts, or the canvas stays in its final state if all the iterations are done 🏁
The pseudocode below shows the rendering process. The notation VP8X.field means the field in the VP8X Chunk with the same description 🧠
VP8X.flags.hasAnimation MUST be TRUE
canvas <- new image of size VP8X.canvasWidth x VP8X.canvasHeight with
background color ANIM.background_color or
application-defined color.
loop_count <- ANIM.loopCount
dispose_method <- Dispose to background color
if loop_count == 0:
loop_count = inf
frame_params <- nil
next chunk in image_data is ANMF MUST be TRUE
for loop = 0..loop_count - 1
clear canvas to ANIM.background_color or application-defined color
until eof or non-ANMF chunk
frame_params.frameX = Frame X
frame_params.frameY = Frame Y
frame_params.frameWidth = Frame Width Minus One + 1
frame_params.frameHeight = Frame Height Minus One + 1
frame_params.frameDuration = Frame Duration
frame_right = frame_params.frameX + frame_params.frameWidth
frame_bottom = frame_params.frameY + frame_params.frameHeight
VP8X.canvasWidth >= frame_right MUST be TRUE
VP8X.canvasHeight >= frame_bottom MUST be TRUE
for subchunk in 'Frame Data':
if subchunk.tag == "ALPH":
alpha subchunks not found in 'Frame Data' earlier MUST be
TRUE
frame_params.alpha = alpha_data
else if subchunk.tag == "VP8 " OR subchunk.tag == "VP8L":
bitstream subchunks not found in 'Frame Data' earlier MUST
be TRUE
frame_params.bitstream = bitstream_data
apply dispose_method.
render frame with frame_params.alpha and frame_params.bitstream
on canvas with top-left corner at (frame_params.frameX,
frame_params.frameY), using Blending method
frame_params.blendingMethod.
canvas contains the decoded image.
Show the contents of the canvas for
frame_params.frameDuration * 1 ms.
dispose_method = frame_params.disposeMethod2.7.3. Example File Layouts 🗂️
A lossy-encoded image with alpha may look like this:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ALPH (alpha bitstream)
+- VP8 (bitstream)Figure 15: A Lossy-Encoded Image with Alpha
A lossless-encoded image may look like this:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- VP8L (lossless bitstream)
+- XYZW (unknown chunk)Figure 16: A Lossless-Encoded Image
A lossless image with an ICC profile and XMP metadata may look like this:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ICCP (color profile)
+- VP8L (lossless bitstream)
+- XMP (metadata)Figure 17: A Lossless Image with an ICC Profile and XMP Metadata
An animated image with Exif metadata may look like this:
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ANIM (global animation parameters)
+- ANMF (frame1 parameters + data)
+- ANMF (frame2 parameters + data)
+- ANMF (frame3 parameters + data)
+- ANMF (frame4 parameters + data)
+- EXIF (metadata)Figure 18: An Animated Image with Exif Metadata
3. Specification for WebP Lossless Bitstream ✨
Note that this section is based on the documentation in the libwebp source repository [webp-lossless-src]. 🍓
3.1. Abstract (from "Specification for WebP Lossless Bitstream") 🌟
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 pixels whose alpha value is 0. It uses subresolution images, recursively embedded into the format itself, to store statistical data about the images, like the entropy codes used, spatial predictors, color space conversion, and color table 🧠 A universal algorithm for sequential data compression [LZ77], prefix coding, and a color cache handle the compression of the bulk data 🔥 Decoding speeds faster than PNG have been demonstrated, plus 25% denser compression than today's PNG format can reach [webp-lossless-study] 👑
3.2. Introduction (from "Specification for WebP Lossless Bitstream") 🦋
This section describes the compressed data representation of a WebP lossless image 🫶
We lean heavily on C programming language syntax [ISO.9899.2018] to describe the bitstream, and we assume there's a function for reading bits, ReadBits(n). Bytes are read in the natural order of the stream containing them, and bits within each byte are read in least-significant-bit-first order 🔍 When multiple bits are read at the same time, the integer is built 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. So this statement:
b = ReadBits(2);is equivalent to these two statements:
b = ReadBits(1);
b |= ReadBits(1) << 1;Each color component (that is, 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 made of 32 bits. In the code that shows how the transforms behave, these values are laid out like this: alpha in bits 31..24, red in bits 23..16, green in bits 15..8, and blue in bits 7..0. Implementations are free to use a different representation internally, though 🌈
Broadly speaking, a WebP lossless image contains header data, transform information, and actual image data. Headers contain the width and height of the image 📐 A WebP lossless image can go through four different types of transforms before being entropy encoded. The transform information in the bitstream holds the data needed to apply the respective inverse transforms ✨
3.3. Nomenclature
Okay, time for the vocab list 📚🎀 These are the terms the rest of the spec leans on, so bookmark this part bestie 🔖
- ARGB: a pixel value made of alpha, red, green, and blue values 🌈
- ARGB image: a two-dimensional array full of ARGB pixels 🖼️
- color cache: a small hash-addressed array that stores recently used colors, so they can be recalled 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 holding data about correlations between color components ✨
- distance mapping: changes LZ77 distances so the smallest values go to pixels that sit close together in two dimensions 🦋
- entropy image: a two-dimensional subresolution image that says which entropy coding gets used in each respective square of the image. Each pixel is a meta prefix code 🧚
- LZ77 [LZ77]: a 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 that says which spatial predictor is used for a particular square in the image 👑
- prefix code: a classic way to do entropy coding where more frequent codes get fewer bits 💖
- prefix coding: a way to entropy code larger integers. A few bits of the integer get coded with an entropy code, and the remaining bits are codified raw. This keeps the descriptions of the entropy codes relatively small even when the range of symbols is huge 🫶
- scan-line order: a processing order of pixels (left to right, then top to bottom) that starts from the left-hand-top pixel. Once a row is completed, it continues from the left-hand column of the next row 🌈
3.4. RIFF Header
Okay, the header kicks things off with the RIFF container 🎀 It's 21 bytes total, and here's the whole lineup:
- String
'RIFF'. - A little-endian, 32-bit value of the chunk length, which is the whole size of the chunk 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'(FourCC for lossless-encoded image data). 💅 - A little-endian, 32-bit value of the number of bytes in the lossless stream. 🍓
- 1-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 like this:
int image_width = ReadBits(14) + 1;
int image_height = ReadBits(14) + 1;Because the width and height are only 14 bits, the max size of a WebP lossless image is 16384x16384 pixels. That's a lot of pixels, bestie 🌸
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. 🙈
int alpha_is_used = ReadBits(1);The version_number is a 3-bit code that MUST be set to 0. Any other value MUST be treated as an error. No vibes for anything else 💀
int version_number = ReadBits(3);3.5. Transforms
Transforms are reversible manipulations of the image data. They can reduce the remaining symbolic entropy by modeling spatial and color correlations, which means the final compression can get way more dense 🧚✨
An image can go through four types of transforms. A 1 bit indicates the presence of a transform. Each transform is allowed to be used only once. The transforms are only used for the main-level ARGB image. The subresolution images (color transform image, entropy image, and predictor image) have no transforms, not even the 0 bit that marks 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.Here's the reading loop in pseudo-code, bestie 💜
while (ReadBits(1)) { // Transform present.
// Decode transform type.
enum TransformType transform_type = ReadBits(2);
// Decode transform data.
...
}
// Decode actual image data.If a transform is present, the next two bits specify the transform type. There are four types of transforms, and they're listed here 🦋
+==========================+=====+
| Transform | Bit |
+==========================+=====+
| PREDICTOR_TRANSFORM | 0 |
+--------------------------+-----+
| COLOR_TRANSFORM | 1 |
+--------------------------+-----+
| SUBTRACT_GREEN_TRANSFORM | 2 |
+--------------------------+-----+
| COLOR_INDEXING_TRANSFORM | 3 |
+--------------------------+-----+
Table 1: Transform TypesThe transform type is followed by the transform data. That data holds everything needed to apply the inverse transform, and what's in it depends on the transform type. The inverse transforms get applied in the reverse order from how they were read out of the bitstream, so last one first 🔄👑
Next up, we break down the transform data for each type. Stay tuned, it's about to get so good 😭🫶
3.5.1. Predictor Transform ✨
okay so the predictor transform is lowkey genius bc neighboring pixels are usually besties with each other 🫶 so instead of storing each pixel's real value, we predict it from the pixels we've already decoded (going in scan-line order) and only store the leftover residual (actual - predicted). smaller numbers = fewer bits = slay 💅. The green component of a pixel picks which of the 14 predictors gets used inside a given block of the ARGB image, and that's the prediction mode. we split the image into squares and every pixel in one square shares the same mode 🧩
the first 3 bits of the prediction data give us the block width and height, as a number of bits 🎀
int size_bits = ReadBits(3) + 2;
int block_width = (1 << size_bits);
int block_height = (1 << size_bits);
#define DIV_ROUND_UP(num, den) (((num) + (den) - 1) / (den))
int transform_width = DIV_ROUND_UP(image_width, 1 << size_bits);the transform data holds the prediction mode for every block 🍓 it's a subresolution image where the green component of each pixel tells you which predictor covers all the block_width * block_height pixels in that block of the ARGB image. this little subresolution image gets encoded with the same tricks from Section 3.6, so no need to panic about it 💖
the number of block columns, transform_width, is what we use for two-dimensional indexing. for a pixel (x, y), you work out its filter block address like this:
int block_index = (y >> size_bits) * transform_width +
(x >> size_bits);there are 14 prediction modes total 👑 in every one of them, the current pixel gets predicted from one or more neighbors whose values we already know. the neighbors we use are TL, T, TR, and L around the current pixel (P):
O O O O O O O O O O O
O O O O O O O O O O O
O O O O TL T TR O O O O
O O O O L P X X X X X
X X X X X X X X X X X
X X X X X X X X X X XFigure 19: Neighboring Pixels of the Current Pixel (P)
TL is top-left, T is top, TR is top-right, and L is left 🦋 by the time we predict P, every O, TL, T, TR, and L pixel has already been processed. P and all the X pixels are still unknown, so they're off-limits. no peeking 🙈
here's the full cheat sheet of what each mode predicts:
+======+======================================================+
| Mode | Predicted Value of Each Channel of the Current Pixel |
+======+======================================================+
| 0 | 0xff000000 (represents solid black color in ARGB) |
+------+------------------------------------------------------+
| 1 | L |
+------+------------------------------------------------------+
| 2 | T |
+------+------------------------------------------------------+
| 3 | TR |
+------+------------------------------------------------------+
| 4 | TL |
+------+------------------------------------------------------+
| 5 | Average2(Average2(L, TR), T) |
+------+------------------------------------------------------+
| 6 | Average2(L, TL) |
+------+------------------------------------------------------+
| 7 | Average2(L, T) |
+------+------------------------------------------------------+
| 8 | Average2(TL, T) |
+------+------------------------------------------------------+
| 9 | Average2(T, TR) |
+------+------------------------------------------------------+
| 10 | Average2(Average2(L, TL), Average2(T, TR)) |
+------+------------------------------------------------------+
| 11 | Select(L, T, TL) |
+------+------------------------------------------------------+
| 12 | ClampAddSubtractFull(L, T, TL) |
+------+------------------------------------------------------+
| 13 | ClampAddSubtractHalf(Average2(L, T), TL) |
+------+------------------------------------------------------+Table 2: Prediction Modes
Average2 works per ARGB component like this 🧁
uint8 Average2(uint8 a, uint8 b) {
return (a + b) / 2;
}the Select predictor is the one that picks whichever neighbor is closer to the estimate 🔍
uint32 Select(uint32 L, uint32 T, uint32 TL) {
// L = left pixel, T = top pixel, TL = top-left pixel.
// ARGB component estimates for prediction.
int pAlpha = ALPHA(L) + ALPHA(T) - ALPHA(TL);
int pRed = RED(L) + RED(T) - RED(TL);
int pGreen = GREEN(L) + GREEN(T) - GREEN(TL);
int pBlue = BLUE(L) + BLUE(T) - BLUE(TL);
// Manhattan distances to estimates for left and top pixels.
int pL = abs(pAlpha - ALPHA(L)) + abs(pRed - RED(L)) +
abs(pGreen - GREEN(L)) + abs(pBlue - BLUE(L));
int pT = abs(pAlpha - ALPHA(T)) + abs(pRed - RED(T)) +
abs(pGreen - GREEN(T)) + abs(pBlue - BLUE(T));
// Return either left or top, the one closer to the prediction.
if (pL < pT) {
return L;
} else {
return T;
}
}ClampAddSubtractFull and ClampAddSubtractHalf also run for each ARGB component, and they both rely on a clamp that keeps everything between 0 and 255 🌈
// Clamp the input value between 0 and 255.
int Clamp(int a) {
return (a < 0) ? 0 : (a > 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);
}now the border pixels get some special treatment 🥹 if there's a predictor transform, then no matter which mode [0..13] is set, the left-topmost pixel of the image is predicted as 0xff000000, every pixel on the top row uses L as its prediction, and every pixel on the leftmost column uses T 💅
the TR-pixel for the rightmost column is the weird one, not gonna lie 💀 those pixels still use modes [0..13] like everyone else, but the leftmost pixel on the same row as the current pixel is used as their TR-pixel instead.
last step: the final pixel is the predicted value plus the encoded residual, channel by channel 🎉
void PredictorTransformOutput(uint32 residual, uint32 pred,
uint8* alpha, uint8* red,
uint8* green, uint8* blue) {
*alpha = ALPHA(residual) + ALPHA(pred);
*red = RED(residual) + RED(pred);
*green = GREEN(residual) + GREEN(pred);
*blue = BLUE(residual) + BLUE(pred);
}3.5.2. Color Transform 🌷
the color transform is all about decorrelating the R, G, and B values of each pixel 🦄 the green (G) value stays exactly as it is, the red (R) value gets transformed based on green, and the blue (B) value gets transformed based on green and then on red. the image gets split into blocks here too, and every pixel in a block uses the same transform mode. each block has three types of color transform elements:
typedef struct {
uint8 green_to_red;
uint8 green_to_blue;
uint8 red_to_blue;
} ColorTransformElement;the actual transform works by defining a color transform delta. that delta depends on the ColorTransformElement, which is the same for all the pixels in a particular block. the delta gets subtracted during the transform, so the inverse transform just adds those deltas back 🔄
the color transform function looks like this:
void ColorTransform(uint8 red, uint8 blue, uint8 green,
ColorTransformElement *trans,
uint8 *new_red, uint8 *new_blue) {
// Transformed values of red and blue components
int tmp_red = red;
int tmp_blue = blue;
// Applying the transform is just subtracting the transform deltas
tmp_red -= ColorTransformDelta(trans->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 from a signed 8-bit integer that represents a 3.5-fixed-point number, plus a signed 8-bit RGB color channel (c) in the range [-128..127] 🧮 it's defined like this:
int8 ColorTransformDelta(int8 t, int8 c) {
return (t * c) >> 5;
}before you call ColorTransformDelta(), you have to convert the 8-bit unsigned representation (uint8) into the 8-bit signed one (int8). the signed value gets read as an 8-bit two's complement number, so the uint8 range [128..255] maps onto the [-128..-1] range of its converted int8 value. it's a bit of a brain-melt, but it's consistent 😵💫
the multiplication needs more precision than 8 bits, with at least 16-bit precision. the sign extension behaviour of the shift doesn't matter here, because only the lowest 8 bits of the result are used, and in those bits, signed and unsigned shifting agree with each other ✨
now, the color transform data has to be laid out so the decoder can apply the inverse transform and get the original red and blue values back 💜 the first 3 bits hold the width and height of the image block as a number of bits, just like the predictor transform:
int size_bits = ReadBits(3) + 2;
int block_width = 1 << size_bits;
int block_height = 1 << size_bits;the rest of the color transform data is a list of ColorTransformElement instances, one for each block of the image 🧱 each ColorTransformElement 'cte' gets treated like a pixel in a subresolution image. its alpha component is 255, its red component is cte.red_to_blue, its green component is cte.green_to_blue, and its blue component is cte.green_to_red.
when decoding, the ColorTransformElement instances for the blocks get decoded, and then the inverse color transform gets applied to the ARGB values of the pixels. like we said earlier, the inverse is just adding ColorTransformElement values onto the red and blue channels. the alpha and green channels stay as they are 🌸
void InverseTransform(uint8 red, uint8 green, uint8 blue,
ColorTransformElement *trans,
uint8 *new_red, uint8 *new_blue) {
// Transformed values of red and blue components
int tmp_red = red;
int tmp_blue = blue;
// Applying the inverse transform is just adding the
// color transform deltas
tmp_red += ColorTransformDelta(trans->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;
}3.5.3. Subtract Green Transform ✨
Okay so the subtract green transform is lowkey the simplest one 💅 It subtracts the green value from the red and blue values of each pixel. When this transform is present, the decoder needs to add the green value back to both red and blue. There's no data attached to it. The decoder applies the inverse like this:
void AddGreenToBlueAndRed(uint8 green, uint8 *red, uint8 *blue) {
*red = (*red + green) & 0xff;
*blue = (*blue + green) & 0xff;
}Honestly this one is kinda redundant 🙈 It can be modeled using the color transform, but since there's no extra data here, the subtract green transform can be coded in fewer bits than a full-blown color transform. Iconic efficiency 🦋
3.5.4. Color Indexing Transform 🌈
If there aren't many unique pixel values, it can be more efficient to make a color index array and replace the pixel values with the array's indices. That's exactly what the color indexing transform does. (Quick aside: in WebP lossless we specifically don't call this a palette transform, because a similar but more dynamic concept already exists in WebP lossless encoding, and that's color cache 🎀)
The color indexing transform checks how many unique ARGB values the image has. If that number is below a threshold (256), it makes an array of those ARGB values and uses it to replace each pixel with the index of its color. The green channel of each pixel gets replaced with the index, all alpha values are set to 255, and all red and blue values are set to 0.
The transform data holds the color table size and the entries in the color table. The decoder reads the color indexing transform data like this:
// 8-bit value for the color table size
int color_table_size = ReadBits(8) + 1;The color table is stored using the image storage format itself 🧚 You can get the color table by reading an image without the RIFF header, image size, and transforms, assuming a height of 1 pixel and a width of color_table_size. The color table is always subtraction-coded to reduce image entropy. The deltas of palette colors usually have way less entropy than the colors themselves, which gives big savings for smaller images. When decoding, every final color in the color table is found by adding the previous color component values for each ARGB component separately, then keeping only the least significant 8 bits of the result.
The inverse transform is basically just swapping each pixel value (which is an index into the color table) for the real color table value. The indexing is done using the green component of the ARGB color:
// Inverse transform
argb = color_table[GREEN(argb)];If the index is equal to 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 get bundled into a single pixel. Pixel bundling packs 2, 4, or 8 pixels into one pixel, which shrinks the image width accordingly.
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 16 or fewer unique values. 🫶
color_table_size decides how many pixels get combined:
+==================+==================+
| color_table_size | width_bits value |
+==================+==================+
| 1..2 | 3 |
+------------------+------------------+
| 3..4 | 2 |
+------------------+------------------+
| 5..16 | 1 |
+------------------+------------------+
| 17..256 | 0 |
+------------------+------------------+
Table 3: Color Table Size to
Bundled Pixel Bit Width MappingSo width_bits can be 0, 1, 2, or 3. A value of 0 means no pixel bundling happens for the image. A value of 1 means two pixels are combined, and each pixel has a range of [0..15]. A value of 2 means four pixels are combined, and each pixel has a range of [0..3]. A value of 3 means eight pixels are combined, and each pixel has a range of [0..1], which is a binary value.
The values get packed into the green component like this:
width_bits = 1: For every x value, wherex = 2k + 0, a green value at x is positioned into the 4 least significant bits of the green value atx / 2, and a green value atx + 1is positioned into the 4 most significant bits of the green value atx / 2.width_bits = 2: For every x value, wherex = 4k + 0, a green value at x is positioned into the 2 least significant bits of the green value atx / 4, and green values atx + 1tox + 3are positioned in order into the more significant bits of the green value atx / 4.width_bits = 3: For every x value, wherex = 8k + 0, a green value at x is positioned into the least significant bit of the green value atx / 8, and green values atx + 1tox + 7are positioned in order into the more significant bits of the green value atx / 8.
After reading this transform, image_width gets subsampled by width_bits, and that affects the size of later transforms. The new size is calculated with DIV_ROUND_UP, as defined in Section 3.5.1:
image_width = DIV_ROUND_UP(image_width, 1 << width_bits);3.6. Image Data 🍓
Image data is an array of pixel values in scan-line order.
3.6.1. 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 (see "Decoding of Meta Prefix Codes" (Section 3.7.2.2)).
- Predictor image: Stores the metadata for the predictor transform (see "Predictor Transform" (Section 3.5.1)).
- Color transform image: Created by ColorTransformElement values (defined in "Color Transform" (Section 3.5.2)) for different blocks of the image.
- Color indexing image: An array of the size of color_table_size (up to 256 ARGB values) that stores the metadata for the color indexing transform (see "Color Indexing Transform" (Section 3.5.4)).
3.6.2. Encoding of Image Data 🎀
The encoding of image data doesn't depend on its role, so it's the same for all of them.
The image is first split into a set of fixed-size blocks (typically 16x16 blocks). Each block gets modeled with its own entropy codes, and several blocks can share the same entropy codes too.
Rationale: Storing an entropy code costs something. That cost can be cut down if statistically similar blocks share an entropy code, so the code only gets stored once. For example, an encoder can find similar blocks by clustering them based on their statistical properties, or by repeatedly joining a pair of randomly selected clusters when that reduces the overall number of bits needed to encode the image. 🧠
Each pixel gets encoded using one of three methods:
- Prefix-coded literals: Each channel (green, red, blue, and alpha) is entropy-coded independently.
- LZ77 backward reference: A sequence of pixels is copied from elsewhere in the image.
- Color cache code: Uses a short multiplicative hash code (color cache index) of a recently seen color.
The following subsections describe each of these in detail.
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).
Rationale: This approach reduces the storage requirement for the entropy code. Also, large values are usually rare, so extra bits would be used for very few values in the image. Thus, this approach results in better compression overall. 🦋
The following table shows the prefix codes and extra bits used for storing different ranges 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. 👑
+=================+=============+============+
| Value Range | Prefix Code | Extra Bits |
+=================+=============+============+
| 1 | 0 | 0 |
+-----------------+-------------+------------+
| 2 | 1 | 0 |
+-----------------+-------------+------------+
| 3 | 2 | 0 |
+-----------------+-------------+------------+
| 4 | 3 | 0 |
+-----------------+-------------+------------+
| 5..6 | 4 | 1 |
+-----------------+-------------+------------+
| 7..8 | 5 | 1 |
+-----------------+-------------+------------+
| 9..12 | 6 | 2 |
+-----------------+-------------+------------+
| 13..16 | 7 | 2 |
+-----------------+-------------+------------+
| ... | ... | ... |
+-----------------+-------------+------------+
| 3072..4096 | 23 | 10 |
+-----------------+-------------+------------+
| ... | ... | ... |
+-----------------+-------------+------------+
| 524289..786432 | 38 | 18 |
+-----------------+-------------+------------+
| 786433..1048576 | 39 | 18 |
+-----------------+-------------+------------+
Table 4: Value to Prefix Code and Extra
Bits MappingThe pseudocode to get a (length or distance) value from the prefix code goes like this:
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;3.6.2.2.1. Distance Mapping
Okay so a distance code is basically a number that tells you where a previously seen pixel is, so you know which one to copy 💅 This subsection defines how a distance code maps to the position of that earlier pixel 🦋
Distance codes larger than 120 denote the pixel distance in scan-line order, offset by 120 ✨
The smallest distance codes, [1..120], are special. They're reserved for a close neighborhood around the current pixel 🌸 That neighborhood is made up 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 the 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 distance_code and the neighboring pixel offset (xi, yi) goes like this 👑
(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)Figure 20: Distance Code to Neighboring Pixel Offset Mapping
For example, distance code 1 gives an offset of (0, 1), which is the pixel directly above the current pixel (0 pixel difference in the X direction and 1 pixel difference in the Y direction) ⭐ Distance code 3 points at the top-left pixel 🧚
The decoder can turn a distance code distance_code into a scan-line order distance dist like this 💖
(xi, yi) = distance_map[distance_code - 1]
dist = xi + yi * image_width
if (dist < 1) {
dist = 1
}Here distance_map is the mapping from above, and image_width is the width of the image in pixels 🎀
3.6.2.3. Color Cache Coding
The color cache stores a set of colors that have been used recently in the image 🌈
Rationale: This way, the recently used colors can sometimes be referred to more efficiently than emitting them using the other two methods (described in Sections 3.6.2.1 and 3.6.2.2).
Color cache codes are stored like this 🍓 First there's a 1-bit value that says whether the color cache is used. If this bit is 0, there are no color cache codes, and they aren't sent in the prefix code that decodes the green symbols and the length prefix codes. 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 sets the size of the color cache (1 << color_cache_code_bits). The allowed range 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 holds one ARGB color. Colors are looked up by indexing them with (0x1e35a7bd * color) >> (32 - color_cache_code_bits). Only one lookup is done in a color cache, and there's no conflict resolution, so it's a single shot 🔥
At the start of decoding or encoding an image, every entry in all of the color cache values is set to zero. The color cache code gets converted to this color at decoding time 🫶 The color cache state is kept up to date by inserting every pixel into the cache, whether it came from backward referencing or was a literal, in the order the pixels appear in the stream 💜
3.7. Entropy Code
3.7.1. Overview
Most of the data is coded using a canonical prefix code [Huffman]. So the codes get sent by transmitting the prefix code lengths, not the actual prefix codes 💅
Specifically, the format uses spatially variant prefix coding. Basically, different blocks of the image can 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 better compression.
3.7.2. Details
The encoded image data is made of several parts:
- Decoding and building the prefix codes.
- Meta prefix codes.
- Entropy-coded image data.
For any given pixel (x, y), there's a set of five prefix codes attached to it, listed here in bitstream order ✨
- Prefix code #1: Used for the green channel, backward-reference length, and color cache.
- Prefix code #2, #3, and #4: Used for the red, blue, and alpha channels, respectively.
- Prefix code #5: Used for backward-reference distance.
From here on, we call this set a prefix code group 🎀
3.7.2.1. Decoding and Building the Prefix Codes
This section explains how to read the prefix code lengths from the bitstream 🦋
The prefix code lengths can be coded in two ways, and a 1-bit value tells you which method is in use 💖
- If this bit is 1, it is a simple code length code.
- 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. That's inefficient, but the format allows it 🙃 The described tree must be a complete binary tree. A single leaf node counts as a complete binary tree and can be encoded with either the simple code length code or the normal code length code. When you code a single leaf node with the normal code length code, all but one code length are zeros, and the single leaf node value is marked with a length of 1, even though no bits get consumed when that single leaf node tree is used 💅
3.7.2.1.1. Simple Code Length Code
This variant is for the special case where only 1 or 2 prefix symbols in the range [0..255] have code length 1. All other prefix code lengths are implicitly zeros 🌈
The first bit tells you how many symbols there are:
int num_symbols = ReadBits(1) + 1;Next come the symbol values. The first symbol is coded with either 1 or 8 bits, depending on the value of is_first_8bits. Its range is [0..1] or [0..255], respectively. The second symbol, if it's there, is always assumed to be in the range [0..255] and is coded with 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;
}The two symbols should be different. Duplicate symbols are allowed, but inefficient.
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 special handling, because empty prefix codes can be coded as those containing a single symbol 0. 🙈
3.7.2.1.2. Normal Code Length Code
The code lengths of the prefix code fit in 8 bits, and they get read like this 💜 First, num_code_lengths says how many code lengths there are 🦋
int num_code_lengths = 4 + ReadBits(4);The code lengths are encoded with prefix codes themselves, so the lower-level code lengths, code_length_code_lengths, have to be read first. The rest of those code_length_code_lengths (following 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 (max_symbol) for each symbol type (A, R, G, B, and distance) is set to its alphabet size 👑
- G channel: 256 + 24 + color_cache_size
- Other literals (A, R, and B): 256
- Distance code: 40
Otherwise, it's defined as:
int length_nbits = 2 + 2 * ReadBits(3);
int max_symbol = 2 + ReadBits(length_nbits);If max_symbol is larger than the size of the alphabet for the symbol type, the bitstream is invalid 🚫
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 nonzero value [3..6] times, that is, 3 + ReadBits(2) times. If code 16 is used before a nonzero value has been emitted, a value of 8 is repeated 🌸
- Code 17 emits a streak of zeros of length [3..10], that is, 3 + ReadBits(3) times.
- Code 18 emits a streak of zeros of length [11..138], that is, 11 + ReadBits(7) times.
Once the code lengths are read, a prefix code for each symbol type (A, R, G, B, and distance) is formed using their respective alphabet sizes 🎀
3.7.2.2. Decoding of Meta Prefix Codes
As noted earlier, the format lets you use different prefix codes for different blocks of the image 🌈 Meta prefix codes are indexes that identify 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, and a 1-bit value says which one you've got:
- If this bit is zero, there's 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 are stored as an entropy image (described below) 🍓
The red and green components of a pixel together define a 16-bit meta prefix code used in a particular block of the ARGB image ✨
3.7.2.2.1. Entropy Image
The entropy image defines which prefix codes get used in different parts of the image 💖
The first 3 bits contain the prefix_bits value. The dimensions of the entropy image come from prefix_bits:
int prefix_bits = ReadBits(3) + 2;
int prefix_image_width =
DIV_ROUND_UP(image_width, 1 << prefix_bits);
int prefix_image_height =
DIV_ROUND_UP(image_height, 1 << prefix_bits);Here, DIV_ROUND_UP is as defined in Section 3.5.1 🫶
The next bits contain an entropy image of width prefix_image_width and height prefix_image_height 💜
3.7.2.2.2. Interpretation of Meta Prefix Codes ✨
okay so the number of prefix code groups in the ARGB image is the thing we find by looking for the largest meta prefix code in the entropy image 🧠 bestie, it's giving math class but make it iconic:
int num_prefix_groups = max(entropy image) + 1;where max(entropy image) means the biggest prefix code stored in the entropy image 💅
each prefix code group holds five prefix codes, so the total number of prefix codes is:
int num_prefix_codes = 5 * num_prefix_groups;now, given a pixel (x, y) in the ARGB image, here's how we grab the prefix codes to use 🫶
int position =
(y >> prefix_bits) * prefix_image_width + (x >> prefix_bits);
int meta_prefix_code = (entropy_image[position] >> 8) & 0xffff;
PrefixCodeGroup prefix_group = prefix_code_groups[meta_prefix_code];we're assuming there's a PrefixCodeGroup structure that represents a set of five prefix codes 🎀 and prefix_code_groups is an array of PrefixCodeGroup (sized num_prefix_groups) 🌸
the decoder then uses that prefix_group to decode the pixel (x, y), as explained in Section 3.7.2.3 🦋
3.7.2.3. Decoding Entropy-Coded Image Data ⭐
so for the current position (x, y) in the image, the decoder first figures out which prefix code group applies (we just covered that in the last section 👑). Once it has the group, the pixel gets read and decoded like this:
first, read 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). See Section 3.6.2.3 for details about color_cache_size. 🧚
the meaning of S depends on its value, periodt 💅
- If S < 256
i. Use S as the green component.
ii. Read red from the bitstream using prefix code #2.
iii. Read blue from the bitstream using prefix code #3.
iv. Read alpha from the bitstream using prefix code #4.
- If S >= 256 & S < 256 + 24
i. Use S - 256 as a length prefix code.
ii. Read extra bits for the length from the bitstream.
iii. Determine backward-reference length L from the length prefix code and the extra bits read.
iv. Read the distance prefix code from the bitstream using prefix code #5.
v. Read extra bits for the distance from the bitstream.
vi. Determine backward-reference distance D from the distance prefix code and the extra bits read.
vii. Copy L pixels (in scan-line order) from the sequence of pixels starting at the current position minus D pixels. 🔥
- If S >= 256 + 24
i. Use S - (256 + 24) as the index into the color cache.
ii. Get the ARGB color from the color cache at that index. 🌈
3.8. Overall Structure of the Format 🍓
okay so here's a view of the format in Augmented Backus-Naur Form [RFC5234] [RFC7405] 🫠 it doesn't cover every single detail, but it gets the vibe across. The end-of-image (EOI) is only implicitly coded into the number of pixels (image_width * image_height), so there's no separate end marker, no cap 🙈
Note that *element means element can be repeated 0 or more times. 5element means element is repeated exactly 5 times. %b represents a binary value. 💜
3.8.1. Basic Structure 🎀
format = RIFF-header image-header image-stream
RIFF-header = %s"RIFF" 4OCTET %s"WEBPVP8L" 4OCTET
image-header = %x2F image-size alpha-is-used version
image-size = 14BIT 14BIT ; width - 1, height - 1
alpha-is-used = 1BIT
version = 3BIT ; 0
image-stream = optional-transform spatially-coded-image3.8.2. Structure of Transforms 🦋
optional-transform = (%b1 transform optional-transform) / %b0
transform = predictor-tx / color-tx / subtract-green-tx
transform =/ color-indexing-tx
predictor-tx = %b00 predictor-image
predictor-image = 3BIT ; sub-pixel code
entropy-coded-image
color-tx = %b01 color-image
color-image = 3BIT ; sub-pixel code
entropy-coded-image
subtract-green-tx = %b10
color-indexing-tx = %b11 color-indexing-image
color-indexing-image = 8BIT ; color count
entropy-coded-image3.8.3. Structure of the Image Data 💅
spatially-coded-image = color-cache-info meta-prefix data
entropy-coded-image = color-cache-info data
color-cache-info = %b0
color-cache-info =/ (%b1 4BIT) ; 1 followed by color cache size
meta-prefix = %b0 / (%b1 entropy-image)
data = prefix-codes lz77-coded-image
entropy-image = 3BIT ; subsample value
entropy-coded-image
prefix-codes = prefix-code-group *prefix-codes
prefix-code-group =
5prefix-code ; See "Interpretation of Meta Prefix Codes" to
; understand what each of these five prefix
; codes are for.
prefix-code = simple-prefix-code / normal-prefix-code
simple-prefix-code = ; see "Simple Code Length Code" for details
normal-prefix-code = ; see "Normal Code Length Code" for details
lz77-coded-image =
*((argb-pixel / lz77-copy / color-cache-code) lz77-coded-image)here's a possible example sequence 🧁
RIFF-header image-size %b1 subtract-green-tx
%b1 predictor-tx %b0 color-cache-info
%b0 prefix-codes lz77-coded-image4. Security Considerations 🚨
okay bestie, this part is SERIOUS 😭 implementations of this format face real security risks, like integer overflows, out-of-bounds reads and writes to both heap and stack, uninitialized data usage, null pointer dereferences, resource (disk or memory) exhaustion, and extended resource usage (long running time) during the demuxing and decoding process. Like, implementations that read this format are likely to take input from unknown and possibly unsafe sources, both clients (for example, web browsers or email clients) and servers (for example, applications that accept uploaded images). These can lead to arbitrary code execution, information leakage (memory layout and contents), or crashes, which can let a device get compromised or cause a denial of service to an application that uses the format [mitre-libwebp] [issues-security]. not okay, honestly 💀
the format doesn't use "active content" 🙌 but it does allow metadata (for example, [XMP] and [Exif]) and custom chunks to be embedded in a file. Applications that interpret those chunks may be subject to security considerations for those formats too 🫶
5. Interoperability Considerations 🌸
the format is defined using little-endian byte ordering (see Section 3.1 of [RFC2781]), but demuxing and decoding are possible on platforms that use a different ordering, with the appropriate conversion 🦋 The container is based on RIFF and allows extension via user-defined chunks, but nothing beyond the chunks defined by the container format (Section 2) is required for decoding the image. These have been finalized, but they were extended in the format's early stages, so some older readers may not support lossless or animated image decoding 🎀
6. IANA Considerations 📚
IANA has registered the 'image/webp' media type [RFC2046] 🍓
6.1. The 'image/webp' Media Type ✨
this section has the media type registration details per [RFC6838] 💖
6.1.1. Registration Details 🌈
- Type name: image
- Subtype name: webp
- Required parameters: N/A
- Optional parameters: N/A
- Encoding considerations: Binary. The Base64 encoding [RFC4648] should be used on transports that cannot accommodate binary data directly.
- Security considerations: See RFC 9649, Section 4.
- Interoperability considerations: See RFC 9649, Section 5.
- Published specification: RFC 9649
- 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: James Zern <jzern@google.com>
- Intended usage: COMMON
- Restrictions on usage: N/A
- Author: James Zern <jzern@google.com>
- Change controller: IETF
7. References 📖
7.1. Normative References ✨
okay bestie, these are the ones you actually need to have read to get the full picture. the spec leans on them hard 💅
- [Exif] Camera & Imaging Products Association (CIPA) and Japan Electronics and Information Technology Industries Association (JEITA), "Exchangeable image file format for digital still cameras: Exif Version 2.3", CIPA DC-008-2012, JEITA CP-3451C, December 2012,
https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf. - [ICC] International Color Consortium, "Image technology colour management -- Architecture, profile format, and data structure", Profile version 4.3.0.0, REVISION of ICC.1:2004-10, Specification ICC.1:2010, December 2010,
https://www.color.org/specification/ICC1v43_2010-12.pdf. - [ISO.9899.2018] International Organization for Standardization, "Information technology -- Programming languages -- C", Fourth Edition, ISO/IEC 9899:2018, June 2018,
https://www.iso.org/standard/74528.html. - [REC601] ITU, "Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratios", ITU-R Recommendation BT.601, March 2011,
https://www.itu.int/rec/R-REC-BT.601/. - [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, DOI 10.17487/RFC1166, July 1990,
https://www.rfc-editor.org/info/rfc1166. - [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996,
https://www.rfc-editor.org/info/rfc2046. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119. - [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000,
https://www.rfc-editor.org/info/rfc2781. - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
https://www.rfc-editor.org/info/rfc4648. - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
https://www.rfc-editor.org/info/rfc5234. - [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011,
https://www.rfc-editor.org/info/rfc6386. - [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013,
https://www.rfc-editor.org/info/rfc6838. - [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014,
https://www.rfc-editor.org/info/rfc7405. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
https://www.rfc-editor.org/info/rfc8174. - [XMP] Adobe Inc., "XMP Specification",
https://www.adobe.com/devnet/xmp.html.
7.2. Informative References 🦋
these ones are the extra reading. nice to know, not strictly required, but they're giving background and I love a good footnote 🧚
- [GIF-spec] CompuServe Incorporated, "Graphics Interchange Format(sm)", Version 89a, July 1990,
https://www.w3.org/Graphics/GIF/spec-gif89a.txt. - [Huffman] Huffman, D., "A Method for the Construction of Minimum-Redundancy Codes", Proceedings of the Institute of Radio Engineers, Vol. 40, Issue 9, pp. 1098-1101, DOI 10.1109/JRPROC.1952.273898, September 1952,
https://doi.org/10.1109/JRPROC.1952.273898. - [issues-security] "libwebp Security Issues",
https://issues.webmproject.org/issues?q=componentid:1618983%2B%20(%22Restrict-View-Security%22%20OR%20type:vulnerability). - [JPEG-spec] "Information Technology - Digital Compression and Coding of Continuous-Tone Still Images - Requirements and Guidelines", ITU-T Recommendation T.81, ISO/IEC 10918-1, September 1992,
https://www.w3.org/Graphics/JPEG/itu-t81.pdf. - [LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for Sequential Data Compression", IEEE Transactions on Information Theory, Vol. 23, Issue 3, pp. 337-343, DOI 10.1109/TIT.1977.1055714, May 1977,
https://doi.org/10.1109/TIT.1977.1055714. - [mitre-libwebp] "libwebp CVE List",
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libwebp. - [MWG] Metadata Working Group, "Guidelines For Handling Image Metadata", Version 2.0, November 2010,
https://web.archive.org/web/20180919181934/http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf. - [RFC2083] Boutell, T., "PNG (Portable Network Graphics) Specification Version 1.0", RFC 2083, DOI 10.17487/RFC2083, March 1997,
https://www.rfc-editor.org/info/rfc2083. - [RIFF-spec] "RIFF (Resource Interchange File Format)",
https://www.loc.gov/preservation/digital/formats/fdd/fdd000025.shtml. - [webp-lossless-src] "WebP Lossless Bitstream Specification", July 2024,
https://chromium.googlesource.com/webm/libwebp/+/refs/tags/webp-rfc9649/doc/webp-lossless-bitstream-spec.txt. - [webp-lossless-study] Alakuijala, J. and V. Rabaud, "Lossless and Transparency Encoding in WebP", August 2017,
https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study. - [webp-riff-src] "WebP RIFF Container", July 2024,
https://chromium.googlesource.com/webm/libwebp/+/refs/tags/webp-rfc9649/doc/webp-container-spec.txt.
Authors' Addresses ✨
the squad behind this one 🫶
- James Zern
- Google LLC
- 1600 Amphitheatre Parkway
- Mountain View, CA 94043
- United States of America
- Phone: +1 650 253-0000
- Email: jzern@google.com
- Pascal Massimino
- Google LLC
- Email: pascal.massimino@gmail.com
- Jyrki Alakuijala
- Google LLC
- Email: jyrki.alakuijala@gmail.com
📦 where this page comes from
- ietf: rfc9649 2024-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms