rfc9649v2.txt | rfc9649.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) J. Zern | Internet Engineering Task Force (IETF) J. Zern | |||
Request for Comments: 9649 P. Massimino | Request for Comments: 9649 P. Massimino | |||
Category: Informational J. Alakuijala | Category: Informational J. Alakuijala | |||
ISSN: 2070-1721 Google LLC | ISSN: 2070-1721 Google LLC | |||
September 2024 | October 2024 | |||
WebP Image Format | WebP Image Format | |||
Abstract | Abstract | |||
This document defines the WebP image format and registers a media | This document defines the WebP image format and registers a media | |||
type supporting its use. | type supporting its use. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at line 493 ¶ | skipping to change at line 493 ¶ | |||
For an animated image, this chunk contains the _global parameters_ of | For an animated image, this chunk contains the _global parameters_ of | |||
the animation. | the animation. | |||
Background Color: 32 bits (_uint32_) | Background Color: 32 bits (_uint32_) | |||
The default background color of the canvas in [Blue, Green, Red, | The default background color of the canvas in [Blue, Green, Red, | |||
Alpha] byte order. This color MAY be used to fill the unused | Alpha] byte order. This color MAY be used to fill the unused | |||
space on the canvas around the frames, as well as the transparent | space on the canvas around the frames, as well as the transparent | |||
pixels of the first frame. The background color is also used | pixels of the first frame. The background color is also used | |||
when the Disposal method is 1. | when the Disposal method is 1. | |||
Note: | Notes: | |||
* The background color MAY contain a nonopaque alpha value, even | * The background color MAY contain a nonopaque alpha value, even | |||
if the _Alpha_ flag in the 'VP8X' Chunk (Figure 7) is unset. | if the _Alpha_ flag in the 'VP8X' Chunk (Figure 7) is unset. | |||
* Viewer applications SHOULD treat the background color value as | * Viewer applications SHOULD treat the background color value as | |||
a hint and are not required to use it. | a hint and are not required to use it. | |||
* The canvas is cleared at the start of each loop. The | * The canvas is cleared at the start of each loop. The | |||
background color MAY be used to achieve this. | background color MAY be used to achieve this. | |||
skipping to change at line 742 ¶ | skipping to change at line 742 ¶ | |||
* Raw data: This consists of a byte sequence of length = width * | * Raw data: This consists of a byte sequence of length = width * | |||
height, containing all the 8-bit transparency values in scan | height, containing all the 8-bit transparency values in scan | |||
order. | order. | |||
* Lossless format compression: The byte sequence is a compressed | * Lossless format compression: The byte sequence is a compressed | |||
image-stream (as described in Section 3) of implicit dimensions | image-stream (as described in Section 3) of implicit dimensions | |||
width x height. That is, this image-stream does NOT contain any | width x height. That is, this image-stream does NOT contain any | |||
headers describing the image dimensions. | headers describing the image dimensions. | |||
Rationale: The dimensions are already known from other sources, so | | Rationale: The dimensions are already known from other sources, | |||
storing them again would be redundant and prone to errors. | | so storing them again would be redundant and prone to errors. | |||
Once the image-stream is decoded into Alpha, Red, Green, Blue | Once the image-stream is decoded into Alpha, Red, Green, Blue | |||
(ARGB) color values, following the process described in the | (ARGB) color values, following the process described in the | |||
lossless format specification, the transparency information must | lossless format specification, the transparency information must | |||
be extracted from the green channel of the ARGB quadruplet. | be extracted from the green channel of the ARGB quadruplet. | |||
Rationale: The green channel is allowed extra transformation steps | | Rationale: The green channel is allowed extra transformation | |||
in the specification -- unlike the other channels -- that can | | steps in the specification -- unlike the other channels -- that | |||
improve compression. | | can improve compression. | |||
2.7.1.3. Bitstream (VP8/VP8L) | 2.7.1.3. Bitstream (VP8/VP8L) | |||
This chunk contains compressed bitstream data for a single frame. | This chunk contains compressed bitstream data for a single frame. | |||
A bitstream chunk may be either (i) a 'VP8 ' Chunk, using 'VP8 ' | A bitstream chunk may be either (i) a 'VP8 ' Chunk, using 'VP8 ' | |||
(note the significant fourth-character space) as its FourCC, _or_ | (note the significant fourth-character space) as its FourCC, _or_ | |||
(ii) a 'VP8L' Chunk, using 'VP8L' as its FourCC. | (ii) a 'VP8L' Chunk, using 'VP8L' as its FourCC. | |||
The formats of' VP8 ' and 'VP8L' Chunks are as described in Sections | The formats of' VP8 ' and 'VP8L' Chunks are as described in Sections | |||
skipping to change at line 2193 ¶ | skipping to change at line 2193 ¶ | |||
security considerations for those formats. | security considerations for those formats. | |||
5. Interoperability Considerations | 5. Interoperability Considerations | |||
The format is defined using little-endian byte ordering (see | The format is defined using little-endian byte ordering (see | |||
Section 3.1 of [RFC2781]), but demuxing and decoding are possible on | Section 3.1 of [RFC2781]), but demuxing and decoding are possible on | |||
platforms using a different ordering with the appropriate conversion. | platforms using a different ordering with the appropriate conversion. | |||
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 | |||
(Section 2) are required for decoding of the image. These have been | (Section 2) are required for decoding of the image. These have been | |||
finalized but were extended in the format's early stages, so some | finalized, but they were extended in the format's early stages, so | |||
older readers may not support lossless or animated image decoding. | some older readers may not support lossless or animated image | |||
decoding. | ||||
6. IANA Considerations | 6. IANA Considerations | |||
IANA has registered the 'image/webp' media type [RFC2046]. | IANA has registered the 'image/webp' media type [RFC2046]. | |||
6.1. The 'image/webp' Media Type | 6.1. The 'image/webp' Media Type | |||
This section contains the media type registration details per | This section contains the media type registration details per | |||
[RFC6838]. | [RFC6838]. | |||
End of changes. 5 change blocks. | ||||
9 lines changed or deleted | 10 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |