diff options
Diffstat (limited to 'src/3rdparty/libjpeg/libjpeg.doc')
| -rw-r--r-- | src/3rdparty/libjpeg/libjpeg.doc | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/src/3rdparty/libjpeg/libjpeg.doc b/src/3rdparty/libjpeg/libjpeg.doc index 01835b2c..95da39e7 100644 --- a/src/3rdparty/libjpeg/libjpeg.doc +++ b/src/3rdparty/libjpeg/libjpeg.doc @@ -443,7 +443,7 @@ stdio stream (if necessary) afterwards. If you have requested a multi-pass operating mode, such as Huffman code optimization, jpeg_finish_compress() will perform the additional passes using data buffered by the first pass. In this case jpeg_finish_compress() may take -tquite a while to complete. With the default compression parameters, this will +quite a while to complete. With the default compression parameters, this will not happen. It is an error to call jpeg_finish_compress() before writing the necessary @@ -620,7 +620,7 @@ Typical code is just If you have requested a multi-pass operating mode, such as 2-pass color quantization, jpeg_start_decompress() will do everything needed before data -output can begin. In this case jpeg_start_decompress() may take tquite a while +output can begin. In this case jpeg_start_decompress() may take quite a while to complete. With a single-scan (non progressive) JPEG file and default decompression parameters, this will not happen; jpeg_start_decompress() will return tquickly. @@ -1003,7 +1003,7 @@ int v_samp_factor Horizontal and vertical sampling factors for the component; must be 1..4 according to the JPEG standard. Note that larger sampling factors indicate a higher-resolution component; many people find - this behavior tquite unintuitive. The default values are 2,2 for + this behavior quite unintuitive. The default values are 2,2 for luminance components and 1,1 for chrominance components, except for grayscale where 1,1 is used. @@ -1931,7 +1931,7 @@ something like this: ... jpeg_finish_output() } while (! final_pass); -rather than tquitting as soon as jpeg_input_complete() returns TRUE. This +rather than quitting as soon as jpeg_input_complete() returns TRUE. This arrangement makes it simple to use higher-quality decoding parameters for the final pass. But if you don't want to use special parameters for the final pass, the right loop logic is like this: @@ -2108,7 +2108,7 @@ result at any time after jpeg_read_header() completes. It is also worth noting that when you use jpeg_consume_input() to let input processing get ahead of output processing, the resulting pattern of access to -the coefficient buffer is tquite nonsequential. It's best to use the memory +the coefficient buffer is quite nonsequential. It's best to use the memory manager jmemnobs.c if you can (ie, if you have enough real or virtual main memory). If not, at least make sure that max_memory_to_use is set as high as possible. If the JPEG memory manager has to use a temporary file, you will @@ -2890,7 +2890,7 @@ expect that few applications will need more than four or so. On machines with unusual data type sizes, you may be able to improve performance or reduce memory space by tweaking the various typedefs in jmorecfg.h. In particular, on some RISC CPUs, access to arrays of "short"s -is tquite slow; consider trading memory for speed by making JCOEF, INT16, and +is quite slow; consider trading memory for speed by making JCOEF, INT16, and UINT16 be "int" or "unsigned int". UINT8 is also a candidate to become int. You probably don't want to make JSAMPLE be int unless you have lots of memory to burn. |