Lines Matching refs:will
135 which typically will write the data into a file; but the application can
154 output scaling ratio that will fit the image into the available screen size.
157 manager, which typically will read the data from a file; but other behaviors
191 interpretation of the components. Most applications will use RGB data
259 You will also need a structure representing a JPEG error handler. The part
264 handler. The default error handler will print JPEG error/warning messages
265 on stderr, and it will call exit() if a fatal error occurs.
280 if you are out of memory. In that case it will exit via the error handler;
361 a compression cycle. This will initialize internal state, allocate working
369 will be written. This is appropriate in most cases. If you think you might
415 This will normally be equal to the number passed in, so you can usually
420 will cause the compressor to return before accepting all the passed lines.
422 stdio destination manager will NOT cause this to happen.
443 optimization, jpeg_finish_compress() will perform the additional passes using
445 quite a while to complete. With the default compression parameters, this will
455 destination manager, the new datastream will be written to the same target.
456 If you do not change any JPEG parameters, the new datastream will be written
466 jpeg_destroy_compress(). This will free all subsidiary memory (regardless of
495 This will return the object to an idle state, releasing any working memory.
499 responsibility; neither of these routines will call term_destination().
505 whack. Either of these two routines will return the object to a known state.
572 This will read the source datastream header markers, up to the beginning
580 below. The normal stdio source manager will NOT cause this to happen.
613 begin decompression. This will initialize internal state, allocate working
621 quantization, jpeg_start_decompress() will do everything needed before data
624 decompression parameters, this will not happen; jpeg_start_decompress() will
639 equals out_color_components. It is the number of JSAMPLE values that will be
642 Typically you will need to allocate data buffers to hold the incoming image.
643 You will need output_width * output_components JSAMPLEs per scanline in your
644 output buffer, and a total of output_height scanlines will be returned.
660 will return up to that many lines. The return value is the number of lines
662 formats", above. Don't forget that grayscale and color JPEGs will return
709 manager, the next image will be read from the same source.
744 installing the JPEG header files in a system directory, you will want to
750 library (only compression or only decompression), only that much code will be
768 it will try to grab extended memory for temp files, and that space will NOT be
803 already be set in cinfo). Many applications will only need to use
942 supply will be overwritten.
962 compressor will then write a JPEG file having one scan for each scan
1017 routines will set up table slot 0 for luminance quality and table
1055 The actual dimensions of the JPEG image that will be written to the file are
1058 also call jpeg_calc_jpeg_dimensions() to obtain the values that will result
1060 to pick a scaling ratio that will get close to a desired target size.
1097 release v6, the compressor library will fill this in automatically;
1133 adhere to the JFIF or Adobe conventions, and the decoder will recognize these
1142 based on jpeg_color_space; typically it will be RGB or grayscale.
1166 If set TRUE, colormapped output will be delivered. Default is FALSE,
1167 meaning that full-color output will be delivered.
1243 to obtain the values that will result from the current parameter settings.
1244 This can be useful if you are trying to pick a scaling ratio that will get
1261 library will still work, but time will be wasted due to unnecessary data
1280 but it must be understood that such files will be unportable.
1308 jpeg_set_colorspace() will set the compression parameters to include or omit
1316 When told that the color space is UNKNOWN, the library will default to using
1350 CMYK files, you will have to deal with it in your application. We cannot
1356 operator. I am told that Photoshop 3.0 will write uninverted YCCK in
1357 EPS/JPEG files, and will omit the PS-level inversion. (But the data
1358 polarity used in bare JPEG files will not change in 3.0.) In either case,
1367 routines will cause a message to be printed on stderr, followed by exit().
1380 program by adjusting the maximum trace level that will be displayed.
1389 All of the error handling routines will receive a pointer to the JPEG object
1393 "err" field. Frequently, custom error handler routines will need to access
1409 generally this routine will exit() or longjmp() somewhere.
1440 jerror.h for the default texts. CAUTION: this table will almost certainly
1483 data in memory. In this case the buffer-reload procedure will be invoked
1533 You will also need code to create a jpeg_destination_mgr struct, fill in its
1559 will occur immediately).
1602 is the best course of action --- this will allow the decompressor to output
1610 You will also need code to create a jpeg_source_mgr struct, fill in its method
1631 maximum amount of time spent in any one call to the library, so it will not
1637 and the data source or destination manager; you will always need a custom
1649 FALSE; typically it will not do anything else. This will cause the
1656 When forced to suspend, the compressor will backtrack to a convenient stopping
1657 point (usually the start of the current MCU); it will regenerate some output
1661 next_output_byte/free_in_buffer. The data beyond that point will be
1690 whole file during jpeg_finish_compress(), which will certainly result in
1699 This will cause the decompressor to return to its caller with an indication
1701 * jpeg_read_header(): will return JPEG_SUSPENDED.
1702 * jpeg_start_decompress(): will return FALSE, rather than its usual TRUE.
1703 * jpeg_read_scanlines(): will return the number of scanlines already
1705 * jpeg_finish_decompress(): will return FALSE, rather than its usual TRUE.
1710 Just as with compression, the decompressor will typically backtrack to a
1713 which is where the decompressor will backtrack to if FALSE is returned.
1727 additional skip distance somewhere else. The decompressor will immediately
1728 call fill_input_buffer(), which should return FALSE, which will cause a
1743 instead it will backtrack to the start of the marker and reprocess the whole
1774 Since fill_input_buffer() will set the pointer and count to refer to a new
1784 The library will never attempt to backtrack over a skip_input_data() call,
1813 will receive a final decoded image without any indication that the file was
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
1859 input with version 5 of the IJG library will need to be modified to check
1916 will be incremented by the time control arrives back at jpeg_start_output()).
1948 events occurs. (If called after the EOI marker is reached, it will
1951 The library's output processing will automatically call jpeg_consume_input()
1986 number greater than the current input scan number, the output processor will
1990 target scan number, the library will just absorb the entire input file and
1998 waiting for input. (However, the library will not accept a target scan
2002 through the image, jpeg_consume_input() will store data into the buffered
2046 will avoid an extra output pass whenever the decoder is able (or nearly able)
2073 as the target scan, expecting that the scan will be small and will arrive
2088 * jpeg_finish_output() will read any markers following the target scan,
2092 * jpeg_finish_decompress() will read until the end of file, and thus can
2169 you should not do either of these things. This will save some nontrivial
2171 (These requirements exist because cinfo.colormap will always be non-NULL
2186 or equal to the current input scan number, jpeg_start_output() will attempt
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
2201 tested by calling jpeg_has_multiple_scans(), which will return a correct
2209 possible. If the JPEG memory manager has to use a temporary file, you will
2220 jpeg_start_decompress() before jpeg_consume_input() will consume more input;
2222 tables-only file this way, jpeg_consume_input() will return JPEG_REACHED_EOI
2224 If this happens, the decompressor will not read any more input until you call
2227 initial markers have been read: it will just return JPEG_SUSPENDED.
2241 and Huffman tables. In a situation where many images will be stored or
2256 that once the decoder has read a table, it will remember that table until a
2267 decompression objects, a quantization or Huffman table will be retained for
2279 calling jpeg_start_compress() will prevent the table from being written at
2289 will force all the sent_table fields to FALSE. (This is a safety feature to
2294 jpeg_write_tables(&cinfo). This will write an abbreviated datastream
2296 and Huffman tables that are currently defined in the compression object will
2298 sent_tables flags will be set TRUE.
2382 from jpeg_read_header(): it will be JPEG_HEADER_OK if an image was found,
2385 Note that jpeg_read_header() will not complain if you read an abbreviated
2430 (NOTE: the upcoming SPIFF standard will use APP8 markers; we recommend you
2436 By default, the IJG compression library will write a JFIF APP0 marker if the
2439 we don't recommend it. The decompression library will recognize JFIF and
2440 Adobe markers and will set the JPEG colorspace properly when one is found.
2448 "JPEG_APP0 + n" for APPn. (Actually, jpeg_write_marker will let you write
2467 forget to set cinfo.JFIF_minor_version = 2 so that the encoder will write the
2489 markers of interest will typically be near the head of the file and so will
2491 method, it will be used for the life of that decompression object
2501 than length_limit data bytes, only length_limit bytes will be saved; this
2513 will not exceed length_limit for the particular marker type. Note that these
2519 SOS marker at which jpeg_read_header stops; if so, the marker list will be
2532 will silently force the length up to the minimum it wants. (But you can set
2604 This notifies the library that you will be supplying raw data.
2625 will be exactly that amount (or possibly some multiple of that amount, in
2647 cinfo->image_height) are 101x101 pixels. Then jpeg_start_compress() will
2661 destination module suspends, jpeg_write_raw_data() will return 0.
2669 The library will not convert to a different color space for you.
2689 module suspends, jpeg_read_raw_data() will return 0. You can also use
2704 and jpeg_read_scanlines(), call jpeg_read_coefficients(). This will read the
2726 If you use a suspending data source, jpeg_read_coefficients() will return
2736 the last jpeg_finish_output() call. The arrays will be available for your use
2766 resulting file will be invalid. For transcoding from an existing JPEG file,
2790 will occur inside jpeg_finish_compress or jpeg_start_decompress; those
2794 You can define a progress-monitor routine which will be called periodically
2795 by the library. No guarantees are made about how often this call will occur,
2797 At present, a call will occur once per MCU row, scanline, or sample row
2808 and set cinfo->progress to point to the struct. The callback will be called
2810 jpeg_create_compress or jpeg_create_decompress; the library will not change
2812 make sure it will live as long as the JPEG object does. Allocating from the
2813 JPEG memory manager with lifetime JPOOL_PERMANENT will work nicely.) You
2839 to know how many output passes will be demanded of it. Currently, the library
2840 sets total_passes based on the assumption that there will be one more output
2843 output pass is started. This means that total_passes will rise as additional
2846 will probably be more useful than using the library's value.
2861 Some data is allocated "permanently" and will not be freed until the JPEG
2864 memory manager yourself to allocate structures that will automatically be
2886 When using temporary files, the library will make the in-memory buffers for
2902 DOS will require a reboot to recover the memory.) Thus, with these memory
2903 managers, it's a good idea to provide a signal handler that will trap any
2938 buffers and quantization pixel buffer. The "fixed-size" data will be
2940 or other unusual color spaces will require different amounts of space.
2993 expect that few applications will need more than four or so.
3036 (These are the minimum requirements of the ANSI C standard.) Wider types will
3042 code work by modifying the typedefs in jmorecfg.h. However, you will probably
3047 unsigned char type is available. If char is wider than 8 bits, you will need
3077 model to compile cjpeg or djpeg by itself, but you will probably have to use
3079 performance. You *will* take a noticeable performance hit if you use a
3083 The JPEG library typically needs 2Kb-3Kb of stack space. It will also
3085 heap, but that doesn't count in this calculation). This figure will vary
3087 There is also about 5Kb-6Kb of constant data which will be allocated in the
3091 static data will account for several K of this, but that still leaves a good
3097 About 2K of the near heap space is "permanent" memory that will not be