Diff: rfc9649v2.txt - rfc9649.txt

	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	November 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 2177 ¶	skipping to change at line 2177 ¶
	overflows, out-of-bounds reads and writes to both heap and stack,	overflows, out-of-bounds reads and writes to both heap and stack,
	uninitialized data usage, null pointer dereferences, resource (disk	uninitialized data usage, null pointer dereferences, resource (disk
	or memory) exhaustion, and extended resource usage (long running	or memory) exhaustion, and extended resource usage (long running
	time) as part of the demuxing and decoding process. In particular,	time) as part of the demuxing and decoding process. In particular,
	implementations reading this format are likely to take input from	implementations reading this format are likely to take input from
	unknown and possibly unsafe sources -- both clients (for example, web	unknown and possibly unsafe sources -- both clients (for example, web
	browsers or email clients) and servers (for example, applications	browsers or email clients) and servers (for example, applications
	that accept uploaded images). These may result in arbitrary code	that accept uploaded images). These may result in arbitrary code
	execution, information leakage (memory layout and contents), or	execution, information leakage (memory layout and contents), or
	crashes and thereby allow a device to be compromised or cause a	crashes and thereby allow a device to be compromised or cause a

	denial of service to an application using the format	denial of service to an application using the format [mitre-libwebp]
	[cve.mitre.org-libwebp] [issues-security].	[issues-security].

	The format does not employ "active content" but does allow metadata	The format does not employ "active content" but does allow metadata
	(for example, [XMP] and [Exif]) and custom chunks to be embedded in a	(for example, [XMP] and [Exif]) and custom chunks to be embedded in a
	file. Applications that interpret these chunks may be subject to	file. Applications that interpret these chunks may be subject to
	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].


	skipping to change at line 2254 ¶	skipping to change at line 2255 ¶
	Zern <jzern@google.com>	Zern <jzern@google.com>

	Intended usage: COMMON	Intended usage: COMMON

	Restrictions on usage: N/A	Restrictions on usage: N/A

	Author: James Zern <jzern@google.com>	Author: James Zern <jzern@google.com>

	Change controller: IETF	Change controller: IETF


	Provisional registration?: No

	7. References	7. References

	7.1. Normative References	7.1. Normative References

	[Exif] Camera & Imaging Products Association (CIPA) and Japan	[Exif] Camera & Imaging Products Association (CIPA) and Japan
	Electronics and Information Technology Industries	Electronics and Information Technology Industries
	Association (JEITA), "Exchangeable image file format for	Association (JEITA), "Exchangeable image file format for
	digital still cameras: Exif Version 2.3", CIPA DC-	digital still cameras: Exif Version 2.3", CIPA DC-
	008-2012, JEITA CP-3451C, December 2012,	008-2012, JEITA CP-3451C, December 2012,
	<https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf>.	<https://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf>.

	skipping to change at line 2334 ¶	skipping to change at line 2333 ¶

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.	May 2017, <https://www.rfc-editor.org/info/rfc8174>.

	[XMP] Adobe Inc., "XMP Specification",	[XMP] Adobe Inc., "XMP Specification",
	<https://www.adobe.com/devnet/xmp.html>.	<https://www.adobe.com/devnet/xmp.html>.

	7.2. Informative References	7.2. Informative References


	[cve.mitre.org-libwebp]
	"libwebp CVE List", <https://cve.mitre.org/cgi-bin/
	cvekey.cgi?keyword=libwebp>.

	[GIF-spec] CompuServe Incorporated, "Graphics Interchange	[GIF-spec] CompuServe Incorporated, "Graphics Interchange
	Format(sm)", Version 89a, July 1990,	Format(sm)", Version 89a, July 1990,
	<https://www.w3.org/Graphics/GIF/spec-gif89a.txt>.	<https://www.w3.org/Graphics/GIF/spec-gif89a.txt>.

	[Huffman] Huffman, D., "A Method for the Construction of Minimum-	[Huffman] Huffman, D., "A Method for the Construction of Minimum-
	Redundancy Codes", Proceedings of the Institute of Radio	Redundancy Codes", Proceedings of the Institute of Radio
	Engineers, Vol. 40, Issue 9, pp. 1098-1101,	Engineers, Vol. 40, Issue 9, pp. 1098-1101,
	DOI 10.1109/JRPROC.1952.273898, September 1952,	DOI 10.1109/JRPROC.1952.273898, September 1952,
	<https://doi.org/10.1109/JRPROC.1952.273898>.	<https://doi.org/10.1109/JRPROC.1952.273898>.


	skipping to change at line 2367 ¶	skipping to change at line 2362 ¶
	Guidelines", ITU-T Recommendation T.81, ISO/IEC 10918-1,	Guidelines", ITU-T Recommendation T.81, ISO/IEC 10918-1,
	September 1992,	September 1992,
	<https://www.w3.org/Graphics/JPEG/itu-t81.pdf>.	<https://www.w3.org/Graphics/JPEG/itu-t81.pdf>.

	[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for	[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for
	Sequential Data Compression", IEEE Transactions on	Sequential Data Compression", IEEE Transactions on
	Information Theory, Vol. 23, Issue 3, pp. 337-343,	Information Theory, Vol. 23, Issue 3, pp. 337-343,
	DOI 10.1109/TIT.1977.1055714, May 1977,	DOI 10.1109/TIT.1977.1055714, May 1977,
	<https://doi.org/10.1109/TIT.1977.1055714>.	<https://doi.org/10.1109/TIT.1977.1055714>.


		[mitre-libwebp]
		"libwebp CVE List", <https://cve.mitre.org/cgi-bin/
		cvekey.cgi?keyword=libwebp>.

	[MWG] Metadata Working Group, "Guidelines For Handling Image	[MWG] Metadata Working Group, "Guidelines For Handling Image
	Metadata", Version 2.0, November 2010,	Metadata", Version 2.0, November 2010,
	<https://web.archive.org/web/20180919181934/	<https://web.archive.org/web/20180919181934/
	http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf>.	http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf>.

	[RFC2083] Boutell, T., "PNG (Portable Network Graphics)	[RFC2083] Boutell, T., "PNG (Portable Network Graphics)
	Specification Version 1.0", RFC 2083,	Specification Version 1.0", RFC 2083,
	DOI 10.17487/RFC2083, March 1997,	DOI 10.17487/RFC2083, March 1997,
	<https://www.rfc-editor.org/info/rfc2083>.	<https://www.rfc-editor.org/info/rfc2083>.


End of changes. 9 change blocks.
	17 lines changed or deleted	16 lines changed or added
This html diff was produced by rfcdiff 1.48.