Lines Matching +full:- +full:denable_shared
11 "abbreviated table specification" (AKA "tables-only") datastreams, which can be
15 3. libjpeg-turbo now performs run-time detection of AltiVec instructions on
17 This allows both AltiVec-equipped (PowerPC G4 and G5) and non-AltiVec-equipped
18 (PowerPC G3) CPUs to be supported using the same build of libjpeg-turbo.
22 iMCU (8 * the vertical sampling factor) using buffered-image mode with
27 properly with buffered-image mode:
29 - Attempting to call `jpeg_crop_scanline()` after
32 - Attempting to use `jpeg_skip_scanlines()` resulted in an error ("Bogus
42 input files into full-color JPEG images unless the `-grayscale` option was
45 2. cjpeg now automatically compresses GIF and 8-bit BMP input files into
49 (Arm 64-bit) Neon SIMD extensions by default when using GCC 12 or later.
52 the merged (non-fancy) upsampling algorithms (that is, with
66 GAS implementations of AArch64 (Arm 64-bit) Neon SIMD functions (which are used
70 prevented libjpeg-turbo from working properly with other linkers and also
74 MCU block size for 4:4:4 JPEG images with non-unary sampling factors and thus
82 4. libjpeg-turbo now performs run-time detection of AltiVec instructions on
84 time. This allows both AltiVec-equipped and non-AltiVec-equipped CPUs to be
85 supported using the same build of libjpeg-turbo.
87 5. cjpeg now accepts a `-strict` argument similar to that of djpeg and
88 jpegtran, which causes the compressor to abort if an LZW-compressed GIF input
98 non-GCC-compatible compilers for Un*x/Arm platforms.
100 2. Fixed a regression introduced by 2.1 beta1[13] that prevented the Arm 32-bit
102 included `-mfloat-abi=softfp` or `-mfloat-abi=hard`.
106 Android systems when running AArch32/Thumb builds of libjpeg-turbo built with
109 4. Added a command-line argument (`-copy icc`) to jpegtran that causes it to
113 5. libjpeg-turbo should now build and run on CHERI-enabled architectures, which
116 6. Fixed a regression (CVE-2021-37972) introduced by 2.1 beta1[5] that caused a
117 segfault in the 64-bit SSE2 Huffman encoder when attempting to losslessly
118 transform a specially-crafted malformed JPEG image.
131 decompress a specially-crafted malformed progressive JPEG image caused the
138 4. Fixed a floating point exception (CVE-2021-20205) that occurred when
139 attempting to compress a specially-crafted malformed GIF image with a specified
143 generate a progressive JPEG image on an SSE2-capable CPU using a scan script
144 containing one or more scans with lengths divisible by 32 and non-zero
151 command-line argument (`-limitscans`) that causes the TurboJPEG decompression
156 ["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswitht…
160 `tjLoadImage()` function to load a 16-bit binary PPM file (a binary PPM file
162 a 16-bit binary PGM file into an RGB image buffer.
165 generated when using the `tjLoadImage()` function to load a 16-bit binary PPM
168 9. Fixed an issue whereby, if a JPEG buffer was automatically re-allocated by
179 1. The build system, x86-64 SIMD extensions, and accelerated Huffman codec now
180 support the x32 ABI on Linux, which allows for using x86-64 instructions with
181 32-bit pointers. The x32 ABI is generally enabled by adding `-mx32` to the
185 - CMake 3.9.0 or later is required in order for the build system to
187 - Java does not support the x32 ABI, and thus the TurboJPEG Java API will
190 2. Added Loongson MMI SIMD implementations of the RGB-to-grayscale, 4:2:2 fancy
192 and fast integer DCT/IDCT algorithms. Relative to libjpeg-turbo 2.0.x, this
195 - the compression of RGB source images into grayscale JPEG images by
197 - the decompression of 4:2:2 JPEG images by approximately 40-60% when
199 - the decompression of 4:2:2 and 4:2:0 JPEG images by approximately
200 15-20% when using merged upsampling
201 - the compression of RGB source images by approximately 30-45% when using
203 - the decompression of JPEG images into RGB destination images by
207 2.3-3.7x (compared to 2-3.5x with libjpeg-turbo 2.0.x.)
209 3. 32-bit (Armv7 or Armv7s) iOS builds of libjpeg-turbo are no longer
210 supported, and the libjpeg-turbo build system can no longer be used to package
211 such builds. 32-bit iOS apps cannot run in iOS 11 and later, and the App Store
214 4. 32-bit (i386) OS X/macOS builds of libjpeg-turbo are no longer supported,
215 and the libjpeg-turbo build system can no longer be used to package such
216 builds. 32-bit Mac applications cannot run in macOS 10.15 "Catalina" and
221 speedup of 12-28% for 64-bit code and 22-52% for 32-bit code on various Intel
223 0-23% on platforms that do not have a SIMD-accelerated Huffman encoding
227 progressive Huffman-encoded JPEG images has been improved in the following
230 - The algorithm is now more fault-tolerant. Previously, if a particular
234 effect of removing block smoothing from lower-frequency scans if they were
235 followed by an incomplete higher-frequency scan. libjpeg-turbo now applies
239 - When applying block smoothing to DC scans, a Gaussian-like kernel with a
243 This speeds up the compression of full-color progressive JPEGs by about 30-40%
244 on average (relative to libjpeg-turbo 2.0.x) when using modern Arm CPUs.
246 8. Added configure-time and run-time auto-detection of Loongson MMI SIMD
248 MIPS64 libjpeg-turbo build.
253 ["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswitht…
255 - Both programs now accept a `-maxscans` argument, which can be used to
257 - Both programs now accept a `-strict` argument, which can be used to
261 TurboJPEG API libraries. This facilitates using libjpeg-turbo with CMake's
264 find_package(libjpeg-turbo CONFIG REQUIRED)
267 target_link_libraries(libjpeg_program PUBLIC libjpeg-turbo::jpeg)
271 libjpeg-turbo::jpeg-static)
275 libjpeg-turbo::turbojpeg)
279 libjpeg-turbo::turbojpeg-static)
282 read/write both LZW-compressed and uncompressed GIF files (feature ported from
283 jpeg-6a and jpeg-9d.)
285 12. jpegtran now includes the `-wipe` and `-drop` options from jpeg-9a and
286 jpeg-9d, as well as the ability to expand the image size using the `-crop`
291 that are SIMD-accelerated on x86 platforms. This new implementation is
292 significantly faster in some cases than the old GAS implementation--
295 so for performance reasons, the default when building libjpeg-turbo with GCC is
298 - 32-bit RGB-to-YCbCr color conversion
299 - 32-bit fast and accurate inverse DCT
300 - 64-bit RGB-to-YCbCr and YCbCr-to-RGB color conversion
301 - 64-bit accurate forward and inverse DCT
302 - 64-bit Huffman encoding
313 15. The build system can now be used to generate a universal x86-64 + Armv8
314 libjpeg-turbo SDK package for both iOS and macOS.
328 - Fixed segfaults or "Corrupt JPEG data: premature end of data segment"
330 4:2:0 JPEG images using merged (non-fancy) upsampling/color conversion (that
333 - `jpeg_skip_scanlines()` now throws an error if two-pass color
334 quantization is enabled. Two-pass color quantization never worked properly
336 - Fixed an issue whereby `jpeg_skip_scanlines()` always returned 0 when
339 3. The Arm 64-bit (Armv8) Neon SIMD extensions can now be built using MinGW
346 5. Fixed an issue whereby libjpeg-turbo would not build if 12-bit-per-component
357 in the libjpeg-turbo regression tests. Specifically, the
361 disabled when building libjpeg-turbo for such CPUs.
368 3. Fixed an issue (CVE-2020-13790) in the PPM reader that caused a buffer
371 header and that maximum value was less than 255. libjpeg-turbo 1.5.0 already
377 instance handle, is now thread-safe on platforms that support thread-local
387 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo SDK for GCC and the
388 64-bit libjpeg-turbo SDK for Visual C++ were installed on the same system, only
393 64-bit C version of TJBench.
395 3. Fixed out-of-bounds write in `tjDecompressToYUV2()` and
399 `cjpeg -grayscale -sample 2x2`).
407 5. Fixed an issue (CVE-2020-17541), detected by ASan, whereby attempting to
408 losslessly transform a specially-crafted malformed JPEG image containing an
409 extremely-high-frequency coefficient block (junk image data that could never be
413 segfault or other user-visible errant behavior, and given that the lossless
417 6. The Arm 64-bit (Armv8) Neon SIMD assembly code now stores constants in a
418 separate read-only data section rather than in the text section, to support
419 execute-only memory layouts.
450 generate a progressive JPEG image on an SSE2-capable CPU using a scan script
466 path (rpath) from being embedded in the libjpeg-turbo shared libraries and
470 libjpeg-turbo shared libraries.
472 2. Fixed an integer overflow and subsequent segfault (CVE-2018-20330) that
476 3. Fixed a buffer overrun (CVE-2018-19664) that occurred when attempting to
477 decompress a specially-crafted malformed JPEG image to a 256-color BMP using
481 decompress a specially-crafted malformed JPEG image with a specified image
485 or 1x3 luminance and chrominance sampling factors. This is a non-standard way
491 incorrect PPM images when used with the `-colors` option.
493 7. Fixed an issue whereby a static build of libjpeg-turbo (a build in which
497 occurred when compressing RGB images whose image rows were not 64-bit-aligned.
505 1. Fixed a regression introduced with the new CMake-based Un*x build system,
507 `"HAVE_*_H" redefined` if it was included by downstream Autotools-based
517 the AVX2 SIMD extensions (2.0 beta1[1]), that caused libjpeg-turbo to crash on
520 4. Fixed out-of-bounds read in cjpeg that occurred when attempting to compress
521 a specially-crafted malformed color-index (8-bit-per-sample) Targa file in
525 5. Fixed an issue whereby installing a fully static build of libjpeg-turbo
526 (a build in which `CFLAGS` contains `-static` and `ENABLE_SHARED` is `0`) would
543 2. Fixed an issue (CVE-2018-11813) whereby a specially-crafted malformed input
553 the underlying library, and because it did not involve any out-of-bounds reads
562 4. Fixed an issue (CVE-2018-1152) whereby a specially-crafted malformed BMP
566 4-component image buffer.
574 a 4:2:2 or 4:2:0 JPEG image using the merged (non-fancy) upsampling algorithms
577 7. The new CMake-based build system will now disable the MIPS DSPr2 SIMD
580 8. Fixed out-of-bounds read in cjpeg (CVE-2018-14498) that occurred when
581 attempting to compress a specially-crafted malformed color-index
582 (8-bit-per-sample) BMP file in which some of the samples (color indices)
587 attempting to decompress a specially-crafted malformed JPEG image. This issue
600 algorithms on AVX2-equipped CPUs, the compression of RGB images is
601 approximately 13-36% (avg. 22%) faster (relative to libjpeg-turbo 1.5.x) with
602 64-bit code and 11-21% (avg. 17%) faster with 32-bit code, and the
603 decompression of RGB images is approximately 9-35% (avg. 17%) faster with
604 64-bit code and 7-17% (avg. 12%) faster with 32-bit code. (As tested on a
608 autotools-based build system. This decision resulted from extensive
609 discussions within the libjpeg-turbo community. libjpeg-turbo traditionally
616 of our build system, owing to CMake's built-in support for various assemblers,
626 libjpeg-turbo to be configured without the use of a terminal/command prompt.
628 autotools-based build system are provided by the new build system.
630 3. The libjpeg API in this version of libjpeg-turbo now includes two additional
639 - Introduced a new function (`tjGetErrorStr2()`) in the TurboJPEG C API
641 in a thread-safe manner. Retrieving error messages from global functions, such
642 as `tjInitCompress()` or `tjBufSize()`, is still thread-unsafe, but since those
645 - Introduced a new function (`tjGetErrorCode()`) in the TurboJPEG C API
649 choose whether to ignore warnings (non-fatal errors) from the underlying
651 - Introduced a new flag (`TJFLAG_STOPONWARNING` in the TurboJPEG C API and
663 enabled for selected transforms in a multi-transform operation.
673 replace the project-private (and slow) bmp API, which was previously used by
674 TJBench, and they also provide a convenient way for first-time users of
675 libjpeg-turbo to quickly develop a complete JPEG compression/decompression
679 that contains the alpha component index for each pixel format (or -1 if the
682 the `tjRedOffset[]`, `tjGreenOffset[]`, and `tjBlueOffset[]` arrays-- and the
684 `TJ.getBlueOffset()` methods-- now return -1 for `TJPF_GRAY`/`TJ.PF_GRAY`
690 Both files are now included in the libjpeg-turbo documentation.
694 to decompress a specially-crafted malformed JPEG image. These issues did not
700 now produces bitwise-identical results to the unmerged algorithms.
702 12. The SIMD function symbols for x86[-64]/ELF, MIPS/ELF, macOS/x86[-64] (if
703 libjpeg-turbo is built with Yasm), and iOS/Arm[64] builds are now private.
705 libraries that link statically with libjpeg-turbo.
707 13. Added Loongson MMI SIMD implementations of the RGB-to-YCbCr and
708 YCbCr-to-RGB colorspace conversion, 4:2:0 chroma downsampling, 4:2:0 fancy
711 compression of RGB images by approximately 70-100% and the decompression of RGB
712 images by approximately 2-3.5x.
717 15. Added SIMD acceleration for progressive Huffman encoding on SSE2-capable
718 x86 and x86-64 platforms. This speeds up the compression of full-color
719 progressive JPEGs by about 85-90% on average (relative to libjpeg-turbo 1.5.x)
736 PPM/PGM was selected along with the `-crop` option. The `-crop` option now
739 write scanlines in bottom-up order.) djpeg will now exit gracefully if an
741 `-crop` option.
743 4. Fixed an issue (CVE-2017-15232) whereby `jpeg_skip_scanlines()` would
747 command-line argument is unrecognized. This prevents the program from silently
758 end of a single-scan (non-progressive) image, subsequent calls to
764 with `cjpeg -grayscale -sample 2x2`).
772 1. Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from
773 building with Android NDK platforms prior to android-21 (5.0).
776 code in libjpeg-turbo from building.
779 version of TJBench from outputting any reference images (the `-nowrite` switch
782 4. libjpeg-turbo should now build and run with full AltiVec SIMD acceleration
783 on PowerPC-based AmigaOS 4 and OpenBSD systems.
786 libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory
789 libjpeg-turbo was built with `-DWITH_JPEG7=1` and `-DWITH_MEMSRCDST=1`.
792 lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was
793 built with libjpeg v7 API/ABI emulation. This was apparently a long-standing
795 in libjpeg-turbo v1.1.
804 `-copy all` must be passed to jpegtran in order to transfer the EXIF tags from
809 (known to occur with GCC 4.x and clang with `-O1` and higher but not with
813 9. The libjpeg-turbo memory manager will now honor the `max_memory_to_use`
815 of memory (in bytes) that libjpeg-turbo should use during decompression or
816 multi-pass (including progressive) compression. This limit can also be set
817 using the `JPEGMEM` environment variable or using the `-maxmemory` switch in
821 implemented the feature. Restricting libjpeg-turbo's memory usage is useful
823 in libFuzzer, and it allows developers of security-sensitive applications to
824 more easily defend against one of the progressive JPEG exploits (LJT-01-004)
826 [this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf).
830 `-warmup` option is now used to specify the amount of warmup time rather than
834 the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a
844 used to force-enable a particular SIMD instruction set if multiple instruction
849 since the ARM implementations of libjpeg-turbo can only use one SIMD
857 ARM and MIPS builds of libjpeg-turbo in QEMU, which passes through
860 2. libjpeg-turbo previously assumed that AltiVec instructions were always
863 and newer e5500 series.) libjpeg-turbo now examines /proc/cpuinfo on
866 `JSIMD_FORCENONE`, to force-enable and force-disable AltiVec instructions in
868 detection (such as when running in QEMU.) On OS X, libjpeg-turbo continues to
869 assume that AltiVec support is always available, which means that libjpeg-turbo
873 3. Fixed an issue whereby 64-bit ARM (AArch64) builds of libjpeg-turbo would
875 caused by an ABI conformance issue in some of libjpeg-turbo's 64-bit NEON SIMD
876 routines. Those routines were incorrectly using 64-bit instructions to
877 transfer a 32-bit JDIMENSION argument, whereas the ABI allows the upper
878 (unused) 32 bits of a 32-bit argument's register to be undefined. The new
879 Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit
880 structure members into a single 64-bit register, and this exposed the ABI
886 The h1v2 fancy upsampling algorithm is not currently SIMD-accelerated.
888 5. If merged upsampling isn't SIMD-accelerated but YCbCr-to-RGB conversion is,
889 then libjpeg-turbo will now disable merged upsampling when decompressing YCbCr
892 upsampling is not used (for example, if the `-nosmooth` option to djpeg is
897 This is a non-standard way of specifying 2x subsampling (normally 4:2:2 JPEGs
904 attempting to decompress a specially-crafted malformed JPEG image. This issue
905 affected only 32-bit code and did not pose a security threat, but removing the
911 specially-crafted malformed JPEG images. None of these issues posed a security
915 9. Fixed an out-of-bounds array reference, introduced by 1.4.90[2] (partial
917 that could be triggered by a specially-crafted malformed JPEG image with more
918 than four components. Because the out-of-bounds reference was still within the
923 10. Fixed another ABI conformance issue in the 64-bit ARM (AArch64) NEON SIMD
934 1. Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast
935 path" of libjpeg-turbo's Huffman decoder to read from uninitialized memory.
937 2. Added libjpeg-turbo version and build information to the global string table
946 than 255. libjpeg-turbo 1.4.2 already included a similar fix for ASCII PPM/PGM
948 to the cjpeg program and did not affect any of the libjpeg-turbo libraries.
958 5. Fixed an issue in the ARM 32-bit SIMD-accelerated Huffman encoder that
976 (128-bit SIMD) instructions. Although the performance of libjpeg-turbo on
979 3-4x and decompression by about 2-2.5x (relative to libjpeg v6b) through the
988 try-with-resources statement.
997 pointers. This facilitates passing read-only buffers to those functions and
999 not create any backward API or ABI incompatibilities with prior libjpeg-turbo
1007 32-bit code, and none of them was known to pose a security threat, but removing
1015 9. Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit
1016 libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora
1019 that macro differs between 32-bit and 64-bit builds, this caused a conflict
1021 are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.)
1024 10. The x86-64 SIMD code can now be disabled at run time by setting the
1028 11. Added a new command-line argument to TJBench (`-nowrite`) that prevents the
1033 12. Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and x86-64
1034 platforms. This speeds up the compression of full-color JPEGs by about 10-15%
1035 on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and AMD
1040 benchmarking or regression testing, SIMD-accelerated Huffman encoding can be
1043 13. Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used
1045 h2v1 downsampling algorithms, which are not accelerated in the 32-bit NEON
1046 implementation.) This speeds up the compression of full-color JPEGs by about
1047 75% on average on a Cavium ThunderX processor and by about 2-2.5x on average on
1048 Cortex-A53 and Cortex-A57 cores.
1050 14. Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit
1051 and 64-bit platforms.
1053 For 32-bit code, this speeds up the compression of full-color JPEGs by
1054 about 30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by
1055 about 6-7% on average on a typical Android device (Nexus 5X, Cortex-A53 and
1056 Cortex-A57), relative to libjpeg-turbo 1.4.x. Note that the larger speedup
1060 For 64-bit code, NEON-accelerated Huffman encoding speeds up the
1061 compression of full-color JPEGs by about 40% on average on a typical iOS device
1062 (iPhone 5S, Apple A7) and by about 7-8% on average on a typical Android device
1063 (Nexus 5X, Cortex-A53 and Cortex-A57), in addition to the speedup described in
1066 For the purposes of benchmarking or regression testing, SIMD-accelerated
1070 15. pkg-config (.pc) scripts are now included for both the libjpeg and
1073 with libjpeg or with a prior version of libjpeg-turbo.
1075 16. Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to
1076 improve performance on CPUs with in-order pipelines. This speeds up the
1077 decompression of full-color JPEGs by nearly 2x on average on a Cavium ThunderX
1078 processor and by about 15% on average on a Cortex-A53 core.
1082 specially-crafted JPEG image was being decompressed. In prior versions of
1083 libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only
1086 long, so this version of libjpeg-turbo activates the accelerated Huffman
1090 with the `-yuv` option.
1100 a negative height if they are stored in top-down order, but such files are
1101 rare and not supported by libjpeg-turbo.)
1103 2. Fixed an issue whereby, under certain circumstances, libjpeg-turbo would
1106 library was built with `-march=haswell` on x86 systems.
1108 3. Fixed an issue whereby libjpeg-turbo would crash when built with the latest
1110 an x86-64 ABI conformance issue in some of libjpeg-turbo's 64-bit SSE2 SIMD
1111 routines. Those routines were incorrectly using a 64-bit `mov` instruction to
1112 transfer a 32-bit JDIMENSION argument, whereas the x86-64 ABI allows the upper
1113 (unused) 32 bits of a 32-bit argument's register to be undefined. The new
1114 Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit
1115 structure members into a single 64-bit register, and this exposed the ABI
1118 4. Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged)
1122 decompressing a non-YCbCr JPEG image, but they are also used when decompressing
1137 `-cmyk` (instead of, for instance, `-rgb`) will cause tjbench to internally
1141 passed to tjbench as a source image.) The CMYK<->RGB conversion operation is
1142 not benchmarked. NOTE: The quick & dirty CMYK<->RGB conversions that tjbench
1154 re-enable the tests and to specify an expected result for them based on the
1158 which speeds up the compression of RGB and CMYK JPEGs by 5-20% when using
1159 64-bit code and 0-3% when using 32-bit code, and the decompression of those
1160 images by 10-30% when using 64-bit code and 3-12% when using 32-bit code.
1163 SIMD-enabled libjpeg-turbo MIPS build was executed with the `-nosmooth` option
1168 6. Performance has been improved significantly on 64-bit non-Linux and
1169 non-Windows platforms (generally 10-20% faster compression and 5-10% faster
1170 decompression.) Due to an oversight, the 64-bit version of the accelerated
1171 Huffman codec was not being compiled in when libjpeg-turbo was built on
1174 7. Fixed an extremely rare bug in the Huffman encoder that caused 64-bit
1175 builds of libjpeg-turbo to incorrectly encode a few specific test images when
1180 shared libraries. This is accomplished by adding either `-DENABLE_STATIC=0` or
1181 `-DENABLE_SHARED=0` to the CMake command line.
1186 as much of the image as possible, but those functions will now return -1 to
1191 in which the right-most MCU was 5 or 6 pixels wide.
1202 2. The non-SIMD RGB565 color conversion code did not work correctly on big
1206 instead of -1 if `componentID` was > 0 and `subsamp` was `TJSAMP_GRAY`.
1209 instead of -1 if `width` was < 1.
1224 with `cjpeg -grayscale -sample 2x2`). Subsampling technically has no meaning
1230 8. cjpeg, djpeg, and jpegtran now accept an argument of `-version`, which will
1236 extremely-high-frequency block (basically junk image data) is being encoded.
1240 setting alternating AC coefficients to 32767 and -32768 in the JPEG scanning
1243 256 bytes, which should prevent any such issue from re-occurring in the future.
1250 11. Restored the `JPP()`, `JMETHOD()`, and `FAR` macros in the libjpeg-turbo
1252 in libjpeg as a way of supporting non-ANSI compilers that lacked support for
1253 prototype parameters. libjpeg-turbo has never supported such compilers, but
1255 Similarly, libjpeg-turbo has never supported MS-DOS and other platforms that
1261 12. Fixed issues that were preventing the ARM 64-bit SIMD code from compiling
1263 the "official" libjpeg-turbo SDK for OS X.
1273 - YUV planar images can now be generated with an arbitrary line padding
1274 (previously only 4-byte padding, which was compatible with X Video, was
1276 - The decompress-to-YUV function has been extended to support image
1278 - JPEG images can now be compressed from YUV planar source images.
1279 - YUV planar images can now be decoded into RGB or grayscale images.
1280 - 4:1:1 subsampling is now supported. This is mainly included for
1281 compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no
1283 - CMYK images are now supported. This feature allows CMYK source images
1288 - The handling of YUV images in the Java API has been significantly
1290 - The Java API now supports encoding a YUV image from an arbitrary
1292 - All of the YUV functions now have a corresponding function that operates
1298 2. Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up
1299 the compression of full-color JPEGs by 70-80% on such platforms and
1300 decompression by 25-35%.
1302 3. If an application attempts to decompress a Huffman-coded JPEG image whose
1303 header does not contain Huffman tables, libjpeg-turbo will now insert the
1306 successfully decompressed by libjpeg-turbo without additional work on the part
1308 instance to re-use tables from a previous frame of the same video.
1312 OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo,
1320 loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with
1323 code (~10-20%) when enabling the feature. Actual mileage may vary.
1326 pixels to be generated when decompressing a JPEG image to a 256-color bitmap,
1327 if compiler optimization was enabled when libjpeg-turbo was built. This caused
1331 7. Improved the accuracy and performance of the non-SIMD implementation of the
1340 for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not
1341 used, then this code path is SIMD-accelerated on ARM platforms.
1343 9. Numerous obsolete features, such as support for non-ANSI compilers and
1344 support for the MS-DOS memory model, were removed from the libjpeg code,
1357 13. Restored 12-bit-per-component JPEG support. A 12-bit version of
1358 libjpeg-turbo can now be built by passing an argument of `--with-12bit` to
1359 configure (Unix) or `-DWITH_12BIT=1` to cmake (Windows.) 12-bit JPEG support
1361 performance features in libjpeg-turbo, as well as arithmetic coding and the
1362 TurboJPEG API. The resulting library still contains the other libjpeg-turbo
1366 14. Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion
1371 15. Fixed an extremely rare bug (CVE-2014-9092) that could cause the Huffman
1372 encoder's local buffer to overrun when a very high-frequency MCU is compressed
1376 injecting random high-frequency YUV data into the compressor), it was
1381 automatically-allocated destination buffer, then TurboJPEG would erroneously
1394 1. On Un*x systems, `make install` now installs the libjpeg-turbo libraries
1395 into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86,
1396 and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just
1397 x86-64. You can override this by overriding either the `prefix` or `libdir`
1401 directory as the rest of the libjpeg-turbo binaries. This was mainly done
1403 When using a 32-bit version of CMake on 64-bit Windows, it is impossible to
1405 TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL.
1408 entropy coding (by passing arguments of `-progressive -arithmetic` to cjpeg or
1412 4. Fixed a couple of issues (CVE-2013-6629 and CVE-2013-6630) whereby malformed
1413 JPEG images would cause libjpeg-turbo to use uninitialized memory during
1423 7. Fixed an issue that prevented SRPMs generated using the in-tree packaging
1441 - To avoid conflict with vendor-supplied libjpeg-turbo packages, the
1442 official RPMs and DEBs for libjpeg-turbo have been renamed to
1443 "libjpeg-turbo-official".
1444 - The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the
1445 official Linux and Mac packages, to avoid conflict with vendor-supplied
1447 - Release packages are now created with the directory structure defined
1453 - To avoid confusion, official libjpeg-turbo packages on Linux/Unix
1454 platforms (except for Mac) will always install the 32-bit libraries in
1455 /opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64.
1456 - Fixed an issue whereby, in some cases, the libjpeg-turbo executables on
1459 - Fixed an issue whereby building the "installer" target on Windows when
1461 - Building the "install" target on Windows now installs files into the
1475 not be SIMD-accelerated when using any of these new scaling factors.
1479 changes in an ABI-incompatible way, that function is renamed and a legacy
1490 5. The 32-bit supplementary package for amd64 Debian systems now provides
1491 symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32.
1492 This allows those libraries to be used on MultiArch-compatible systems (such as
1496 without having to pass `-Djava.library.path=/usr/lib` to java.
1500 `java -cp turbojpeg.jar TJBench`.
1503 (feature ported from jpeg-8d.)
1505 9. The width and height in the `-crop` argument passed to jpegtran can now be
1510 bottom right corner (feature ported from jpeg-8d.)
1513 images (feature ported from jpeg-8d.)
1519 12. The in-memory source/destination managers (`jpeg_mem_src()` and
1520 `jpeg_mem_dest()`) are now included by default when building libjpeg-turbo with
1522 functions without requiring the use of the backward-incompatible libjpeg v8
1523 ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been
1526 libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See
1530 libjpeg-turbo binary package for OS X, so that those libraries can be used to
1540 properly work when the input or output colorspace is one of the libjpeg-turbo
1543 2. When libjpeg-turbo was built without SIMD support and merged (non-fancy)
1544 upsampling was used along with an alpha-enabled colorspace during
1549 3. Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the
1553 4. Fixed a regression (CVE-2012-2806) caused by 1.2.0[6] whereby decompressing
1555 erroneously set to a large value) would cause libjpeg-turbo to segfault.
1558 processors. The `MASKMOVDQU` instruction, which was used by the libjpeg-turbo
1564 6. Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM
1565 platforms. This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such
1569 running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or
1570 4:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy
1571 upsampling would produce several incorrect columns of pixels at the right-hand
1588 1. Fixed build issue with Yasm on Unix systems (the libjpeg-turbo build system
1592 2. Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
1595 actual run-time problems, but the issue showed up when running libjpeg-turbo in
1598 3. Added a compile-time macro (`LIBJPEG_TURBO_VERSION`) that can be used to
1599 check the version of libjpeg-turbo against which an application was compiled.
1603 when decompressing to a 4-component RGB buffer, the unused byte should be set
1606 5. Fixed regression issue whereby DevIL failed to build against libjpeg-turbo
1607 because libjpeg-turbo's distributed version of jconfig.h contained an `INLINE`
1609 internally when building libjpeg-turbo, so it was moved into config.h.
1611 6. libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose
1617 the official libjpeg-turbo binary package for OS X, so that those libraries can
1632 3. Added SIMD routines for RGB-to-grayscale color conversion, which
1654 8. All legacy VirtualGL code has been re-factored, and this has allowed
1655 libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license.
1657 9. libjpeg-turbo can now be built with Yasm.
1665 version of `TJBUFSIZE()` that computes a worst-case JPEG size based on the
1675 support in libjpeg-turbo v1.1.0 introduced several new error constants in
1677 the error enum in libjpeg-turbo to sometimes have different values than the
1683 14. Fixed an issue whereby Windows applications that used libjpeg-turbo would
1687 15. Fixed 32-bit supplementary package for amd64 Debian systems, which was
1692 libjpeg-turbo will now set the unused byte to 0xFF, which allows applications
1701 1. Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated
1704 2. libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected
1711 default, which differed from the behavior of 64-bit Visual C++. MinGW64 1.0
1712 has adopted the behavior of 64-bit Visual C++ as the default, so to accommodate
1713 this, the libjpeg-turbo SIMD function names are no longer prefixed with an
1715 libjpeg-turbo with older versions of MinGW64, you will now have to add
1716 `-fno-leading-underscore` to the `CFLAGS`.
1722 `cinfo->image_width` and `cinfo->image_height` if libjpeg v7 or v8 emulation
1724 linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8
1741 used. Thus, the non-SIMD quantization function is now used for those cases,
1742 and libjpeg-turbo should now produce identical output to libjpeg v6b in all
1749 high-quality images but is necessary to ensure that the images are perceptually
1756 the RGB-to-luminance lookup tables.
1758 5. The Windows distribution packages now include the libjpeg run-time programs
1778 2. Created a new CMake-based build system for the Visual C++ and MinGW builds.
1786 5. If the default install prefix (/opt/libjpeg-turbo) is used, then
1787 `make install` now creates /opt/libjpeg-turbo/lib32 and
1788 /opt/libjpeg-turbo/lib64 sym links to duplicate the behavior of the binary
1791 6. All symbols in the libjpeg-turbo dynamic library are now versioned, even
1813 from a corrupt JPEG image.) Previously, these would cause libjpeg-turbo to
1829 `--host` when configuring on a 64-bit system)
1832 include file can always be found in /opt/libjpeg-turbo/include, the 32-bit
1833 static libraries can always be found in /opt/libjpeg-turbo/lib32, and the
1834 64-bit static libraries can always be found in /opt/libjpeg-turbo/lib64.
1836 3. The Unix/Linux distribution packages now include the libjpeg run-time
1839 4. Created a 32-bit supplementary package for amd64 Debian systems, which
1840 contains just the 32-bit libjpeg-turbo libraries.
1846 7. No longer necessary to specify `--without-simd` on non-x86 architectures,
1855 1. 2982659: Fixed x86-64 build on FreeBSD systems
1857 2. 2988188: Added support for Windows 64-bit systems
1868 and/or using buffered I/O with the libjpeg-turbo decompressor