diff options
author | James Zern <jzern@google.com> | 2022-11-21 10:40:33 -0800 |
---|---|---|
committer | James Zern <jzern@google.com> | 2022-11-21 16:48:41 -0800 |
commit | b5700efb705e4e07944e73866b3ac3cd9cbdc381 (patch) | |
tree | 42a7b4232b7c0ef0af49415d4fdff0cda27af9ed | |
parent | 52ec0b8f61a480509f92d13a9dba3be66ce4998b (diff) | |
download | libwebp-b5700efb705e4e07944e73866b3ac3cd9cbdc381.tar.gz |
webp-lossless-bitstream-spec,cosmetics: grammar/capitalization
Bug: webp:448
Change-Id: I2d6cc66b45342716fdba7792c570510601432109
-rw-r--r-- | doc/webp-lossless-bitstream-spec.txt | 50 |
1 files changed, 25 insertions, 25 deletions
diff --git a/doc/webp-lossless-bitstream-spec.txt b/doc/webp-lossless-bitstream-spec.txt index 79a8ea00..89c9d012 100644 --- a/doc/webp-lossless-bitstream-spec.txt +++ b/doc/webp-lossless-bitstream-spec.txt @@ -40,7 +40,7 @@ today's PNG format. -------------- This document describes the compressed data representation of a WebP -lossless image. It is intended as a detailed reference for WebP lossless +lossless image. It is intended as a detailed reference for the WebP lossless encoder and decoder implementation. In this document, we extensively use C programming language syntax to @@ -380,7 +380,7 @@ on the same row as the current pixel is instead used as the TR-pixel. \[AMENDED2\] The goal of the color transform is to decorrelate the R, G and B values -of each pixel. Color transform keeps the green (G) value as it is, +of each pixel. The color transform keeps the green (G) value as it is, transforms red (R) based on green and transforms blue (B) based on green and then based on red. @@ -399,7 +399,7 @@ typedef struct { The actual color transformation is done by defining a color transform delta. The color transform delta depends on the `ColorTransformElement`, which is the same for all the pixels in a particular block. The delta is -subtracted during color transform. The inverse color transform then is just +subtracted during the color transform. The inverse color transform then is just adding those deltas. The color transform function is defined as follows: @@ -475,7 +475,7 @@ void InverseTransform(uint8 red, uint8 green, uint8 blue, int tmp_red = red; int tmp_blue = blue; - // Applying inverse transform is just adding the + // Applying the inverse transform is just adding the // color transform deltas tmp_red += ColorTransformDelta(trans->green_to_red, green); tmp_blue += ColorTransformDelta(trans->green_to_blue, green); @@ -517,7 +517,7 @@ create a color index array and replace the pixel values by the array's indices. The color indexing transform achieves this. (In the context of WebP lossless, we specifically do not call this a palette transform because a similar but more dynamic concept exists in WebP lossless -encoding: color cache.) +encoding: color cache). The color indexing transform checks for the number of unique ARGB values in the image. If that number is below a threshold (256), it creates an @@ -556,7 +556,7 @@ color. argb = color_table[GREEN(argb)]; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -If the index is equal or larger than color_table_size, the argb color value +If the index is equal or larger than `color_table_size`, the argb color value should be set to 0x00000000 (transparent black). \[AMENDED\] When the color table is small (equal to or less than 16 colors), several @@ -583,7 +583,7 @@ 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 +bundling is 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\], @@ -650,7 +650,7 @@ the image. Each pixel is encoded using one of the three possible methods: - 1. prefix coded literal: each channel (green, red, blue and alpha) is + 1. Prefix coded literal: each channel (green, red, blue and alpha) is entropy-coded independently; 2. LZ77 backward reference: a sequence of pixels are copied from elsewhere in the image; or @@ -681,7 +681,7 @@ while the extra bits are stored as they are (without an entropy code). **Rationale**: This approach reduces the storage requirement for the entropy code. Also, large values are usually rare, and so extra bits would be used for -very few values in the image. Thus, this approach results in a better +very few values in the image. Thus, this approach results in better compression overall. The following table denotes the prefix codes and extra bits used for storing @@ -722,12 +722,12 @@ return offset + ReadBits(extra_bits) + 1; **Distance Mapping:** {:#distance-mapping} -As noted previously, distance code is a number indicating the position of a +As noted previously, a distance code is a number indicating the position of a 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. -The distance codes larger than 120 denote the pixel-distance in scan-line +Distance codes larger than 120 denote the pixel-distance in scan-line order, offset by 120. The smallest distance codes \[1..120\] are special, and are reserved for a close @@ -763,10 +763,10 @@ The mapping between distance code `i` and the neighboring pixel offset (8, 7) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For example, distance code `1` indicates an offset of `(0, 1)` for the +For example, the distance code `1` indicates an offset of `(0, 1)` for the neighboring pixel, that is, the pixel above the current pixel (0 pixel -difference in X-direction and 1 pixel difference in Y-direction). Similarly, -distance code `3` indicates the left-top pixel. +difference in the X-direction and 1 pixel difference in the Y-direction). +Similarly, the distance code `3` indicates the left-top pixel. The decoder can convert a distance code `i` to a scan-line order distance `dist` as follows: @@ -897,7 +897,7 @@ if (num_symbols == 2) { (an empty prefix code). For example, a prefix code for distance can be empty if there are no backward references. Similarly, prefix codes for alpha, red, and blue can be empty if all pixels within the same meta prefix code are -produced using the color cache. However, this case doesn't need a special +produced using the color cache. However, this case doesn't need special handling, as empty prefix codes can be coded as those containing a single symbol `0`. @@ -913,7 +913,7 @@ int num_code_lengths = 4 + ReadBits(4); If `num_code_lengths` is > 18, the bitstream is invalid. The code lengths are themselves encoded using prefix codes: lower level code -lengths `code_length_code_lengths` first have to be read. The rest of those +lengths, `code_length_code_lengths`, first have to be read. The rest of those `code_length_code_lengths` (according to the order in `kCodeLengthCodeOrder`) are zeros. @@ -980,7 +980,7 @@ The entropy image defines which prefix codes are used in different parts of the image, as described below. The first 3-bits contain the `prefix_bits` value. The dimensions of the entropy -image are derived from 'prefix_bits'. +image are derived from `prefix_bits`. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ int prefix_bits = ReadBits(3) + 2; @@ -998,11 +998,11 @@ The next bits contain an entropy image of width `prefix_xsize` and height For any given pixel (x, y), there is a set of five prefix codes associated with it. These codes are (in bitstream order): - * **prefix code #1**: used for green channel, backward-reference length and - color cache - * **prefix code #2, #3 and #4**: used for red, blue and alpha channels + * **Prefix code #1**: used for green channel, backward-reference length and + color cache. + * **Prefix code #2, #3 and #4**: used for red, blue and alpha channels respectively. - * **prefix code #5**: used for backward-reference distance. + * **Prefix code #5**: used for backward-reference distance. From here on, we refer to this set as a **prefix code group**. @@ -1047,8 +1047,8 @@ For the current position (x, y) in the image, the decoder first identifies the corresponding prefix code group (as explained in the last section). Given the prefix code group, the pixel is read and decoded as follows: -Read next symbol S from the bitstream using prefix code #1. Note that S is any -integer in the range `0` to +Read the next symbol S from the bitstream using prefix code #1. Note that S is +any integer in the range `0` to `(256 + 24 + ` [`color_cache_size`](#color-cache-code)` - 1)`. The interpretation of S depends on its value: @@ -1139,9 +1139,9 @@ prefix-code-group = ; codes are for. 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 = code-length-code encoded-code-lengths -code-length-code = ; see section "Normal code length code" +code-length-code = ; see section "Normal Code Length Code" lz77-coded-image = *((argb-pixel / lz77-copy / color-cache-code) lz77-coded-image) |