Internet Engineering Task Force (IETF) J. Zern
Request for Comments: 9649 P. Massimino
Category: Informational J. Alakuijala
ISSN: 2070-1721 Google LLC
November 2024
This document defines the WebP image format and registers a media type supporting its use.
このドキュメントでは、WebPイメージ形式を定義し、その使用をサポートするメディアタイプを登録します。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9649で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
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' Addresses
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は、リソースインターチェンジファイル形式（RIFF）[RIFF-SPEC]（セクション2）に基づいた画像ファイル形式であり、ロスレスと損失のある圧縮、およびアルファ（透明性）とアニメーションをサポートします。JPEG [JPEG-Spec]、PNG [RFC2083]、およびグラフィックスインターチェンジ形式（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.
WebPは、アルファ（透明性）情報を含む画像ピクセルデータのサイズを削減するために使用される2つの圧縮アルゴリズムで構成されています。VP8イントラフレームエンコード[RFC6386]を使用して、損失のある圧縮が達成されます。ロスレスアルゴリズム（セクション3）は、完全に透明なピクセルの色値を含む、ピクセル値を正確に復元し、復元します。シーケンシャルデータ圧縮[LZ77]、プレフィックスコーディング[Huffman]、およびカラーキャッシュのユニバーサルアルゴリズムは、バルクデータの圧縮に使用されます。
Note that this section is based on the documentation in the libwebp source repository [webp-riff-src].
このセクションは、LibWebpソースリポジトリ[WebP-Riff-SRC]のドキュメントに基づいていることに注意してください。
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.
WebPは、（i）VP8イントラフレームエンコード[RFC6386]を使用して、画像データを損失のある方法で圧縮する画像形式または（ii）WebPロスレスエンコーディング（セクション3）のいずれかを使用する画像形式です。これらのエンコードスキームは、JPEG、GIF、PNGなどの古い形式よりも効率的にする必要があります。ネットワーク上での高速画像転送（たとえば、Webサイトの場合）のために最適化されています。WebP形式には、他の形式と同様に、機能パリティ（カラープロファイル、メタデータ、アニメーションなど）があります。このセクションでは、WebPファイルの構造について説明します。
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:
WebPコンテナ（つまり、WebP用のリフコンテナ）により、WebPの基本的なユースケース（つまり、VP8キーフレームとしてエンコードされた単一の画像を含むファイル）の上の機能サポートが可能になります。WebPコンテナは、以下に追加のサポートを提供します。
* Lossless Compression: An image can be losslessly compressed, using the WebP lossless format.
* ロスレス圧縮：WebPロスレスフォーマットを使用して、画像を損失を無効にすることができます。
* Metadata: An image may have metadata stored in Exchangeable Image File Format [Exif] or Extensible Metadata Platform [XMP] format.
* メタデータ：画像には、交換可能な画像ファイル形式[EXIF]または拡張可能なメタデータプラットフォーム[XMP]形式に保存されているメタデータがあります。
* Transparency: An image may have transparency, that is, an alpha channel.
* 透明性：画像には透明性、つまりアルファチャネルがある場合があります。
* Color Profile: An image may have an embedded ICC profile (ICCP) [ICC].
* カラープロファイル：画像には、ICCプロファイルが埋め込まれている場合があります（ICCP）[ICC]。
* 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", "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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
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.
WebPファイルには、静止画像（つまり、ピクセルのエンコードされたマトリックス）またはアニメーション（セクション2.7.1.1）のいずれかが含まれます。オプションで、透明性情報、カラープロファイル、メタデータも含めることができます。ピクセルのマトリックスを画像の_canvas_と呼びます。
Bit numbering in chunk diagrams starts at 0 for the most significant bit ('MSB 0'), as described in [RFC1166].
チャンク図のビット番号は、[RFC1166]で説明されているように、最も重要なビット（ 'MSB 0'）で0から始まります。
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_.
WebPファイルを読み取るコードは_reader_と呼ばれ、それらを書き込むコードは_writer_と呼ばれます。
uint16
UINT16
A 16-bit, little-endian, unsigned integer.
16ビット、リトルエンディアン、署名されていない整数。
uint24
uint24
A 24-bit, little-endian, unsigned integer.
24ビット、リトルエンディアン、署名されていない整数。
uint32
UINT32
A 32-bit, little-endian, unsigned integer.
32ビット、リトルエンディアン、署名されていない整数。
FourCC
4cc
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.
4文字のコード（Fourcc）は、4つのASCII文字をリトルエンディアンの順序で連結することによって作成されたUINT32です。これは、「AAAA」（0x61616161）および「AAAA」（0x41414141）が異なる4ccとして扱われることを意味します。
1-based
1ベース
An unsigned integer field storing values offset by -1, for example, such a field would store value _25_ as _24_.
たとえば、そのようなフィールドは_24_として_25_を保存する場合、署名されていない整数フィールド保存値が-1でオフセットされます。
ChunkHeader('ABCD')
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.
個々のチャンクの_ fourcc _および_チャンクサイズのヘッダーを説明するために使用されます。ここで、「abcd」はチャンクの4ccです。この要素のサイズは8バイトです。
The WebP file format is based on the RIFF [RIFF-spec] document format.
WebPファイル形式は、RIFF [RIFF-SPEC]ドキュメント形式に基づいています。
The basic element of a RIFF file is a _chunk_. It consists of:
リフファイルの基本要素は_chunk_です。それは次のとおりです。
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
図1：「リフ」チャンク構造
Chunk FourCC: 32 bits
チャンク4cc：32ビット
ASCII four-character code used for chunk identification.
チャンク識別に使用されるASCII 4文字コード。
Chunk Size: 32 bits (_uint32_)
チャンクサイズ：32ビット（_uint32_）
The size of the chunk in bytes, not including this field, the chunk identifier, or padding.
このフィールド、チャンク識別子、またはパディングは含まれないバイトのチャンクのサイズ。
Chunk Payload: _Chunk Size_ bytes
チャンクペイロード：_chunk size_バイト
The data payload. If _Chunk Size_ is odd, a single padding byte -- which MUST be 0 to conform with RIFF [RIFF-spec] -- is added.
データペイロード。_chunk size_が奇数の場合、単一のパディングバイト（Riff [riff-spec]に準拠するために0でなければなりません）が追加されます。
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.
注：Riffには、すべての大文字のチャンク4ccが任意のリフファイル形式に適用される標準チャンクであるという規則がありますが、ファイル形式に固有の4ccsはすべて小文字です。Webpはこの慣習に従いません。
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
図2：WebPファイルヘッダーチャンク
'RIFF': 32 bits
「リフ」：32ビット
The ASCII characters 'R', 'I', 'F', 'F'.
ASCII文字 'r'、 'i'、 'f'、 'f'。
File Size: 32 bits (_uint32_)
ファイルサイズ：32ビット（_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.
オフセット8から始まるファイルのサイズ。このフィールドの最大値は2^32マイナス10バイトであるため、ファイル全体のサイズは最大4ギブマイナス2バイトです。
'WEBP': 32 bits
「Webp」：32ビット
The ASCII characters 'W', 'E', 'B', 'P'.
ASCII文字 '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.
WebPファイルは、4cc 'webp'を備えたリフヘッダーで開始する必要があります。ヘッダーのファイルサイズは、「WebP」4ccの4バイトに続くチャンクの合計サイズです。ファイルには、_file size_で指定されたデータの後にデータを含めるべきではありません。読者は、そのようなファイルを解析して、後続のデータを無視する場合があります。チャンクのサイズが均等であるため、リフヘッダーで与えられるサイズも偶数です。個々のチャンクの内容については、次のセクションで説明します。
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.
このレイアウトは、画像が紛失したエンコードを必要とし、拡張形式で提供される透明性またはその他の高度な機能を必要としない場合に使用する必要があります。このレイアウトを備えたファイルは小さく、古いソフトウェアでサポートされています。
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
図3：シンプルなWebp（損失）ファイル形式
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
図4： 'VP8'チャンク
VP8 data: _Chunk Size_ bytes
VP8データ：_Chunk Size_バイト
VP8 bitstream data.
VP8ビットストリームデータ。
Note that the fourth character in the 'VP8 ' FourCC is an ASCII space (0x20).
「VP8」4ccの4番目の文字はASCIIスペース（0x20）であることに注意してください。
The VP8 bitstream format specification is described in [RFC6386].
VP8ビットストリーム形式の仕様は[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.
VP8フレームヘッダーには、VP8フレームの幅と高さが含まれていることに注意してください。それはキャンバスの幅と高さであると想定されています。
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.
VP8仕様では、画像をY'CBCR形式にデコードする方法について説明します。RGBに変換するには、推奨601 [Rec601]を使用する必要があります。アプリケーションは別の変換方法を使用する場合がありますが、視覚的な結果はデコーダー間で異なる場合があります。
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.
このレイアウトは、画像がロスレスエンコード（オプションの透明性チャネルを使用）を必要とし、拡張形式で提供される高度な機能を必要としない場合に使用する必要があります。
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
図5：シンプルなWebp（ロスレス）ファイル形式
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
図6： 'VP8L'チャンク
VP8L data: _Chunk Size_ bytes
VP8Lデータ：_Chunk Size_バイト
VP8L bitstream data.
VP8Lビットストリームデータ。
The specification of the VP8L bitstream can be found in Section 3.
VP8Lビットストリームの仕様は、セクション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.
VP8Lヘッダーには、VP8L画像の幅と高さが含まれていることに注意してください。それはキャンバスの幅と高さであると想定されています。
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.
* ファイルで使用されている機能に関する情報を含む「VP8X」チャンク。
* An optional 'ICCP' Chunk with a color profile.
* カラープロファイルを備えたオプションの「ICCP」チャンク。
* An optional 'ANIM' Chunk with animation control data.
* アニメーション制御データを備えたオプションの「アニック」チャンク。
* Image data.
* 画像データ。
* An optional 'EXIF' Chunk with Exif metadata.
* exifメタデータを備えたオプションの「exif」チャンク。
* An optional 'XMP ' Chunk with XMP metadata.
* XMPメタデータを備えたオプションの「XMP」チャンク。
* An optional list of unknown chunks (Section 2.7.1.6).
* 不明なチャンクのオプションのリスト（セクション2.7.1.6）。
For a _still image_, the _image data_ consists of a single frame, which is made up of:
静止画像の場合、画像データは次のような単一のフレームで構成されています。
* An optional alpha subchunk (Section 2.7.1.2).
* オプションのアルファサブチャンク（セクション2.7.1.2）。
* A bitstream subchunk (Section 2.7.1.3).
* ビットストリームサブチャンク（セクション2.7.1.3）。
For an _animated image_, the _image data_ consists of multiple frames. More details about frames can be found in Section 2.7.1.1.
アニメーション画像の場合、画像データは複数のフレームで構成されています。フレームの詳細については、セクション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.
再構築と色の補正に必要なすべてのチャンク、つまり「VP8X」、「ICCP」、「ANIM」、「ANMF」、「ALPH」、「VP8」、および「VP8L」は、前述の順序で表示する必要があります。再構築に必要なチャンクと色の補正が故障している場合、読者は失敗する必要があります。
Metadata (Section 2.7.1.5) and unknown chunks (Section 2.7.1.6) MAY appear out of order.
メタデータ（セクション2.7.1.5）および未知のチャンク（セクション2.7.1.6）は、順不同で表示される場合があります。
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.
理論的根拠：再構成に必要なチャンクは、ファイルに最初に表示され、すべてのデータを受信する前に読者が画像のデコードを開始できるようにする必要があります。アプリケーションは、実装に合わせてメタデータとカスタムチャンクの順序を変更することで恩恵を受ける場合があります。
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
図7：拡張Webpファイルヘッダー
Reserved (Rsv): 2 bits
予約済み（RSV）：2ビット
MUST be 0. Readers MUST ignore this field.
0でなければなりません。読者はこのフィールドを無視する必要があります。
ICC profile (I): 1 bit
ICCプロファイル（i）：1ビット
Set if the file contains an 'ICCP' Chunk.
ファイルが「ICCP」チャンクが含まれている場合に設定します。
Alpha (L): 1 bit
アルファ（L）：1ビット
Set if any of the frames of the image contain transparency information ("alpha").
画像のフレームのいずれかが透明性情報（「アルファ」）が含まれているかどうかを設定します。
Exif metadata (E): 1 bit
exifメタデータ（e）：1ビット
Set if the file contains Exif metadata.
ファイルがExifメタデータが含まれている場合に設定します。
XMP metadata (X): 1 bit
XMPメタデータ（X）：1ビット
Set if the file contains XMP metadata.
ファイルにXMPメタデータが含まれている場合は設定します。
Animation (A): 1 bit
アニメーション（a）：1ビット
Set if this is an animated image. Data in 'ANIM' and 'ANMF' Chunks should be used to control the animation.
これがアニメーション画像の場合は設定します。「アニメ」と「ANMF」チャンクのデータを使用して、アニメーションを制御する必要があります。
Reserved (R): 1 bit
予約済み（r）：1ビット
MUST be 0. Readers MUST ignore this field.
0でなければなりません。読者はこのフィールドを無視する必要があります。
Reserved: 24 bits
予約済み：24ビット
MUST be 0. Readers MUST ignore this field.
0でなければなりません。読者はこのフィールドを無視する必要があります。
Canvas Width Minus One: 24 bits
キャンバス幅から1つ：24ビット
_1-based_ width of the canvas in pixels. The actual canvas width is 1 + Canvas Width Minus One.
_1ベース_ピクセルのキャンバスの幅。実際のキャンバス幅は、1 +キャンバス幅を引いたものです。
Canvas Height Minus One: 24 bits
キャンバスの高さから1つ：24ビット
_1-based_ height of the canvas in pixels. The actual canvas height is 1 + Canvas Height Minus One.
_1ベース_ピクセルのキャンバスの高さ。実際のキャンバスの高さは、1 +キャンバスの高さを引いたものです。
The product of _Canvas Width_ and _Canvas Height_ MUST be at most 2^32 - 1.
_canvas width_および_canvas height_の積は、せいぜい2^32-1でなければなりません。
Future specifications may add more fields. Unknown fields MUST be ignored.
将来の仕様は、より多くのフィールドを追加する可能性があります。未知のフィールドは無視する必要があります。
An animation is controlled by 'ANIM' and 'ANMF' Chunks.
アニメーションは、「アニック」と「ANMF」チャンクによって制御されます。
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
図8： 'Anim'チャンク
For an animated image, this chunk contains the _global parameters_ of the animation.
アニメーション画像の場合、このチャンクにはアニメーションのグローバルパラメーターが含まれています。
Background Color: 32 bits (_uint32_)
背景色：32ビット（_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.
[青、緑、赤、アルファ]バイトのキャンバスのデフォルトの背景色。この色は、フレームの周りのキャンバス上の未使用のスペースと、最初のフレームの透明なピクセルを埋めるために使用できます。廃棄方法が1の場合にも背景色が使用されます。
Notes:
注：
* The background color MAY contain a nonopaque alpha value, even if the _Alpha_ flag in the 'VP8X' Chunk (Figure 7) is unset.
* 背景色には、「VP8X」チャンク（図7）の_ALPHA_フラグが設定されていない場合でも、非透過alpha値を含む場合があります。
* 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_)
ループカウント：16ビット（_uint16_）
The number of times to loop the animation. If it is 0, this means infinitely.
アニメーションをループする回数。0の場合、これは無限に意味します。
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.
このチャンクは、「VP8X」チャンクの_Animation_フラグが設定されている場合に表示する必要があります。_animation_フラグが設定されておらず、このチャンクが存在する場合、無視する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('ANMF') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame X | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Frame Y | Frame Width Minus One ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Frame Height Minus One |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Duration | Reserved |B|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Frame Data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: 'ANMF' Chunk
図9：「ANMF」チャンク
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.
アニメーション画像の場合、このチャンクには_single_フレームに関する情報が含まれています。_Animation Flag_が設定されていない場合、このチャンクは存在しないはずです。
Frame X: 24 bits (_uint24_)
フレームX：24ビット（_uint24_）
The X coordinate of the upper left corner of the frame is Frame X * 2.
フレームの左上隅のx座標はフレームx * 2です。
Frame Y: 24 bits (_uint24_)
フレームY：24ビット（_uint24_）
The Y coordinate of the upper left corner of the frame is Frame Y * 2.
フレームの左上隅のy座標はフレームy * 2です。
Frame Width Minus One: 24 bits (_uint24_)
フレーム幅マイナス1：24ビット（_uint24_）
The _1-based_ width of the frame. The frame width is 1 + Frame Width Minus One.
フレームの_1ベース_幅。フレーム幅は1 +フレーム幅を引いたものです。
Frame Height Minus One: 24 bits (_uint24_)
フレーム高さマイナス1：24ビット（_uint24_）
The _1-based_ height of the frame. The frame height is 1 + Frame Height Minus One.
フレームの_1ベースの高さ。フレームの高さは1 +フレーム高さを引いたものです。
Frame Duration: 24 bits (_uint24_)
フレーム持続時間：24ビット（_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.
次のフレームを1ミリ秒単位で表示する前に待つ時間。0のフレーム持続時間の解釈（および多くの場合<= 10）は、実装によって定義されることに注意してください。多くのツールとブラウザは、GIFと同様の最小期間を割り当てます。
Reserved: 6 bits
予約済み：6ビット
MUST be 0. Readers MUST ignore this field.
0でなければなりません。読者はこのフィールドを無視する必要があります。
Blending method (B): 1 bit
ブレンド方法（b）：1ビット
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.
* 0：アルファブレンドを使用します。前のフレームを処分した後、アルファブレンドを使用してキャンバスの現在のフレームをレンダリングします。現在のフレームにアルファチャネルがない場合、アルファ値が255であると仮定し、長方形を効果的に置き換えます。
* 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.
* 1：ブレンドしないでください。前のフレームを処分した後、現在のフレームで覆われた長方形を上書きすることにより、キャンバスの現在のフレームをレンダリングします。
Disposal method (D): 1 bit
廃棄方法（d）：1ビット
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.
* 0：処分しないでください。キャンバスをそのままにしておきます。
* 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).
* 1：背景色に分けます。_current frame_で覆われたキャンバスの_rectangle_を「アニミアン」チャンクで指定された背景色で埋めます（図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.
* フレーム廃棄は、_frame rectangle_、つまり_frame x_、_ frame y_、_frame width_、_frame height_で定義される長方形にのみ適用されます。キャンバス全体をカバーする場合とカバーしない場合があります。
* 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:
R、G、B、およびAチャネルのそれぞれが8ビットで、RGBチャネルがAlphaによって_Not Premultipired_であることを考えると、「DST」を「SRC」にブレンドするための式は次のとおりです。
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.)
* 画像の色プロファイル（セクション2.7.1.4）を考慮して、アルファブレンドは線形の色空間で行う必要があります。カラープロファイルが存在しない場合、標準のRGB（SRGB）が想定されます。（〜2.2のガンマのために、SRGBも線形化する必要があることに注意してください。）
Frame Data: _Chunk Size_ bytes - 16
フレームデータ：_Chunk Size_バイト-16
Consists of:
で構成されています：
* An optional alpha subchunk (Section 2.7.1.2) for the frame.
* フレームのオプションのアルファサブチャンク（セクション2.7.1.2）。
* A bitstream subchunk (Section 2.7.1.3) for the frame.
* フレームのビットストリームサブチャンク（セクション2.7.1.3）。
* An optional list of unknown chunks (Section 2.7.1.6).
* 不明なチャンクのオプションのリスト（セクション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).
注：「ANMF」ペイロード_Frame Data_は、RIFFファイル形式（セクション2.3）で説明されているように、個々の_Padded_チャンクで構成されています。
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
図10：「アルフ」チャンク
Reserved (Rsv): 2 bits
予約済み（RSV）：2ビット
MUST be 0. Readers MUST ignore this field.
0でなければなりません。読者はこのフィールドを無視する必要があります。
Preprocessing (P): 2 bits
プリプロセシング（P）：2ビット
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.
* 0：前処理なし。
* 1: Level reduction.
* 1：レベルの削減。
Decoders are not required to use this information in any specified way.
デコーダーは、この情報を指定された方法で使用する必要はありません。
Filtering method (F): 2 bits
フィルタリング方法（F）：2ビット
The filtering methods used are described as follows:
使用されるフィルタリング方法は、次のように説明されています。
* 0: None.
* 0：なし。
* 1: Horizontal filter.
* 1：水平フィルター。
* 2: Vertical filter.
* 2：垂直フィルター。
* 3: Gradient filter.
* 3：勾配フィルター。
For each pixel, filtering is performed using the following calculations. Assume the alpha values surrounding the current X position are labeled as:
各ピクセルについて、以下の計算を使用してフィルタリングが実行されます。現在のX位置を取り巻くアルファ値のラベルが次のようにラベル付けされていると仮定します。
C | B |
---+---+
A | X |
Figure 11: Pixels Used in Alpha Filtering
図11：アルファフィルタリングで使用されるピクセル
We seek to compute the alpha value at position X. First, a prediction is made depending on the filtering method:
位置Xでアルファ値を計算しようとします。まず、フィルタリング方法に応じて予測が行われます。
* Method 0: predictor = 0
* 方法0：Predictor = 0
* Method 1: predictor = A
* 方法1：予測因子= a
* Method 2: predictor = B
* 方法2：予測因子= b
* Method 3: predictor = clip(A + B - C)
* 方法3：Predictor = Clip（A + B -C）
where clip(v) is equal to:
クリップ（v）が等しい場所：
* 0 if v < 0,
* 0 v <0の場合、
* 255 if v > 255, or
* 255 v> 255の場合、または
* v otherwise.
* Vそれ以外の場合。
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:
最終的な値は、減圧値xを予測子に追加し、modulo-256算術を使用して[256..511]範囲を[0..255] 1つにラップすることにより導出されます。
alpha = (predictor + X) % 256
There are special cases for the left-most and top-most pixel positions.
左および最上位のピクセル位置には特別なケースがあります。
For example, the top-left value at location (0, 0) uses 0 as the predictor value. Otherwise:
たとえば、場所（0、0）の左上値は、予測値として0を使用します。さもないと：
* For horizontal or gradient filtering methods, the left-most pixels at location (0, y) are predicted using the location (0, y-1) just above.
* 水平または勾配のフィルタリング方法の場合、場所（0、y）の左端のピクセルが、上記の場所（0、y-1）を使用して予測されます。
* 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.
* 垂直または勾配のフィルタリング方法の場合、左側の位置（x-1、0）を使用して、位置（x、0）の最上位ピクセルが予測されます。
Compression method (C): 2 bits
圧縮法（c）：2ビット
The compression method used:
使用された圧縮方法：
* 0: No compression.
* 0：圧縮なし。
* 1: Compressed using the WebP lossless format.
* 1：WebPロスレス形式を使用して圧縮されます。
Alpha bitstream: _Chunk Size_ bytes - 1
Alpha BitStream：_Chunk Size_バイト-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.
このオプションのチャンクには、このフレームのエンコードされたアルファデータが含まれています。「VP8L」チャンクを含むフレームには、このチャンクを含めるべきではありません。
Rationale: The transparency information is already part of the 'VP8L' Chunk.
根拠：透明性情報は、すでに「VP8L」チャンクの一部です。
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').
アルファチャネルデータは、圧縮されていない生データ（圧縮方法が「0」の場合）として保存されるか、ロスレス形式（圧縮方法が「1」の場合）を使用して圧縮されます。
* Raw data: This consists of a byte sequence of length = width * height, containing all the 8-bit transparency values in scan order.
* 生データ：これは、スキャン順序ですべての8ビットの透明度値を含む長さ=幅 *高さのバイトシーケンスで構成されています。
* 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.
* ロスレスフォーマット圧縮：バイトシーケンスは、暗黙の寸法幅x高さの圧縮画像ストリーム（セクション3で説明されている）です。つまり、この画像ストリームには、画像の寸法を説明するヘッダーが含まれていません。
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.
画像ストリームがアルファ、赤、緑、青（argb）の色の値にデコードされたら、ロスレス形式の仕様で説明されているプロセスに従って、透明情報をargb quadrupletの緑のチャネルから抽出する必要があります。
Rationale: The green channel is allowed extra transformation steps in the specification -- unlike the other channels -- that can improve compression.
理論的根拠：グリーンチャネルは、圧縮を改善できる、他のチャネルとは異なり、仕様内の追加の変換ステップを許可されています。
This chunk contains compressed bitstream data for a single frame.
このチャンクには、単一のフレームの圧縮ビットストリームデータが含まれています。
A bitstream chunk may be either (i) a 'VP8 ' Chunk, using 'VP8 ' (note the significant fourth-character space) as its FourCC, _or_ (ii) a 'VP8L' Chunk, using 'VP8L' as its FourCC.
ビットストリームチャンクは、（i） 'vp8'（vp8 ''（重要な4番目のキャラクタースペース）を4cc、_or_（ii） 'vp8l'チャンク、「vp8l」を4ccとして使用します。
The formats of' VP8 ' and 'VP8L' Chunks are as described in Sections 2.5 and 2.6, respectively.
「VP8」と「VP8L」チャンクの形式は、それぞれセクション2.5と2.6で説明されています。
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
図12：「ICCP」チャンク
Color Profile: _Chunk Size_ bytes
カラープロファイル：_Chunk Size_バイト
ICC profile.
ICCプロファイル。
This chunk MUST appear before the image data.
このチャンクは、画像データの前に表示する必要があります。
There SHOULD be at most one such chunk. If there are more such chunks, readers MAY ignore all except the first one. See the ICC specification [ICC] for details.
せいぜいそのようなチャンクがあるはずです。そのようなチャンクがもっとある場合、読者は最初のものを除くすべてを無視するかもしれません。詳細については、ICC仕様[ICC]を参照してください。
If this chunk is not present, sRGB SHOULD be assumed.
このチャンクが存在しない場合、SRGBを想定する必要があります。
Metadata can be stored in 'EXIF' or 'XMP ' Chunks.
メタデータは、「exif」または「xmp」チャンクに保存できます。
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.
各タイプのせいぜい1つのチャンク（「exif」と「xmp」）が必要です。そのようなチャンクがもっとある場合、読者は最初のものを除くすべてを無視するかもしれません。
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
図13：「exif」チャンク
Exif Metadata: _Chunk Size_ bytes
exifメタデータ：_chunk size_バイト
Image metadata in [Exif] format.
[exif]形式の画像メタデータ。
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
図14： 'xmp'チャンク
XMP Metadata: _Chunk Size_ bytes
XMPメタデータ：_Chunk Size_バイト
Image metadata in [XMP] format.
[xmp]形式の画像メタデータ。
Note that the fourth character in the 'XMP ' FourCC is an ASCII space (0x20).
「XMP」4ccの4番目の文字はASCIIスペース（0x20）であることに注意してください。
Additional guidance about handling metadata can be found in the Metadata Working Group's "Guidelines For Handling Image Metadata" [MWG].
メタデータの取り扱いに関する追加のガイダンスは、メタデータワーキンググループの「画像メタデータの取り扱いガイドライン」[MWG]に記載されています。
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_.
このセクションで説明されているチャンクのいずれかとは異なるリフチャンク（セクション2.3で説明）は、_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
* セクション2.7で説明されているように、ファイルの最後に、または
* at the end of 'ANMF' Chunks, as described in Section 2.7.1.1.
* セクション2.7.1.1で説明されているように、「ANMF」チャンクの終わりに。
Readers SHOULD ignore these chunks. Writers SHOULD preserve them in their original order (unless they specifically intend to modify these chunks).
読者はこれらのチャンクを無視する必要があります。作家は、それらを元の順序で保存する必要があります（これらのチャンクを特に変更するつもりがない限り）。
Here, we provide an overview of how a reader MUST assemble a canvas in the case of an animated image.
ここでは、アニメーション画像の場合、読者がキャンバスを組み立てる方法の概要を説明します。
The process begins with creating a canvas using the dimensions given in 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 process is repeated. This is Loop Count - 1 for nonzero Loop Count values or infinite if the Loop Count is zero.
このプロセスは、「VP8X」チャンク、キャンバスの幅で与えられた寸法を使用してキャンバスを作成することから始まります。「Anim」チャンクからのループカウントフィールドは、アニメーションプロセスが何回繰り返されるかを制御します。これはループカウントです-1ゼロループカウント値の場合は1、またはループカウントがゼロの場合は無限です。
At the beginning of each loop iteration, the canvas is filled using the background color from the 'ANIM' Chunk or an application-defined color.
各ループイテレーションの先頭に、キャンバスは「アニック」チャンクまたはアプリケーション定義の色の背景色を使用して満たされます。
'ANMF' Chunks contain individual frames given in display order. Before rendering each frame, the previous frame's Disposal method is applied.
「ANMF」チャンクには、ディスプレイの順序で与えられた個々のフレームが含まれています。各フレームをレンダリングする前に、前のフレームの廃棄方法が適用されます。
The rendering of the decoded frame begins at the Cartesian coordinates (2 * Frame X, 2 * Frame Y), using 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 are rendered onto the canvas using the Blending method.
デコードされたフレームのレンダリングは、キャンバスの左上コーナーを原点として使用して、デカルト座標（2 *フレームx、2 *フレームy）で始まります。フレーム幅マイナス1ピクセル + 1ピクセル、フレーム高さをマイナス1ピクセル + 1ピクセル + 1ピクセルは、ブレンディング方法を使用してキャンバスにレンダリングされます。
The canvas is displayed for Frame Duration milliseconds. This continues until all frames given by 'ANMF' Chunks have been displayed. A new loop iteration is then begun, or the canvas is left in its final state if all iterations have been completed.
キャンバスは、フレーム持続時間ミリ秒間表示されます。これは、「ANMF」チャンクで与えられるすべてのフレームが表示されるまで続きます。その後、すべての反復が完了した場合、新しいループ反復が開始されるか、キャンバスが最終状態に残されます。
The following pseudocode illustrates the rendering process. The notation _VP8X.field_ means the field in the 'VP8X' Chunk with the same description.
次の擬似コードは、レンダリングプロセスを示しています。表記_VP8X.Field_は、同じ説明で「VP8X」チャンクのフィールドを意味します。
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.disposeMethod
A lossy-encoded image with alpha may look as follows:
Alphaを使用した損失のある画像は、次のように見える場合があります。
RIFF/WEBP
+- VP8X (descriptions of features used)
+- ALPH (alpha bitstream)
+- VP8 (bitstream)
Figure 15: A Lossy-Encoded Image with Alpha
図15：アルファを使用した喪失したエンコード画像
A lossless-encoded image may look as follows:
ロスレスエンコード画像は次のように見える場合があります。
RIFF/WEBP
+- VP8X (descriptions of features used)
+- VP8L (lossless bitstream)
+- XYZW (unknown chunk)
Figure 16: A Lossless-Encoded Image
図16：ロスレスエンコード画像
A lossless image with an ICC profile and XMP metadata may look as follows:
ICCプロファイルとXMPメタデータを備えたロスレス画像は、次のように見える場合があります。
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
図17：ICCプロファイルとXMPメタデータを備えたロスレス画像
An animated image with Exif metadata may look as follows:
exifメタデータを備えたアニメーション画像は、次のように見える場合があります。
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
図18：Exifメタデータを備えたアニメーション画像
Note that this section is based on the documentation in the libwebp source repository [webp-lossless-src].
このセクションは、libwebpソースリポジトリ[WebPロスレス-SRC]のドキュメントに基づいていることに注意してください。
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. 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. A universal algorithm for sequential data compression [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 [webp-lossless-study].
Webp Losslessは、Argb画像のロスレス圧縮の画像形式です。ロスレスフォーマットは、アルファ値が0であるピクセルの色値を含む、ピクセル値を正確に復元します。フォーマットは、使用されたエントロピーコードなどの画像に関する統計データを保存するために、形式自体に再帰的に埋め込まれたサブ解像度画像を使用します。、空間予測因子、カラースペース変換、カラーテーブル。シーケンシャルデータ圧縮[LZ77]、プレフィックスコーディング、およびカラーキャッシュのユニバーサルアルゴリズムは、バルクデータの圧縮に使用されます。PNGよりも速くデコード速度が実証されており、今日のPNG形式[WebP-Lossless-Study]を使用して達成できるよりも25％密度の高い圧縮。
This section describes the compressed data representation of a WebP lossless image.
このセクションでは、WebPロスレス画像の圧縮データ表現について説明します。
In this section, we extensively use C programming language syntax [ISO.9899.2018] 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
このセクションでは、Cプログラミング言語構文[ISO.9899.2018]を使用して、ビットストリームを説明し、ビット、読み取りビット（n）を読むための関数の存在を想定しています。バイトは、それらを含むストリームの自然な順序で読み取られ、各バイトのビットは、重要なビットファースト順序で読み取られます。複数のビットが同時に読み取られると、整数は元の順序で元のデータから構築されます。返された整数の最も重要なビットも、元のデータの最も重要なビットです。したがって、声明
b = ReadBits(2);
is equivalent with the two statements below:
以下の2つのステートメントと同等です。
b = ReadBits(1);
b |= ReadBits(1) << 1;
We assume that 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, which is an unsigned integer consisting of 32 bits. In the code showing the behavior of the transforms, these values are codified in the following bits: alpha in bits 31..24, red in bits 23..16, green in bits 15..8, and blue in bits 7..0; however, implementations of the format are free to use another representation internally.
各色のコンポーネント（つまり、アルファ、赤、青、緑）が8ビットバイトを使用して表されると仮定します。対応するタイプをUINT8として定義します。Argbピクセル全体は、32ビットで構成される署名されていない整数であるUINT32と呼ばれるタイプで表されます。変換の動作を示すコードでは、これらの値は次のビットで成文化されています：ビット31..24のアルファ、ビット23..16、ビット15..8の緑、ビット7の青。0;ただし、形式の実装は、内部で別の表現を自由に使用できます。
Broadly, 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 contains the data required to apply the respective inverse transforms.
概して、WebPのロスレス画像には、ヘッダーデータ、変換情報、および実際の画像データが含まれています。ヘッダーには、画像の幅と高さが含まれています。WebPロスレス画像は、エントロピーエンコードされる前に、4つの異なるタイプの変換を経ることができます。BitStreamの変換情報には、それぞれの逆変換を適用するために必要なデータが含まれています。
ARGB
argb
A pixel value consisting of alpha, red, green, and blue values.
アルファ、赤、緑、青の値で構成されるピクセル値。
ARGB image
Argb画像
A two-dimensional array containing ARGB pixels.
Argbピクセルを含む2次元配列。
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).
小整数を使用してインデックス化できる色の1次元画像（WebPロスレス内で最大256）。
color transform image
色変換画像
A two-dimensional subresolution image containing data about correlations of color components.
カラーコンポーネントの相関に関するデータを含む2次元サブ解像度画像。
distance mapping
距離マッピング
Changes LZ77 distances to have the smallest values for pixels in two-dimensional proximity.
LZ77距離を変更して、2次元近接でピクセルの値が最小になります。
entropy image
エントロピー画像
A two-dimensional subresolution image indicating which entropy coding should be used in a respective square in the image, that is, each pixel is a meta prefix code.
画像内のそれぞれの正方形で使用するエントロピーコーディングを示す2次元サブ解像度画像、つまり各ピクセルはメタプレフィックスコードです。
LZ77 [LZ77]
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.
メタプレフィックステーブルの要素をインデックス化する小さな整数（最大16ビット）。
predictor image
予測因子画像
A two-dimensional subresolution image indicating which spatial predictor is used for a particular square in the image.
画像内の特定の正方形にどの空間予測因子が使用されているかを示す2次元サブ解像度画像。
prefix code
プレフィックスコード
A classic way to do entropy coding where a smaller number of bits are used for more frequent codes.
より頻繁なコードに少数のビットが使用されるエントロピーコーディングを行うための古典的な方法。
prefix coding
プレフィックスコーディング
A way to entropy code larger integers, which 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 and top to bottom), starting from the left-hand-top pixel. Once a row is completed, continue from the left-hand column of the next row.
左のハンドトップピクセルから始まるピクセルの処理順序（左から右、上から下）。行が完了したら、次の行の左側の列から続行します。
The beginning of the header has the RIFF container. This consists of the following 21 bytes:
ヘッダーの始まりには、リフ容器があります。これは、次の21バイトで構成されています。
1. String 'RIFF'.
1. 文字列「リフ」。
2. 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).
2. リフヘッダーによって制御されるチャンクの全サイズであるチャンク長の小さなエンディアンの32ビット値。通常、これはペイロードサイズに等しくなります（ファイルサイズマイナス8バイト：「リフ」識別子の4バイト、値自体を保存するための4バイト）。
3. String 'WEBP' (RIFF container name).
3. 文字列 'webp'（リフコンテナ名）。
4. String 'VP8L' (FourCC for lossless-encoded image data).
4. 文字列 'vp8l'（ロスレスエンコード画像データの4cc）。
5. A little-endian, 32-bit value of the number of bytes in the lossless stream.
5. ロスレスストリーム内のバイト数の小さなエンディアン、32ビット値。
6. 1-byte signature 0x2f.
6. 1バイト署名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:
ビットストリームの最初の28ビットは、画像の幅と高さを指定します。幅と高さは、次のように14ビットの整数としてデコードされます。
int image_width = ReadBits(14) + 1;
int image_height = ReadBits(14) + 1;
The 14-bit precision for image width and height limits the maximum size of a WebP lossless image to 16384x16384 pixels.
画像の幅と高さの14ビット精度は、WebPロスレス画像の最大サイズを16384x16384ピクセルに制限します。
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.
Alpha_is_used Bitはヒントのみであり、デコードに影響を与えるべきではありません。すべてのアルファ値が写真で255、それ以外の場合は1の場合、0に設定する必要があります。
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.
version_numberは3ビットコードであり、0に設定する必要があります。他の値はエラーとして扱う必要があります。
int version_number = ReadBits(3);
The transforms are reversible manipulations of the image data that can reduce the remaining symbolic entropy by modeling spatial and color correlations. They can make the final compression 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 used only 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 indicating the end of transforms.
画像は4種類の変換を通過できます。1ビットは、変換の存在を示します。各変換は一度だけ使用することができます。変換は、メインレベルのArgb画像にのみ使用されます。サブ解像度の画像（色変換画像、エントロピー画像、予測因子画像）には変換がなく、変換の終わりを示す0ビットでさえありません。
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.
通常、エンコーダはこれらの変換を使用して、残留画像のシャノンエントロピーを減らします。また、変換データは、エントロピーの最小化に基づいて決定できます。
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, then the next two bits specify the transform type. There are four types of transforms.
変換が存在する場合、次の2つのビットが変換タイプを指定します。変換には4つのタイプがあります。
+==========================+=====+
| Transform | Bit |
+==========================+=====+
| PREDICTOR_TRANSFORM | 0 |
+--------------------------+-----+
| COLOR_TRANSFORM | 1 |
+--------------------------+-----+
| SUBTRACT_GREEN_TRANSFORM | 2 |
+--------------------------+-----+
| COLOR_INDEXING_TRANSFORM | 3 |
+--------------------------+-----+
Table 1: Transform Types
表1：変換タイプ
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. The inverse transforms are applied in the reverse order that they are read from the bitstream, that is, last one first.
変換タイプの後に変換データが続きます。変換データには、逆変換を適用するために必要な情報が含まれ、変換タイプに依存します。逆変換は、ビットストリームから読み取られる逆の順序で適用されます。つまり、最後の1つです。
Next, we describe the transform data for different types.
次に、さまざまなタイプの変換データについて説明します。
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 green component of a pixel defines which of the 14 predictors is used within a particular block of the ARGB image. The _prediction mode_ determines the type of prediction to use. We divide the image into squares, and all the pixels in a square use the same prediction mode.
予測変換は、隣接するピクセルがしばしば相関しているという事実を活用することにより、エントロピーを減らすために使用できます。予測変換では、現在のピクセル値は既にデコードされたピクセル（スキャンライン順）から予測され、残差値（実際の予測）のみがエンコードされます。ピクセルの緑色のコンポーネントは、ArgB画像の特定のブロック内で使用される14の予測因子のどれが使用されるかを定義します。_ predictionモード_使用する予測のタイプを決定します。画像を正方形に分割し、正方形のすべてのピクセルは同じ予測モードを使用します。
The first 3 bits of prediction data define the block width and height in number of bits.
予測データの最初の3ビットは、ビット数のブロック幅と高さを定義します。
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 contains the prediction mode for each block of the image. It is a subresolution image where the green component of a pixel defines which of the 14 predictors is used for all the block_width * block_height pixels within a particular block of the ARGB image. This subresolution image is encoded using the same techniques described in Section 3.6.
変換データには、画像の各ブロックの予測モードが含まれています。これは、ピクセルの緑色のコンポーネントが、ArgB画像の特定のブロック内のすべてのblock_width * block_heightピクセルに使用される14の予測因子のうちどれが使用されるかを定義するサブ解像度画像です。このサブ解像度画像は、セクション3.6で説明したのと同じ手法を使用してエンコードされます。
The number of block columns, transform_width, is used in two-dimensional indexing. For a pixel (x, y), one can compute the respective filter block address by:
ブロック列の数、transform_widthは、2次元のインデックス作成で使用されます。ピクセル（x、y）の場合、それぞれのフィルターブロックアドレスを次のように計算できます。
int block_index = (y >> size_bits) * transform_width +
(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.
14の異なる予測モードがあります。各予測モードでは、現在のピクセル値は、値がすでに既知である1つ以上の隣接ピクセルから予測されます。
We chose the neighboring pixels (TL, T, TR, and L) of the current pixel (P) as follows:
次のように、現在のピクセル（P）の隣接ピクセル（TL、T、TR、およびL）を選択しました。
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 X
Figure 19: Neighboring Pixels of the Current Pixel (P)
図19：現在のピクセルの隣接ピクセル（P）
where TL means top-left, T means top, TR means top-right, and L means left. At the time of predicting a value for P, all O, TL, T, TR, and L pixels have already been processed, and the P pixel and all X pixels are unknown.
TLは左上を意味し、tは上部、TRは最前線、Lは左に意味があります。Pの値を予測する時点で、すべてのO、TL、T、TR、およびLピクセルはすでに処理されており、PピクセルとすべてのXピクセルは不明です。
Given the preceding neighboring pixels, the different prediction modes are defined as follows.
前の隣接するピクセルを考えると、異なる予測モードは次のように定義されます。
+======+======================================================+
| 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
表2：予測モード
Average2 is defined as follows for each ARGB component:
平均2は、各argbコンポーネントの次のように定義されます。
uint8 Average2(uint8 a, uint8 b) {
return (a + b) / 2;
}
The Select predictor is defined as follows:
選択予測子は次のように定義されています。
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;
}
}
The functions ClampAddSubtractFull and ClampAddSubtractHalf are performed for each ARGB component as follows:
関数clampaddsubtractfullおよびclampaddsubtracthalfは、次のように各argbコンポーネントに対して実行されます。
// 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);
}
There are special handling rules for some border pixels. If there is a predictor transform, regardless of the mode [0..13] for these pixels, the predicted value for the left-topmost pixel of the image is 0xff000000, all pixels on the top row are L-pixel, and all pixels on the leftmost column are T-pixel.
一部のボーダーピクセルの特別な取り扱いルールがあります。これらのピクセルのモード[0..13]に関係なく、予測変換がある場合、画像の左上ピクセルの予測値は0xff000000で、一番上の行のすべてのピクセルはLピクセルで、すべてのピクセル左端の列にはT-Pixelがあります。
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.
右端の列のピクセルのTRピクセルにアドレス指定することは例外的です。右端の列のピクセルは、境界線ではなくピクセルと同じように、モード[0..13]を使用して予測されますが、現在のピクセルと同じ行の左端のピクセルは、代わりにTRピクセルとして使用されます。
The final pixel value is obtained by adding each channel of the predicted value to the encoded residual value.
最終ピクセル値は、予測値の各チャネルをエンコードされた残差値に追加することによって取得されます。
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);
}
The goal of the color transform is to decorrelate the R, G, and B values of each pixel. The color transform keeps the green (G) value as it is, transforms the red (R) value based on the green value, and transforms the blue (B) value based on the green value and then on the red value.
色変換の目標は、各ピクセルのr、g、およびb値を切り離すことです。色の変換は、緑（g）値をそのままに保ち、緑の値に基づいて赤（r）値を変換し、緑の値に基づいて青（b）値を変換し、次に赤い値に変換します。
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.
予測変換の場合と同様に、最初に画像はブロックに分割され、ブロック内のすべてのピクセルで同じ変換モードが使用されます。各ブロックには、3種類の色変換要素があります。
typedef struct {
uint8 green_to_red;
uint8 green_to_blue;
uint8 red_to_blue;
} ColorTransformElement;
The actual color transform 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 the color transform. The inverse color transform then is just adding those deltas.
実際の色変換は、色変換Deltaを定義することによって行われます。Color Transform Deltaは、特定のブロック内のすべてのピクセルで同じであるColor Transformelementに依存します。デルタは、色変換中に差し引かれます。逆色の変換は、それらのデルタを追加するだけです。
The color transform function is defined as follows:
色変換関数は次のように定義されます。
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 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:
Color TransformDeltaは、3.5フィックスのポイント番号と署名された8ビットRGBカラーチャネル（C）[-128..127]を表す署名された8ビット整数を使用して計算され、次のように定義されます。
int8 ColorTransformDelta(int8 t, int8 c) {
return (t * c) >> 5;
}
A conversion from the 8-bit unsigned representation (uint8) to the 8-bit signed one (int8) is required before calling ColorTransformDelta(). The signed value should be interpreted as an 8-bit two's complement number (that is: uint8 range [128..255] is mapped to the [-128..-1] range of its converted int8 value).
Color TransformDelta（）を呼び出す前に、8ビットの符号付き表現（UINT8）から8ビットの署名付き（int8）への変換が必要です。署名された値は、8ビット2の補数数（つまり、UINT8範囲[128..255]が[-128 ..-1]の変換されたINT8値の範囲にマッピングされる）として解釈する必要があります。
The multiplication is to be done using more precision (with at least 16-bit precision). The sign extension property of the shift operation does not matter here; only the lowest 8 bits are used from the result, and in these bits, the sign extension shifting and unsigned shifting are consistent with each other.
乗算は、より精度を使用して行われます（少なくとも16ビット精度で）。ここでは、シフト操作の標識拡張プロパティは関係ありません。結果から最も低い8ビットのみが使用され、これらのビットでは、標識拡張シフトと署名されていないシフトが互いに一致しています。
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:
次に、色変換データの内容について説明して、デコードが逆色変換を適用して元の赤と青の値を回復できるようにします。カラー変換データの最初の3ビットには、予測子変換のように、ビット数の画像ブロックの幅と高さが含まれています。
int size_bits = ReadBits(3) + 2;
int block_width = 1 << size_bits;
int block_height = 1 << size_bits;
The remaining part of the color transform data contains ColorTransformElement instances, corresponding to each block of the image. Each ColorTransformElement 'cte' is treated as a pixel in a subresolution image 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 Transformelementインスタンスが含まれています。各カラートランスフォームレメント「CTE」は、アルファコンポーネントが255、赤いコンポーネントがCTE.RED_TO_BLUE、緑色のコンポーネントはCTE.GREEN_TO_BLUEであり、青色コンポーネントはCTE.GREEN_TO_REDです。
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 adding ColorTransformElement values to the red and blue channels. The alpha and green channels are left as is.
デコード中、ブロックの色変換インスタンスがデコードされ、逆色変換がピクセルのARGB値に適用されます。前述のように、その逆色の変換は、赤と青のチャネルに色変換値を追加するだけです。アルファと緑のチャネルはそのまま残っています。
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;
}
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 the red and blue values. There is no data associated with this transform. The decoder applies the inverse transform as follows:
Subtract Green変換は、各ピクセルの赤と青の値から緑の値を減算します。この変換が存在する場合、デコーダーは赤と青の両方の値に緑の値を追加する必要があります。この変換に関連するデータはありません。デコーダーは、次のように逆変換を適用します。
void AddGreenToBlueAndRed(uint8 green, uint8 *red, uint8 *blue) {
*red = (*red + green) & 0xff;
*blue = (*blue + green) & 0xff;
}
This transform is redundant, as it can be modeled using the color transform, but since there is no additional data here, the subtract green transform can be coded using fewer bits than a full-blown color 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.)
一意のピクセル値があまりない場合、カラーインデックスアレイを作成し、アレイのインデックスでピクセル値を置き換える方が効率的です。カラーインデックスの変換はこれを達成します。（WebP Losslessのコンテキストでは、WebPロスレスエンコーディング：カラーキャッシュには同様だがダイナミックな概念が存在するため、これをパレット変換と呼びません。）
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, and all red and blue values are set to 0.
カラーインデックス化変換は、画像内の一意のArgB値の数をチェックします。その数値がしきい値（256）を下回っている場合、それらのargb値の配列を作成し、ピクセル値を対応するインデックスに置き換えるために使用されます。ピクセルのグリーンチャネルはインデックスに置き換えられます。255に設定され、すべての赤と青の値は0に設定されています。
The transform data contains the color table size and the entries in the color table. The decoder reads the color indexing transform data as follows:
変換データには、カラーテーブルのサイズとカラーテーブルのエントリが含まれています。デコーダーは、次のように色インデックスの変換データを読み取ります。
// 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. The color table can be obtained by reading an image, without the RIFF header, image size, and transforms, assuming the height of 1 pixel and the 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.
カラーテーブルは、画像ストレージ形式自体を使用して保存されます。カラーテーブルは、1ピクセルの高さとcolor_table_sizeの幅を想定して、リフヘッダー、画像サイズ、変換なしで画像を読み取ることで取得できます。カラーテーブルは、画像エントロピーを削減するために常に減算コード化されています。パレットの色のデルタには、通常、色自体よりもはるかに少ないエントロピーが含まれており、小さな画像の大幅な節約につながります。デコードでは、各ARGBコンポーネントによって以前のカラーコンポーネント値を個別に追加し、結果の最小の8ビットを保存することにより、カラーテーブルのすべての最終色を取得できます。
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.
画像の逆変換は、単にピクセル値（カラーテーブルのインデックス）を実際のカラーテーブル値に置き換えることです。インデックスは、Argb色の緑色のコンポーネントに基づいて行われます。
// 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).
インデックスがcolor_table_size以上の場合、argb色の値は0x00000000（透明な黒）に設定する必要があります。
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.
カラーテーブルが小さい場合（16色以下）、数ピクセルが単一のピクセルにバンドルされます。ピクセルバンドリングは、いくつかの（2、4、または8）ピクセルを単一のピクセルにパックし、それぞれ画像幅を減らします。
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.
Pixelバンドルは、隣接するピクセルのより効率的なジョイント分布エントロピーコーディングを可能にし、エントロピーコードに算術コーディングのような利点を提供しますが、一意の値が16以下の場合にのみ使用できます。
color_table_size specifies how many pixels are combined:
color_table_size結合されたピクセルの数を指定します。
+==================+==================+
| 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 Mapping
表3：カラーテーブルサイズからバンドルされたピクセルビット幅マッピング
width_bits has a value of 0, 1, 2, or 3. A value of 0 indicates no pixel bundling is to be done for the image. A value of 1 indicates that two pixels are combined, and each pixel has a range of [0..15]. A value of 2 indicates that four pixels are combined, and each pixel has a range of [0..3]. A value of 3 indicates that eight pixels are combined, and each pixel has a range of [0..1], that is, a binary value.
width_bitsの値は0、1、2、または3です。値0の値は、画像に対して行われるピクセルバンドリングがないことを示します。1の値は、2つのピクセルが組み合わされており、各ピクセルには[0..15]の範囲があることを示します。2の値は、4つのピクセルが組み合わされており、各ピクセルには[0..3]の範囲があることを示します。3の値は、8つのピクセルが組み合わされており、各ピクセルには[0..1]の範囲、つまりバイナリ値があることを示します。
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, and a green value at x + 1 is positioned into the 4 most significant bits of the green value at x / 2.
* width_bits = 1：x = 2k + 0のすべてのx値について、xの緑の値はx / 2の緑の値の4つの最も有意なビットに配置され、x + 1の緑の値は4 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, and green values at x + 1 to x + 3 are positioned in order to the more significant bits of the green value at x / 4.
* width_bits = 2：x = 4k + 0のすべてのx値について、xの緑の値はx / 4のグリーン値の2つの最も重要なビットに、x + 1からx + 3の緑の値に配置されます。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, and green values at x + 1 to x + 7 are positioned in order to the more significant bits of the green value at x / 8.
* width_bits = 3：x = 8k + 0すべてのx値の場合、xの緑の値はx / 8の緑の値の最小ビットに、x + 1からx + 7の緑の値は配置されますx / 8での緑の値のより重要なビットに。
After reading this transform, image_width is subsampled by width_bits. This affects the size of subsequent transforms. The new size can be calculated using DIV_ROUND_UP, as defined in Section 3.5.1.
この変換を読んだ後、image_widthはwidth_bitsでサブサンプリングされます。これは、後続の変換のサイズに影響します。セクション3.5.1で定義されているように、新しいサイズはdiv_round_upを使用して計算できます。
image_width = DIV_ROUND_UP(image_width, 1 << width_bits);
Image data is an array of pixel values in scan-line order.
画像データは、スキャンラインの順序でピクセル値の配列です。
We use image data in five different roles:
5つの異なる役割で画像データを使用します。
1. ARGB image: Stores the actual pixels of the image.
1. Argb画像：画像の実際のピクセルを保存します。
2. Entropy image: Stores the meta prefix codes (see "Decoding of Meta Prefix Codes" (Section 3.7.2.2)).
2. エントロピー画像：メタプレフィックスコードを保存します（「メタプレフィックスコードのデコード」（セクション3.7.2.2）を参照）。
3. Predictor image: Stores the metadata for the predictor transform (see "Predictor Transform" (Section 3.5.1)).
3. 予測因子画像：予測変換のメタデータを保存します（「予測変換」（セクション3.5.1）を参照）。
4. Color transform image: Created by ColorTransformElement values (defined in "Color Transform" (Section 3.5.2)) for different blocks of the image.
4. 画像の色変換画像：画像のさまざまなブロックの色変換値（「色変換」（セクション3.5.2）で定義）によって作成されます。
5. 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)).
5. 色インデックス画像：色インデックス変換のメタデータを保存するColor_table_size（最大256 Argb値）のサイズの配列（「色インデックス化変換」（セクション3.5.4）を参照）。
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.
画像は、最初に固定サイズのブロックのセット（通常16x16ブロック）に分割されます。これらの各ブロックは、独自のエントロピーコードを使用してモデル化されています。また、いくつかのブロックが同じエントロピーコードを共有する場合があります。
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.
根拠：エントロピーコードを保存すると、コストがかかります。統計的に類似したブロックがエントロピーコードを共有し、そのコードを1回だけ保存する場合、このコストを最小限に抑えることができます。たとえば、エンコーダーは、統計的特性を使用してクラスタリングするか、画像をエンコードするのに必要なビットの全体の量を減らすと、ランダムに選択されたクラスターのペアを繰り返し結合することにより、同様のブロックを見つけることができます。
Each pixel is encoded using one of the three possible methods:
各ピクセルは、可能な3つの方法のいずれかを使用してエンコードされます。
1. Prefix-coded literals: Each channel (green, red, blue, and alpha) is entropy-coded independently.
1. プレフィックスコード化されたリテラル：各チャネル（緑、赤、青、アルファ）は、独立してエントロピーコードされています。
2. LZ77 backward reference: A sequence of pixels are copied from elsewhere in the image.
2. LZ77後方参照：画像の他の場所から一連のピクセルがコピーされます。
3. Color cache code: Using a short multiplicative hash code (color cache index) of a recently seen color.
3. カラーキャッシュコード：最近見られた色の短い乗算ハッシュコード（色キャッシュインデックス）を使用します。
The following subsections describe each of these in detail.
次のサブセクションでは、これらのそれぞれについて詳しく説明しています。
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.7.2.3を参照してください。
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).
* 距離コードは、以前に見られたピクセルの位置を示す数字であり、そこからピクセルをコピーすることです。正確なマッピングについては、以下に説明します（セクション3.6.2.2.1）。
The length and distance values are stored using *LZ77 prefix coding*.
長さと距離の値は、 *LZ77プレフィックスコーディング *を使用して保存されます。
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).
LZ77プレフィックスコーディングは、大きな整数値を2つの部分に分割します：_prefix code_と_extra bits_。プレフィックスコードはエントロピーコードを使用して保存されますが、追加ビットはそのまま保存されます（エントロピーコードなし）。
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 denotes 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.
注：最大後方参照長は4096に制限されています。したがって、最初の24のプレフィックスコード（それぞれの追加ビット付き）のみが長さの値に対して意味があります。ただし、距離値の場合、40のプレフィックスコードはすべて有効です。
+=================+=============+============+
| 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 Mapping
表4：プレフィックスコードと追加ビットマッピングへの値
The pseudocode to obtain a (length or distance) value from the prefix code is as follows:
プレフィックスコードから（長さまたは距離）値を取得するための擬似コードは次のとおりです。
if (prefix_code < 4) {
return prefix_code + 1;
}
int extra_bits = (prefix_code - 2) >> 1;
int offset = (2 + (prefix_code & 1)) << extra_bits;
return offset + ReadBits(extra_bits) + 1;
As noted previously, a distance code is a number indicating the position of a previously seen pixel, from which the pixels are to be copied. This subsection defines the mapping between a distance code and the position of a previous pixel.
前述のように、距離コードは、以前に見られたピクセルの位置を示す数字であり、そこからピクセルをコピーすることです。このサブセクションでは、距離コードと以前のピクセルの位置との間のマッピングを定義します。
Distance codes larger than 120 denote the pixel distance in scan-line order, offset by 120.
120を超える距離コードは、スキャンライン順序でピクセル距離を示し、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:
最小の距離コード[1..120]は特別であり、現在のピクセルの近所に予約されています。この近所は120ピクセルで構成されています。
* 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].
* 現在のピクセルから1〜7行で、左側に最大8列または現在のピクセルの右側に最大7列にあるピクセル[合計ピクセル= 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].
* 現在のピクセルと同じ行にあるピクセルは、現在のピクセルの左側に最大8列です[8そのようなピクセル]。
The mapping between distance code distance_code and the neighboring pixel offset (xi, yi) is as follows:
距離コードdistance_codeと隣接するピクセルオフセット（xi、yi）の間のマッピングは次のとおりです。
(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
図20：隣接するピクセルオフセットマッピングへの距離コード
For example, the distance code 1 indicates an offset of (0, 1) for the neighboring pixel, that is, the pixel above the current pixel (0 pixel difference in the X direction and 1 pixel difference in the Y direction). Similarly, the distance code 3 indicates the top-left pixel.
たとえば、距離コード1は、隣接するピクセルの（0、1）のオフセット、つまり現在のピクセルの上のピクセル（X方向の0ピクセルの差、Y方向の1ピクセルの差）のオフセットを示します。同様に、距離コード3は、左上ピクセルを示します。
The decoder can convert a distance code distance_code to a scan-line order distance dist as follows:
デコーダーは、距離コード距離_codeを次のようにスキャンライン順序距離距離に変換できます。
(xi, yi) = distance_map[distance_code - 1]
dist = xi + yi * image_width
if (dist < 1) {
dist = 1
}
where distance_map is the mapping noted above, and image_width is the width of the image in pixels.
ここで、distance_mapは上記のマッピングであり、image_widthはピクセルの画像の幅です。
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 the other two methods (described in Sections 3.6.2.1 and 3.6.2.2).
理論的根拠：このように、最近使用された色は、他の2つの方法（セクション3.6.2.1および3.6.2.2で説明）を使用してそれらを放射するよりも効率的に参照できる場合があります。
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:
カラーキャッシュコードは次のように保存されます。まず、色キャッシュが使用されているかどうかを示す1ビット値があります。このビットが0の場合、カラーキャッシュコードは存在せず、緑色のシンボルと長さのプレフィックスコードをデコードするプレフィックスコードには送信されません。ただし、このビットが1の場合、色キャッシュサイズが次に読まれます。
int color_cache_code_bits = ReadBits(4);
int color_cache_size = 1 << color_cache_code_bits;
color_cache_code_bits defines the size of the color cache (1 << color_cache_code_bits). The range of allowed values for color_cache_code_bits is [1..11]. Compliant decoders MUST indicate a corrupted bitstream for other values.
color_cache_code_bits色キャッシュのサイズ（1 << color_cache_code_bits）を定義します。color_cache_code_bitsの許容値の範囲は[1..11]です。準拠したデコーダーは、他の値に対して破損したビットストリームを示す必要があります。
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.
カラーキャッシュは、サイズのcolor_cache_sizeの配列です。各エントリは1つのArgb色を保存します。色は、（0x1E35A7BD *カラー）>>（32 -CACHE_CODE_BITS）でインデックスを作成することで見上げられます。カラーキャッシュでは1つのルックアップのみが行われます。紛争解決はありません。
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.
画像のデコードまたはエンコードの開始では、すべての色キャッシュ値のすべてのエントリがゼロに設定されます。色キャッシュコードは、デコード時にこの色に変換されます。カラーキャッシュの状態は、後方参照またはリテラルとして生成され、ストリームに表示される順序でキャッシュにすべてのピクセルを挿入することによって維持されます。
Most of the data is coded using a canonical prefix code [Huffman]. Hence, the codes are transmitted by sending the _prefix code lengths_, as opposed to the actual _prefix codes_.
ほとんどのデータは、標準的なプレフィックスコード[Huffman]を使用してコーディングされます。したがって、実際の_prefixコード_とは対照的に、コードは_prefixコード長さ_を送信することにより送信されます。
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 better compression.
理論的根拠：画像の領域が異なる場合があります。したがって、異なるエントロピーコードを使用できるようにすると、より柔軟性と潜在的に優れた圧縮が提供されます。
The encoded image data consists of several parts:
エンコードされた画像データは、いくつかの部分で構成されています。
1. Decoding and building the prefix codes.
1. プレフィックスコードのデコードと構築。
2. Meta prefix codes.
2. メタプレフィックスコード。
3. Entropy-coded image data.
3. エントロピーコード化された画像データ。
For any given pixel (x, y), there is a set of five prefix codes associated with it. These codes are (in bitstream order):
特定のピクセル（x、y）には、それに関連付けられた5つのプレフィックスコードのセットがあります。これらのコードは（ビットストリーム順序で）です。
* *Prefix code #1*: Used for green channel, backward-reference length, and color cache.
* *プレフィックスコード＃1*：緑色のチャネル、後方参照の長さ、色キャッシュに使用されます。
* *Prefix code #2, #3, and #4*: Used for red, blue, and alpha channels, respectively.
* *プレフィックスコード＃2、＃3、および＃4*：それぞれ赤、青、およびアルファチャネルに使用されます。
* *Prefix code #5*: Used for backward-reference distance.
* *プレフィックスコード＃5*：後方参照距離に使用されます。
From here on, we refer to this set as a *prefix code group*.
ここから、このセットを *プレフィックスコードグループ *と呼びます。
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.
プレフィックスコードの長さは、2つの方法でコーディングできます。使用される方法は、1ビット値で指定されます。
* If this bit is 1, it is a _simple code length code_.
* このビットが1の場合、それは_シンプルコード長コード_です。
* If this bit is 0, it is a _normal code length code_.
* このビットが0の場合、それは_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. The described tree must be a complete binary tree. A single leaf node is considered a complete binary tree and can be encoded using either the simple code length code or the normal code length code. When coding a single leaf node using the _normal code length code_, all but one code length are zeros, and the single leaf node value is marked with the length of 1 -- even when no bits are consumed when that single leaf node tree is used.
どちらの場合も、まだストリームの一部である未使用のコードの長さがあります。これは非効率的かもしれませんが、形式で許可されています。説明されているツリーは完全なバイナリツリーでなければなりません。単一のリーフノードは、完全なバイナリツリーと見なされ、単純なコード長コードまたは通常のコード長コードのいずれかを使用してエンコードできます。_normal code length code_を使用して単一のリーフノードをコーディングする場合、1つのコード長を除くすべてがゼロであり、単一のリーフノード値は1の長さでマークされます - その単一のリーフノードツリーを使用するときにビットが消費されない場合でも。
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.
このバリアントは、1つまたは2つのプレフィックス記号のみがコード長の範囲[0..255]にある場合、特別なケースで使用されます。他のすべてのプレフィックスコード長は暗黙的にゼロです。
The first bit indicates the number of symbols:
最初のビットは、シンボルの数を示します。
int num_symbols = ReadBits(1) + 1;
The 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.
以下はシンボル値です。この最初のシンボルは、IS_FIRST_8BITSの値に応じて、1ビットまたは8ビットを使用してコーディングされます。範囲はそれぞれ[0..1]または[0..255]です。2番目のシンボルは、存在する場合、常に範囲[0..255]にあり、8ビットを使用してコード化されていると想定されます。
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.
2つのシンボルは異なるはずです。重複したシンボルは許可されていますが、非効率的です。
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, as empty prefix codes can be coded as those containing a single symbol 0.
注：別の特別なケースは、_all_プレフィックスコードの長さが_zeros_（空のプレフィックスコード）である場合です。たとえば、後方参照がない場合、距離のプレフィックスコードは空になる可能性があります。同様に、同じメタプレフィックスコード内のすべてのピクセルがカラーキャッシュを使用して生成される場合、アルファ、赤、青のプレフィックスコードは空になる可能性があります。ただし、空のプレフィックスコードは単一のシンボル0を含むものとしてコード化できるため、このケースは特別な処理を必要としません。
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.
プレフィックスコードのコード長は8ビットに収まり、次のように読み取られます。まず、num_code_lengthsはコードの長さの数を指定します。
int num_code_lengths = 4 + ReadBits(4);
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.
コードの長さは、それ自体がプレフィックスコードを使用してエンコードされています。低レベルのコード長、code_length_code_lengths、最初に読む必要があります。これらのcode_length_code_lengthsの残りの部分（kcodelengthcodeordorの順序による）は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:
次に、readbits（1）== 0の場合、各シンボルタイプ（a、r、g、b、および距離）の異なる読み取り記号（max_symbol）の最大数がアルファベットサイズに設定されます。
* G channel: 256 + 24 + color_cache_size
* Gチャネル：256 + 24 + color_cache_size
* Other literals (A, R, and B): 256
* その他のリテラル（a、r、b）：256
* Distance code: 40
* 距離コード：40
Otherwise, it is 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.
MAX_SYMBOLがシンボルタイプのアルファベットのサイズよりも大きい場合、ビットストリームは無効です。
A prefix table is then built from code_length_code_lengths and used to read up to max_symbol code lengths.
プレフィックステーブルは、code_length_code_lengthsから構築され、max_symbolコードの長さまで読み取るために使用されます。
* Code [0..15] indicates literal code lengths.
* コード[0..15]は、リテラルコードの長さを示します。
- Value 0 means no symbols have been coded.
- 値0は、記号がコード化されていないことを意味します。
- Values [1..15] indicate the bit length of the respective code.
- 値[1..15]は、それぞれのコードのビット長を示します。
* 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.
* コード16は、以前の非ゼロ値[3..6]を繰り返します。つまり、3 + readbits（2）回数を繰り返します。ゼロ以外の値が放出される前にコード16が使用される場合、8の値が繰り返されます。
* Code 17 emits a streak of zeros of length [3..10], that is, 3 + ReadBits(3) times.
* コード17は、長さのゼロの縞模様[3..10]、つまり3 + readbits（3）回を放出します。
* Code 18 emits a streak of zeros of length [11..138], that is, 11 + ReadBits(7) times.
* コード18は、長さのゼロの縞模様[11..138]、つまり11 + readbits（7）回を放出します。
Once code lengths are read, a prefix code for each symbol type (A, R, G, B, and distance) is formed using their respective alphabet sizes.
コードの長さが読み取られると、それぞれのアルファベットサイズを使用して、各シンボルタイプ（a、r、g、b、および距離）のプレフィックスコードが形成されます。
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プレフィックスcodes_は、画像のさまざまな部分で使用するプレフィックスコードを識別するインデックスです。
Meta prefix codes may be used _only_ when the image is being used in the role (Section 3.6.1) of an _ARGB image_.
_ARGB Image_の役割（セクション3.6.1）で画像が使用されている場合、メタプレフィックスコードは_only_を使用できます。
There are two possibilities for the meta prefix codes, indicated by a 1-bit value:
メタプレフィックスコードには、1ビット値で示される2つの可能性があります。
* If this bit is zero, there is only one meta prefix code used everywhere in the image. No more data is stored.
* このビットがゼロの場合、画像内のどこでも使用されるメタプレフィックスコードは1つだけです。これ以上のデータは保存されません。
* 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 red and green components of a pixel define a 16-bit meta prefix code used in a particular block of the ARGB image.
ピクセルの赤と緑のコンポーネントは、ARGB画像の特定のブロックで使用される16ビットメタプレフィックスコードを定義します。
The entropy image defines which prefix codes are used in different parts of the image.
エントロピー画像は、画像のさまざまな部分で使用されるプレフィックスコードを定義します。
The first 3 bits contain the prefix_bits value. The dimensions of the entropy image are derived from prefix_bits:
最初の3ビットには、プレフィックス_bits値が含まれています。エントロピー画像の寸法は、プレフィックス_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);
where DIV_ROUND_UP is as defined in Section 3.5.1.
ここで、div_round_upはセクション3.5.1で定義されています。
The next bits contain an entropy image of width prefix_image_width and height prefix_image_height.
次のビットには、幅prefix_image_widthとheight prefix_image_heightのエントロピー画像が含まれています。
The number of prefix code groups in the ARGB image can be obtained by finding the _largest meta prefix code_ from the entropy image:
Argb画像のプレフィックスコードグループの数は、エントロピー画像から_lestgest MetaプレフィックスCode_を見つけることで取得できます。
int num_prefix_groups = max(entropy image) + 1;
where max(entropy image) indicates the largest prefix code stored in the entropy image.
ここで、MAX（エントロピー画像）は、エントロピー画像に保存されている最大のプレフィックスコードを示します。
As each prefix code group contains five prefix codes, the total number of prefix codes is:
各プレフィックスコードグループには5つのプレフィックスコードが含まれているため、プレフィックスコードの総数は次のとおりです。
int num_prefix_codes = 5 * num_prefix_groups;
Given a pixel (x, y) in the ARGB image, we can obtain the corresponding prefix codes to be used as follows:
Argb画像にピクセル（x、y）が与えられた場合、次のように使用する対応するプレフィックスコードを取得できます。
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];
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_prefix_groups).
5つのプレフィックスコードのセットを表すプレフィックスコデグロング構造の存在を想定しています。また、prefix_code_groupsは、[size num_prefix_groups）のプレフィックスコデグロングの配列です。
The decoder then uses prefix code group prefix_group to decode the pixel (x, y), as explained in Section 3.7.2.3.
デコーダーは、セクション3.7.2.3で説明されているように、プレフィックスコードグループPrefix_Groupを使用してピクセル（x、y）をデコードします。
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.
画像の現在の位置（x、y）の場合、デコーダーは最初に対応するプレフィックスコードグループを識別します（最後のセクションで説明したように）。プレフィックスコードグループを考えると、ピクセルは次のように読み取られてデコードされます。
Next, read symbol S from the bitstream using prefix code #1.
次に、プレフィックスコード＃1を使用して、ビットストリームからシンボルSを読み取ります。
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.
Sは0〜（256 + 24 + color_cache_size -1）の範囲の整数であることに注意してください。Color_cache_sizeの詳細については、セクション3.6.2.3を参照してください。
The interpretation of S depends on its value:
Sの解釈は、その価値に依存します。
1. If S < 256
1. s <256の場合
i. Use S as the green component.
i. sを緑色のコンポーネントとして使用します。
ii. Read red from the bitstream using prefix code #2.
ii。プレフィックスコード＃2を使用して、ビットストリームから赤を読み取ります。
iii. Read blue from the bitstream using prefix code #3.
iii。プレフィックスコード＃3を使用して、ビットストリームから青を読み取ります。
iv. Read alpha from the bitstream using prefix code #4.
IV。プレフィックスコード＃4を使用して、ビットストリームからアルファを読んでください。
2. If S >= 256 & S < 256 + 24
2. s> = 256＆s <256 + 24の場合
i. Use S - 256 as a length prefix code.
i. 長さのプレフィックスコードとしてS -256を使用します。
ii. Read extra bits for the length from the bitstream.
ii。ビットストリームから長さのビットを追加してください。
iii. Determine backward-reference length L from length prefix code and the extra bits read.
iii。長さのプレフィックスコードから後方参照の長さlを決定し、追加ビットを読み取ります。
iv. Read the distance prefix code from the bitstream using prefix code #5.
IV。プレフィックスコード＃5を使用して、ビットストリームから距離プレフィックスコードをお読みください。
v. Read extra bits for the distance from the bitstream.
v. ビットストリームからの距離のために余分なビットを読んでください。
vi. Determine backward-reference distance D from the distance prefix code and the extra bits read.
vi。距離プレフィックスコードと追加ビットの読み取りから後方参照距離dを決定します。
vii. Copy L pixels (in scan-line order) from the sequence of pixels starting at the current position minus D pixels.
vii。現在の位置からdピクセルを差し引いて始まるピクセルのシーケンスから（スキャンライン順）をコピーします。
3. If S >= 256 + 24
3. s> = 256 + 24の場合
i. Use S - (256 + 24) as the index into the color cache.
i. s-（256 + 24）をカラーキャッシュへのインデックスとして使用します。
ii. Get ARGB color from the color cache at that index.
ii。そのインデックスで色キャッシュからargb色を取得します。
Below is a view into the format in Augmented Backus-Naur Form [RFC5234] [RFC7405]. It does not cover all details. The end-of-image (EOI) is only implicitly coded into the number of pixels (image_width * image_height).
以下は、拡張されたBackus-Naurフォーム[RFC5234] [RFC7405]の形式のビューです。すべての詳細をカバーするわけではありません。イメージの終了（EOI）は、暗黙的にピクセル数（Image_Width * Image_Height）にのみコード化されます。
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.
*要素は、要素を0回以上繰り返すことができることを意味することに注意してください。5電位は、要素が正確に5回繰り返されることを意味します。％bはバイナリ値を表します。
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-image
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-image
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)
The following is a possible example sequence:
以下は、可能な例のシーケンスです。
RIFF-header image-size %b1 subtract-green-tx
%b1 predictor-tx %b0 color-cache-info
%b0 prefix-codes lz77-coded-image
Implementations of this format face security risks, such as 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) as part of the demuxing and decoding process. In particular, implementations reading 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 may result in arbitrary code execution, information leakage (memory layout and contents), or crashes and thereby allow a device to be compromised or cause a denial of service to an application using the format [mitre-libwebp] [issues-security].
このフォーマットの実装は、整数のオーバーフロー、アウトバウンドの読み取り、ヒープとスタックの両方に読み書きされ、無認定データの使用、ヌルポインターの宣言、リソース（ディスクまたはメモリ）疲労、および拡張リソースの使用（長期走行）の両方に読み書きされ、書き込み（長期走行）などのセキュリティリスクに直面しています。時間）デンキングおよびデコードプロセスの一部として。特に、この形式を読む実装は、不明でおそらく安全でないソース（クライアント（Webブラウザーや電子メールクライアントなど）とサーバー（アップロードされた画像を受け入れるアプリケーション）の両方から入力を取得する可能性があります。これらは、任意のコードの実行、情報漏れ（メモリレイアウトとコンテンツ）、またはクラッシュする可能性があり、それによってデバイスを侵害したり、[Mitre-LibWebp] [Issues-Security]を使用してアプリケーションにサービスの拒否を引き起こす可能性があります。
The format does not employ "active content" but does allow metadata (for example, [XMP] and [Exif]) and custom chunks to be embedded in a file. Applications that interpret these chunks may be subject to security considerations for those formats.
この形式は「アクティブなコンテンツ」を使用していませんが、メタデータ（[XMP]および[exif]）とカスタムチャンクをファイルに埋め込むことができます。これらのチャンクを解釈するアプリケーションは、これらの形式のセキュリティ上の考慮事項の対象となる場合があります。
The format is defined using little-endian byte ordering (see Section 3.1 of [RFC2781]), but demuxing and decoding are possible on platforms using 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) are required for decoding of 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.
この形式は、リトルエンディアンバイトの順序付けを使用して定義されます（[RFC2781]のセクション3.1を参照）が、適切な変換で異なる順序を使用してプラットフォームでは、デンキングとデコードが可能です。コンテナはリフに基づいており、ユーザー定義のチャンクを介して拡張を許可しますが、画像のデコードにはコンテナ形式（セクション2）で定義されたチャンクを超えて拡張機能があります。これらは確定されていますが、形式の初期段階で拡張されたため、一部の年上の読者はロスレスまたはアニメーション画像デコードをサポートしていない場合があります。
IANA has registered the 'image/webp' media type [RFC2046].
IANAは「Image/Webp」メディアタイプ[RFC2046]を登録しています。
This section contains the media type registration details per [RFC6838].
このセクションには、[RFC6838]ごとにメディアタイプの登録の詳細が含まれています。
Type name:
タイプ名：
image
画像
Subtype name:
サブタイプ名：
webp
webp
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
Binary. The Base64 encoding [RFC4648] should be used on transports that cannot accommodate binary data directly.
バイナリ。[RFC4648]をエンコードするbase64は、バイナリデータに直接対応できないトランスポートに使用する必要があります。
Security considerations:
セキュリティ上の考慮事項：
See RFC 9649, Section 4.
RFC 9649、セクション4を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
See RFC 9649, Section 5.
RFC 9649、セクション5を参照してください。
Published specification:
公開された仕様：
RFC 9649
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
n/a
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
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').
最初の4バイトは0x52、0x49、0x46、0x46（ 'riff'）で、その後に「リフ」チャンクサイズの4バイトが続きます。次の7バイトは、0x57、0x45、0x42、0x50、0x56、0x50、0x38（ 'webpvp8'）です。
File extension(s):
ファイル拡張子：
webp
webp
Apple Uniform Type Identifier:
リンゴの均一な型識別子：
org.webmproject.webp conforms to public.image
org.webmproject.webpはpublic.imageに準拠しています
Object Identifiers:
オブジェクト識別子：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
James Zern <jzern@google.com>
James Zern <jzern@google.com>
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
N/A
n/a
Author:
著者：
James Zern <jzern@google.com>
James Zern <jzern@google.com>
Change controller:
Change Controller：
IETF
IETF
[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>.
[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>.
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