for fixes to the distance_map pseudo-code, the inverse color transform
description and the num_code_lengths check.
Bug: webp:448
Bug: webp:551
Change-Id: Id7e791b97704dd64bb9519657ce48b92cb457ae4
The prose describing the process was missed in:
44dd765d webp-lossless-bitstream-spec: fix ColorTransform impl
Bug: webp:448
Bug: webp:551
Change-Id: If5fb95103ffedeed113e3ad62510f3a19bfd280e
in the 'Normal Code Length Code' description the number of valid code
lengths is 19, not 18.
Bug: webp:448
Bug: webp:551
Change-Id: Id929604e1d771cb09b2d0ac617e83f21077f21de
'zero alpha pixels' was a bit hard to parse; replace this with something
more explicit
Bug: webp:448
Change-Id: Ifc8c93af5520ffdafc58e3fc311dfb4cb19626e9
this makes the syntax in this document consistent with
webp-lossless-bitstream-spec.txt
[N-M] -> [N..M]
Bug: webp:448
Change-Id: Iebf39eefb7d3c081a3d10e2804ee215c3aed6b79
this is similar to an earlier change for most of the code examples:
7a0a9935 doc/*.txt: restrict code to 69 columns
some renderers may limit output to 72 and use a 3 space indent; this
avoids overflowing into the margin
Bug: webp:448
Change-Id: I2e8d66f598889c7bd824e911ea01fd70f98a4130
The distance code read from the bitstream is reduced by 1 before doing
the lookup. The prose describing the lookup was correct, the pseudocode
failed to subtract 1 and used x/y instead of xi/yi from the lookup.
Bug: webp:448
Change-Id: I152477b888c26a0473a35373d3d331fddd14237f
this has a better canonical reference [1] and is preferred in IETF docs
[1] https://www.rfc-editor.org/rfc/rfc5234
Bug: webp:448
Change-Id: I3f0bd34d3ca4c62b255d5d6cbae0c55e2940dfb5
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
some renderers may limit output to 72 and use a 3 space indent; this
avoids overflowing into the margin
Change-Id: Iaf4e8b71be27ef00fccd1d82b79bf96c01040f10
these were intended as an extension point, but in this version of the
spec they're not defined. if they ever were used leaving them as SHOULD
could result in a source of incompatibility.
Change-Id: I1376ab7abe7d955ae335106f2faebc217dac77cd
for compatibility SHOULDs are left as is with some additional
description given of behavior if the recommendation is ignored.
Change-Id: I7a25b1a6fd9f9594390c30fce3af5ca17c3158c0
this avoids presenting it in the description of a chunk where it could
appear it was defining an element of the diagram
Change-Id: I51b2c2a0dcecb4fc130711ad37c884a434920ecd
Note the fourth character is an ASCII space to avoid confusion.
Also update the FourCC definition to mention that they're case
sensitive.
Change-Id: I87d0cbcf06e7c25bf2b33419b4c8c891adb82a8a
Use the correct number of lines for fixed width entries like
ChunkHeader(). ':' is used instead of '|' for variable length entries.
Bug: webp:546
Change-Id: I6ec60af674c0777d5ea6ae99c8aa3c7854ddd9f9
Fixed: webp:546
RFC 2119 was updated by RFC 8174; use the text from there
+ change INFORMATIVE to informative to avoid confusion with the key
words in the RFCs
Change-Id: I0a3fe9dc48d284e7ac95633896ffb855ecd1a229
... since no guarantee of Huffman coding can be introduced at decoding
time and encoding didn't actually use Huffman coding in the first place
Bug: webp:551
Change-Id: I400466bb3b4a1d5506353eb3f287d658603164ee
