Lines Matching refs:is
4 This file is part of the Independent JPEG Group's software.
14 The library source code, of course, is the ultimate reference.
72 The library includes a substantial amount of code that is not covered by the
73 JPEG standard but is necessary for typical applications of JPEG. These
78 For example, if colormapped output is requested, then the decompression
86 compression is normally less time-critical. It should be understood that the
98 We support 8-bit to 12-bit data precision, but this is a compile-time choice
99 rather than a run-time choice; hence it is difficult to use different
105 are embedded in more complex file formats. (For example, this library is
112 The rough outline of a JPEG compression operation is:
131 The image data to be compressed is supplied to jpeg_write_scanlines() from
132 in-memory buffers. If the application is doing file-to-file compression,
133 reading image data from the source file is the application's responsibility.
138 Similarly, the rough outline of a JPEG decompression operation is:
150 This is comparable to the compression outline except that reading the
151 datastream header is a separate step. This is helpful because information
152 about the image's size, colorspace, etc is available when the application
158 can be obtained with a custom source manager. Decompressed data is delivered
161 It is possible to abort an incomplete compression or decompression operation
169 The JPEG library has no static variables: all state is in the compression
170 or decompression object. Therefore it is possible to process multiple
185 Before diving into procedural details, it is helpful to understand the
188 The standard input image format is a rectangular array of pixels, with each
197 There is no provision for colormapped input. JPEG files are always full-color
201 because of dithering noise. This is discussed in more detail in the JPEG FAQ
206 example, R,G,B,R,G,B,R,G,B,... for 24-bit RGB color. Each scanline is an
207 array of data type JSAMPLE --- which is typically "unsigned char", unless
212 A 2-D array of pixels is formed by making a list of pointers to the starts of
216 type JSAMPROW, and the pointer to the pointer array is of type JSAMPARRAY.
219 It is not possible to process part of a row at a time. Scanlines are always
232 The data format returned by the decompressor is the same in all details,
233 except that colormapped output is supported. (Again, a JPEG file is never
237 its value is an index into a color map. The color map is represented as
239 that is, colormap[i][j] is the value of the i'th color component for pixel
241 JSAMPLEs, the maximum number of colors is limited by the size of JSAMPLE
252 A JPEG compression object is a "struct jpeg_compress_struct". (It also has
255 variable in the calling routine, if a single routine is going to execute the
260 of this that the library cares about is a "struct jpeg_error_mgr". If you
262 jpeg_error_mgr struct in a larger structure; this is discussed later under
271 Typical code for this step, if you are using the default error handler, is
304 WARNING: it is critical that the binary compressed data be delivered to the
327 of 1 to 64K pixels in either direction. The input color space is typically
328 RGB or grayscale, and input_components is 3 or 1 accordingly. (See "Special
334 image is encoded. Most applications don't need or want to know about all
346 Typical code for a 24-bit RGB source image is
369 will be written. This is appropriate in most cases. If you think you might
383 to the total image height. In most applications it is convenient to pass
385 data is discussed under "Data formats", above.
416 ignore the return value. It is different in just two cases:
421 This feature is discussed under "I/O suspension", below. The normal
423 In any case, the return value is the same as the change in the value of
430 complete the compression cycle. This step is ESSENTIAL to ensure that the
431 last bufferload of data is written to the data destination.
448 It is an error to call jpeg_finish_compress() before writing the necessary
475 it is your responsibility --- jpeg_destroy() won't. Ditto for the error
489 jpeg_destroy_compress() or jpeg_destroy() to release memory. This is
496 jpeg_abort() is allowed at any time after successful object creation.
498 Note that cleaning up the data destination, if required, is your
504 for more info). The internal state of such an object is likely to be out of
515 This is just like initialization for compression, as discussed above,
516 except that the object is a "struct jpeg_decompress_struct" and you
517 call jpeg_create_decompress(). Error handling is exactly the same.
551 WARNING: it is critical that the binary compressed data be read unchanged.
568 Typical code for this step is just
577 More complex code is necessary if
578 * A suspending data source is used --- in that case jpeg_read_header()
585 It is permissible to stop at this point if you just wanted to find out the
597 For example, the default is to produce full color output from a color file.
616 Typical code is just
628 scaling, are available in the JPEG object; so is the selected colormap, if
638 output_components is 1 (a colormap index) when quantizing colors; otherwise it
639 equals out_color_components. It is the number of JSAMPLE values that will be
648 request large buffers *before* calling jpeg_start_decompress(). This is a
660 will return up to that many lines. The return value is the number of lines
661 actually read. The format of the returned data is discussed under "Data
665 Image data is returned in top-to-bottom scanline order. If you must write
675 image_height field is the height of the original unscaled image.)
678 If you don't use a suspending data source, it is safe to assume that
682 If you use a buffer larger than one scanline, it is NOT safe to assume that
702 It is an error to call jpeg_finish_decompress() before reading the correct
737 size_t. On ANSI-conforming systems, including <stdio.h> is sufficient; on
748 is to prepare a library file ("libjpeg.a", or a corresponding name on non-Unix
751 included from the library, unless your linker is hopelessly brain-damaged.
755 you, we don't really recommend it. The trouble with shared libraries is that
759 version. In other words, the library's API is *not* guaranteed binary
766 that temporary files are deleted if the program is interrupted. This is most
788 of the JPEG standard; if you don't know what a parameter is for, it's best
793 all the parameters; that way your code is more likely to work with future JPEG
795 you use a helper routine where one is provided, in preference to twiddling
816 and calls jpeg_set_colorspace(). This is actually a subroutine of
822 quality setting. The quality value is expressed on the 0..100 scale
825 in future IJG releases as more is learned about DCT quantization.
826 If the force_baseline parameter is TRUE, then the quantization table
831 is capable of reading the non-baseline files generated at low quality
832 settings when force_baseline is FALSE, but other decoders may not be.
838 specified scale factor (which is expressed as a percentage; thus
840 scale factors give lower quality. This entry point is useful for
863 (or to 1..255 if force_baseline is TRUE).
868 "#if JPEG_LIB_VERSION >= 61" is the right test.
872 This is the recommended method of creating a progressive file,
874 the JPEG color space is set correctly before calling this routine.
885 Default is 8 (baseline format).
888 An exact DCT stage is possible with 1 or 2.
890 the DCT+Quantization stage is lossless for value 1.
902 The FLOAT method is very slightly more accurate than the ISLOW method,
906 floating-point method may also be the fastest. The IFAST method is
907 considerably less accurate than the other two; its use is not
908 recommended if high quality is a concern. JDCT_DEFAULT and
912 Scale the image by the fraction scale_num/scale_denom. Default is
914 M/N with all N from 1 to 16, where M is the destination DCT size,
915 which is 8 by default (see block_size parameter above).
917 is not likely to be implemented any time soon.)
937 therefore costs a good deal of space and time. The default is
940 of file size compared to the default tables. Note that when this is
949 restart_in_rows is not 0, then restart_interval is set after the
950 image width in MCUs is computed.) Defaults are zero (no restarts).
951 One restart marker per MCU row is often a good choice.
952 NOTE: the overhead of restart markers is higher in grayscale JPEG
959 By default, scan_info is NULL; this causes the compressor to write a
963 definition record. This is used to generate noninterleaved or
966 a suitable scan definition array for progressive JPEG.) This is
973 Default is TRUE.
975 it is preferable that this value matches the corresponding
979 If non-zero, the input image is smoothed; the value should be 1 for
981 for details of the smoothing algorithm. The default is zero.
984 If TRUE, a JFIF APP0 marker is emitted. jpeg_set_defaults() and
986 (ie, YCbCr or grayscale) is selected, otherwise FALSE.
1004 If TRUE, an Adobe APP14 marker is emitted. jpeg_set_defaults() and
1006 or YCCK is selected, otherwise FALSE. It is generally a bad idea
1014 or NULL if no table is defined for a slot. Usually these should
1016 is general enough to define any quantization table. The other
1026 Here is an example code which corresponds to cjpeg -quality 90,70:
1039 is 2x2:
1047 no table is defined for a slot. Slots 0 and 1 are filled with the
1069 comp_info[] array is allocated by jpeg_set_defaults(); if you choose not
1084 for grayscale where 1,1 is used.
1087 Quantization table number for component. The default value is
1104 Decompression parameter selection is somewhat simpler than compression
1131 The JPEG color space, unfortunately, is something of a guess since the JPEG
1145 output from a color file. (This is useful for previewing: grayscale
1146 output is faster than full color since the color components need not
1154 N is the source DCT size, which is 8 for baseline JPEG. (The library
1155 design allows for arbitrary scaling ratios but this is not likely
1158 this is 8/8. If you change only the scale_num value while leaving
1160 applied on the given input. For baseline JPEG this is equivalent
1161 to M/8 scaling, since the source DCT size for baseline JPEG is 8.
1166 If set TRUE, colormapped output will be delivered. Default is FALSE,
1169 The next three parameters are relevant only if quantize_colors is TRUE.
1173 map (the actual number of colors is returned in a different field).
1177 If TRUE, an extra pass over the image is made to select a custom color
1179 fits-all colormap that is used otherwise. Default is TRUE. Ignored
1187 Default is JDITHER_FS. (At present, ordered dither is implemented
1189 ordered dither when two_pass_quantize is TRUE or when you supply
1192 When quantize_colors is TRUE, the target color map is described by the next
1193 two fields. colormap is set to NULL by jpeg_read_header(). The application
1197 [Implementation restriction: at present, an externally supplied colormap is
1204 pointed to by this field is released by jpeg_finish_decompress().
1220 Default is TRUE.
1222 it is preferable that this value matches the corresponding
1226 If TRUE, interblock smoothing is applied in early stages of decoding
1227 progressive JPEG files; if FALSE, not. Default is TRUE. Early
1230 AC coefficients are known to full accuracy, so it is relevant only
1236 These are significant only in buffered-image mode, which is
1255 When quantizing colors, output_components is 1, indicating a single color map
1259 rec_outbuf_height is the recommended minimum height (in scanlines) of the
1260 buffer passed to jpeg_read_scanlines(). If the buffer is smaller, the
1262 copying. In high-quality modes, rec_outbuf_height is always 1, but some
1266 (An output buffer larger than rec_outbuf_height lines is OK, but won't
1273 The JPEG standard itself is "color blind" and doesn't specify any particular
1274 color space. It is customary to convert color data to a luminance/chrominance
1288 For compression, the source data's color space is specified by field
1289 in_color_space. This is transformed to the JPEG file's color space given
1305 that indicate the color space of the JPEG file. It is important to ensure
1307 is not one of the ones supported by the interchange standards.
1309 the APPn markers properly, so long as it is told the truth about the JPEG
1316 When told that the color space is UNKNOWN, the library will default to using
1321 For decompression, the JPEG file's color space is given in jpeg_color_space,
1322 and this is transformed to the output color space out_color_space.
1324 conforms to JFIF or Adobe conventions, but otherwise it is no better than a
1337 as well as the null transforms. (Since GRAYSCALE=>RGB is provided, an
1341 The two-pass color quantizer, jquant2.c, is specialized to handle RGB data
1344 jquant2.c is used to map to an application-supplied colormap as well as for
1349 This is arguably a bug in Photoshop, but if you need to work with Photoshop
1366 When the default error handler is used, any error detected inside the JPEG
1370 The file example.c illustrates the most common case, which is to have the
1376 * Warnings: the library can continue, but the data is corrupt, and a
1377 damaged output image is likely to result.
1385 This is accomplished by calling jpeg_std_error() as usual, but then overriding
1394 additional data which is not known to the JPEG library or the standard error
1395 handler. The most convenient way to do this is to embed either the JPEG
1399 with IJG version 6b, there is also a void pointer "client_data" in each
1421 stored in cinfo->err. This method is called by output_message. Few
1423 reason for doing so is to implement dynamic switching of error message
1429 would be to abort on warnings. msg_level is -1 for warnings,
1435 The actual message texts are stored in an array of strings which is pointed to
1437 err->last_jpeg_message, and it is these code numbers that are used in the
1452 Actual invocation of the error handler is done via macros defined in jerror.h:
1476 In both cases, compressed data is processed a bufferload at a time: the
1478 the manager only when the buffer is filled or emptied. (You could define a
1487 The work buffer is defined as an array of datatype JOCTET, which is generally
1488 "char" or "unsigned char". On a machine where char is not exactly 8 bits
1500 is filled. The manager's empty_output_buffer method must reset the pointer
1501 and count. The manager is expected to remember the buffer's starting address
1507 Initialize destination. This is called by jpeg_start_compress()
1508 before any data is actually written. It must initialize
1513 This is called whenever the buffer has filled (free_in_buffer
1519 free_in_buffer must be set to a positive value when TRUE is
1520 returned. A FALSE return should only be used when I/O suspension is
1521 desired (this operating mode is discussed in the next section).
1527 free_in_buffer to determine how much data is in the buffer.
1529 term_destination() is NOT called by jpeg_abort() or jpeg_destroy(). If you
1549 is emptied. The manager's fill_input_buffer method must reset the pointer and
1556 Initialize source. This is called by jpeg_read_header() before any
1557 data is actually read. Unlike init_destination(), it may leave
1562 This is called whenever bytes_in_buffer has reached zero and more
1563 data is wanted. In typical applications, it should read fresh data
1567 It is not necessary to fill the buffer entirely, only to obtain at
1569 if TRUE is returned. A FALSE return should only be used when I/O
1570 suspension is desired (this mode is discussed in the next section).
1575 needed. This is used to skip over a potentially large amount of
1578 but it's not clear that being smart is worth much trouble; large
1583 This routine is called only when the decompressor has failed to find
1584 a restart (RSTn) marker where one is expected. Its mission is to
1598 For both fill_input_buffer() and skip_input_data(), there is no such thing
1602 is the best course of action --- this will allow the decompressor to output
1603 however much of the image is there. In pathological cases, the decompressor
1607 term_source() is NOT called by jpeg_abort() or jpeg_destroy(). If you want
1624 memory filter: when the compressed data buffer is filled or emptied, they want
1630 The I/O suspension mode is not a panacea: nothing is guaranteed about the
1636 To use I/O suspension, cooperation is needed between the calling application
1639 already.) The basic idea is that the empty_output_buffer() or
1640 fill_input_buffer() routine is a no-op, merely returning FALSE to indicate
1642 operation and returns to its caller. The surrounding application is
1658 data when restarted. Therefore, although empty_output_buffer() is only
1659 called when the buffer is filled, you should NOT write out the entire buffer
1664 Because of the backtracking behavior, a good-size output buffer is essential
1669 call jpeg_write_scanlines() unless there is a reasonable amount of space in
1673 The compressor does not allow suspension while it is trying to write JPEG
1677 so bytes). The recommended buffer size is bigger than this anyway, so
1678 this is not a problem as long as you start with an empty buffer. However,
1687 A more significant restriction is that jpeg_finish_compress() cannot suspend.
1711 convenient restart point before suspending. When fill_input_buffer() is
1713 which is where the decompressor will backtrack to if FALSE is returned.
1717 it. Again, this behavior means that a several-Kbyte work buffer is essential
1723 suspension scenario. This routine is NOT granted the ability to suspend the
1731 (Yes, this design is rather baroque, but it avoids complexity in the far more
1732 common case where a non-suspending source manager is used.)
1737 within fill_input_buffer(); the latter is probably more efficient. If
1738 fill_input_buffer() knows that no more data is available, it can set the
1747 We recommend at least a 2K buffer for performance reasons, which is much
1748 larger than any correct marker is likely to be. For robustness against
1750 application for the case that the input buffer is completely full and yet
1753 provide this test since it has no idea whether "the buffer is full", or
1754 even whether there is a fixed-size input buffer.)
1759 suspension is handled correctly, and in the latter case, the problem of
1760 buffer overrun is placed on skip_input_data's shoulders, as explained above.
1766 In some applications it is desirable to store the compressed data in a linked
1769 to reference the next available buffer; FALSE is returned only if no more
1770 buffers are available. Although seemingly straightforward, there is a
1771 pitfall in this approach: the backtrack that occurs when FALSE is returned
1773 is called, the current pointer & count indicate the backtrack restart point.
1777 additional input data is available, so fill_input_buffer must return FALSE.
1779 buffer, then *the correct restart point is the saved position in the prior
1788 It's much simpler to use only a single buffer; when fill_input_buffer() is
1791 space. This approach requires a little more data copying but is far easier
1799 increasing quality. In situations where a JPEG file is transmitted across a
1802 more scans are received. The final image after all scans are complete is
1805 sequential JPEG files, but the possibility of incremental display is the main
1810 Creation of progressive JPEG files is otherwise transparent to the encoder.
1822 it is possible to skip displaying the image and simply add the incoming bits
1823 to the decoder's coefficient buffer. This is fast because only Huffman
1828 suit the time available as the image is received. Also, a final
1830 the end of the file is reached.
1843 When scan_info is not NULL, the compression library will store DCT'd data
1844 into a buffer array as jpeg_write_scanlines() is called, and will emit all
1854 When buffered-image mode is not used, the decoder library will read all of
1863 buffered-image mode. This is described in the next section.
1871 This mode is typically used for incremental display of progressive JPEG files,
1876 input and display processing run independently, it is possible for the
1880 The basic control flow for buffered-image decoding is
1900 This differs from ordinary unbuffered decoding in that there is an additional
1904 The simplest approach to displaying progressive images is to do one display
1906 condition is typically
1911 file is to be displayed; the scans are numbered starting at 1 for this
1913 the library's input scan counter is easier.) The library automatically reads
1917 With this technique, data is read from the input file only as needed, and
1923 sequence. For example, a useful technique is to use fast one-pass color
1924 quantization for display passes made while the image is arriving, followed by
1926 is done by changing the library parameters before the final output pass.
1927 Changing parameters between passes is discussed in detail below.
1930 until after it is read, so a post-input display pass is the best approach if
1938 output. This is done by calling the routine jpeg_consume_input().
1939 The return value is one of the following:
1945 (JPEG_SUSPENDED can occur only if a suspending data source is used.) This
1948 events occurs. (If called after the EOI marker is reached, it will
1954 calls to jpeg_consume_input(), you can absorb data in advance of what is
1964 This is discussed further under "I/O suspension", above. (Note: the JPEG
1965 library currently is not thread-safe. You must not call jpeg_consume_input()
1966 from one thread of control if a different library routine is working on the
1969 When input arrives fast enough that more than one new scan is available
1973 The input_scan_number field is simply the index of the scan currently being
1974 consumed by the input processor. You can ensure that this is up-to-date by
1979 The target scan number passed to jpeg_start_output() is saved in the
1982 that scan is less than or equal to the current output scan number and row.
1983 Thus, input processing can "get ahead" of the output processing but is not
1988 an infinite loop, the target scan number is automatically reset to the last
1989 scan number when the end of image is reached. Thus, if you specify a large
1991 then perform an output pass. This is effectively the same as what
1994 the image is displayed no faster than the current input scan arrives. The
1995 final possibility is to pass a target scan number less than the current input
2001 When data is arriving faster than the output display processing can advance
2003 image beyond the point at which the output processing is reading data out
2005 the point where the input is more than one whole scan ahead of the output.
2007 paying attention to the input, the effect seen on-screen is that the lower
2008 part of the image is one or more scans better in quality than the upper part.
2009 Then, when the next output scan is started, you have a choice of what target
2010 scan number to use. The recommended choice is to use the current input scan
2019 be full quality across the whole screen. So the right outer loop logic is
2032 the final pass, the right loop logic is like this:
2042 In this case you don't need to know in advance whether an output pass is to
2044 the final output pass; rather, what you want to test is whether the output
2046 will avoid an extra output pass whenever the decoder is able (or nearly able)
2049 When the data transmission speed is high, you might begin a display pass,
2057 A variant strategy is to abort and restart display if more than one complete
2068 higher-quality final pass is to be done, it should be started (aborting any
2069 incomplete output pass) as soon as the end of file is received. However,
2085 and the target scan isn't fully read yet. (This is discussed below.)
2102 It is possible to change decoding parameters between output passes in the
2105 allowed after jpeg_start_decompress() is called:
2114 of memory involved is not large (a scanline or so), it may cause the
2118 This setting is relevant only when decoding a progressive JPEG image.
2120 instead of the very "blocky" look seen without it; which is better seems a
2121 matter of personal taste. But block smoothing is nearly always a win
2128 quantization method is used.
2130 When generating color-quantized output, changing quantization method is a
2137 two_pass_quantize is ignored); also set cinfo.actual_number_of_colors.
2140 (This is the default setting selected by jpeg_read_header, but it is
2143 only the first method is available for quantizing in non-RGB color spaces.
2184 progress monitor hook is called during this pass, if defined. It is also
2185 important to realize that if the specified target scan number is greater than
2190 target scan is the only case in which jpeg_start_output() will consume input.
2194 for all JPEG images, even single-scan ones. This will work, but it is
2195 inefficient: there is no need to create an image-sized coefficient buffer for
2204 It is also worth noting that when you use jpeg_consume_input() to let input
2206 the coefficient buffer is quite nonsequential. It's best to use the memory
2208 memory). If not, at least make sure that max_memory_to_use is set as high as
2215 input processing, including reading the initial markers; that is, you may
2225 jpeg_abort() to reset it. It is OK to call jpeg_consume_input() even when not
2251 To decode an abbreviated image, it is necessary to load the missing table(s)
2254 image is an interchange (complete) datastream, while subsequent ones are
2255 abbreviated and rely on the tables loaded by the first image. It is assumed
2257 new definition for the same table number is encountered.
2259 It is the application designer's responsibility to figure out how to associate
2261 can be useful in a closed environment, their use is strongly discouraged in
2268 the lifetime of the object, unless it is overwritten by a new table definition.
2271 To create abbreviated image datastreams, it is only necessary to tell the
2272 compressor not to emit some or all of the tables it is using. Each
2274 which normally is initialized to FALSE. For each table used by the image, the
2275 header-writing process emits the table and sets sent_table = TRUE unless it is
2289 will force all the sent_table fields to FALSE. (This is a safety feature to
2297 be emitted unless their sent_tables flag is already TRUE, and then all the
2301 is to proceed as follows:
2318 optimization is selected. (If you could, there'd be no way to decode the
2338 quant_ptr = cinfo.quant_tbl_ptrs[n]; /* quant_ptr is JQUANT_TBL* */
2340 /* Qtable[] is desired quantization table, in natural array order */
2344 Code to load a fixed Huffman table is typically (for AC table "n"):
2348 huff_ptr = cinfo.ac_huff_tbl_ptrs[n]; /* huff_ptr is JHUFF_TBL* */
2350 /* counts[i] is number of Huffman codes of length i bits, i=1..16 */
2354 /* symbols[] is the list of Huffman symbols, in code-length order */
2359 constant JQUANT_TBL object is not safe. If the incoming file happened to
2365 hard-wiring them into your application. The jpeg_read_header() call is
2368 typical scenario is
2384 JPEG_SUSPENDED, is possible when using a suspending data source manager.)
2390 It is possible to read a series of images from a single source file by
2413 Unfortunately, the use of these markers is not specified by the standard.
2428 identifying string so that you can tell whether the marker is actually yours.
2437 selected JPEG colorspace is grayscale or YCbCr, or an Adobe APP14 marker if
2438 the selected colorspace is RGB, CMYK, or YCCK. You can disable this, but
2440 Adobe markers and will set the JPEG colorspace properly when one is found.
2469 is to write version 1.01, but that's wrong if you insert any 1.02 extension
2481 The first method is simpler to use, especially if you are using a suspending
2482 data source; writing a marker processor that copes with input suspension is
2483 not easy (consider what happens if the marker is longer than your available
2492 (potentially many datastreams), unless you change it. Marker handling is
2498 where marker_code is the marker type to save, JPEG_COM or JPEG_APP0+n.
2500 routine 17 times, for COM and APP0-APP15.) If the incoming marker is longer
2504 data, set length_limit to 0xFFFF; that is enough since marker lengths are only
2506 type from being saved at all. (That is the default behavior, in fact.)
2515 within the JPEG file includes it. (Hence the maximum data length is really
2518 It is possible that additional special markers appear in the file beyond the
2520 extended during reading of the rest of the file. This is not expected to be
2527 jpeg_abort, at which point the memory is freed and the list is set to empty.
2530 Note that the library is internally interested in APP0 and APP14 markers;
2535 65533 by malloc() limitations. It is therefore best not to assume that the
2536 effective length limit is exactly what you set it to be.
2543 Although the marker code is not explicitly passed, the routine can find it
2545 read from the data source module. The processor routine is responsible for
2552 If you override the default APP0 or APP14 processors, it is up to you to
2555 want to do that. (A better idea is to save these marker types for later
2574 The interface is different from the standard one and is somewhat harder to
2575 use. If your interest is merely in bypassing color conversion, we recommend
2578 The mechanism described in this section is necessary only to supply or
2587 namely a JSAMPIMAGE array. This is an array of pointers to two-dimensional
2589 color component. This structure is necessary since the components are of
2591 you must also pad the data correctly (usually, this is done by replicating
2593 block in each component: that is, each downsampled row must contain a
2596 conversion of digital TV images, the standard image size is usually a
2599 The procedure for compression of raw data is basically the same as normal
2603 * Set cinfo->raw_data_in to TRUE. (It is set FALSE by jpeg_set_defaults().)
2606 real downsampled data. (It is set TRUE by jpeg_set_defaults().)
2607 * Ensure jpeg_color_space is correct --- an explicit jpeg_set_colorspace()
2608 call is a good idea. Note that since color conversion is bypassed,
2609 in_color_space is ignored, except that jpeg_set_defaults() uses it to
2619 The scanlines count passed to and returned from jpeg_write_raw_data is
2622 jpeg_write_raw_data() processes one MCU row per call, which is to say
2626 future library versions). This is true even on the last call at the bottom
2634 is smaller than this, it must be padded appropriately. For some sampling
2639 Assume 2h2v downsampling of YCbCr data, that is
2652 MCU height is max_v_samp_factor = 2 DCT rows so you must pass at least 16
2653 scanlines on each call to jpeg_write_raw_data(), which is to say 16 actual
2656 of Y data is dummy, so it doesn't matter what you pass for it in the data
2660 Output suspension is supported with raw-data compression: if the data
2672 jpeg_start_decompress() (it is set FALSE by jpeg_read_header()). Be sure to
2675 downsampled data (it is set TRUE by jpeg_read_header()).
2677 decompression process is otherwise the same as usual.
2681 is the same as for raw-data compression). The buffer you pass must be large
2685 above example of computing buffer dimensions for raw-data compression is
2688 Input suspension is supported with raw-data decompression: if the data source
2696 It is possible to read or write the contents of a JPEG file as raw DCT
2697 coefficients. This facility is mainly intended for use in lossless
2706 component. The return value is a pointer to an array of virtual-array
2719 fields of the component's comp_info entry.) This is also the data format
2727 NULL if it is forced to suspend; a non-NULL return value indicates successful
2731 It is also possible to call jpeg_read_coefficients() to obtain access to the
2744 yourself. In either case, jpeg_write_coefficients() is substituted for
2745 jpeg_start_compress() and jpeg_write_scanlines(). Thus the sequence is
2752 jpeg_write_coefficients() is passed a pointer to an array of virtual block
2753 array descriptors; the number of arrays is equal to cinfo.num_components.
2756 jpeg_write_coefficients() is called. A side-effect of
2757 jpeg_write_coefficients() is to realize any virtual arrays that have been
2760 after calling jpeg_write_coefficients(). The data is actually written out
2764 When writing raw DCT coefficients, it is crucial that the JPEG quantization
2771 JPEG input file --- that is, it should be awaiting jpeg_finish_decompress().
2775 jpeg_start_compress(cinfo, TRUE)). This is for safety's sake, to avoid
2786 often. The typical use of this feature is to produce a percent-done bar or
2798 group, whichever unit is convenient for the current processing mode; so the
2809 whenever cinfo->progress is non-NULL. (This pointer is set to NULL by
2822 pass_limit; the step size is usually but not necessarily 1. The pass_limit
2824 passes is in total_passes, and the number of passes already completed is in
2835 opposite case). It is not wise to put great faith in the work estimate.
2838 estimate is likely to be completely unhelpful, because the library has no way
2843 output pass is started. This means that total_passes will rise as additional
2856 All memory and temporary file allocation within the library is done via the
2861 Some data is allocated "permanently" and will not be freed until the JPEG
2862 object is destroyed. Most data is allocated "per image" and is freed by
2865 freed at these times. Typical code for this is
2889 after creating the JPEG object. (Of course, there is still a minimum size for
2890 the buffers, so the max-memory setting is effective only if it is bigger than
2894 that space allocated with alloc_small() is ignored, on the assumption that
2898 If you use the jmemname.c or jmemdos.c memory manager back end, it is
2900 files get deleted. (This is especially crucial with jmemdos.c, where the
2905 or jpeg_destroy() for any active JPEG objects. A handler is not needed with
2907 since the C library is supposed to take care of deleting files made with
2924 is about 34 bytes * width in pixels for a color image. A grayscale image
2926 3. A full-image DCT coefficient buffer is needed to decode a multi-scan JPEG
2950 if Huffman-table optimization is asked for, even if progressive mode is not
2979 application source files. This is untested ... if you try it, we'd like to
2991 The maximum number of components (color channels) in the image is determined
2998 is quite slow; consider trading memory for speed by making JCOEF, INT16, and
2999 UINT16 be "int" or "unsigned int". UINT8 is also a candidate to become int.
3007 the standard error message table occupies about 5Kb. This is particularly
3023 library to be less portable than is claimed here, we'd appreciate hearing
3030 The code is not dependent on the exact sizes of the C data types. As
3032 char is at least 8 bits wide
3033 short is at least 16 bits wide
3034 int is at least 16 bits wide
3035 long is at least 32 bits wide
3037 work fine, although memory may be used inefficiently if char is much larger
3038 than 8 bits or short is much bigger than 16 bits. The code should work
3043 have difficulty if int is less than 16 bits wide, since references to plain
3047 unsigned char type is available. If char is wider than 8 bits, you will need
3057 stdio is used only by the data source/destination modules and the error
3074 The IJG code is designed to work efficiently in 80x86 "small" or "medium"
3087 There is also about 5Kb-6Kb of constant data which will be allocated in the
3088 near data segment (about 4Kb of this is the error message table).
3094 1K. Another possibility is to move the error message table to far memory;
3097 About 2K of the near heap space is "permanent" memory that will not be
3098 released until you destroy the JPEG object. This is only an issue if you
3102 images. The most memory-intensive case is decompression with two-pass color
3111 can use it; the JPEG library is significantly faster in flat model.