Alien-FreeImage
view release on metacpan or search on metacpan
src/Source/LibJPEG/structure.txt view on Meta::CPAN
* Colorspace conversion: converts application image data into the desired
JPEG color space; also changes the data from pixel-interleaved layout to
separate component planes. Processes one pixel row at a time.
* Downsampling: performs reduction of chroma components as required.
Optionally may perform pixel-level smoothing as well. Processes a "row
group" at a time, where a row group is defined as Vmax pixel rows of each
component before downsampling, and Vk sample rows afterwards (remember Vk
differs across components). Some downsampling or smoothing algorithms may
require context rows above and below the current row group; the
preprocessing controller is responsible for supplying these rows via proper
buffering. The downsampler is responsible for edge expansion at the right
edge (i.e., extending each sample row to a multiple of block_size samples);
but the preprocessing controller is responsible for vertical edge expansion
(i.e., duplicating the bottom sample row as needed to make a multiple of
block_size rows).
* Coefficient controller: buffer controller for the DCT-coefficient data.
This controller handles MCU assembly, including insertion of dummy DCT
blocks when needed at the right or bottom edge. When performing
Huffman-code optimization or emitting a multiscan JPEG file, this
controller is responsible for buffering the full image. The equivalent of
one fully interleaved MCU row of subsampled data is processed per call,
even when the JPEG file is noninterleaved.
* Forward DCT and quantization: Perform DCT, quantize, and emit coefficients.
Works on one or more DCT blocks at a time. (Note: the coefficients are now
emitted in normal array order, which the entropy encoder is expected to
convert to zigzag order as necessary. Prior versions of the IJG code did
the conversion to zigzag order within the quantization step.)
* Entropy encoding: Perform Huffman or arithmetic entropy coding and emit the
coded data to the data destination module. Works on one MCU per call.
For progressive JPEG, the same DCT blocks are fed to the entropy coder
during each pass, and the coder must emit the appropriate subset of
coefficients.
In addition to the above objects, the compression library includes these
objects:
* Master control: determines the number of passes required, controls overall
and per-pass initialization of the other modules.
* Marker writing: generates JPEG markers (except for RSTn, which is emitted
by the entropy encoder when needed).
* Data destination manager: writes the output JPEG datastream to its final
destination (e.g., a file). The destination manager supplied with the
library knows how to write to a stdio stream or to a memory buffer;
for other behaviors, the surrounding application may provide its own
destination manager.
* Memory manager: allocates and releases memory, controls virtual arrays
(with backing store management, where required).
* Error handler: performs formatting and output of error and trace messages;
determines handling of nonfatal errors. The surrounding application may
override some or all of this object's methods to change error handling.
* Progress monitor: supports output of "percent-done" progress reports.
This object represents an optional callback to the surrounding application:
if wanted, it must be supplied by the application.
The error handler, destination manager, and progress monitor objects are
defined as separate objects in order to simplify application-specific
customization of the JPEG library. A surrounding application may override
individual methods or supply its own all-new implementation of one of these
objects. The object interfaces for these objects are therefore treated as
part of the application interface of the library, whereas the other objects
are internal to the library.
The error handler and memory manager are shared by JPEG compression and
decompression; the progress monitor, if used, may be shared as well.
*** Decompression object structure ***
Here is a sketch of the logical structure of the JPEG decompression library:
|-- Entropy decoding
|-- Coefficient controller --|
| |-- Dequantize, Inverse DCT
Main controller --|
| |-- Upsampling
|-- Postprocessing controller --| |-- Colorspace conversion
|-- Color quantization
|-- Color precision reduction
As before, this diagram also represents typical control flow. The objects
shown are:
* Main controller: buffer controller for the subsampled-data buffer, which
holds the output of JPEG decompression proper. This controller's primary
task is to feed the postprocessing procedure. Some upsampling algorithms
may require context rows above and below the current row group; when this
is true, the main controller is responsible for managing its buffer so as
to make context rows available. In the current design, the main buffer is
always a strip buffer; a full-image buffer is never required.
* Coefficient controller: buffer controller for the DCT-coefficient data.
This controller handles MCU disassembly, including deletion of any dummy
DCT blocks at the right or bottom edge. When reading a multiscan JPEG
file, this controller is responsible for buffering the full image.
(Buffering DCT coefficients, rather than samples, is necessary to support
progressive JPEG.) The equivalent of one fully interleaved MCU row of
subsampled data is processed per call, even when the source JPEG file is
noninterleaved.
* Entropy decoding: Read coded data from the data source module and perform
Huffman or arithmetic entropy decoding. Works on one MCU per call.
For progressive JPEG decoding, the coefficient controller supplies the prior
coefficients of each MCU (initially all zeroes), which the entropy decoder
modifies in each scan.
* Dequantization and inverse DCT: like it says. Note that the coefficients
buffered by the coefficient controller have NOT been dequantized; we
merge dequantization and inverse DCT into a single step for speed reasons.
When scaled-down output is asked for, simplified DCT algorithms may be used
that need fewer coefficients and emit fewer samples per DCT block, not the
full 8x8. Works on one DCT block at a time.
( run in 0.871 second using v1.01-cache-2.11-cpan-411bb0df24b )