dany/libwebp
1
0
Fork 0
mirror of https://github.com/webmproject/libwebp.git synced 2024-12-26 05:38:22 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Formatting fixes in lossless bitstream spec

Browse Source 
- Escape brackets for which kramdown was generating a warning.
Note: This only changes this source file; output HTML would look exactly
the same.
- Also write '5' in words ('five').

Change-Id: I472a03c090a12eb7520719ea463469b36a2736b9
This commit is contained in:
Urvang Joshi 2012-12-20 11:25:59 -08:00
parent 18e9167ea6
commit 8425aaee8f
1 changed files with 17 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
doc/webp-lossless-bitstream-spec.txt
View File

@ -361,14 +361,14 @@ int ClampAddSubtractHalf(int a, int b) {
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are special handling rules for some border pixels. If there is a
prediction transform, regardless of the mode [0..13] for these pixels,
prediction transform, regardless of the mode \[0..13\] for these pixels,
the predicted value for the left-topmost pixel of the image is
0xff000000, L-pixel for all pixels on the top row, and T-pixel for all
pixels on the leftmost column.
Addressing the TR-pixel for pixels on the rightmost column is
exceptional. The pixels on the rightmost column are predicted by using
the modes [0..13] just like pixels not on border, but by using the
the modes \[0..13\] just like pixels not on border, but by using the
leftmost pixel on the same row as the current TR-pixel. The TR-pixel
offset in memory is the same for border and non-border pixels.
@ -420,7 +420,7 @@ void ColorTransform(uint8 red, uint8 blue, uint8 green,
`ColorTransformDelta` is computed using a signed 8-bit integer
representing a 3.5-fixed-point number, and a signed 8-bit RGB color
channel (c) [-128..127] and is defined as follows:
channel (c) \[-128..127\] and is defined as follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
int8 ColorTransformDelta(int8 t, int8 c) {
@ -567,10 +567,10 @@ 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
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
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.
The values are packed into the green component as follows:
@ -714,7 +714,7 @@ pixel.
The 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
The smallest distance codes \[1..120\] are special, and are reserved for a close
neighborhood of the current pixel. This neighborhood consists of 120 pixels:
* Pixels that are 1 to 7 rows above the current pixel, and are up to 8 columns
@ -785,7 +785,7 @@ int color_cache_size = 1 << color_cache_code_bits;
`color_cache_code_bits` defines the size of the color_cache by (1 <<
`color_cache_code_bits`). The range of allowed values for
`color_cache_code_bits` is [1..11]. Compliant decoders must indicate a
`color_cache_code_bits` is \[1..11\]. Compliant decoders must indicate a
corrupted bitstream for other values.
A color cache is an array of size `color_cache_size`. Each entry
@ -953,7 +953,7 @@ by a 1-bit value.
**(i) Simple Code Length Code:**
This variant is used in the special case when only 1 or 2 Huffman code lengths
are non-zero, and are in the range of [0, 255]. All other Huffman code lengths
are non-zero, and are in the range of \[0, 255\]. All other Huffman code lengths
are implicitly zeros.
The first bit indicates the number of non-zero code lengths:
@ -963,7 +963,7 @@ int num_code_lengths = ReadBits(1) + 1;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The first code length is stored either using a 1-bit code for values of 0 and 1,
or using an 8-bit code for values in range [0, 255]. The second code length,
or using an 8-bit code for values in range \[0, 255\]. The second code length,
when present, is coded as an 8-bit code.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -1000,15 +1000,15 @@ for (i = 0; i < num_code_lengths; ++i) {
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Code length code [0..15] indicates literal code lengths.
* Code length code \[0..15\] indicates literal code lengths.
* Value 0 means no symbols have been coded.
* Values [1..15] indicate the bit length of the respective code.
* Code 16 repeats the previous non-zero value [3..6] times, i.e.,
* Values \[1..15\] indicate the bit length of the respective code.
* Code 16 repeats the previous non-zero value \[3..6\] times, i.e.,
3 + `ReadBits(2)` times. If code 16 is used before a non-zero
value has been emitted, a value of 8 is repeated.
* Code 17 emits a streak of zeros [3..10], i.e., 3 + `ReadBits(3)`
* Code 17 emits a streak of zeros \[3..10\], i.e., 3 + `ReadBits(3)`
times.
* Code 18 emits a streak of zeros of length [11..138], i.e.,
* Code 18 emits a streak of zeros of length \[11..138\], i.e.,
11 + `ReadBits(7)` times.
@ -1059,7 +1059,8 @@ of pixels (xsize * ysize).
<huffman code group> ::= <huffman code><huffman code><huffman code>
<huffman code><huffman code>
See "Interpretation of Meta Huffman codes" to
understand what each of these 5 Huffman codes are for.
understand what each of these five Huffman codes are
for.
<huffman code> ::= <simple huffman code> | <normal huffman code>
<simple huffman code> ::= see "Simple code length code" for details
<normal huffman code> ::= <code length code>; encoded code lengths