mirror of
https://github.com/webmproject/libwebp.git
synced 2024-12-27 22:28:22 +01:00
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
This commit is contained in:
parent
3ed2b27517
commit
8a6185dd27
@ -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
|
(and possibly other encodings in the future). These encoding schemes should
|
||||||
make it more efficient than currently used formats. It is optimized for fast
|
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
|
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.
|
well. This document describes the structure of a WebP file.
|
||||||
|
|
||||||
The WebP container (i.e., RIFF container for WebP) allows feature support over
|
The WebP container (i.e., RIFF container for WebP) allows feature support over
|
||||||
|
@ -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
|
least-significant-bit-first order. When multiple bits are read at the
|
||||||
same time, the integer is constructed from the original data in the
|
same time, the integer is constructed from the original data in the
|
||||||
original order. The most significant bits of the returned integer are
|
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);
|
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
|
the subresolution images have no transforms, not even the 0 bit
|
||||||
indicating the end-of-transforms.
|
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
|
entropy in the residual image. Also, the transform data can be decided
|
||||||
based on entropy minimization.
|
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
|
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 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;
|
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
|
`width_bits` has a value of 0, 1, 2 or 3. A value of 0 indicates no pixel
|
||||||
pixel bundling to be done for the image. A value of 1 indicates that two
|
bundling to be done for the image. A value of 1 indicates that two pixels are
|
||||||
pixels are combined together, and each pixel has a range of \[0..15\]. A
|
combined, and each pixel has a range of \[0..15\]. A value of 2 indicates that
|
||||||
value of 2 indicates that four pixels are combined together, and each
|
four pixels are combined, and each pixel has a range of \[0..3\]. A value of 3
|
||||||
pixel has a range of \[0..3\]. A value of 3 indicates that eight pixels
|
indicates that eight pixels are combined and each pixel has a range of \[0..1\],
|
||||||
are combined together and each pixel has a range of \[0..1\], i.e., a
|
i.e., a binary value.
|
||||||
binary value.
|
|
||||||
|
|
||||||
The values are packed into the green component as follows:
|
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
|
3. Color cache code: using a short multiplicative hash code (color cache
|
||||||
index) of a recently seen color.
|
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
|
#### 5.2.1 Prefix Coded Literals
|
||||||
|
|
||||||
@ -725,7 +724,7 @@ 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, 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
|
defines the mapping between a distance code and the position of a previous
|
||||||
pixel.
|
pixel.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user