The DCT sequential mode of operation
consists of the FDCT and Quantization steps, and the multiple-componont
control. In addition to the Baseline sequential codec, other DCT sequential
codec are defined to accommodate the two different sample precisions (8
and 12 bits) and the two different types of entropy coding methods (Huffman
and arithmetic).
Baseline sequential coding is for
images with 8-bit samples and uses Huffman coding only. It also differs
from the other sequential DCT codecs in that its decoder can store only
two sets of Huffman tables (one AC table and DC table per set). This restriction
means that, for images with three or four interleaved components, at least
one set of Huffman tables must be shared by two components. This restriction
poses no limitation at all for noninterleaved components; a new set of
tables can be loaded into the decoder before decoompression of a noninterleaved
component begins.
For many applications which do need
to inerleave three color components, this restriction is hardly a limitation
at all. Color spaces (YUV, CIELUV, CIELAB, and others) which represent
the chromatic ("color") information in two components and the achromatic
("grayscale") information ina third are more efficient for compression
than spaces like RGB. One Hufman table set can be used for the achromatic
component and aone for the chrominance components. DCT coefficient statistics
are similar for the chrominance components of most images, and one set
of Huffman tables can encode both almost as optimally as two.
In this part, Baseline sequential
coding will be shown and one example will be introduced. Other DCT sequential
coding will be noted briefly.
After all coefficients are represented
by the intermediate symbols, variable-length codes are assigned. For each
8x8 block, the DC coefficient's intermediate symbol is coded and output
first.
For both DC and AC coefficients,
each first symbol is encoded with a variable-length code (VLC) from
the Huffman table set assigned to the 8x8 block's image component.
The second symbol is encoded with a variable-length integer (VLI)
code in Table. Note that VLIs are not Huffman codes. The length of a VLC
(Huffman code) is not known until it is decoded, but the length ofa VLI
is stored in its preceding VLC.
Huffman codes (VLCs) must be specified
externally as an input to JPEG encoders. The JPEG proposal includes an
example set of Huffman tables in its information annes, but because they
are application-specific, it specifies none for required use. However,
the VLI codes are "hardwired" into the proposal, because they are far more
numerous, can be computed rather than stored, and have not been shown to
be appreciably more efficient when implemented as Huffman codes..