Lines Matching +full:dozen +full:- +full:test +full:- +full:rules
4 Copyright (C) 1991-2012, Thomas G. Lane, Guido Vollbeding.
5 It was modified by The libjpeg-turbo Project to include only information
6 relevant to libjpeg-turbo.
21 In this document, JPEG-specific terminology follows the JPEG standard:
30 pixel, we mean an element of the full-size image, while a sample is an element
44 command-line user interface and I/O routines for several uncompressed image
53 without the extensive pre- and post-processing provided by this library.
61 we treat 8-bit vs. 12-bit data precision as a compile-time switch, not a
62 run-time option, because most machines can store 8-bit pixels much more
63 compactly than 12-bit.
65 By itself, the library handles only interchange JPEG datastreams --- in
80 ranging from very-high-quality down to fast-preview operation. On the
81 compression side we have generally not provided low-quality choices, since
82 compression is normally less time-critical. It should be understood that the
83 low-quality modes may not meet the JPEG standard's accuracy requirements;
92 image data that Rec. ITU-T T.81 | ISO/IEC 10918-1 regards as its input or
105 smoothing --- this is often helpful for low-quality source data.
112 module responsible for physically writing the output data --- typically
127 * Optional color precision reduction (e.g., 24-bit to 15-bit color).
139 low-quality ordered-dither technique. The system architecture is designed to
145 Rec. ITU-T T.81 | ISO/IEC 10918-1 includes it in compression/decompression. We
150 data properly. Padding will occur only to the next block (8-sample) boundary.
151 In an interleaved-scan situation, additional dummy blocks may be used to fill
159 buffering and padding for odd-sized images.
162 *** Poor man's object-oriented programming ***
164 It should be clear by now that we have a lot of quasi-independent processing
166 code with lots of switch statements, we use a simple form of object-style
176 a method name in real object-oriented languages. During initialization we
181 making the required run-time choice. The really significant benefit, of
186 module-specific object structs be separately allocated entities, which will
205 use straight-line code instead of for-loops. The cost to determine which
209 This plan differs a little bit from usual object-oriented structures, in that
234 1B. Per-pass control. This determines how many passes will be performed
236 appropriately at the beginning of each pass. End-of-pass processing,
246 inter-processing-step data buffer. This module is responsible for
253 ------------------ controller ------------------
260 higher-level control module; thus the control modules form a binary tree with
266 module and its pair of processing-step modules with a single processing-
271 modes, a full-image buffer is needed and several passes are required.
274 unaware of the multi-pass behavior.
278 practice, each one contains considerable special-case processing for its
288 |-- Colorspace conversion
289 |-- Preprocessing controller --|
290 | |-- Downsampling
291 Main controller --|
292 | |-- Forward DCT, quantize
293 |-- Coefficient controller --|
294 |-- Entropy encoding
303 * Main controller: buffer controller for the subsampled-data buffer, which
305 fill the subsampled-data buffer, and JPEG compression to empty it. There is
306 usually no need for a full-image buffer here; a strip buffer is adequate.
314 JPEG color space; also changes the data from pixel-interleaved layout to
318 Optionally may perform pixel-level smoothing as well. Processes a "row
329 * Coefficient controller: buffer controller for the DCT-coefficient data.
332 Huffman-code optimization or emitting a multiscan JPEG file, this
353 and per-pass initialization of the other modules.
371 * Progress monitor: supports output of "percent-done" progress reports.
376 defined as separate objects in order to simplify application-specific
378 individual methods or supply its own all-new implementation of one of these
391 |-- Entropy decoding
392 |-- Coefficient controller --|
393 | |-- Dequantize, Inverse DCT
394 Main controller --|
395 | |-- Upsampling
396 |-- Postprocessing controller --| |-- Colorspace conversion
397 |-- Color quantization
398 |-- Color precision reduction
403 * Main controller: buffer controller for the subsampled-data buffer, which
409 always a strip buffer; a full-image buffer is never required.
411 * Coefficient controller: buffer controller for the DCT-coefficient data.
429 When scaled-down output is asked for, simplified DCT algorithms may be used
435 controller just calls the upsampler.) For two-pass quantization, this
436 controller is responsible for buffering the full-image data.
443 buffer controller for the upsampling->color conversion buffer. However, in
444 all but the highest-quality operating modes, upsampling and color
448 and change data layout from separate component planes to pixel-interleaved.
453 is not used for full-color output. Works on one pixel row at a time; may
456 design, the output values are JSAMPLEs, so an 8-bit compilation cannot
461 generating 15-bit color (5 bits/primary) from JPEG's 24-bit output.
465 Note that some high-speed operating modes might condense the entire
473 and per-pass initialization of the other modules. This is subdivided into
474 input and output control: jdinput.c controls only input-side processing,
475 while jdmaster.c handles overall initialization and output-side control.
513 losing anything, since the coefficient buffer is read-only as far as the
516 A full-image coefficient array is only created if the JPEG file has multiple
517 scans (or if the application specifies buffered-image mode anyway). When
518 reading a single-scan file, the coefficient controller normally creates only
519 a one-MCU buffer, so input and output processing must run in lockstep in this
520 case. jpeg_consume_input() is effectively a no-op in this situation.
532 file as one pass when buffered-image mode is not used, and to ignore data
533 input work completely when buffered-image mode is used. Note that the
536 in buffered-image mode. So the work estimate is inherently bogus anyway.
549 typedef JSAMPARRAY *JSAMPIMAGE; ptr to a list of color-component arrays
553 compile-time option). Otherwise, unsigned char is used.
557 specification that sample values run from -128..127 is accommodated by
560 0..255. (NB: different values are required when 12-bit samples are in use.
562 defined as 255 and 128 respectively in an 8-bit implementation, and as 4095
563 and 2048 in a 12-bit implementation.)
565 We use a pointer per row, rather than a two-dimensional JSAMPLE array. This
592 Since most image-processing applications prefer to work on images in which
598 converted to component-wise storage inside the JPEG library. (Applications
600 with component-wise storage.)
603 Arrays of DCT-coefficient values use the following data structure:
605 typedef short JCOEF; a 16-bit signed integer
611 The underlying type is at least a 16-bit signed integer; while "short" is big
634 incremental, memory-to-memory filter. In this situation the data source or
635 destination may be a limited-size buffer, and we can't rely on being able to
652 we require callers to test the counter rather than just assume all of the data
667 must be large enough to hold a worst-case compressed MCU; a couple thousand
670 In a successive-approximation AC refinement scan, the progressive Huffman
673 previously-zero and previously-nonzero coefficients. This is a bit tedious
694 there are a dozen or two bytes available before calling jpeg_finish_compress()
695 will suffice for the trailer.) This would not work for writing multi-scan
713 can be freed at once. This approach helps prevent storage-leak bugs, and
720 across from one datastream to another; this includes all application-visible
724 peak memory usage would be about the same anyway; and having per-pass storage
725 substantially complicates the virtual memory allocation rules --- see below.)
728 1. "Small" objects. Typically these require no more than 10K-20K total.
733 pointers on MS-DOS machines.) Note that individual "large" objects cannot
736 3. "Virtual" objects. These are large 2-D arrays of JSAMPLEs or JBLOCKs
755 In a non-virtual-memory machine, some performance benefit can be gained by
756 making the in-memory buffers for virtual arrays be as large as possible.
761 of the virtual arrays at once. Therefore, there isn't a one-step allocation
765 realize routine must allow for space occupied by non-virtual large objects.
782 In a virtual-memory machine, we simply pretend that the available space is
784 the virtual arrays as full-size in-memory buffers. The overhead of the
785 virtual-array access protocol is very small when no swapping occurs.
787 A virtual array can be specified to be "pre-zeroed"; when this flag is set,
788 never-yet-written sections of the array are set to zero before being made
789 available to the caller. If this flag is not set, never-written sections
794 The first write pass on a virtual array is required to occur in top-to-bottom
798 support seeking beyond the current end-of-file in a temporary file. The main
800 converting top-to-bottom data order to bottom-to-top) must be handled while
807 memory manager into two parts. There is a reasonably system-independent
814 jpeg_mem_init, jpeg_mem_term system-dependent initialization/shutdown
820 FAR malloc/free on MS-DOS machines; now the
825 jpeg_open_backing_store create a backing-store object
827 read_backing_store, manipulate a backing-store object
831 On some systems there will be more than one type of backing-store object.
842 install its own signal handler, because that would pre-empt the surrounding
854 height (this would be useful for a fax-like scanner's output, for instance).
863 height, and must re-test for termination after each MCU row. This would
866 In cases where image-size data structures are allocated, this approach will
867 result in very inefficient use of virtual memory or much-larger-than-necessary
869 mainstream usage. People might have to forgo use of memory-hogging options
870 (such as two-pass color quantization or noninterleaved JPEG files) if they
872 demanding a user-supplied upper bound for the height, less than 65536; in most
884 2. There is no way to hide the last-minute change in image height from an
890 A different approach is to insist that DNL-using files be preprocessed by a
894 a lot smaller temp file than is implied by the maximum-height method. For
895 this approach we'd simply treat DNL as a no-op in the decompressor (at most,