Lines Matching full:was
6 distributions. This was due to the addition of a macro in jconfig.h that
15 specially-crafted JPEG image was being decompressed. In prior versions of
16 libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only
33 negative width or height was used as an input image (Windows bitmaps can have
39 forward DCT were used. This was known to cause 'make test' to fail when the
40 library was built with '-march=haswell' on x86 systems.
43 & greatest development version of the Clang/LLVM compiler. This was caused by
54 decompressing a 4:2:0 JPEG image whose scaled output width was less than 16
60 Clang undefined behavior sanitizers. None of these was known to pose a
98 SIMD-enabled libjpeg-turbo MIPS build was executed with the -nosmooth option on
105 Huffman codec was not being compiled in when libjpeg-turbo was built on
121 indicate that the decompression was not entirely successful.
125 in which the right-most MCU was 5 or 6 pixels wide.
138 instead of -1 if componentID was > 0 and subsamp was TJSAMP_GRAY.
141 instead of -1 if width was < 1.
150 already been called. The exception was caught, but it was still an expensive
159 was being too rigid and was expecting the sampling factors to be equal to 1
165 [9] Referring to 1.4 beta1 [15], another extremely rare circumstance was
169 Even though the Huffman local buffer was increased from 128 bytes to 136 bytes
174 size of the unencoded blocks. Thus, the Huffman local buffer was increased to
203 (previously only 4-byte padding, which was compatible with X Video, was
255 if compiler optimization was enabled when libjpeg-turbo was built. This caused
278 [11] Fixed an issue whereby wrjpgcom was allowing comments longer than 65k
279 characters to be passed on the command line, which was causing it to generate
282 [12] Fixed a bug in the build system that was causing the Windows version of
302 resized by the destination manager. This issue was so rare that, even with a
304 high-frequency YUV data into the compressor), it was reproducible only once in
308 compression functions was called repeatedly with the same
310 assume that the jpegSize parameter was equal to the size of the buffer, when in
311 fact that parameter was probably equal to the size of the most recently
312 compressed JPEG image. If the size of the previous JPEG image was not as large
327 directory as the rest of the libjpeg-turbo binaries. This was mainly done
335 jpegtran, for instance) would result in an error, "Requested feature was
397 [2] The TurboJPEG dynamic library is now versioned. It was not strictly
455 specially-crafted JPEG image was being decompressed. In prior versions of
456 libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only
470 [2] When libjpeg-turbo was built without SIMD support and merged (non-fancy)
471 upsampling was used along with an alpha-enabled colorspace during
472 decompression, the unused byte of the decompressed pixels was not being set to
481 images (specifically, images in which the component count was erroneously set
485 processors. The MASKMOVDQU instruction, which was used by the libjpeg-turbo
499 side of the output image if each row in the output image was not evenly
514 was not adding the current directory to the assembler include path, so YASM
515 was not able to find jsimdcfg.inc.)
518 a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes.
519 This was more of an annoyance than an actual bug, since it did not cause any
524 check the version of libjpeg-turbo against which an application was compiled.
534 internally when building libjpeg-turbo, so it was moved into config.h.
574 was necessary in order for it to read 4:2:2 JPEG files that had been losslessly
594 the application was invoked using I/O redirection
603 error value. The fix was to include the new error constants conditionally
604 based on whether libjpeg v7 or v8 emulation was enabled.
608 This issue was caused by a conflict in the definition of the INT32 type.
610 [15] Fixed 32-bit supplementary package for amd64 Debian systems, which was
643 cinfo->image_width and cinfo->image_height if libjpeg v7 or v8 emulation was
644 enabled. This specifically caused the jpegoptim program to fail if it was
645 linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8
652 application was invoked using I/O redirection (cjpeg <inputfile >output.jpg).
692 README-turbo.txt for more details. This feature was sponsored by CamTrace SAS.
730 [2] Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to