rfc9649.original.xml   rfc9649.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
submissionType="IETF" info" consensus="true" docName="draft-zern-webp-15" number="9649" ipr="trust2009
category="info" 02" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs
consensus="true" ="true" sortRefs="true" version="3">
docName="draft-zern-webp-15"
ipr="trust200902"
obsoletes=""
updates=""
xml:lang="en"
tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true"
version="3">
<front> <front>
<title>WebP Image Format</title> <title abbrev="WebP Image Format">WebP Image Format</title>
<seriesInfo name="Internet-Draft" value="draft-zern-webp-15" /> <seriesInfo name="RFC" value="9649"/>
<seriesInfo status="informational" name="" value="draft-zern-webp-15" />
<author fullname="James Zern" initials="J." surname="Zern"> <author fullname="James Zern" initials="J." surname="Zern">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<postal> <postal>
<street>1600 Amphitheatre Parkway</street> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
skipping to change at line 54 skipping to change at line 40
<address> <address>
<email>pascal.massimino@gmail.com</email> <email>pascal.massimino@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jyrki Alakuijala" initials="J." surname="Alakuijala"> <author fullname="Jyrki Alakuijala" initials="J." surname="Alakuijala">
<organization>Google LLC</organization> <organization>Google LLC</organization>
<address> <address>
<email>jyrki.alakuijala@gmail.com</email> <email>jyrki.alakuijala@gmail.com</email>
</address> </address>
</author> </author>
<date year="2024" month="April"/> <date year="2024" month="September"/>
<area>art</area> <area>art</area>
<keyword>VP8</keyword> <keyword>VP8</keyword>
<keyword>WebP</keyword> <keyword>WebP</keyword>
<abstract> <abstract>
<t>This document defines the WebP image format and registers a media type <t>This document defines the WebP image format and registers a media type
supporting its use.</t> supporting its use.</t>
</abstract> </abstract>
</front> </front>
skipping to change at line 85 skipping to change at line 73
<xref target="GIF-spec">Graphics Interchange Format (GIF)</xref>.</t> <xref target="GIF-spec">Graphics Interchange Format (GIF)</xref>.</t>
<t>WebP consists of two compression algorithms used to reduce the size of <t>WebP consists of two compression algorithms used to reduce the size of
image pixel data, including alpha (transparency) information. Lossy image pixel data, including alpha (transparency) information. Lossy
compression is achieved using VP8 intra-frame encoding <xref compression is achieved using VP8 intra-frame encoding <xref
target="RFC6386"/>. The <xref target="webp-lossless">lossless target="RFC6386"/>. The <xref target="webp-lossless">lossless
algorithm</xref> stores and restores the pixel values exactly, algorithm</xref> stores and restores the pixel values exactly,
including the color values for fully transparent pixels. A universal algo rithm for sequential data compression including the color values for fully transparent pixels. A universal algo rithm for sequential data compression
<xref target="LZ77"/>, <xref target="Huffman">prefix coding</xref>, <xref target="LZ77"/>, <xref target="Huffman">prefix coding</xref>,
and a color cache are used for compression of the bulk data.</t> and a color cache are used for compression of the bulk data.</t>
</section> </section>
<section anchor="webp-container" numbered="true" toc="default"> <section anchor="webp-container" numbered="true" toc="default">
<name>WebP Container Specification</name> <name>WebP Container Specification</name>
<t>Note that this section is based on the documentation in the <xref <t>Note that this section is based on the documentation in the <xref target
target="webp-riff-src">libwebp source repository</xref>.</t> ="webp-riff-src">libwebp source repository</xref>.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction (from "WebP Container Specification")</name> <name>Introduction (from "WebP Container Specification")</name>
<t>WebP is an image format that uses either (i) the VP8 intra-frame <t>WebP is an image format that uses either (i) the VP8 intra-frame
encoding <xref target="RFC6386"/> to compress image data in a lossy encoding <xref target="RFC6386"/> to compress image data in a lossy
way or (ii) the <xref target="webp-lossless">WebP lossless way or (ii) the <xref target="webp-lossless"> WebP lossless
encoding</xref>. These encoding schemes should make it more encoding</xref>. These encoding schemes should make it more
efficient than older formats, such as JPEG, GIF, and PNG. It is o ptimized for fast efficient than older formats, such as JPEG, GIF, and PNG. It is o ptimized for fast
image transfer over the network (for example, for websites). The WebP image transfer over the network (for example, for websites). The WebP
format has feature parity (color profile, metadata, animation, format has feature parity (color profile, metadata, animation,
etc.) with other formats as well. This section describes the etc.) with other formats as well. This section describes the
structure of a WebP file.</t> structure of a WebP file.</t>
<t>The WebP container (that is, the RIFF container for WebP) allows featu re <t>The WebP container (that is, the RIFF container for WebP) allows featu re
support over and above the basic use case of WebP (that is, a file 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 containing a single image encoded as a VP8 key frame). The WebP
container provides additional support for the following:</t> container provides additional support for the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Lossless Compression: An image can be losslessly compressed, <li>Lossless Compression: An image can be losslessly compressed,
using the WebP lossless format.</li> using the WebP lossless format.</li>
<li>Metadata: An image may have metadata stored in Exchangeable Image File Format <xref <li>Metadata: An image may have metadata stored in Exchangeable Image File Format <xref
target="Exif"/> or Extensible Metadata Platform <xref target="XMP"/ > format.</li> target="Exif"/> or Extensible Metadata Platform <xref target="XMP"/ > format.</li>
<li>Transparency: An image may have transparency, that is, an alpha <li>Transparency: An image may have transparency, that is, an alpha
channel.</li> channel.</li>
<li>Color Profile: An image may have an embedded <xref <li>Color Profile: An image may have an embedded <xref target="ICC">I
target="ICC">ICC profile (ICCP)</xref>.</li> CC profile (ICCP)</xref>.</li>
<li>Animation: An image may have multiple frames with pauses between <li>Animation: An image may have multiple frames with pauses between
them, making it an animation.</li> them, making it an animation.</li>
</ul> </ul>
</section> </section>
<section anchor="terminology-amp-basics" numbered="true" toc="default"> <section anchor="terminology-amp-basics" numbered="true" toc="default">
<name>Terminology &amp; Basics</name> <name>Terminology &amp; Basics</name>
<t> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
skipping to change at line 187 skipping to change at line 176
| Chunk FourCC | | Chunk FourCC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Size | | Chunk Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Chunk Payload : : Chunk Payload :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal" indent="4"> <dl newline="true" spacing="normal" indent="4">
<dt>Chunk FourCC: 32 bits</dt> <dt>Chunk FourCC: 32 bits</dt>
<dd>ASCII four-character code used for chunk identification.</dd> <dd>The ASCII four-character code used for chunk identification.</dd>
<dt>Chunk Size: 32 bits (<em>uint32</em>)</dt> <dt>Chunk Size: 32 bits (<em>uint32</em>)</dt>
<dd>The size of the chunk in bytes, not including this field, the <dd>The size of the chunk in bytes, not including this field, the
chunk identifier, or padding.</dd> chunk identifier, or padding.</dd>
<dt>Chunk Payload: <em>Chunk Size</em> bytes</dt> <dt>Chunk Payload: <em>Chunk Size</em> bytes</dt>
<dd>The data payload. If <em>Chunk Size</em> is odd, a single <dd>The data payload. If <em>Chunk Size</em> is odd, a single
padding byte -- which <bcp14>MUST</bcp14> be <tt>0</tt> to conform with <xref padding byte -- which <bcp14>MUST</bcp14> be <tt>0</tt> to conform with <xref
target="RIFF-spec">RIFF</xref> -- is added.</dd> target="RIFF-spec">RIFF</xref> -- is added.</dd>
</dl> </dl>
<aside><t>Note: RIFF has a convention that all uppercase chunk FourCCs are <aside><t>Note: RIFF has a convention that all uppercase chunk FourCCs are
standard chunks that apply to any RIFF file format, while FourCCs standard chunks that apply to any RIFF file format, while FourCCs
skipping to change at line 252 skipping to change at line 241
<t>This layout <bcp14>SHOULD</bcp14> be used if the image requires lossy encoding and <t>This layout <bcp14>SHOULD</bcp14> be used if the image requires lossy encoding and
does not require transparency or other advanced features provided by does not require transparency or other advanced features provided by
the extended format. Files with this layout are smaller and supported the extended format. Files with this layout are smaller and supported
by older software.</t> by older software.</t>
<t> <t>
Simple WebP (lossy) file format: Simple WebP (lossy) file format:
</t> </t>
<!--[rfced] To avoid redundancy, may we remove the introductory text
from Figures 3-9, 13, and 14 since that text is the same as the
titles of the figures?
For example, may we remove "'VP8 ' Chunk:" above
the bit ruler in the following figure?
Original:
'VP8 ' 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ChunkHeader('VP8 ') |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: VP8 data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: 'VP8 ' Chunk
-->
<figure> <figure>
<name>Simple WebP (Lossy) File Format</name> <name>Simple WebP (Lossy) File Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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) | | WebP file header (12 bytes) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 295 skipping to change at line 306
<dd>VP8 bitstream data.</dd> <dd>VP8 bitstream data.</dd>
</dl> </dl>
<t>Note that the fourth character in the 'VP8 ' FourCC is an ASCII space <t>Note that the fourth character in the 'VP8 ' FourCC is an ASCII space
(0x20).</t> (0x20).</t>
<t>The VP8 bitstream format specification is described in <xref <t>The VP8 bitstream format specification is described in <xref
target="RFC6386"/>. Note that the VP8 frame header contains the VP8 target="RFC6386"/>. Note that the VP8 frame header contains the VP8
frame width and height. That is assumed to be the width and height of frame width and height. That is assumed to be the width and height of
the canvas.</t> the canvas.</t>
<t>The VP8 specification describes how to decode the image into Y'CbCr <t>The VP8 specification describes how to decode the image into Y'CbCr
format. To convert to RGB, <xref target="rec601">Recommendation 601</xre f> <bcp14>SHOULD</bcp14> format. To convert to RGB, <xref target="rec601">ITU-R Recommendation 60 1</xref> <bcp14>SHOULD</bcp14>
be used. Applications <bcp14>MAY</bcp14> use another conversion method , but visual be used. Applications <bcp14>MAY</bcp14> use another conversion method , but visual
results may differ among decoders.</t> results may differ among decoders.</t>
</section> </section>
<section anchor="simple-file-format-lossless" numbered="true" <section anchor="simple-file-format-lossless" numbered="true"
toc="default"> toc="default">
<name>Simple File Format (Lossless)</name> <name>Simple File Format (Lossless)</name>
<!-- [rfced] Please note that some text denoted with "Note:" and
"Rationale:" is in the <aside> element and some text is not. For
consistency, may we add the <aside> element to all instances of
"Note:" and "Rationale:"? It is defined as "a container for content
that is semantically less important or tangential to the content
that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
<t>Note: Older readers may not support files using the lossless <t>Note: Older readers may not support files using the lossless
format.</t> format.</t>
<t>This layout <bcp14>SHOULD</bcp14> be used if the image requires lossle ss encoding <t>This layout <bcp14>SHOULD</bcp14> be used if the image requires lossle ss encoding
(with an optional transparency channel) and does not require advanced (with an optional transparency channel) and does not require advanced
features provided by the extended format.</t> features provided by the extended format.</t>
<t> <t>
Simple WebP (lossless) file format: Simple WebP (lossless) file format:
</t> </t>
skipping to change at line 362 skipping to change at line 382
target="webp-lossless"/>. Note that the VP8L header contains the target="webp-lossless"/>. Note that the VP8L header contains the
VP8L image width and height. That is assumed to be the width and VP8L image width and height. That is assumed to be the width and
height of the canvas.</t> height of the canvas.</t>
</section> </section>
<section anchor="ext-file-form" numbered="true" toc="default"> <section anchor="ext-file-form" numbered="true" toc="default">
<name>Extended File Format</name> <name>Extended File Format</name>
<t>Note: Older readers may not support files using the extended <t>Note: Older readers may not support files using the extended
format.</t> format.</t>
<t>An extended format file consists of:</t> <t>An extended format file consists of the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A 'VP8X' Chunk with information about features used in the <li>a 'VP8X' Chunk with information about features used in the
file.</li> file</li>
<li>An optional 'ICCP' Chunk with a color profile.</li> <li>an optional 'ICCP' Chunk with a color profile</li>
<li>An optional 'ANIM' Chunk with animation control data.</li> <li>an optional 'ANIM' Chunk with animation control data</li>
<li>Image data.</li> <li>image data</li>
<li>An optional 'EXIF' Chunk with Exif metadata.</li> <li>an optional 'EXIF' Chunk with Exif metadata</li>
<li>An optional 'XMP ' Chunk with XMP metadata.</li> <li>an optional 'XMP ' Chunk with XMP metadata</li>
<li>An optional list of <xref target="unknown-chunks">unknown <li>an optional list of <xref target="unknown-chunks">unknown
chunks</xref>.</li> chunks</xref></li>
</ul> </ul>
<t>For a <em>still image</em>, the <em>image data</em> consists of a <t>For a <em>still image</em>, the <em>image data</em> consists of a
single frame, which is made up of:</t> single frame, which is made up of the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>An optional <xref target="alpha">alpha subchunk</xref>.</li> <li>an optional <xref target="alpha">alpha subchunk</xref></li>
<li>A <xref target="bitstream-vp8vp8l">bitstream subchunk</xref>.</li> <li>a <xref target="bitstream-vp8vp8l">bitstream subchunk</xref></li>
</ul> </ul>
<t>For an <em>animated image</em>, the <em>image data</em> consists of <t>For an <em>animated image</em>, the <em>image data</em> consists of
multiple frames. More details about frames can be found in <xref multiple frames. More details about frames can be found in <xref
target="animation"/>.</t> target="animation"/>.</t>
<t>All chunks necessary for reconstruction and color correction, that is <t>All chunks necessary for reconstruction and color correction, that is,
'VP8X', 'ICCP', 'ANIM', 'ANMF', 'ALPH', 'VP8 ' and 'VP8L', 'VP8X', 'ICCP', 'ANIM', 'ANMF', 'ALPH', 'VP8 ', and 'VP8L',
<bcp14>MUST</bcp14> appear in the order described earlier. Readers <bcp14>MUST</bcp14> appear in the order described earlier. Readers
<bcp14>SHOULD</bcp14> fail when chunks necessary for reconstruction and <bcp14>SHOULD</bcp14> fail when chunks necessary for reconstruction and
color correction are out of order.</t> color correction are out of order.</t>
<t><xref target="metadata">Metadata</xref> and <xref <t><xref target="metadata">Metadata</xref> and <xref
target="unknown-chunks">unknown</xref> chunks MAY appear out of target="unknown-chunks">unknown chunks</xref> MAY appear out of
order.</t> order.</t>
<aside><t>Rationale: The chunks necessary for reconstruction should <aside><t>Rationale: The chunks necessary for reconstruction should
appear first in the file to allow a reader to begin decoding an image 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 before receiving all of the data. An application may benefit from
varying the order of metadata and custom chunks to suit the varying the order of metadata and custom chunks to suit the
implementation.</t></aside> implementation.</t></aside>
<t> <t>
Extended WebP file header: Extended WebP file header:
skipping to change at line 496 skipping to change at line 515
</figure> </figure>
<dl newline="true" spacing="normal" indent="4"> <dl newline="true" spacing="normal" indent="4">
<dt>Background Color: 32 bits (<em>uint32</em>)</dt> <dt>Background Color: 32 bits (<em>uint32</em>)</dt>
<dd> <dd>
<t>The default background color of the canvas in [Blue, Green, <t>The default background color of the canvas in [Blue, Green,
Red, Alpha] byte order. This color <bcp14>MAY</bcp14> be used t o fill the Red, Alpha] byte order. This color <bcp14>MAY</bcp14> be used t o fill the
unused space on the canvas around the frames, as well as the unused space on the canvas around the frames, as well as the
transparent pixels of the first frame. The background color is transparent pixels of the first frame. The background color is
also used when the Disposal method is <tt>1</tt>.</t> also used when the Disposal method is <tt>1</tt>.</t>
<t>Note:</t> <t>Notes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The background color <bcp14>MAY</bcp14> contain a nonopaque alpha value, <li>The background color <bcp14>MAY</bcp14> contain a nonopaque alpha value,
even if the <em>Alpha</em> flag in the <xref even if the <em>Alpha</em> flag in the <xref
target="extended_header">'VP8X' Chunk</xref> is unset.</li> target="extended_header">'VP8X' Chunk</xref> is unset.</li>
<li>Viewer applications <bcp14>SHOULD</bcp14> treat the backgro und color value <li>Viewer applications <bcp14>SHOULD</bcp14> treat the backgro und color value
as a hint and are not required to use it.</li> as a hint and are not required to use it.</li>
<li>The canvas is cleared at the start of each loop. The <li>The canvas is cleared at the start of each loop. The
background color <bcp14>MAY</bcp14> be used to achieve this.< /li> background color <bcp14>MAY</bcp14> be used to achieve this.< /li>
</ul> </ul>
</dd> </dd>
skipping to change at line 520 skipping to change at line 539
infinitely.</dd> infinitely.</dd>
</dl> </dl>
<t>This chunk <bcp14>MUST</bcp14> appear if the <em>Animation</em> fl ag in the 'VP8X' <t>This chunk <bcp14>MUST</bcp14> appear if the <em>Animation</em> fl ag in the 'VP8X'
Chunk is set. If the <em>Animation</em> flag is not set and this Chunk is set. If the <em>Animation</em> flag is not set and this
chunk is present, it <bcp14>MUST</bcp14> be ignored.</t> chunk is present, it <bcp14>MUST</bcp14> be ignored.</t>
<t>'ANMF' Chunk:</t> <t>'ANMF' Chunk:</t>
<t>For animated images, this chunk contains information about a <t>For animated images, this chunk contains information about a
<em>single</em> frame. If the <em>Animation flag</em> is not set, <em>single</em> frame. If the <em>Animation</em> flag is not set,
then this chunk <bcp14>SHOULD NOT</bcp14> be present.</t> then this chunk <bcp14>SHOULD NOT</bcp14> be present.</t>
<figure> <figure>
<name>'ANMF' Chunk</name> <name>'ANMF' Chunk</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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') | | ChunkHeader('ANMF') |
| | | |
skipping to change at line 567 skipping to change at line 586
is <tt>1 + Frame Height Minus One</tt>.</dd> is <tt>1 + Frame Height Minus One</tt>.</dd>
<dt>Frame Duration: 24 bits (<em>uint24</em>)</dt> <dt>Frame Duration: 24 bits (<em>uint24</em>)</dt>
<dd>The time to wait before displaying the next frame, in <dd>The time to wait before displaying the next frame, in
1-millisecond units. Note that the interpretation of the Frame Duration 1-millisecond units. Note that the interpretation of the Frame Duration
of 0 (and often &lt;= 10) is defined by the implementation. Man y of 0 (and often &lt;= 10) is defined by the implementation. Man y
tools and browsers assign a minimum duration similar to tools and browsers assign a minimum duration similar to
GIF.</dd> GIF.</dd>
<dt>Reserved: 6 bits</dt> <dt>Reserved: 6 bits</dt>
<dd><bcp14>MUST</bcp14> be <tt>0</tt>. Readers <bcp14>MUST</bcp14 > ignore this field.</dd> <dd><bcp14>MUST</bcp14> be <tt>0</tt>. Readers <bcp14>MUST</bcp14 > ignore this field.</dd>
<dt>Blending method (B): 1 bit</dt> <dt>Blending method (B): 1 bit</dt>
<dd><t>Indicates how transparent pixels of <em>the current <dd><t>Indicates how transparent pixels of the <em>current
frame</em> are to be blended with corresponding pixels of the frame</em> are to be blended with corresponding pixels of the
previous canvas:</t> previous canvas:</t>
<ul spacing="normal"> <ul spacing="normal">
<li><tt>0</tt>: Use alpha-blending. After disposing of the <li><tt>0</tt>: Use alpha-blending. After disposing of the
previous frame, render the current frame on the canvas previous frame, render the current frame on the canvas
using <xref target="alpha-blending">alpha-blending</xref>. using <xref target="alpha-blending">alpha-blending</xref>.
If the current frame does not have an alpha channel, If the current frame does not have an alpha channel,
assume the alpha value is 255, effectively replacing the assume the alpha value is 255, effectively replacing the
rectangle.</li> rectangle.</li>
<li><tt>1</tt>: Do not blend. After disposing of the <li><tt>1</tt>: Do not blend. After disposing of the
previous frame, render the current frame on the canvas by previous frame, render the current frame on the canvas by
overwriting the rectangle covered by the current overwriting the rectangle covered by the current
frame.</li> frame.</li>
</ul> </ul>
</dd> </dd>
<dt>Disposal method (D): 1 bit</dt> <dt>Disposal method (D): 1 bit</dt>
<dd><t>Indicates how <em>the current frame</em> is to be treated <dd><t>Indicates how the <em>current frame</em> is to be treated
after it has been displayed (before rendering the next frame) after it has been displayed (before rendering the next frame)
on the canvas:</t> on the canvas:</t>
<ul spacing="normal"> <ul spacing="normal">
<li><tt>0</tt>: Do not dispose. Leave the canvas as is.</li> <li><tt>0</tt>: Do not dispose. Leave the canvas as is.</li>
<li><tt>1</tt>: Dispose to the background color. Fill the <li><tt>1</tt>: Dispose to the background color. Fill the
<em>rectangle</em> on the canvas covered by the <em>current <em>rectangle</em> on the canvas covered by the <em>current
frame</em> with the background color specified in the <xref frame</em> with the background color specified in the <xref
target="anim_chunk">'ANIM' Chunk</xref>.</li> target="anim_chunk">'ANIM' Chunk</xref>.</li>
</ul> </ul>
<t>Notes:</t> <t>Notes:</t>
skipping to change at line 624 skipping to change at line 643
]]></sourcecode> ]]></sourcecode>
</li> </li>
<li>Alpha-blending <bcp14>SHOULD</bcp14> be done in linear co lor space by <li>Alpha-blending <bcp14>SHOULD</bcp14> be done in linear co lor space by
taking into account the <xref target="color-profile">color taking into account the <xref target="color-profile">color
profile</xref> of the image. If the color profile is not profile</xref> of the image. If the color profile is not
present, standard RGB (sRGB) is to be assumed. (Note th at sRGB also present, standard RGB (sRGB) is to be assumed. (Note th at sRGB also
needs to be linearized due to a gamma of ~2.2.)</li> needs to be linearized due to a gamma of ~2.2.)</li>
</ul> </ul>
</dd> </dd>
<dt>Frame Data: <em>Chunk Size</em> - <tt>16</tt> bytes</dt> <dt>Frame Data: <em>Chunk Size</em> - <tt>16</tt> bytes</dt>
<dd><t>Consists of:</t> <dd><t>Consists of the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>An optional <xref target="alpha">alpha subchunk</xref> <li>an optional <xref target="alpha">alpha subchunk</xref>
for the frame.</li> for the frame</li>
<li>A <xref target="bitstream-vp8vp8l">bitstream <li>a <xref target="bitstream-vp8vp8l">bitstream
subchunk</xref> for the frame.</li> subchunk</xref> for the frame</li>
<li>An optional list of <xref <li>an optional list of <xref
target="unknown-chunks">unknown chunks</xref>.</li> target="unknown-chunks">unknown chunks</xref></li>
</ul> </ul>
</dd> </dd>
</dl> </dl>
<t>Note: The 'ANMF' payload, <em>Frame Data</em>, consists <t>Note: The 'ANMF' payload, i.e., <em>Frame Data</em>, consists
of individual <em>padded</em> chunks, as described by the <xref of individual <em>padded</em> chunks, as described by the <xref
target="riff-file-format">RIFF file format</xref>.</t> target="riff-file-format">RIFF file format</xref>.</t>
</section> </section>
<section anchor="alpha" numbered="true" toc="default"> <section anchor="alpha" numbered="true" toc="default">
<name>Alpha</name> <name>Alpha</name>
<figure> <figure>
<name>'ALPH' Chunk</name> <name>'ALPH' Chunk</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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
skipping to change at line 682 skipping to change at line 701
<ul spacing="normal"> <ul spacing="normal">
<li><tt>0</tt>: None.</li> <li><tt>0</tt>: None.</li>
<li><tt>1</tt>: Horizontal filter.</li> <li><tt>1</tt>: Horizontal filter.</li>
<li><tt>2</tt>: Vertical filter.</li> <li><tt>2</tt>: Vertical filter.</li>
<li><tt>3</tt>: Gradient filter.</li> <li><tt>3</tt>: Gradient filter.</li>
</ul> </ul>
<t>For each pixel, filtering is performed using the following <t>For each pixel, filtering is performed using the following
calculations. Assume the alpha values surrounding the current calculations. Assume the alpha values surrounding the current
<tt>X</tt> position are labeled as:</t> <tt>X</tt> position are labeled as:</t>
<!--[rfced] Tables 1-4 and Figures 11, 19, and 20 do not have
titles. Please review and provide titles if desired.
-->
<figure> <figure>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
C | B | C | B |
---+---+ ---+---+
A | X | A | X |
]]></artwork> ]]></artwork>
</figure> </figure>
<t>We seek to compute the alpha value at position X. First, a <t>We seek to compute the alpha value at position X. First, a
prediction is made depending on the filtering method:</t> prediction is made depending on the filtering method:</t>
skipping to change at line 715 skipping to change at line 737
</ul> </ul>
<t>The final value is derived by adding the decompressed value <t>The final value is derived by adding the decompressed value
<tt>X</tt> to the predictor and using modulo-256 arithmetic to <tt>X</tt> to the predictor and using modulo-256 arithmetic to
wrap the [256..511] range into the [0..255] one:</t> wrap the [256..511] range into the [0..255] one:</t>
<sourcecode type="c"><![CDATA[ <sourcecode type="c"><![CDATA[
alpha = (predictor + X) % 256 alpha = (predictor + X) % 256
]]></sourcecode> ]]></sourcecode>
<t>There are special cases for the left-most and top-most pixel <t>There are special cases for the leftmost and topmost pixel
positions.</t> positions.</t>
<t>For example, the top-left value at location (0, 0) uses 0 as the predictor <t>For example, the top-left value at location (0, 0) uses 0 as the predictor
value. Otherwise:</t> value. Otherwise:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For horizontal or gradient filtering methods, the <li>For horizontal or gradient filtering methods, the
left-most pixels at location (0, y) are predicted using the leftmost pixels at location (0, y) are predicted using the
location (0, y-1) just above.</li> location (0, y-1) just above.</li>
<li>For vertical or gradient filtering methods, the top-most <li>For vertical or gradient filtering methods, the topmost
pixels at location (x, 0) are predicted using the location pixels at location (x, 0) are predicted using the location
(x-1, 0) on the left.</li> (x-1, 0) on the left.</li>
</ul> </ul>
</dd> </dd>
<dt>Compression method (C): 2 bits</dt> <dt>Compression method (C): 2 bits</dt>
<dd><t>The compression method used:</t> <dd><t>The compression method used:</t>
<ul spacing="normal"> <ul spacing="normal">
<li><tt>0</tt>: No compression.</li> <li><tt>0</tt>: No compression.</li>
<li><tt>1</tt>: Compressed using the WebP lossless format.</li> <li><tt>1</tt>: Compressed using the WebP lossless format.</li>
</ul> </ul>
</dd> </dd>
<!--[rfced] Is "1 bytes" (plural) correct, or should it be updated as
"1 byte" (singular)?
Original:
Alpha bitstream: _Chunk Size_ - 1 bytes
Encoded alpha bitstream.
-->
<dt>Alpha bitstream: <em>Chunk Size</em> - <tt>1</tt> bytes</dt> <dt>Alpha bitstream: <em>Chunk Size</em> - <tt>1</tt> bytes</dt>
<dd>Encoded alpha bitstream.</dd> <dd>Encoded alpha bitstream.</dd>
</dl> </dl>
<t>This optional chunk contains encoded alpha data for this frame. A <t>This optional chunk contains encoded alpha data for this frame. A
frame containing a 'VP8L' Chunk <bcp14>SHOULD NOT</bcp14> contain t his chunk.</t> frame containing a 'VP8L' Chunk <bcp14>SHOULD NOT</bcp14> contain t his chunk.</t>
<aside><t>Rationale: The transparency information is already part of the <aside><t>Rationale: The transparency information is already part of the
'VP8L' Chunk.</t></aside> 'VP8L' Chunk.</t></aside>
<t>The alpha channel data is stored as uncompressed raw data <t>The alpha channel data is stored as uncompressed raw data
(when the compression method is '0') or compressed using the (when the compression method is '0') or compressed using the
skipping to change at line 770 skipping to change at line 801
from the green channel of the ARGB quadruplet.</t> from the green channel of the ARGB quadruplet.</t>
<t>Rationale: The green channel is allowed extra transformation <t>Rationale: The green channel is allowed extra transformation
steps in the specification -- unlike the other channels -- that steps in the specification -- unlike the other channels -- that
can improve compression.</t></li> can improve compression.</t></li>
</ul> </ul>
</section> </section>
<section anchor="bitstream-vp8vp8l" numbered="true" toc="default"> <section anchor="bitstream-vp8vp8l" numbered="true" toc="default">
<name>Bitstream (VP8/VP8L)</name> <name>Bitstream (VP8/VP8L)</name>
<t>This chunk contains compressed bitstream data for a single <t>This chunk contains compressed bitstream data for a single
frame.</t> frame.</t>
<t>A bitstream chunk may be either (i) a 'VP8 ' Chunk, using 'VP8 ' <t>A bitstream chunk may be either (i) a 'VP8 ' Chunk using 'VP8 '
(note the significant fourth-character space) as its FourCC, (note the significant fourth-character space) as its FourCC
<em>or</em> (ii) a 'VP8L' Chunk, using 'VP8L' as its FourCC.</t> <em>or</em> (ii) a 'VP8L' Chunk using 'VP8L' as its FourCC.</t>
<t>The formats of' VP8 ' and 'VP8L' Chunks are as described in Sectio ns <xref <t>The formats of' VP8 ' and 'VP8L' Chunks are as described in Sectio ns <xref
target="simple-file-format-lossy" format="counter"/> and <xref target="simple-file-format-lossy" format="counter"/> and <xref
target="simple-file-format-lossless" format="counter"/>, respecti vely.</t> target="simple-file-format-lossless" format="counter"/>, respecti vely.</t>
</section> </section>
<section anchor="color-profile" numbered="true" toc="default"> <section anchor="color-profile" numbered="true" toc="default">
<name>Color Profile</name> <name>Color Profile</name>
<figure> <figure>
<name>'ICCP' Chunk</name> <name>'ICCP' Chunk</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
skipping to change at line 865 skipping to change at line 896
Metadata Working Group's <xref target="MWG">"Guidelines For Metadata Working Group's <xref target="MWG">"Guidelines For
Handling Image Metadata"</xref>.</t> Handling Image Metadata"</xref>.</t>
</section> </section>
<section anchor="unknown-chunks" numbered="true" toc="default"> <section anchor="unknown-chunks" numbered="true" toc="default">
<name>Unknown Chunks</name> <name>Unknown Chunks</name>
<t>A RIFF chunk (described in <xref <t>A RIFF chunk (described in <xref
target="riff-file-format"/>) whose <em>FourCC</em> is target="riff-file-format"/>) whose <em>FourCC</em> is
different from any of the chunks described in this section is different from any of the chunks described in this section is
considered an <em>unknown chunk</em>.</t> considered an <em>unknown chunk</em>.</t>
<aside><t>Rationale: Allowing unknown chunks gives a provision for <aside><t>Rationale: Allowing unknown chunks gives a provision for
future extension of the format and also allows storage of any future extensions of the format and also allows storage of any
application-specific data.</t></aside> application-specific data.</t></aside>
<t>A file <bcp14>MAY</bcp14> contain unknown chunks:</t> <t>A file <bcp14>MAY</bcp14> contain unknown chunks:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>at the end of the file, as described in <xref <li>at the end of the file, as described in <xref
target="ext-file-form"/>, or</li> target="ext-file-form"/>, or</li>
<li>at the end of 'ANMF' Chunks, as described in <xref <li>at the end of 'ANMF' Chunks, as described in <xref
target="animation"/>.</li> target="animation"/>.</li>
</ul> </ul>
<t>Readers <bcp14>SHOULD</bcp14> ignore these chunks. Writers <bcp14> SHOULD</bcp14> preserve them <t>Readers <bcp14>SHOULD</bcp14> ignore these chunks. Writers <bcp14> SHOULD</bcp14> preserve them
in their original order (unless they specifically intend to modify in their original order (unless they specifically intend to modify
these chunks).</t> these chunks).</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Canvas Assembly from Frames</name> <name>Canvas Assembly from Frames</name>
<t>Here, we provide an overview of how a reader <bcp14>MUST</bcp14> ass emble a canvas <t>Here, we provide an overview of how a reader <bcp14>MUST</bcp14> ass emble a canvas
in the case of an animated image.</t> in the case of an animated image.</t>
<t>The process begins with creating a canvas using the dimensions <t>The process begins with creating a canvas using the dimensions
given in the 'VP8X' Chunk, <tt>Canvas Width Minus One + 1</tt> given in the 'VP8X' Chunk: <tt>Canvas Width Minus One + 1</tt>
pixels wide by <tt>Canvas Height Minus One + 1</tt> pixels high. pixels wide by <tt>Canvas Height Minus One + 1</tt> pixels high.
The <tt>Loop Count</tt> field from the 'ANIM' Chunk controls how The <tt>Loop Count</tt> field from the 'ANIM' Chunk controls how
many times the animation process is repeated. This is <tt>Loop many times the animation process is repeated. This is <tt>Loop
Count - 1</tt> for nonzero <tt>Loop Count</tt> values or Count - 1</tt> for nonzero <tt>Loop Count</tt> values or
infinite if the <tt>Loop Count</tt> is zero.</t> infinite if the <tt>Loop Count</tt> is zero.</t>
<t>At the beginning of each loop iteration, the canvas is filled using <t>At the beginning of each loop iteration, the canvas is filled using
the background color from the 'ANIM' Chunk or an application-defined the background color from the 'ANIM' Chunk or an application-defined
color.</t> color.</t>
<t>'ANMF' Chunks contain individual frames given in display order. <t>'ANMF' Chunks contain individual frames given in display order.
Before rendering each frame, the previous frame's <tt>Disposal Before rendering each frame, the previous frame's <tt>Disposal
method</tt> is applied.</t> method</tt> is applied.</t>
<t>The rendering of the decoded frame begins at the Cartesian <t>The rendering of the decoded frame begins at the Cartesian
coordinates (<tt>2 * Frame X</tt>, <tt>2 * Frame Y</tt>), using the coordinates (<tt>2 * Frame X</tt>, <tt>2 * Frame Y</tt>), using the
top-left corner of the canvas as the origin. <tt>Frame Width Minus top-left corner of the canvas as the origin. <tt>Frame Width Minus
One + 1</tt> pixels wide by <tt>Frame Height Minus One + 1</tt> One + 1</tt> pixels wide by <tt>Frame Height Minus One + 1</tt>
pixels high are rendered onto the canvas using the <tt>Blending pixels high is rendered onto the canvas using the <tt>Blending
method</tt>.</t> method</tt>.</t>
<t>The canvas is displayed for <tt>Frame Duration</tt> milliseconds. <t>The canvas is displayed for <tt>Frame Duration</tt> milliseconds.
This continues until all frames given by 'ANMF' Chunks have been This continues until all frames given by 'ANMF' Chunks have been
displayed. A new loop iteration is then begun, or the canvas is left displayed. A new loop iteration is then begun, or the canvas is left
in its final state if all iterations have been completed.</t> in its final state if all iterations have been completed.</t>
<t>The following pseudocode illustrates the rendering process. The <t>The following pseudocode illustrates the rendering process. The
notation <em>VP8X.field</em> means the field in the 'VP8X' Chunk notation <em>VP8X.field</em> means the field in the 'VP8X' Chunk
with the same description.</t> with the same description.</t>
skipping to change at line 1014 skipping to change at line 1045
</section> </section>
</section> </section>
</section> </section>
<section anchor="webp-lossless" numbered="true" toc="default"> <section anchor="webp-lossless" numbered="true" toc="default">
<name>Specification for WebP Lossless Bitstream</name> <name>Specification for WebP Lossless Bitstream</name>
<t>Note that this section is based on the documentation in the <xref <t>Note that this section is based on the documentation in the <xref
target="webp-lossless-src">libwebp source repository</xref>.</t> target="webp-lossless-src">libwebp source repository</xref>.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Abstract (from "Specification for WebP Lossless Bitstream")</name> <name>Abstract (from "Specification for WebP Lossless Bitstream")</name>
<t>WebP lossless is an image format for lossless compression of ARGB <t>WebP lossless format is an image format for lossless compression of AR GB
images. The lossless format stores and restores the pixel values images. The lossless format stores and restores the pixel values
exactly, including the color values for pixels whose alpha value is 0. exactly, including the color values for pixels whose alpha value is 0.
<!--[rfced] We note that "subresolution" has not been used in
previously published RFCs. Will readers understand the meaning of
this term, or may we update its usage throughout the document to
"sub-pixel resolution" instead for clarity? For example:
Original:
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
Perhaps:
The format uses sub-pixel resolution images, recursively embedded into
the format itself, for storing statistical data about the images,
such as the used entropy codes, spatial predictors, color space
-->
The format uses subresolution images, recursively embedded into the The format uses subresolution images, recursively embedded into the
format itself, for storing statistical data about the images, such as format itself, for storing statistical data about the images, such as
the used entropy codes, spatial predictors, color space conversion, the used entropy codes, spatial predictors, color space conversion,
and color table. A universal algorithm for sequential data compression <xref target="LZ77"/>, prefix coding, and a color cache are used for and color table. A universal algorithm for sequential data compression <xref target="LZ77"/>, prefix coding, and a color cache are used for
compression of the bulk data. Decoding speeds faster than PNG have compression of the bulk data. Decoding speeds faster than PNG have
been demonstrated, as well as 25% denser compression than can be been demonstrated, as well as 25% denser compression than can be
achieved using today's PNG format <xref achieved using today's PNG format <xref
target="webp-lossless-study"/>.</t> target="webp-lossless-study"/>.</t>
</section> </section>
skipping to change at line 1078 skipping to change at line 1126
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Nomenclature</name> <name>Nomenclature</name>
<dl newline="true" spacing="normal" indent="4"> <dl newline="true" spacing="normal" indent="4">
<dt>ARGB</dt> <dt>ARGB</dt>
<dd>A pixel value consisting of alpha, red, green, and blue <dd>A pixel value consisting of alpha, red, green, and blue
values.</dd> values.</dd>
<dt>ARGB image</dt> <dt>ARGB image</dt>
<dd>A two-dimensional array containing ARGB pixels.</dd> <dd>A two-dimensional array containing ARGB pixels.</dd>
<dt>color cache</dt> <dt>color cache</dt>
<dd>A small hash-addressed array to store recently used colors to be <dd>A small, hash-addressed array to store recently used colors to be
able to recall them with shorter codes.</dd> able to recall them with shorter codes.</dd>
<dt>color indexing image</dt> <dt>color indexing image</dt>
<dd>A one-dimensional image of colors that can be indexed using a <dd>A one-dimensional image of colors that can be indexed using a
small integer (up to 256 within WebP lossless).</dd> small integer (up to 256 within WebP lossless).</dd>
<dt>color transform image</dt> <dt>color transform image</dt>
<dd>A two-dimensional subresolution image containing data about <dd>A two-dimensional subresolution image containing data about
correlations of color components.</dd> correlations of color components.</dd>
<dt>distance mapping</dt> <dt>distance mapping</dt>
<dd>Changes LZ77 distances to have the smallest values for pixels in <dd>Changes LZ77 distances to have the smallest values for pixels in
two-dimensional proximity.</dd> two-dimensional proximity.</dd>
skipping to change at line 1178 skipping to change at line 1226
color correlations. They can make the final compression color correlations. They can make the final compression
more dense.</t> more dense.</t>
<t>An image can go through four types of transforms. A 1 bit <t>An image can go through four types of transforms. A 1 bit
indicates the presence of a transform. Each transform is allowed to be indicates the presence of a transform. Each transform is allowed to be
used only once. The transforms are used only for the main-level used only once. The transforms are used only for the main-level
ARGB image; the subresolution images (color transform image, entropy ARGB image; the subresolution images (color transform image, entropy
image, and predictor image) have no transforms, not even the 0 bit image, and predictor image) have no transforms, not even the 0 bit
indicating the end of transforms.</t> indicating the end of transforms.</t>
<aside><t>Typically, an encoder would use these transforms to reduce the <aside><t>Note: Typically, an encoder would use these transforms to reduc e the
Shannon entropy in the residual image. Also, the transform data can be Shannon entropy in the residual image. Also, the transform data can be
decided based on entropy minimization.</t></aside> decided based on entropy minimization.</t></aside>
<sourcecode type="c"><![CDATA[ <sourcecode type="c"><![CDATA[
while (ReadBits(1)) { // Transform present. while (ReadBits(1)) { // Transform present.
// Decode transform type. // Decode transform type.
enum TransformType transform_type = ReadBits(2); enum TransformType transform_type = ReadBits(2);
// Decode transform data. // Decode transform data.
... ...
} }
skipping to change at line 1231 skipping to change at line 1279
<t>The transform type is followed by the transform data. Transform data <t>The transform type is followed by the transform data. Transform data
contains the information required to apply the inverse transform and contains the information required to apply the inverse transform and
depends on the transform type. The inverse transforms are applied in depends on the transform type. The inverse transforms are applied in
the reverse order that they are read from the bitstream, that is, last the reverse order that they are read from the bitstream, that is, last
one first.</t> one first.</t>
<t>Next, we describe the transform data for different types.</t> <t>Next, we describe the transform data for different types.</t>
<section anchor="predictor-transform" numbered="true" toc="default"> <section anchor="predictor-transform" numbered="true" toc="default">
<name>Predictor Transform</name> <name>Predictor Transform</name>
<t>The predictor transform can be used to reduce entropy by exploiting <t>The predictor transform can be used to reduce entropy by exploiting
the fact that neighboring pixels are often correlated. In the the fact that neighboring pixels are often correlated. In the
predictor transform, the current pixel value is predicted from the predictor transform, the current pixel value is predicted from the
pixels already decoded (in scan-line order) and only the residual pixels already decoded (in scan-line order) and only the residual
value (actual - predicted) is encoded. The green component of a value (actual - predicted) is encoded. The green component of a
pixel defines which of the 14 predictors is used within a particular pixel defines which of the 14 predictors is used within a particular
block of the ARGB image. The <em>prediction mode</em> determines the block of the ARGB image. The <em>prediction mode</em> determines the
type of prediction to use. We divide the image into squares, and all type of prediction to use. We divide the image into squares, and all
the pixels in a square use the same prediction mode.</t> the pixels in a square use the same prediction mode.</t>
<t>The first 3 bits of prediction data define the block width and <t>The first 3 bits of prediction data define the block width and
height in number of bits.</t> height in number of bits.</t>
skipping to change at line 1258 skipping to change at line 1306
int transform_width = DIV_ROUND_UP(image_width, 1 << size_bits); int transform_width = DIV_ROUND_UP(image_width, 1 << size_bits);
]]></sourcecode> ]]></sourcecode>
<t>The transform data contains the prediction mode for each block of <t>The transform data contains the prediction mode for each block of
the image. It is a subresolution image where the green component 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 of a pixel defines which of the 14 predictors is used for all the
<tt>block_width * block_height</tt> pixels within a particular <tt>block_width * block_height</tt> pixels within a particular
block of the ARGB image. This subresolution image is encoded using block of the ARGB image. This subresolution image is encoded using
the same techniques described in <xref target="image-data"/>.</t> the same techniques described in <xref target="image-data"/>.</t>
<t>The number of block columns, <t>The number of block columns, i.e.,
<tt>transform_width</tt>, is used in two-dimensional indexing. For a pixel (x, y), one can compute the respective filter <tt>transform_width</tt>, is used in two-dimensional indexing. For a pixel (x, y), one can compute the respective filter
block address by:</t> block address by:</t>
<sourcecode type="c"><![CDATA[ <sourcecode type="c"><![CDATA[
int block_index = (y >> size_bits) * transform_width + int block_index = (y >> size_bits) * transform_width +
(x >> size_bits); (x >> size_bits);
]]></sourcecode> ]]></sourcecode>
<t>There are 14 different prediction modes. In each prediction mode, <t>There are 14 different prediction modes. In each prediction mode,
the current pixel value is predicted from one or more neighboring the current pixel value is predicted from one or more neighboring
skipping to change at line 1417 skipping to change at line 1465
} }
int ClampAddSubtractHalf(int a, int b) { int ClampAddSubtractHalf(int a, int b) {
return Clamp(a + (a - b) / 2); return Clamp(a + (a - b) / 2);
} }
]]></sourcecode> ]]></sourcecode>
<t>There are special handling rules for some border pixels. If there <t>There are special handling rules for some border pixels. If there
is a prediction transform, regardless of the mode [0..13] for these is a prediction transform, regardless of the mode [0..13] for these
pixels, the predicted value for the left-topmost pixel of the image pixels, the predicted value for the left-topmost pixel of the image
is 0xff000000, all pixels on the top row are L-pixel, and is 0xff000000, all pixels on the top row are L pixels, and
all pixels on the leftmost column are T-pixel.</t> all pixels on the leftmost column are T pixels.</t>
<t>Addressing the TR-pixel for pixels on the rightmost column is <t>Addressing the TR pixel for pixels on the rightmost column is
exceptional. The pixels on the rightmost column are predicted by exceptional. The pixels on the rightmost column are predicted by
using the modes [0..13], just like pixels not on the border, but the 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 leftmost pixel on the same row as the current pixel is instead used
as the TR-pixel.</t> as the TR pixel.</t>
<t>The final pixel value is obtained by adding each channel of the <t>The final pixel value is obtained by adding each channel of the
predicted value to the encoded residual value.</t> predicted value to the encoded residual value.</t>
<sourcecode type="c"><![CDATA[ <sourcecode type="c"><![CDATA[
void PredictorTransformOutput(uint32 residual, uint32 pred, void PredictorTransformOutput(uint32 residual, uint32 pred,
uint8* alpha, uint8* red, uint8* alpha, uint8* red,
uint8* green, uint8* blue) { uint8* green, uint8* blue) {
*alpha = ALPHA(residual) + ALPHA(pred); *alpha = ALPHA(residual) + ALPHA(pred);
*red = RED(residual) + RED(pred); *red = RED(residual) + RED(pred);
*green = GREEN(residual) + GREEN(pred); *green = GREEN(residual) + GREEN(pred);
skipping to change at line 1505 skipping to change at line 1553
} }
]]></sourcecode> ]]></sourcecode>
<t>A conversion from the 8-bit unsigned representation <t>A conversion from the 8-bit unsigned representation
(<tt>uint8</tt>) to the 8-bit signed one (<tt>int8</tt>) is required (<tt>uint8</tt>) to the 8-bit signed one (<tt>int8</tt>) is required
before calling <tt>ColorTransformDelta()</tt>. before calling <tt>ColorTransformDelta()</tt>.
The signed value should be interpreted as an 8-bit two's complement number (that is: uint8 range [128..255] is mapped 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).</t> to the [-128..-1] range of its converted int8 value).</t>
<t>The multiplication is to be done using more precision (with at <t>The multiplication is to be done using more precision (with at
least 16-bit precision). The sign extension property of the shift least 16-bit precision).
<!--[rfced] May we clarify "and there" as follows?
Original:
The sign extension property of the shift
operation does not matter here; only the lowest 8 bits are used from
the result, and there the sign extension shifting and unsigned
shifting are consistent with each other.
Perhaps:
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.
-->
The sign extension property of the shift
operation does not matter here; only the lowest 8 bits are used from operation does not matter here; only the lowest 8 bits are used from
the result, and there the sign extension shifting and unsigned the result, and there the sign extension shifting and unsigned
shifting are consistent with each other.</t> shifting are consistent with each other.</t>
<t>Now, we describe the contents of color transform data so that <t>Now, we describe the contents of color transform data so that
decoding can apply the inverse color transform and recover the decoding can apply the inverse color transform and recover the
original red and blue values. The first 3 bits of the color original red and blue values. The first 3 bits of the color
transform data contain the width and height of the image block in transform data contain the width and height of the image block in
number of bits, just like the predictor transform:</t> number of bits, just like the predictor transform:</t>
skipping to change at line 1606 skipping to change at line 1671
<t>The transform data contains the color table size and the entries in the <t>The transform data contains the color table size and the entries in the
color table. The decoder reads the color indexing transform data as color table. The decoder reads the color indexing transform data as
follows:</t> follows:</t>
<sourcecode type="c"><![CDATA[ <sourcecode type="c"><![CDATA[
// 8-bit value for the color table size // 8-bit value for the color table size
int color_table_size = ReadBits(8) + 1; int color_table_size = ReadBits(8) + 1;
]]></sourcecode> ]]></sourcecode>
<t>The color table is stored using the image storage format itself. <t>The color table is stored using the image storage format itself.
The color table can be obtained by reading an image, without the The color table can be obtained by reading an image without the
RIFF header, image size, and transforms, assuming the height of 1 RIFF header, image size, and transforms, assuming the height of 1
pixel and the width of <tt>color_table_size</tt>. The color table is pixel and the width of <tt>color_table_size</tt>. The color table is
always subtraction-coded to reduce image entropy. The deltas of always subtraction-coded to reduce image entropy. The deltas of
palette colors contain typically much less entropy than the colors palette colors typically contain much less entropy than the colors
themselves, leading to significant savings for smaller images. In themselves, leading to significant savings for smaller images. In
decoding, every final color in the color table can be obtained by decoding, every final color in the color table can be obtained by
adding the previous color component values by each ARGB component adding the previous color component values by each ARGB component
separately and storing the least significant 8 bits of the separately and storing the least significant 8 bits of the
result.</t> result.</t>
<t>The inverse transform for the image is simply replacing the pixel <t>The inverse transform for the image is simply replacing the pixel
values (which are indices to the color table) with the actual color values (which are indices to the color table) with the actual color
table values. The indexing is done based on the green component of table values. The indexing is done based on the green component of
the ARGB color.</t> the ARGB color.</t>
skipping to change at line 1635 skipping to change at line 1700
]]></sourcecode> ]]></sourcecode>
<t>If the index is equal to or larger than <tt>color_table_size</tt>, t he <t>If the index is equal to or larger than <tt>color_table_size</tt>, t he
argb color value should be set to 0x00000000 (transparent argb color value should be set to 0x00000000 (transparent
black).</t> black).</t>
<t>When the color table is small (equal to or less than 16 colors), <t>When the color table is small (equal to or less than 16 colors),
several pixels are bundled into a single pixel. The pixel bundling several pixels are bundled into a single pixel. The pixel bundling
packs several (2, 4, or 8) pixels into a single pixel, reducing the packs several (2, 4, or 8) pixels into a single pixel, reducing the
image width respectively.</t> image width respectively.</t>
<aside><t>Pixel bundling allows for a more efficient <aside><t>Note: Pixel bundling allows for a more efficient
joint distribution entropy coding of neighboring pixels and gives joint distribution entropy coding of neighboring pixels and gives
some arithmetic coding-like benefits to the entropy code, but it can some arithmetic coding-like benefits to the entropy code, but it can
only be used when there are 16 or fewer unique values.</t></aside> only be used when there are 16 or fewer unique values.</t></aside>
<t><tt>color_table_size</tt> specifies how many pixels are <t><tt>color_table_size</tt> specifies how many pixels are
combined:</t> combined:</t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th>color_table_size</th> <th>color_table_size</th>
skipping to change at line 1722 skipping to change at line 1787
<ol spacing="normal"> <ol spacing="normal">
<li>ARGB image: Stores the actual pixels of the image.</li> <li>ARGB image: Stores the actual pixels of the image.</li>
<li>Entropy image: Stores the meta prefix <li>Entropy image: Stores the meta prefix
codes (see <xref codes (see <xref
target="decoding-of-meta-prefix-codes">"Decoding of Meta Prefix Cod es"</xref>).</li> target="decoding-of-meta-prefix-codes">"Decoding of Meta Prefix Cod es"</xref>).</li>
<li>Predictor image: Stores the metadata for the predictor transform (see <xref <li>Predictor image: Stores the metadata for the predictor transform (see <xref
target="predictor-transform">"Predictor Transform"</xref>).</li> target="predictor-transform">"Predictor Transform"</xref>).</li>
<li>Color transform image: Created by <li>Color transform image: Created by
<tt>ColorTransformElement</tt> values (defined in <xref <tt>ColorTransformElement</tt> values (defined in <xref
target="color-transform">"Color Transform"</xref>) for different target="color-transform">"Color Transform"</xref>) for different
blocks of the image.</li> blocks of the image.</li>
<!--[rfced] We are having some difficulty parsing the definition below.
How should it be updated for clarity?
Original:
5. Color indexing image: An array of size color_table_size (up to
256 ARGB values) storing the metadata for the color indexing
transform (see "Color Indexing Transform" (Section 3.5.4)).
Perhaps:
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)).
-->
<li>Color indexing image: An array of size <li>Color indexing image: An array of size
<tt>color_table_size</tt> (up to 256 ARGB values) storing the <tt>color_table_size</tt> (up to 256 ARGB values) storing the
metadata for the color metadata for the color
indexing transform (see <xref target="color-indexing-transform" >"Color Indexing Transform"</xref>).</li> indexing transform (see <xref target="color-indexing-transform" >"Color Indexing Transform"</xref>).</li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Encoding of Image Data</name> <name>Encoding of Image Data</name>
<t>The encoding of image data is independent of its role.</t> <t>The encoding of image data is independent of its role.</t>
skipping to change at line 1971 skipping to change at line 2051
</section> </section>
</section> </section>
<section anchor="color-cache-coding" numbered="true" toc="default"> <section anchor="color-cache-coding" numbered="true" toc="default">
<name>Color Cache Coding</name> <name>Color Cache Coding</name>
<t>Color cache stores a set of colors that have been recently used <t>Color cache stores a set of colors that have been recently used
in the image.</t> in the image.</t>
<aside><t>Rationale: This way, the recently used colors can <aside><t>Rationale: This way, the recently used colors can
sometimes be referred to more efficiently than emitting them using sometimes be referred to more efficiently than emitting them using
the other two methods (described in Sections <xref the other two methods (as described in Sections <xref
target="prefix-coded-literals" format="counter"/> target="prefix-coded-literals" format="counter"/>
and <xref target="lz77-backward-reference" and <xref target="lz77-backward-reference"
format="counter"/>).</t></aside> format="counter"/>).</t></aside>
<t>Color cache codes are stored as follows. First, there is a 1-bit <t>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, 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 no color cache codes exist, and they are not transmitted in the
prefix code that decodes the green symbols and the length prefix prefix code that decodes the green symbols and the length prefix
codes. However, if this bit is 1, the color cache size is read codes. However, if this bit is 1, the color cache size is read
next:</t> next:</t>
skipping to change at line 2041 skipping to change at line 2121
<t>The encoded image data consists of several parts:</t> <t>The encoded image data consists of several parts:</t>
<ol spacing="normal"> <ol spacing="normal">
<li>Decoding and building the prefix codes.</li> <li>Decoding and building the prefix codes.</li>
<li>Meta prefix codes.</li> <li>Meta prefix codes.</li>
<li>Entropy-coded image data.</li> <li>Entropy-coded image data.</li>
</ol> </ol>
<t>For any given pixel (x, y), there is a set of five prefix codes <t>For any given pixel (x, y), there is a set of five prefix codes
associated with it. These codes are (in bitstream order):</t> associated with it. These codes are (in bitstream order):</t>
<ul spacing="normal"> <dl newline="false" spacing="normal">
<li><strong>Prefix code #1</strong>: Used for green channel, <dt><strong>Prefix code #1</strong>:</dt> <dd>Used for green channel,
backward-reference length, and color cache.</li> backward-reference length, and color cache.</dd>
<li><strong>Prefix code #2, #3, and #4</strong>: Used for red, <dt><strong>Prefix code #2, #3, and #4</strong>:</dt> <dd>Used for re
blue, and alpha channels, respectively.</li> d,
<li><strong>Prefix code #5</strong>: Used for backward-reference blue, and alpha channels, respectively.</dd>
distance.</li> <dt><strong>Prefix code #5</strong>:</dt> <dd>Used for backward-refer
</ul> ence
distance.</dd>
</dl>
<t>From here on, we refer to this set as a <strong>prefix code <t>From here on, we refer to this set as a <strong>prefix code
group</strong>.</t> group</strong>.</t>
<section anchor="decoding-and-building-the-prefix-codes" <section anchor="decoding-and-building-the-prefix-codes"
numbered="true" toc="default"> numbered="true" toc="default">
<name>Decoding and Building the Prefix Codes</name> <name>Decoding and Building the Prefix Codes</name>
<t>This section describes how to read the prefix code lengths from <t>This section describes how to read the prefix code lengths from
the bitstream.</t> the bitstream.</t>
skipping to change at line 2109 skipping to change at line 2189
<sourcecode type="c"><![CDATA[ <sourcecode type="c"><![CDATA[
int is_first_8bits = ReadBits(1); int is_first_8bits = ReadBits(1);
symbol0 = ReadBits(1 + 7 * is_first_8bits); symbol0 = ReadBits(1 + 7 * is_first_8bits);
code_lengths[symbol0] = 1; code_lengths[symbol0] = 1;
if (num_symbols == 2) { if (num_symbols == 2) {
symbol1 = ReadBits(8); symbol1 = ReadBits(8);
code_lengths[symbol1] = 1; code_lengths[symbol1] = 1;
} }
]]></sourcecode> ]]></sourcecode>
<aside><t>The two symbols should be different. Duplicate symbols are <aside><t>Note: The two symbols should be different. Duplicate symbol
allowed, but inefficient.</t></aside> s are
allowed but inefficient.</t></aside>
<t>Note: Another special case is when <em>all</em> prefix code <t>Note: Another special case is when <em>all</em> prefix code
lengths are <em>zeros</em> (an empty prefix code). For example, a lengths are <em>zeros</em> (an empty prefix code). For example, a
prefix code for distance can be empty if there are no backward prefix code for distance can be empty if there are no backward
references. Similarly, prefix codes for alpha, red, and blue can references. Similarly, prefix codes for alpha, red, and blue can
be empty if all pixels within the same meta prefix code are be empty if all pixels within the same meta prefix code are
produced using the color cache. However, this case doesn't need produced using the color cache. However, this case doesn't need
special handling, as empty prefix codes can be coded as those special handling, as empty prefix codes can be coded as those
containing a single symbol <tt>0</tt>.</t> containing a single symbol <tt>0</tt>.</t>
</section> </section>
skipping to change at line 2133 skipping to change at line 2213
<t>The code lengths of the prefix code fit in 8 bits and are read <t>The code lengths of the prefix code fit in 8 bits and are read
as follows. First, <tt>num_code_lengths</tt> specifies the number as follows. First, <tt>num_code_lengths</tt> specifies the number
of code lengths.</t> of code lengths.</t>
<sourcecode type="c"><![CDATA[ <sourcecode type="c"><![CDATA[
int num_code_lengths = 4 + ReadBits(4); int num_code_lengths = 4 + ReadBits(4);
]]></sourcecode> ]]></sourcecode>
<t>The code lengths are themselves encoded using prefix codes; <t>The code lengths are themselves encoded using prefix codes;
lower-level code lengths, <tt>code_length_code_lengths</tt>, first lower-level code lengths, i.e., <tt>code_length_code_lengths</tt>, first
have to be read. The rest of those have to be read. The rest of those
<tt>code_length_code_lengths</tt> (according to the order in <tt>code_length_code_lengths</tt> (according to the order in
<tt>kCodeLengthCodeOrder</tt>) are zeros.</t> <tt>kCodeLengthCodeOrder</tt>) are zeros.</t>
<sourcecode type="c"><![CDATA[ <sourcecode type="c"><![CDATA[
int kCodeLengthCodes = 19; int kCodeLengthCodes = 19;
int kCodeLengthCodeOrder[kCodeLengthCodes] = { int kCodeLengthCodeOrder[kCodeLengthCodes] = {
17, 18, 0, 1, 2, 3, 4, 5, 16, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 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 int code_length_code_lengths[kCodeLengthCodes] = { 0 }; // All zeros
skipping to change at line 2276 skipping to change at line 2356
<t>Given a pixel (x, y) in the ARGB image, we can obtain the <t>Given a pixel (x, y) in the ARGB image, we can obtain the
corresponding prefix codes to be used as follows:</t> corresponding prefix codes to be used as follows:</t>
<sourcecode type="c"><![CDATA[ <sourcecode type="c"><![CDATA[
int position = int position =
(y >> prefix_bits) * prefix_image_width + (x >> prefix_bits); (y >> prefix_bits) * prefix_image_width + (x >> prefix_bits);
int meta_prefix_code = (entropy_image[position] >> 8) & 0xffff; int meta_prefix_code = (entropy_image[position] >> 8) & 0xffff;
PrefixCodeGroup prefix_group = prefix_code_groups[meta_prefix_code]; PrefixCodeGroup prefix_group = prefix_code_groups[meta_prefix_code];
]]></sourcecode> ]]></sourcecode>
<t>where we have assumed the existence of <tt>PrefixCodeGroup</tt> <t>where we have assumed the existence of the <tt>PrefixCodeGroup</tt >
structure, which represents a set of five prefix codes. Also, structure, which represents a set of five prefix codes. Also,
<tt>prefix_code_groups</tt> is an array of <tt>prefix_code_groups</tt> is an array of
<tt>PrefixCodeGroup</tt> (of size <tt>num_prefix_groups</tt>).</t> <tt>PrefixCodeGroup</tt> (of size <tt>num_prefix_groups</tt>).</t>
<t>The decoder then uses prefix code group <tt>prefix_group</tt> to <t>The decoder then uses prefix code group <tt>prefix_group</tt> to
decode the pixel (x, y), as explained in <xref decode the pixel (x, y), as explained in <xref
target="decoding-entropy-coded-image-data"/>.</t> target="decoding-entropy-coded-image-data"/>.</t>
</section> </section>
</section> </section>
<section anchor="decoding-entropy-coded-image-data" numbered="true" <section anchor="decoding-entropy-coded-image-data" numbered="true"
toc="default"> toc="default">
<name>Decoding Entropy-Coded Image Data</name> <name>Decoding Entropy-Coded Image Data</name>
<t>For the current position (x, y) in the image, the decoder first <t>For the current position (x, y) in the image, the decoder first
identifies the corresponding prefix code group (as explained in identifies the corresponding prefix code group (as explained in
the last section). Given the prefix code group, the pixel is read the last section). Given the prefix code group, the pixel is read
and decoded as follows.</t> and decoded as follows.</t>
<!-- [rfced] May we move the citation out of the equation below?
Original:
Note that S is any integer in the range 0 to (256 + 24 + color_cache_size
(Section 3.6.2.3)- 1).
Perhaps:
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.
-->
<t>Next, read symbol S from the bitstream using prefix code #1. <t>Next, read symbol S from the bitstream using prefix code #1.
Note that S is any integer in the range <tt>0</tt> to Note that S is any integer in the range <tt>0</tt> to
<tt>(256 + 24 + </tt> <xref <tt>(256 + 24 + </tt> <xref
target="color-cache-coding"><tt>color_cache_size</tt></xref><tt> - target="color-cache-coding"><tt>color_cache_size</tt></xref><tt> -
1)</tt>.</t> 1)</tt>.</t>
<t>The interpretation of S depends on its value:</t> <t>The interpretation of S depends on its value:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li><t>If S &lt; 256</t> <li><t>If S &lt; 256:</t>
<ol spacing="normal" type="i"> <ol spacing="normal" type="i">
<li>Use S as the green component.</li> <li>Use S as the green component.</li>
<li>Read red from the bitstream using prefix code #2.</li> <li>Read red from the bitstream using prefix code #2.</li>
<li>Read blue from the bitstream using prefix code #3.</li> <li>Read blue from the bitstream using prefix code #3.</li>
<li>Read alpha from the bitstream using prefix code #4.</li> <li>Read alpha from the bitstream using prefix code #4.</li>
</ol> </ol>
</li> </li>
<li><t>If S &gt;= 256 &amp; S &lt; 256 + 24</t> <li><t>If S &gt;= 256 &amp; S &lt; 256 + 24:</t>
<ol spacing="normal" type="i"> <ol spacing="normal" type="i">
<li>Use S - 256 as a length prefix code.</li> <li>Use S - 256 as a length prefix code.</li>
<li>Read extra bits for the length from the bitstream.</li> <li>Read extra bits for the length from the bitstream.</li>
<li>Determine backward-reference length L from length prefix <li>Determine backward-reference length L from length prefix
code and the extra bits read.</li> code and the extra bits read.</li>
<li>Read the distance prefix code from the bitstream using pref ix <li>Read the distance prefix code from the bitstream using pref ix
code #5.</li> code #5.</li>
<li>Read extra bits for the distance from the bitstream.</li> <li>Read extra bits for the distance from the bitstream.</li>
<li>Determine backward-reference distance D from the distance <li>Determine backward-reference distance D from the distance
prefix code and the extra bits read.</li> prefix code and the extra bits read.</li>
<li>Copy L pixels (in scan-line order) from the sequence of pix els <li>Copy L pixels (in scan-line order) from the sequence of pix els,
starting at the current position minus D pixels.</li> starting at the current position minus D pixels.</li>
</ol> </ol>
</li> </li>
<li><t>If S &gt;= 256 + 24</t> <li><t>If S &gt;= 256 + 24:</t>
<ol spacing="normal" type="i"> <ol spacing="normal" type="i">
<li>Use S - (256 + 24) as the index into the color cache.</li> <li>Use S - (256 + 24) as the index into the color cache.</li>
<li>Get ARGB color from the color cache at that index.</li> <li>Get ARGB color from the color cache at that index.</li>
</ol> </ol>
</li> </li>
</ol> </ol>
</section> </section>
</section> </section>
</section> </section>
skipping to change at line 2414 skipping to change at line 2505
prefix-code = simple-prefix-code / normal-prefix-code prefix-code = simple-prefix-code / normal-prefix-code
simple-prefix-code = ; see "Simple Code Length Code" for details simple-prefix-code = ; see "Simple Code Length Code" for details
normal-prefix-code = ; see "Normal Code Length Code" for details normal-prefix-code = ; see "Normal Code Length Code" for details
lz77-coded-image = lz77-coded-image =
*((argb-pixel / lz77-copy / color-cache-code) lz77-coded-image) *((argb-pixel / lz77-copy / color-cache-code) lz77-coded-image)
]]></sourcecode> ]]></sourcecode>
<t>The following is a possible example sequence:</t> <t>The following is a possible example sequence:</t>
<!-- [rfced] Please review the "type" attribute of each sourcecode
element in the XML file to ensure correctness. The current list
of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
Please let us know if the "type" attribute for the sourcecode at the end
of Section 3.8.3 should be set. Note that it is also acceptable to leave
it not set.
-->
<sourcecode><![CDATA[ <sourcecode><![CDATA[
RIFF-header image-size %b1 subtract-green-tx RIFF-header image-size %b1 subtract-green-tx
%b1 predictor-tx %b0 color-cache-info %b1 predictor-tx %b0 color-cache-info
%b0 prefix-codes lz77-coded-image %b0 prefix-codes lz77-coded-image
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
skipping to change at line 2460 skipping to change at line 2561
The container is based on RIFF and allows extension via user-defined The container is based on RIFF and allows extension via user-defined
chunks, but nothing beyond the chunks defined by the container format chunks, but nothing beyond the chunks defined by the container format
(<xref target="webp-container"/>) are required for decoding of the image. (<xref target="webp-container"/>) are required for decoding of the image.
These have been finalized but were extended in the format's early These have been finalized but were extended in the format's early
stages, so some older readers may not support lossless or animated image stages, so some older readers may not support lossless or animated image
decoding.</t> decoding.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<!-- [rfced] We have included a specific question about the IANA text
below. In addition to responding to the question, please review
all of the IANA-related updates carefully and let us know if any
further updates are needed.
a) Section 6.1.1. Per the template in Section 5.6 of RFC 6838, we
ordered "Intended usage" above "Restrictions on usage". We also notice
that "Provisional registration?" is missing from the list - should it
be included after "Change controller" to match the template?
-->
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA has registered the 'image/webp' media type <xref <t>IANA has registered the 'image/webp' media type <xref
target="RFC2046"/>.</t> target="RFC2046"/>.</t>
<section anchor="webp-media-type" numbered="true" toc="default"> <section anchor="webp-media-type" numbered="true" toc="default">
<name>The 'image/webp' Media Type</name> <name>The 'image/webp' Media Type</name>
<t>This section contains the media type registration details per <xref <t>This section contains the media type registration details per <xref
target="RFC6838"/>.</t> target="RFC6838"/>.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registration Details</name> <name>Registration Details</name>
<!-- RFC Editor Note: Remove this text element after updating. -->
<t><strong>RFC Editor Note:</strong> Replace RFC XXXX / rfcXXXX with
the published RFC number.</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Type name:</dt> <dd>image</dd> <dt>Type name:</dt> <dd>image</dd>
<dt>Subtype name:</dt> <dd>webp</dd> <dt>Subtype name:</dt> <dd>webp</dd>
<dt>Required parameters:</dt> <dd>N/A</dd> <dt>Required parameters:</dt> <dd>N/A</dd>
<dt>Optional parameters:</dt> <dd>N/A</dd> <dt>Optional parameters:</dt> <dd>N/A</dd>
<dt>Encoding considerations:</dt> <dd>Binary. The <xref target="RFC46 48">Base64 <dt>Encoding considerations:</dt> <dd>Binary. The <xref target="RFC46 48">base64
encoding</xref> should be used on transports that cannot accommodate encoding</xref> should be used on transports that cannot accommodate
binary data directly.</dd> binary data directly.</dd>
<dt>Security considerations:</dt> <dd>See RFC XXXX, <xref target="Sec <dt>Security considerations:</dt> <dd>See RFC 9649, <xref target="Sec
urity"/>.</dd> urity"/>.</dd>
<dt>Interoperability considerations:</dt> <dd>See RFC XXXX, <xref tar <dt>Interoperability considerations:</dt> <dd>See RFC 9649, <xref tar
get="Interop"/>.</dd> get="Interop"/>.</dd>
<dt>Published specification:</dt> <dd>RFC XXXX</dd> <dt>Published specification:</dt> <dd>RFC 9649</dd>
<dt>Applications that use this media type:</dt> <dd>Applications that are used to <dt>Applications that use this media type:</dt> <dd>Applications that are used to
display and process images, especially when smaller image file sizes display and process images, especially when smaller image file sizes
are important.</dd> are important.</dd>
<dt>Fragment identifier considerations:</dt> <dd>N/A</dd> <dt>Fragment identifier considerations:</dt> <dd>N/A</dd>
<dt>Additional information:</dt> <dt>Additional information:</dt>
<dd><t><br/></t> <dd><t><br/></t>
<dl spacing="compact"> <dl spacing="compact">
<dt>Deprecated alias names for this type:</dt> <dd>N/A</dd> <dt>Deprecated alias names for this type:</dt> <dd>N/A</dd>
<dt>Magic number(s):</dt> <dd>The first 4 bytes are 0x52, 0x49, 0x46, 0x46 <dt>Magic number(s):</dt> <dd>The first 4 bytes are 0x52, 0x49, 0x46, 0x46
skipping to change at line 2506 skipping to change at line 2615
('WEBPVP8').</dd> ('WEBPVP8').</dd>
<dt>File extension(s):</dt> <dd>webp</dd> <dt>File extension(s):</dt> <dd>webp</dd>
<dt>Apple Uniform Type Identifier:</dt> <dd>org.webmproject.webp conf orms to <dt>Apple Uniform Type Identifier:</dt> <dd>org.webmproject.webp conf orms to
public.image</dd> public.image</dd>
<dt>Object Identifiers:</dt> <dd>N/A</dd> <dt>Object Identifiers:</dt> <dd>N/A</dd>
</dl></dd> </dl></dd>
<dt>Person &amp; email address to contact for further information:</dt> <dt>Person &amp; email address to contact for further information:</dt>
<dd>James Zern &lt;jzern@google.com&gt;</dd></dl> <dd>James Zern &lt;jzern@google.com&gt;</dd></dl>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Intended usage:</dt> <dd>COMMON</dd>
<dt>Restrictions on usage:</dt> <dd>N/A</dd> <dt>Restrictions on usage:</dt> <dd>N/A</dd>
<dt>Author:</dt> <dt>Author:</dt>
<dd>James Zern &lt;jzern@google.com&gt;</dd> <dd>James Zern &lt;jzern@google.com&gt;</dd>
</dl> <dt>Change controller:</dt><dd>IETF</dd>
<dl newline="false" spacing="compact"> </dl>
<dt>Change controller:</dt><dd></dd>
<dt></dt><dd>IETF</dd>
</dl>
<dl newline="false" spacing="normal">
<dt>Intended usage:</dt> <dd>COMMON</dd>
</dl>
</section> </section>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="Exif" <reference anchor="Exif" target="https://www.cipa.jp/std/documents/e/DC-0
target="https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf"> 08-2012_E.pdf">
<front> <front>
<title>Exchangeable image file format for digital still cameras: <title>Exchangeable image file format for digital still cameras:
Exif Version 2.3</title> Exif Version 2.3</title>
<author> <author>
<organization>Camera &amp; Imaging Products Association <organization>Camera &amp; Imaging Products Association
(CIPA)</organization> (CIPA)</organization>
</author> </author>
<author> <author>
<organization>Japan Electronics and Information Technology <organization>Japan Electronics and Information Technology
Industries Association (JEITA)</organization> Industries Association (JEITA)</organization>
</author> </author>
<date month="December" year="2012"/> <date month="December" year="2012"/>
</front> </front>
<seriesInfo name="CIPA" value="DC-008-2012"/> <seriesInfo name="CIPA" value="DC-008-2012"/>
<seriesInfo name="JEITA" value="CP-3451C"/> <seriesInfo name="JEITA" value="CP-3451C"/>
</reference> </reference>
<reference anchor="ICC" <reference anchor="ICC"
target="https://www.color.org/specification/ICC1v43_2010-12.pdf"> target="https://www.color.org/specification/ICC1v43_2010-12.pdf">
<front> <front>
<title>Image technology colour management -- Architecture, profile fo rmat, and data structure</title> <title>Image technology colour management - Architecture, profile for mat, and data structure</title>
<author> <author>
<organization>International Color Consortium</organization> <organization>International Color Consortium</organization>
</author> </author>
<date month="December" year="2010"/> <date month="December" year="2010"/>
</front> </front>
<seriesInfo name="Specification" value="ICC.1:2010"/> <seriesInfo name="Specification" value="ICC.1:2010"/>
<refcontent>Profile version 4.3.0.0, REVISION of ICC.1:2004-10</refcontent> <refcontent>Profile version 4.3.0.0, REVISION of ICC.1:2004-10</refcontent>
</reference> </reference>
<reference anchor="ISO.9899.2018" target="https://www.iso.org/standard/74 528.html"> <reference anchor="ISO.9899.2018" target="https://www.iso.org/standard/74 528.html">
<front> <front>
<title>Information technology -- Programming languages -- C</title> <title>Information technology - Programming languages - C</title>
<author> <author>
<organization> <organization>
International Organization for Standardization International Organization for Standardization
</organization> </organization>
</author> </author>
<date month="June" year="2018"/> <date month="June" year="2018"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="9899:2018"/> <seriesInfo name="ISO/IEC" value="9899:2018"/>
<refcontent>Fourth Edition</refcontent> <refcontent>Fourth Edition</refcontent>
</reference> </reference>
<reference anchor="rec601" <reference anchor="rec601"
target="https://www.itu.int/rec/R-REC-BT.601/"> target="https://www.itu.int/rec/R-REC-BT.601/">
<front> <front>
<title>Studio encoding parameters of digital television for <title>Studio encoding parameters of digital television for
standard 4:3 and wide screen 16:9 aspect ratios</title> standard 4:3 and wide-screen 16:9 aspect ratios</title>
<author> <author>
<organization>ITU</organization> <organization>ITU-R</organization>
</author> </author>
<date month="March" year="2011" /> <date month="March" year="2011" />
</front> </front>
<seriesInfo name="ITU-R Recommendation" value="BT.601"/> <seriesInfo name="ITU-R Recommendation" value="BT.601-7"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1166.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1166.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2781.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2781.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6386.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6386.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" />
<reference anchor="XMP" <reference anchor="XMP" target="https://www.adobe.com/devnet/xmp.html">
target="https://www.adobe.com/devnet/xmp.html">
<front> <front>
<title>XMP Specification</title> <title>XMP Specification</title>
<author> <author>
<organization>Adobe Inc.</organization> <organization>Adobe Inc.</organization>
</author> </author>
</front> </front>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="crbug-security" target="https://bugs.chromium. <!--[rfced] The URL for the reference below redirects to the following page:
org/p/webp/issues/list?q=label%3ASecurity"> https://issues.webmproject.org/issues?q=componentid:1618983%2B%20is:open
Please review and let us know how the URL should be updated.
Original:
[crbug-security]
"libwebp Security Issues",
<https://bugs.chromium.org/p/webp/issues/
list?q=label%3ASecurity>.
-->
<reference anchor="crbug-security" target="https://bugs.chromium.org/p/we
bp/issues/list?q=label%3ASecurity">
<front> <front>
<title>libwebp Security Issues</title> <title>libwebp Security Issues</title>
<author> <author>
<organization/> <organization/>
</author> </author>
</front> </front>
</reference> </reference>
<reference anchor="cve.mitre.org-libwebp" <reference anchor="cve.mitre.org-libwebp"
target="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libwebp"> target="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libwebp">
skipping to change at line 2653 skipping to change at line 2766
<reference anchor="Huffman"> <reference anchor="Huffman">
<front> <front>
<title>A Method for the Construction of Minimum-Redundancy <title>A Method for the Construction of Minimum-Redundancy
Codes</title> Codes</title>
<author initials="D." surname="Huffman"> <author initials="D." surname="Huffman">
<organization/> <organization/>
</author> </author>
<date month="September" year="1952" /> <date month="September" year="1952" />
</front> </front>
<seriesInfo name="DOI" value="10.1109/JRPROC.1952.273898"/> <seriesInfo name="DOI" value="10.1109/JRPROC.1952.273898"/>
<refcontent>Proceedings of the Institute of Radio Engineers, Vol. 40, Issue 9 , pp. 1098-1101</refcontent> <refcontent>Proceedings of the IRE, vol. 40, no. 9, pp. 1098-1101</refcontent >
</reference> </reference>
<reference anchor="JPEG-spec" <reference anchor="JPEG-spec"
target="https://www.w3.org/Graphics/JPEG/itu-t81.pdf"> target="https://www.w3.org/Graphics/JPEG/itu-t81.pdf">
<front> <front>
<title>Information Technology - Digital Compression and Coding of Con tinuous-Tone Still Images - Requirements and Guidelines</title> <title>Information Technology - Digital Compression and Coding of Con tinuous-Tone Still Images - Requirements and Guidelines</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date month="September" year="1992"/> <date month="September" year="1992"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="T.81"/> <seriesInfo name="ITU-T Recommendation" value="T.81"/>
<seriesInfo name="ISO/IEC" value="10918-1"/> <seriesInfo name="ISO/IEC" value="10918-1:1993(E)"/>
</reference> </reference>
<reference anchor="LZ77"> <reference anchor="LZ77">
<front> <front>
<title>A Universal Algorithm for Sequential Data Compression</title> <title>A universal algorithm for sequential data compression</title>
<author initials="J." surname="Ziv"> <author initials="J." surname="Ziv">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Lempel"> <author initials="A." surname="Lempel">
<organization/> <organization/>
</author> </author>
<date month="May" year="1977" /> <date month="May" year="1977" />
</front> </front>
<seriesInfo name="DOI" value="10.1109/TIT.1977.1055714"/> <seriesInfo name="DOI" value="10.1109/TIT.1977.1055714"/>
<refcontent>IEEE Transactions on Information Theory, Vol. 23, Issue 3, pp. 33 7-343</refcontent> <refcontent>IEEE Transactions on Information Theory, vol. 23, no. 3, pp. 337- 343</refcontent>
</reference> </reference>
<reference anchor="MWG" target="https://web.archive.org/web/20180 919181934/http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf"> <reference anchor="MWG" target="https://web.archive.org/web/20180 919181934/http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf">
<front> <front>
<title>Guidelines For Handling Image Metadata</title> <title>Guidelines For Handling Image Metadata</title>
<author> <author>
<organization>Metadata Working Group</organization> <organization>Metadata Working Group</organization>
</author> </author>
<date month="November" year="2010"/> <date month="November" year="2010"/>
</front> </front>
<refcontent>Version 2.0</refcontent> <refcontent>Version 2.0, Wayback Machine archive</refcontent>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2083.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2083.xml" />
<reference anchor="RIFF-spec" <reference anchor="RIFF-spec"
target="https://www.loc.gov/preservation/digital/formats/fdd/fdd000025.shtml"> target="https://www.loc.gov/preservation/digital/formats/fdd/fdd000025.shtml">
<front> <front>
<title>RIFF (Resource Interchange File Format)</title> <title>RIFF (Resource Interchange File Format)</title>
<author> <author>
<organization/> <organization/>
</author> </author>
</front> </front>
<refcontent>From the Library of Congress, Sustainability of Digital Forma ts</refcontent>
</reference> </reference>
<!--[rfced] We have made some updates to the text. Please ensure that
the source documents listed below are updated to match the document
accordingly.
Additionally, once this document is ready for publication, we will
confirm that the links work correctly. They currently lead to
pages that require signing in to access.
[webp-lossless-src]
Alakuijala, J., "WebP Lossless Bitstream Specification",
October 2023,
<https://chromium.googlesource.com/webm/libwebp/+/refs/
tags/webp-rfc9649/doc/webp-lossless-bitstream-spec.txt>.
[webp-riff-src]
Google LLC, "WebP RIFF Container", April 2024,
<https://chromium.googlesource.com/webm/libwebp/+/refs/
tags/webp-rfc9649/doc/webp-container-spec.txt>.
-->
<reference anchor="webp-lossless-src" <reference anchor="webp-lossless-src"
target="https://chromium.googlesource.com/webm/libwebp/+/refs/tags/webp -rfcXXXX/doc/webp-lossless-bitstream-spec.txt"> target="https://chromium.googlesource.com/webm/libwebp/+/refs/tags/webp -rfc9649/doc/webp-lossless-bitstream-spec.txt">
<front> <front>
<title>WebP Lossless Bitstream Specification</title> <title>WebP Lossless Bitstream Specification</title>
<author initials="J." surname="Alakuijala" <author initials="J." surname="Alakuijala"
fullname="Jyrki Alakuijala"> fullname="Jyrki Alakuijala">
<organization>Google LLC</organization> <organization>Google LLC</organization>
</author> </author>
<date month="October" year="2023" /> <date month="October" year="2023" />
</front> </front>
</reference> </reference>
skipping to change at line 2732 skipping to change at line 2866
<author initials="J." surname="Alakuijala" <author initials="J." surname="Alakuijala"
fullname="Jyrki Alakuijala"> fullname="Jyrki Alakuijala">
<organization>Google LLC</organization> <organization>Google LLC</organization>
</author> </author>
<author initials="V." surname="Rabaud" <author initials="V." surname="Rabaud"
fullname="Vincent Rabaud"> fullname="Vincent Rabaud">
<organization>Google LLC</organization> <organization>Google LLC</organization>
</author> </author>
<date month="August" year="2017" /> <date month="August" year="2017" />
</front> </front>
<refcontent>Google LLC</refcontent>
</reference> </reference>
<reference anchor="webp-riff-src" target="https://chromium.googlesour ce.com/webm/libwebp/+/refs/tags/webp-rfcXXXX/doc/webp-container-spec.txt"> <reference anchor="webp-riff-src" target="https://chromium.googlesour ce.com/webm/libwebp/+/refs/tags/webp-rfc9649/doc/webp-container-spec.txt">
<front> <front>
<title>WebP RIFF Container</title> <title>WebP RIFF Container</title>
<author> <author>
<organization>Google LLC</organization> <organization>Google LLC</organization>
</author> </author>
<date month="April" year="2024" /> <date month="April" year="2024" />
</front> </front>
</reference> </reference>
</references> </references>
</references> </references>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 91 change blocks. 
140 lines changed or deleted 293 lines changed or added

This html diff was produced by rfcdiff 1.48.