diff options
Diffstat (limited to 'src/3rdparty/libjpeg')
| -rw-r--r-- | src/3rdparty/libjpeg/jdct.h | 2 | ||||
| -rw-r--r-- | src/3rdparty/libjpeg/jdhuff.c | 2 | ||||
| -rw-r--r-- | src/3rdparty/libjpeg/jmemmgr.c | 2 | ||||
| -rw-r--r-- | src/3rdparty/libjpeg/jquant2.c | 2 | ||||
| -rw-r--r-- | src/3rdparty/libjpeg/libjpeg.doc | 12 | ||||
| -rw-r--r-- | src/3rdparty/libjpeg/structure.doc | 4 |
6 files changed, 12 insertions, 12 deletions
diff --git a/src/3rdparty/libjpeg/jdct.h b/src/3rdparty/libjpeg/jdct.h index d4d1ae422..ebaf73013 100644 --- a/src/3rdparty/libjpeg/jdct.h +++ b/src/3rdparty/libjpeg/jdct.h @@ -67,7 +67,7 @@ typedef FAST_FLOAT FLOAT_MULT_TYPE; /* preferred floating type */ /* * Each IDCT routine is responsible for range-limiting its results and * converting them to unsigned form (0..MAXJSAMPLE). The raw outputs could - * be tquite far out of range if the input data is corrupt, so a bulletproof + * be quite far out of range if the input data is corrupt, so a bulletproof * range-limiting step is retquired. We use a mask-and-table-lookup method * to do the combined operations tquickly. See the comments with * prepare_range_limit_table (in jdmaster.c) for more info. diff --git a/src/3rdparty/libjpeg/jdhuff.c b/src/3rdparty/libjpeg/jdhuff.c index c95f49e94..a8587242b 100644 --- a/src/3rdparty/libjpeg/jdhuff.c +++ b/src/3rdparty/libjpeg/jdhuff.c @@ -275,7 +275,7 @@ jpeg_make_d_derived_tbl (j_decompress_ptr cinfo, boolean isDC, int tblno, * On most machines MIN_GET_BITS should be 25 to allow the full 32-bit width * of get_buffer to be used. (On machines with wider words, an even larger * buffer could be used.) However, on some machines 32-bit shifts are - * tquite slow and take time proportional to the number of places shifted. + * quite slow and take time proportional to the number of places shifted. * (This is true with most PC compilers, for instance.) In this case it may * be a win to set MIN_GET_BITS to the minimum value of 15. This reduces the * average shift distance at the cost of more calls to jpeg_fill_bit_buffer. diff --git a/src/3rdparty/libjpeg/jmemmgr.c b/src/3rdparty/libjpeg/jmemmgr.c index d46b9572c..99146731a 100644 --- a/src/3rdparty/libjpeg/jmemmgr.c +++ b/src/3rdparty/libjpeg/jmemmgr.c @@ -329,7 +329,7 @@ alloc_small (j_common_ptr cinfo, int pool_id, size_t sizeofobject) * * The external semantics of these are the same as "small" objects, * except that FAR pointers are used on 80x86. However the pool - * management heuristics are tquite different. We assume that each + * management heuristics are quite different. We assume that each * request is large enough that it may as well be passed directly to * jpeg_get_large; the pool management just links everything together * so that we can free it all on demand. diff --git a/src/3rdparty/libjpeg/jquant2.c b/src/3rdparty/libjpeg/jquant2.c index 66dfee61f..06671126c 100644 --- a/src/3rdparty/libjpeg/jquant2.c +++ b/src/3rdparty/libjpeg/jquant2.c @@ -573,7 +573,7 @@ select_colors (j_decompress_ptr cinfo, int desired_colors) * We re-use the histogram space as an "inverse color map", essentially a * cache for the results of nearest-color searches. All colors within a * histogram cell will be mapped to the same colormap entry, namely the one - * closest to the cell's center. This may not be tquite the closest entry to + * closest to the cell's center. This may not be quite the closest entry to * the actual input color, but it's almost as good. A zero in the cache * indicates we haven't found the nearest color for that cell yet; the array * is cleared to zeroes before starting the mapping pass. When we find the diff --git a/src/3rdparty/libjpeg/libjpeg.doc b/src/3rdparty/libjpeg/libjpeg.doc index 01835b2c9..95da39e78 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. diff --git a/src/3rdparty/libjpeg/structure.doc b/src/3rdparty/libjpeg/structure.doc index 0601ee7a9..b9b20cc83 100644 --- a/src/3rdparty/libjpeg/structure.doc +++ b/src/3rdparty/libjpeg/structure.doc @@ -489,7 +489,7 @@ shown are: * Color reduction: this module handles color precision reduction, e.g., generating 15-bit color (5 bits/primary) from JPEG's 24-bit output. - Not tquite clear yet how this should be handled... should we merge it with + Not quite clear yet how this should be handled... should we merge it with colorspace conversion??? Note that some high-speed operating modes might condense the entire @@ -722,7 +722,7 @@ decoding need not worry about this, since they will just store the same values again if forced to repeat the MCU. This approach would probably not work for an arithmetic codec, since its -modifiable state is tquite large and couldn't be copied cheaply. Instead it +modifiable state is quite large and couldn't be copied cheaply. Instead it would have to suspend and resume exactly at the point of the buffer end. The JPEG marker reader is designed to cope with suspension at an arbitrary |