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.