From 6bdd36dbe7d0e82c57d1766145dabe55ae4ab9d4 Mon Sep 17 00:00:00 2001 From: James Zern Date: Mon, 26 Sep 2022 17:27:42 -0700 Subject: [PATCH 01/13] webp-container-spec: clarify Chunk Size is in bytes based on comments from: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_robert-wilton Bug: webp:448 Change-Id: Idc874e5fa04d3cd122d31b87e833bf9f30ec9d05 --- doc/webp-container-spec.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index 63ec01d7..fba29b72 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -123,8 +123,8 @@ Chunk FourCC: 32 bits Chunk Size: 32 bits (_uint32_) -: The size of the chunk not including this field, the chunk identifier or - padding. +: The size of the chunk in bytes, not including this field, the chunk + identifier or padding. Chunk Payload: _Chunk Size_ bytes From 41f0bf680b0b139417bafdd92ec96ae666d29a61 Mon Sep 17 00:00:00 2001 From: James Zern Date: Mon, 26 Sep 2022 17:28:54 -0700 Subject: [PATCH 02/13] webp-container-spec: update note on trailing data clarify that the data is after the size specified by the file size in the header; an alternate way to read the previous statement was that the data was after the 'WEBP' fourcc. based on comments from: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_robert-wilton Bug: webp:448 Change-Id: I7c5c5440a94cb817da51fe07d1ccf45d6af0f001 --- doc/webp-container-spec.txt | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index fba29b72..de17be46 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -166,10 +166,11 @@ File Size: 32 bits (_uint32_) A WebP file MUST begin with a RIFF header with the FourCC 'WEBP'. The file size in the header is the total size of the chunks that follow plus `4` bytes for -the 'WEBP' FourCC. The file SHOULD NOT contain anything after it. Readers MAY -parse such files, ignoring the trailing data. As the size of any chunk is even, -the size given by the RIFF header is also even. The contents of individual -chunks will be described in the following sections. +the 'WEBP' FourCC. The file SHOULD NOT contain any data after the data +specified by _File Size_. Readers MAY parse such files, ignoring the trailing +data. As the size of any chunk is even, the size given by the RIFF header is +also even. The contents of individual chunks will be described in the following +sections. Simple File Format (Lossy) From 280a810f2a834cb1bfcce4f2b12308d9543d5af8 Mon Sep 17 00:00:00 2001 From: James Zern Date: Mon, 26 Sep 2022 17:31:05 -0700 Subject: [PATCH 03/13] webp-container-spec: make padding byte=0 a MUST this is consistent with the RIFF specification. based on comments from: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_robert-wilton Bug: webp:448 Change-Id: I7a09177c9ea001b2e8759dcc5102242864c78105 --- doc/webp-container-spec.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index de17be46..d2bc2458 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -128,9 +128,8 @@ Chunk Size: 32 bits (_uint32_) Chunk Payload: _Chunk Size_ bytes -: The data payload. If _Chunk Size_ is odd, a single padding byte -- that - SHOULD be `0` to conform with RIFF -- is added. Applications MAY use - another value, but readers may fail to parse the file. +: The data payload. If _Chunk Size_ is odd, a single padding byte -- that MUST + be `0` to conform with RIFF -- is added. **Note:** RIFF has a convention that all-uppercase chunk FourCCs are standard chunks that apply to any RIFF file format, while FourCCs specific to a file From 1dc594352f22e24861c0e31b3ec14c6822f79be8 Mon Sep 17 00:00:00 2001 From: James Zern Date: Mon, 26 Sep 2022 19:18:00 -0700 Subject: [PATCH 04/13] webp-container-spec: add unknown fields MUST be ignored based on comments in: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_paul-wouters Bug: webp:448 Change-Id: I1eccb573b536f931b123261662efad7f92700500 --- doc/webp-container-spec.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index d2bc2458..1856e713 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -366,7 +366,7 @@ Canvas Height Minus One: 24 bits The product of _Canvas Width_ and _Canvas Height_ MUST be at most `2^32 - 1`. -Future specifications MAY add more fields. +Future specifications may add more fields. Unknown fields MUST be ignored. ### Chunks From a8f6b5ee949048a772561e053bb162d4cfcb5c3a Mon Sep 17 00:00:00 2001 From: James Zern Date: Mon, 26 Sep 2022 19:19:36 -0700 Subject: [PATCH 05/13] webp-container-spec: change SHOULD to MUST w/ANIM chunk based on comments in: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_paul-wouters Bug: webp:448 Change-Id: I9464dbbd734f1b78b287139eff13b1db8814c8d9 --- doc/webp-container-spec.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index 1856e713..28e1fef9 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -414,8 +414,8 @@ Loop Count: 16 bits (_uint16_) : The number of times to loop the animation. `0` means infinitely. This chunk MUST appear if the _Animation_ flag in the VP8X chunk is set. -If the _Animation_ flag is not set and this chunk is present, it -SHOULD be ignored. +If the _Animation_ flag is not set and this chunk is present, it MUST be +ignored. ANMF chunk: From 902dd787627f2263fe740e652830e06cb00afa41 Mon Sep 17 00:00:00 2001 From: James Zern Date: Thu, 29 Sep 2022 18:48:04 -0700 Subject: [PATCH 06/13] webp-container-spec: prefer hex literals to ABNF-style values; this makes the doc more consistent with doc/webp-lossless-bitstream-spec.txt. based on comments from: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_lars-eggert Bug: webp:448 Change-Id: I751cf0b7f728866ae663beb06e6352e5b3d848b2 --- doc/webp-container-spec.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index 28e1fef9..c73f7356 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -84,8 +84,8 @@ _uint32_ _FourCC_ : A _FourCC_ (four-character code) is a _uint32_ created by concatenating four - ASCII characters in little-endian order. This means 'aaaa' (%x61.61.61.61) and - 'AAAA' (%x41.41.41.41) are treated as different _FourCCs_. + ASCII characters in little-endian order. This means 'aaaa' (0x61616161) and + 'AAAA' (0x41414141) are treated as different _FourCCs_. _1-based_ @@ -206,7 +206,7 @@ VP8 data: _Chunk Size_ bytes : VP8 bitstream data. -Note the fourth character in the 'VP8 ' FourCC is an ASCII space (%x20). +Note the fourth character in the 'VP8 ' FourCC is an ASCII space (0x20). The VP8 bitstream format specification can be found at [VP8 Data Format and Decoding Guide][vp8spec]. Note that the VP8 frame header contains the VP8 frame @@ -721,7 +721,7 @@ XMP Metadata: _Chunk Size_ bytes : image metadata in XMP format. -Note the fourth character in the 'XMP ' FourCC is an ASCII space (%x20). +Note the fourth character in the 'XMP ' FourCC is an ASCII space (0x20). Additional guidance about handling metadata can be found in the Metadata Working Group's [Guidelines for Handling Metadata][metadata]. From 951c292d12a6f10ca7c18c6201a29dff04789eb1 Mon Sep 17 00:00:00 2001 From: James Zern Date: Thu, 29 Sep 2022 18:50:19 -0700 Subject: [PATCH 07/13] webp-container-spec: come too late -> out of order based on comments from: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_lars-eggert Bug: webp:448 Change-Id: Ie32d5500f3966b3c9f910675fb11d8a2cc60de3c --- doc/webp-container-spec.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index c73f7356..93bbc031 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -292,7 +292,7 @@ details about frames can be found in the [Animation](#animation) section. All chunks SHOULD be placed in the same order as listed above. If a chunk appears in the wrong place, the file is invalid, but readers MAY parse the -file, ignoring the chunks that come too late. +file, ignoring the chunks that are out of order. **Rationale:** Setting the order of chunks should allow quicker file parsing. For example, if an 'ALPH' chunk does not appear in its required From 3ed2b275175325ed0be711d652092bed5bc1837c Mon Sep 17 00:00:00 2001 From: James Zern Date: Thu, 29 Sep 2022 18:52:20 -0700 Subject: [PATCH 08/13] webp-container-spec: clarify background color note replace ...a transparency value (alpha)... with clearer text based on comments from: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_lars-eggert Bug: webp:448 Change-Id: I79157b669c4317ebfc4f8434ee38f2666d1559ec --- doc/webp-container-spec.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index 93bbc031..9a2be1a8 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -400,8 +400,8 @@ Background Color: 32 bits (_uint32_) **Note**: - * Background color MAY contain a transparency value (alpha), even if the - _Alpha_ flag in [VP8X chunk](#extended_header) is unset. + * Background color MAY contain a non-opaque alpha value, even if the _Alpha_ + flag in [VP8X chunk](#extended_header) is unset. * Viewer applications SHOULD treat the background color value as a hint, and are not required to use it. From 8a6185dd27fd23d60fbb642e1ba3e9fa0d59ee16 Mon Sep 17 00:00:00 2001 From: James Zern Date: Thu, 29 Sep 2022 18:58:27 -0700 Subject: [PATCH 09/13] doc/webp-*: fix some punctuation, grammar based on comments from: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_lars-eggert Bug: webp:448 Change-Id: I0a410b28b7b62fb4552ea3db444743be61469fe8 --- doc/webp-container-spec.txt | 2 +- doc/webp-lossless-bitstream-spec.txt | 23 +++++++++++------------ 2 files changed, 12 insertions(+), 13 deletions(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index 9a2be1a8..fece8f6b 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -25,7 +25,7 @@ to compress image data in a lossy way, or (ii) the WebP lossless encoding (and possibly other encodings in the future). These encoding schemes should make it more efficient than currently used formats. It is optimized for fast image transfer over the network (e.g., for websites). The WebP format has -feature parity (color profile, metadata, animation etc) with other formats as +feature parity (color profile, metadata, animation, etc.) with other formats as well. This document describes the structure of a WebP file. The WebP container (i.e., RIFF container for WebP) allows feature support over diff --git a/doc/webp-lossless-bitstream-spec.txt b/doc/webp-lossless-bitstream-spec.txt index c1ff493e..3c882bb4 100644 --- a/doc/webp-lossless-bitstream-spec.txt +++ b/doc/webp-lossless-bitstream-spec.txt @@ -51,7 +51,7 @@ the stream containing them, and bits of each byte are read in least-significant-bit-first order. When multiple bits are read at the same time, the integer is constructed from the original data in the original order. The most significant bits of the returned integer are -also the most significant bits of the original data. Thus the statement +also the most significant bits of the original data. Thus, the statement ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ b = ReadBits(2); @@ -196,7 +196,7 @@ once. The transformations are used only for the main level ARGB image: the subresolution images have no transforms, not even the 0 bit indicating the end-of-transforms. -Typically an encoder would use these transforms to reduce the Shannon +Typically, an encoder would use these transforms to reduce the Shannon entropy in the residual image. Also, the transform data can be decided based on entropy minimization. @@ -568,7 +568,7 @@ distribution entropy coding of neighboring pixels, and gives some arithmetic coding-like benefits to the entropy code, but it can only be used when there are a small number of unique values. -`color_table_size` specifies how many pixels are combined together: +`color_table_size` specifies how many pixels are combined: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ int width_bits; @@ -583,13 +583,12 @@ if (color_table_size <= 2) { } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -`width_bits` has a value of 0, 1, 2 or 3. A value of 0 indicates no -pixel bundling to be done for the image. A value of 1 indicates that two -pixels are combined together, and each pixel has a range of \[0..15\]. A -value of 2 indicates that four pixels are combined together, and each -pixel has a range of \[0..3\]. A value of 3 indicates that eight pixels -are combined together and each pixel has a range of \[0..1\], i.e., a -binary value. +`width_bits` has a value of 0, 1, 2 or 3. A value of 0 indicates no pixel +bundling to be done for the image. A value of 1 indicates that two pixels are +combined, and each pixel has a range of \[0..15\]. A value of 2 indicates that +four pixels are combined, and each pixel has a range of \[0..3\]. A value of 3 +indicates that eight pixels are combined and each pixel has a range of \[0..1\], +i.e., a binary value. The values are packed into the green component as follows: @@ -659,7 +658,7 @@ Each pixel is encoded using one of the three possible methods: 3. Color cache code: using a short multiplicative hash code (color cache index) of a recently seen color. -The following sub-sections describe each of these in detail. +The following subsections describe each of these in detail. #### 5.2.1 Prefix Coded Literals @@ -725,7 +724,7 @@ return offset + ReadBits(extra_bits) + 1; {:#distance-mapping} As noted previously, distance code is a number indicating the position of a -previously seen pixel, from which the pixels are to be copied. This sub-section +previously seen pixel, from which the pixels are to be copied. This subsection defines the mapping between a distance code and the position of a previous pixel. From dfd32e45922144f8b43fc5d5f8410b472c8de6b6 Mon Sep 17 00:00:00 2001 From: James Zern Date: Thu, 29 Sep 2022 19:00:21 -0700 Subject: [PATCH 10/13] webp-container-spec: remove redundant sentence in the note regarding metadata the possibility of multiple XMP/EXIF chunks was already covered in the previous sentences. based on comments from: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_lars-eggert Bug: webp:448 Change-Id: I6ee938e4d95bda1b144d3175fbf9f9296cf23352 --- doc/webp-container-spec.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index fece8f6b..8618f6eb 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -686,8 +686,7 @@ If this chunk is not present, sRGB SHOULD be assumed. Metadata can be stored in 'EXIF' or 'XMP ' chunks. There SHOULD be at most one chunk of each type ('EXIF' and 'XMP '). If there -are more such chunks, readers MAY ignore all except the first one. Also, a file -may possibly contain both 'EXIF' and 'XMP ' chunks. +are more such chunks, readers MAY ignore all except the first one. The chunks are defined as follows: From 57101d3fc5abcdffb86b7a5550ab7cd4691d33bb Mon Sep 17 00:00:00 2001 From: James Zern Date: Thu, 29 Sep 2022 19:03:03 -0700 Subject: [PATCH 11/13] webp-lossless-bitstream-spec: improve 'small' color table stmt this is defined earlier as 16 or fewer unique values based on comments from: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_lars-eggert Bug: webp:448 Change-Id: If9e18e5aaec3641e477c2bb68dacc0a4fd029cfb --- doc/webp-lossless-bitstream-spec.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/webp-lossless-bitstream-spec.txt b/doc/webp-lossless-bitstream-spec.txt index 3c882bb4..bb5a9435 100644 --- a/doc/webp-lossless-bitstream-spec.txt +++ b/doc/webp-lossless-bitstream-spec.txt @@ -566,7 +566,7 @@ pixels are bundled into a single pixel. The pixel bundling packs several respectively. Pixel bundling allows for a more efficient joint distribution entropy coding of neighboring pixels, and gives some arithmetic coding-like benefits to the entropy code, but it can only be -used when there are a small number of unique values. +used when there are 16 or fewer unique values. `color_table_size` specifies how many pixels are combined: From 73b19b64fd169b4916333c9f0e6d5389b3127d36 Mon Sep 17 00:00:00 2001 From: James Zern Date: Mon, 10 Oct 2022 14:05:04 -0700 Subject: [PATCH 12/13] webp-container-spec: note reserved fields MUST be ignored based on comments in: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_lars-eggert Bug: webp:448 Change-Id: I45880467d8955389a2ef657beca9d734da223457 --- doc/webp-container-spec.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index 8618f6eb..c283374c 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -322,7 +322,7 @@ Extended WebP file header: Reserved (Rsv): 2 bits -: MUST be `0`. +: MUST be `0`. Readers MUST ignore this field. ICC profile (I): 1 bit @@ -348,11 +348,11 @@ Animation (A): 1 bit Reserved (R): 1 bit -: MUST be `0`. +: MUST be `0`. Readers MUST ignore this field. Reserved: 24 bits -: MUST be `0`. +: MUST be `0`. Readers MUST ignore this field. Canvas Width Minus One: 24 bits @@ -466,7 +466,7 @@ Frame Duration: 24 bits (_uint24_) Reserved: 6 bits -: MUST be 0. +: MUST be `0`. Readers MUST ignore this field. Blending method (B): 1 bit @@ -547,7 +547,7 @@ _padded_ chunks as described by the [RIFF file format](#riff-file-format). Reserved (Rsv): 2 bits -: MUST be `0`. +: MUST be `0`. Readers MUST ignore this field. Pre-processing (P): 2 bits From 83270c7f8941e4d851dc59dc5099619db076979c Mon Sep 17 00:00:00 2001 From: James Zern Date: Mon, 10 Oct 2022 17:23:58 -0700 Subject: [PATCH 13/13] webp-container-spec: add prose for rendering process this is given in addition to the pseudocode, which has been corrected in the process based on comments in: https://datatracker.ietf.org/doc/draft-zern-webp/ballot/#draft-zern-webp_lars-eggert Bug: webp:448 Change-Id: I96bc063c2a71572ff61609a731a9c4e8edc2b971 --- doc/webp-container-spec.txt | 37 ++++++++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 7 deletions(-) diff --git a/doc/webp-container-spec.txt b/doc/webp-container-spec.txt index c283374c..38a3e2ce 100644 --- a/doc/webp-container-spec.txt +++ b/doc/webp-container-spec.txt @@ -746,19 +746,40 @@ original order (unless they specifically intend to modify these chunks). ### Assembling the Canvas from frames -Here we provide an overview of how a reader should assemble a canvas in the -case of an animated image. The notation _VP8X.field_ means the field in the -'VP8X' chunk with the same description. +Here we provide an overview of how a reader MUST assemble a canvas in the case +of an animated image. -Displaying an _animated image_ canvas MUST be equivalent to the following -pseudocode: +The process begins with creating a canvas using the dimensions given in the +'VP8X' chunk, `Canvas Width Minus One + 1` pixels wide by `Canvas Height Minus +One + 1` pixels high. The `Loop Count` field from the 'ANIM' chunk controls how +many times the animation process is repeated. This is `Loop Count - 1` for +non-zero `Loop Count` values or infinitely if `Loop Count` is zero. + +At the beginning of each loop iteration the canvas is filled using the +background color from the 'ANIM' chunk or an application defined color. + +'ANMF' chunks contain individual frames given in display order. Before rendering +each frame, the previous frame's `Disposal method` is applied. + +The rendering of the decoded frame begins at the Cartesian coordinates (`2 * +Frame X`, `2 * Frame Y`) using the top-left corner of the canvas as the origin. +`Frame Width Minus One + 1` pixels wide by `Frame Height Minus One + 1` pixels +high are rendered onto the canvas using the `Blending method`. + +The canvas is displayed for `Frame Duration` milliseconds. This continues until +all frames given by 'ANMF' chunks have been displayed. A new loop iteration is +then begun or the canvas is left in its final state if all iterations have been +completed. + +The following pseudocode illustrates the rendering process. The notation +_VP8X.field_ means the field in the 'VP8X' chunk with the same description. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ assert VP8X.flags.hasAnimation canvas ← new image of size VP8X.canvasWidth x VP8X.canvasHeight with background color ANIM.background_color. loop_count ← ANIM.loopCount -dispose_method ← ANIM.disposeMethod +dispose_method ← Dispose to background color if loop_count == 0: loop_count = ∞ frame_params ← nil @@ -784,10 +805,12 @@ for loop = 0..loop_count - 1 frame_params.bitstream = bitstream_data render frame with frame_params.alpha and frame_params.bitstream on canvas with top-left corner at (frame_params.frameX, - frame_params.frameY), using dispose method dispose_method. + frame_params.frameY), using blending method + frame_params.blendingMethod. canvas contains the decoded image. Show the contents of the canvas for frame_params.frameDuration * 1ms. + dispose_method = frame_params.disposeMethod ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~