• Home
  • Raw
  • Download

Lines Matching +full:test +full:- +full:core +full:- +full:simd

7 non-GCC-compatible compilers for Un*x/Arm platforms.
9 2. Fixed a regression introduced by 2.1 beta1[13] that prevented the Arm 32-bit
10 (AArch32) Neon SIMD extensions from building unless the C compiler flags
11 included `-mfloat-abi=softfp` or `-mfloat-abi=hard`.
13 3. Fixed an issue in the AArch32 Neon SIMD Huffman encoder whereby reliance on
15 Android systems when running AArch32/Thumb builds of libjpeg-turbo built with
29 decompress a specially-crafted malformed progressive JPEG image caused the
32 3. Fixed an issue in the Arm Neon SIMD Huffman encoders that caused the
36 4. Fixed a floating point exception (CVE-2021-20205) that occurred when
37 attempting to compress a specially-crafted malformed GIF image with a specified
41 generate a progressive JPEG image on an SSE2-capable CPU using a scan script
42 containing one or more scans with lengths divisible by 32 and non-zero
49 command-line argument (`-limitscans`) that causes the TurboJPEG decompression
54 ["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswitht…
58 `tjLoadImage()` function to load a 16-bit binary PPM file (a binary PPM file
60 a 16-bit binary PGM file into an RGB image buffer.
63 generated when using the `tjLoadImage()` function to load a 16-bit binary PPM
66 9. Fixed an issue whereby, if a JPEG buffer was automatically re-allocated by
77 1. The build system, x86-64 SIMD extensions, and accelerated Huffman codec now
78 support the x32 ABI on Linux, which allows for using x86-64 instructions with
79 32-bit pointers. The x32 ABI is generally enabled by adding `-mx32` to the
83 - CMake 3.9.0 or later is required in order for the build system to
85 - Java does not support the x32 ABI, and thus the TurboJPEG Java API will
88 2. Added Loongson MMI SIMD implementations of the RGB-to-grayscale, 4:2:2 fancy
90 and fast integer DCT/IDCT algorithms. Relative to libjpeg-turbo 2.0.x, this
93 - the compression of RGB source images into grayscale JPEG images by
95 - the decompression of 4:2:2 JPEG images by approximately 40-60% when
97 - the decompression of 4:2:2 and 4:2:0 JPEG images by approximately
98 15-20% when using merged upsampling
99 - the compression of RGB source images by approximately 30-45% when using
101 - the decompression of JPEG images into RGB destination images by
105 2.3-3.7x (compared to 2-3.5x with libjpeg-turbo 2.0.x.)
107 3. 32-bit (Armv7 or Armv7s) iOS builds of libjpeg-turbo are no longer
108 supported, and the libjpeg-turbo build system can no longer be used to package
109 such builds. 32-bit iOS apps cannot run in iOS 11 and later, and the App Store
112 4. 32-bit (i386) OS X/macOS builds of libjpeg-turbo are no longer supported,
113 and the libjpeg-turbo build system can no longer be used to package such
114 builds. 32-bit Mac applications cannot run in macOS 10.15 "Catalina" and
117 5. The SSE2 (x86 SIMD) and C Huffman encoding algorithms have been
119 speedup of 12-28% for 64-bit code and 22-52% for 32-bit code on various Intel
121 0-23% on platforms that do not have a SIMD-accelerated Huffman encoding
125 progressive Huffman-encoded JPEG images has been improved in the following
128 - The algorithm is now more fault-tolerant. Previously, if a particular
132 effect of removing block smoothing from lower-frequency scans if they were
133 followed by an incomplete higher-frequency scan. libjpeg-turbo now applies
137 - When applying block smoothing to DC scans, a Gaussian-like kernel with a
140 7. Added SIMD acceleration for progressive Huffman encoding on Arm platforms.
141 This speeds up the compression of full-color progressive JPEGs by about 30-40%
142 on average (relative to libjpeg-turbo 2.0.x) when using modern Arm CPUs.
144 8. Added configure-time and run-time auto-detection of Loongson MMI SIMD
145 instructions, so that the Loongson MMI SIMD extensions can be included in any
146 MIPS64 libjpeg-turbo build.
151 ["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswitht…
153 - Both programs now accept a `-maxscans` argument, which can be used to
155 - Both programs now accept a `-strict` argument, which can be used to
159 TurboJPEG API libraries. This facilitates using libjpeg-turbo with CMake's
162 find_package(libjpeg-turbo CONFIG REQUIRED)
165 target_link_libraries(libjpeg_program PUBLIC libjpeg-turbo::jpeg)
169 libjpeg-turbo::jpeg-static)
173 libjpeg-turbo::turbojpeg)
177 libjpeg-turbo::turbojpeg-static)
180 read/write both LZW-compressed and uncompressed GIF files (feature ported from
181 jpeg-6a and jpeg-9d.)
183 12. jpegtran now includes the `-wipe` and `-drop` options from jpeg-9a and
184 jpeg-9d, as well as the ability to expand the image size using the `-crop`
187 13. Added a complete intrinsics implementation of the Arm Neon SIMD extensions,
188 thus providing SIMD acceleration on Arm platforms for all of the algorithms
189 that are SIMD-accelerated on x86 platforms. This new implementation is
190 significantly faster in some cases than the old GAS implementation--
191 depending on the algorithms used, the type of CPU core, and the compiler. GCC,
193 so for performance reasons, the default when building libjpeg-turbo with GCC is
196 - 32-bit RGB-to-YCbCr color conversion
197 - 32-bit fast and accurate inverse DCT
198 - 64-bit RGB-to-YCbCr and YCbCr-to-RGB color conversion
199 - 64-bit accurate forward and inverse DCT
200 - 64-bit Huffman encoding
205 Since the new intrinsics implementation includes SIMD acceleration
209 14. The Arm Neon SIMD extensions can now be built using Visual Studio.
211 15. The build system can now be used to generate a universal x86-64 + Armv8
212 libjpeg-turbo SDK package for both iOS and macOS.
226 - Fixed segfaults or "Corrupt JPEG data: premature end of data segment"
228 4:2:0 JPEG images using merged (non-fancy) upsampling/color conversion (that
231 - `jpeg_skip_scanlines()` now throws an error if two-pass color
232 quantization is enabled. Two-pass color quantization never worked properly
234 - Fixed an issue whereby `jpeg_skip_scanlines()` always returned 0 when
237 3. The Arm 64-bit (Armv8) Neon SIMD extensions can now be built using MinGW
244 5. Fixed an issue whereby libjpeg-turbo would not build if 12-bit-per-component
254 1. Worked around issues in the MIPS DSPr2 SIMD extensions that caused failures
255 in the libjpeg-turbo regression tests. Specifically, the
257 in the MIPS DSPr2 SIMD extensions are now disabled until/unless they can be
259 disabled when building libjpeg-turbo for such CPUs.
266 3. Fixed an issue (CVE-2020-13790) in the PPM reader that caused a buffer
269 header and that maximum value was less than 255. libjpeg-turbo 1.5.0 already
275 instance handle, is now thread-safe on platforms that support thread-local
285 2.0 beta1[2]) whereby, if both the 64-bit libjpeg-turbo SDK for GCC and the
286 64-bit libjpeg-turbo SDK for Visual C++ were installed on the same system, only
291 64-bit C version of TJBench.
293 3. Fixed out-of-bounds write in `tjDecompressToYUV2()` and
297 `cjpeg -grayscale -sample 2x2`).
305 5. Fixed an issue (CVE-2020-17541), detected by ASan, whereby attempting to
306 losslessly transform a specially-crafted malformed JPEG image containing an
307 extremely-high-frequency coefficient block (junk image data that could never be
311 segfault or other user-visible errant behavior, and given that the lossless
315 6. The Arm 64-bit (Armv8) Neon SIMD assembly code now stores constants in a
316 separate read-only data section rather than in the text section, to support
317 execute-only memory layouts.
329 2. Fixed a regression in the SIMD feature detection code, introduced by
330 the AVX2 SIMD extensions (2.0 beta1[1]), that was known to cause an illegal
348 generate a progressive JPEG image on an SSE2-capable CPU using a scan script
364 path (rpath) from being embedded in the libjpeg-turbo shared libraries and
368 libjpeg-turbo shared libraries.
370 2. Fixed an integer overflow and subsequent segfault (CVE-2018-20330) that
374 3. Fixed a buffer overrun (CVE-2018-19664) that occurred when attempting to
375 decompress a specially-crafted malformed JPEG image to a 256-color BMP using
379 decompress a specially-crafted malformed JPEG image with a specified image
383 or 1x3 luminance and chrominance sampling factors. This is a non-standard way
389 incorrect PPM images when used with the `-colors` option.
391 7. Fixed an issue whereby a static build of libjpeg-turbo (a build in which
394 8. Fixed a severe performance issue in the Loongson MMI SIMD extensions that
395 occurred when compressing RGB images whose image rows were not 64-bit-aligned.
403 1. Fixed a regression introduced with the new CMake-based Un*x build system,
405 `"HAVE_*_H" redefined` if it was included by downstream Autotools-based
410 functions in the MIPS DSPr2 SIMD extensions are now disabled at compile time
414 3. Fixed a regression in the SIMD feature detection code, introduced by
415 the AVX2 SIMD extensions (2.0 beta1[1]), that caused libjpeg-turbo to crash on
418 4. Fixed out-of-bounds read in cjpeg that occurred when attempting to compress
419 a specially-crafted malformed color-index (8-bit-per-sample) Targa file in
423 5. Fixed an issue whereby installing a fully static build of libjpeg-turbo
424 (a build in which `CFLAGS` contains `-static` and `ENABLE_SHARED` is `0`) would
441 2. Fixed an issue (CVE-2018-11813) whereby a specially-crafted malformed input
451 the underlying library, and because it did not involve any out-of-bounds reads
460 4. Fixed an issue (CVE-2018-1152) whereby a specially-crafted malformed BMP
464 4-component image buffer.
472 a 4:2:2 or 4:2:0 JPEG image using the merged (non-fancy) upsampling algorithms
475 7. The new CMake-based build system will now disable the MIPS DSPr2 SIMD
478 8. Fixed out-of-bounds read in cjpeg (CVE-2018-14498) that occurred when
479 attempting to compress a specially-crafted malformed color-index
480 (8-bit-per-sample) BMP file in which some of the samples (color indices)
485 attempting to decompress a specially-crafted malformed JPEG image. This issue
495 1. Added AVX2 SIMD implementations of the colorspace conversion, chroma
498 algorithms on AVX2-equipped CPUs, the compression of RGB images is
499 approximately 13-36% (avg. 22%) faster (relative to libjpeg-turbo 1.5.x) with
500 64-bit code and 11-21% (avg. 17%) faster with 32-bit code, and the
501 decompression of RGB images is approximately 9-35% (avg. 17%) faster with
502 64-bit code and 7-17% (avg. 12%) faster with 32-bit code. (As tested on a
503 3 GHz Intel Core i7. Actual mileage may vary.)
506 autotools-based build system. This decision resulted from extensive
507 discussions within the libjpeg-turbo community. libjpeg-turbo traditionally
514 of our build system, owing to CMake's built-in support for various assemblers,
524 libjpeg-turbo to be configured without the use of a terminal/command prompt.
526 autotools-based build system are provided by the new build system.
528 3. The libjpeg API in this version of libjpeg-turbo now includes two additional
537 - Introduced a new function (`tjGetErrorStr2()`) in the TurboJPEG C API
539 in a thread-safe manner. Retrieving error messages from global functions, such
540 as `tjInitCompress()` or `tjBufSize()`, is still thread-unsafe, but since those
543 - Introduced a new function (`tjGetErrorCode()`) in the TurboJPEG C API
547 choose whether to ignore warnings (non-fatal errors) from the underlying
549 - Introduced a new flag (`TJFLAG_STOPONWARNING` in the TurboJPEG C API and
561 enabled for selected transforms in a multi-transform operation.
571 replace the project-private (and slow) bmp API, which was previously used by
572 TJBench, and they also provide a convenient way for first-time users of
573 libjpeg-turbo to quickly develop a complete JPEG compression/decompression
577 that contains the alpha component index for each pixel format (or -1 if the
580 the `tjRedOffset[]`, `tjGreenOffset[]`, and `tjBlueOffset[]` arrays-- and the
582 `TJ.getBlueOffset()` methods-- now return -1 for `TJPF_GRAY`/`TJ.PF_GRAY`
588 Both files are now included in the libjpeg-turbo documentation.
592 to decompress a specially-crafted malformed JPEG image. These issues did not
598 now produces bitwise-identical results to the unmerged algorithms.
600 12. The SIMD function symbols for x86[-64]/ELF, MIPS/ELF, macOS/x86[-64] (if
601 libjpeg-turbo is built with YASM), and iOS/Arm[64] builds are now private.
603 libraries that link statically with libjpeg-turbo.
605 13. Added Loongson MMI SIMD implementations of the RGB-to-YCbCr and
606 YCbCr-to-RGB colorspace conversion, 4:2:0 chroma downsampling, 4:2:0 fancy
609 compression of RGB images by approximately 70-100% and the decompression of RGB
610 images by approximately 2-3.5x.
615 15. Added SIMD acceleration for progressive Huffman encoding on SSE2-capable
616 x86 and x86-64 platforms. This speeds up the compression of full-color
617 progressive JPEGs by about 85-90% on average (relative to libjpeg-turbo 1.5.x)
634 PPM/PGM was selected along with the `-crop` option. The `-crop` option now
637 write scanlines in bottom-up order.) djpeg will now exit gracefully if an
639 `-crop` option.
641 4. Fixed an issue (CVE-2017-15232) whereby `jpeg_skip_scanlines()` would
645 command-line argument is unrecognized. This prevents the program from silently
656 end of a single-scan (non-progressive) image, subsequent calls to
662 with `cjpeg -grayscale -sample 2x2`).
670 1. Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from
671 building with Android NDK platforms prior to android-21 (5.0).
673 2. Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD
674 code in libjpeg-turbo from building.
677 version of TJBench from outputting any reference images (the `-nowrite` switch
680 4. libjpeg-turbo should now build and run with full AltiVec SIMD acceleration
681 on PowerPC-based AmigaOS 4 and OpenBSD systems.
684 libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory
687 libjpeg-turbo was built with `-DWITH_JPEG7=1` and `-DWITH_MEMSRCDST=1`.
690 lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was
691 built with libjpeg v7 API/ABI emulation. This was apparently a long-standing
693 in libjpeg-turbo v1.1.
702 `-copy all` must be passed to jpegtran in order to transfer the EXIF tags from
707 (known to occur with GCC 4.x and clang with `-O1` and higher but not with
711 9. The libjpeg-turbo memory manager will now honor the `max_memory_to_use`
713 of memory (in bytes) that libjpeg-turbo should use during decompression or
714 multi-pass (including progressive) compression. This limit can also be set
715 using the `JPEGMEM` environment variable or using the `-maxmemory` switch in
719 implemented the feature. Restricting libjpeg-turbo's memory usage is useful
721 in libFuzzer, and it allows developers of security-sensitive applications to
722 more easily defend against one of the progressive JPEG exploits (LJT-01-004)
724 [this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf).
728 `-warmup` option is now used to specify the amount of warmup time rather than
732 the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a
742 used to force-enable a particular SIMD instruction set if multiple instruction
744 feature detection is bulletproof and multiple SIMD instruction sets are
747 since the ARM implementations of libjpeg-turbo can only use one SIMD
754 These environment variables provide a workaround for those attempting to test
755 ARM and MIPS builds of libjpeg-turbo in QEMU, which passes through
758 2. libjpeg-turbo previously assumed that AltiVec instructions were always
761 and newer e5500 series.) libjpeg-turbo now examines /proc/cpuinfo on
764 `JSIMD_FORCENONE`, to force-enable and force-disable AltiVec instructions in
766 detection (such as when running in QEMU.) On OS X, libjpeg-turbo continues to
767 assume that AltiVec support is always available, which means that libjpeg-turbo
771 3. Fixed an issue whereby 64-bit ARM (AArch64) builds of libjpeg-turbo would
773 caused by an ABI conformance issue in some of libjpeg-turbo's 64-bit NEON SIMD
774 routines. Those routines were incorrectly using 64-bit instructions to
775 transfer a 32-bit JDIMENSION argument, whereas the ABI allows the upper
776 (unused) 32 bits of a 32-bit argument's register to be undefined. The new
777 Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit
778 structure members into a single 64-bit register, and this exposed the ABI
784 The h1v2 fancy upsampling algorithm is not currently SIMD-accelerated.
786 5. If merged upsampling isn't SIMD-accelerated but YCbCr-to-RGB conversion is,
787 then libjpeg-turbo will now disable merged upsampling when decompressing YCbCr
790 upsampling is not used (for example, if the `-nosmooth` option to djpeg is
795 This is a non-standard way of specifying 2x subsampling (normally 4:2:2 JPEGs
802 attempting to decompress a specially-crafted malformed JPEG image. This issue
803 affected only 32-bit code and did not pose a security threat, but removing the
809 specially-crafted malformed JPEG images. None of these issues posed a security
813 9. Fixed an out-of-bounds array reference, introduced by 1.4.90[2] (partial
815 that could be triggered by a specially-crafted malformed JPEG image with more
816 than four components. Because the out-of-bounds reference was still within the
821 10. Fixed another ABI conformance issue in the 64-bit ARM (AArch64) NEON SIMD
832 1. Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast
833 path" of libjpeg-turbo's Huffman decoder to read from uninitialized memory.
835 2. Added libjpeg-turbo version and build information to the global string table
844 than 255. libjpeg-turbo 1.4.2 already included a similar fix for ASCII PPM/PGM
846 to the cjpeg program and did not affect any of the libjpeg-turbo libraries.
856 5. Fixed an issue in the ARM 32-bit SIMD-accelerated Huffman encoder that
873 1. Added full SIMD acceleration for PowerPC platforms using AltiVec VMX
874 (128-bit SIMD) instructions. Although the performance of libjpeg-turbo on
877 3-4x and decompression by about 2-2.5x (relative to libjpeg v6b) through the
886 try-with-resources statement.
895 pointers. This facilitates passing read-only buffers to those functions and
897 not create any backward API or ABI incompatibilities with prior libjpeg-turbo
900 6. The MIPS DSPr2 SIMD code can now be compiled to support either FR=0 or FR=1
905 32-bit code, and none of them was known to pose a security threat, but removing
909 8. Removed the unnecessary `.arch` directive from the ARM64 NEON SIMD code.
913 9. Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit
914 libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora
917 that macro differs between 32-bit and 64-bit builds, this caused a conflict
919 are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.)
922 10. The x86-64 SIMD code can now be disabled at run time by setting the
923 `JSIMD_FORCENONE` environment variable to `1` (the other SIMD implementations
926 11. Added a new command-line argument to TJBench (`-nowrite`) that prevents the
931 12. Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and x86-64
932 platforms. This speeds up the compression of full-color JPEGs by about 10-15%
933 on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and AMD
938 benchmarking or regression testing, SIMD-accelerated Huffman encoding can be
941 13. Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used
943 h2v1 downsampling algorithms, which are not accelerated in the 32-bit NEON
944 implementation.) This speeds up the compression of full-color JPEGs by about
945 75% on average on a Cavium ThunderX processor and by about 2-2.5x on average on
946 Cortex-A53 and Cortex-A57 cores.
948 14. Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit
949 and 64-bit platforms.
951 For 32-bit code, this speeds up the compression of full-color JPEGs by
952 about 30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by
953 about 6-7% on average on a typical Android device (Nexus 5X, Cortex-A53 and
954 Cortex-A57), relative to libjpeg-turbo 1.4.x. Note that the larger speedup
958 For 64-bit code, NEON-accelerated Huffman encoding speeds up the
959 compression of full-color JPEGs by about 40% on average on a typical iOS device
960 (iPhone 5S, Apple A7) and by about 7-8% on average on a typical Android device
961 (Nexus 5X, Cortex-A53 and Cortex-A57), in addition to the speedup described in
964 For the purposes of benchmarking or regression testing, SIMD-accelerated
968 15. pkg-config (.pc) scripts are now included for both the libjpeg and
971 with libjpeg or with a prior version of libjpeg-turbo.
973 16. Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to
974 improve performance on CPUs with in-order pipelines. This speeds up the
975 decompression of full-color JPEGs by nearly 2x on average on a Cavium ThunderX
976 processor and by about 15% on average on a Cortex-A53 core.
980 specially-crafted JPEG image was being decompressed. In prior versions of
981 libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only
984 long, so this version of libjpeg-turbo activates the accelerated Huffman
988 with the `-yuv` option.
998 a negative height if they are stored in top-down order, but such files are
999 rare and not supported by libjpeg-turbo.)
1001 2. Fixed an issue whereby, under certain circumstances, libjpeg-turbo would
1003 forward DCT were used. This was known to cause `make test` to fail when the
1004 library was built with `-march=haswell` on x86 systems.
1006 3. Fixed an issue whereby libjpeg-turbo would crash when built with the latest
1008 an x86-64 ABI conformance issue in some of libjpeg-turbo's 64-bit SSE2 SIMD
1009 routines. Those routines were incorrectly using a 64-bit `mov` instruction to
1010 transfer a 32-bit JDIMENSION argument, whereas the x86-64 ABI allows the upper
1011 (unused) 32 bits of a 32-bit argument's register to be undefined. The new
1012 Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit
1013 structure members into a single 64-bit register, and this exposed the ABI
1016 4. Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged)
1020 decompressing a non-YCbCr JPEG image, but they are also used when decompressing
1035 `-cmyk` (instead of, for instance, `-rgb`) will cause tjbench to internally
1039 passed to tjbench as a source image.) The CMYK<->RGB conversion operation is
1040 not benchmarked. NOTE: The quick & dirty CMYK<->RGB conversions that tjbench
1044 2. `make test` now performs additional bitwise regression tests using tjbench,
1048 3. `make test` no longer tests the regression of the floating point DCT/IDCT
1050 question are not implemented using SIMD instructions on a particular platform.
1052 re-enable the tests and to specify an expected result for them based on the
1056 which speeds up the compression of RGB and CMYK JPEGs by 5-20% when using
1057 64-bit code and 0-3% when using 32-bit code, and the decompression of those
1058 images by 10-30% when using 64-bit code and 3-12% when using 32-bit code.
1061 SIMD-enabled libjpeg-turbo MIPS build was executed with the `-nosmooth` option
1062 on a MIPS machine that lacked DSPr2 support. The MIPS SIMD routines for h2v1
1066 6. Performance has been improved significantly on 64-bit non-Linux and
1067 non-Windows platforms (generally 10-20% faster compression and 5-10% faster
1068 decompression.) Due to an oversight, the 64-bit version of the accelerated
1069 Huffman codec was not being compiled in when libjpeg-turbo was built on
1072 7. Fixed an extremely rare bug in the Huffman encoder that caused 64-bit
1073 builds of libjpeg-turbo to incorrectly encode a few specific test images when
1078 shared libraries. This is accomplished by adding either `-DENABLE_STATIC=0` or
1079 `-DENABLE_SHARED=0` to the CMake command line.
1084 as much of the image as possible, but those functions will now return -1 to
1089 in which the right-most MCU was 5 or 6 pixels wide.
1100 2. The non-SIMD RGB565 color conversion code did not work correctly on big
1104 instead of -1 if `componentID` was > 0 and `subsamp` was `TJSAMP_GRAY`.
1107 instead of -1 if `width` was < 1.
1122 with `cjpeg -grayscale -sample 2x2`). Subsampling technically has no meaning
1128 8. cjpeg, djpeg, and jpegtran now accept an argument of `-version`, which will
1134 extremely-high-frequency block (basically junk image data) is being encoded.
1138 setting alternating AC coefficients to 32767 and -32768 in the JPEG scanning
1141 256 bytes, which should prevent any such issue from re-occurring in the future.
1148 11. Restored the `JPP()`, `JMETHOD()`, and `FAR` macros in the libjpeg-turbo
1150 in libjpeg as a way of supporting non-ANSI compilers that lacked support for
1151 prototype parameters. libjpeg-turbo has never supported such compilers, but
1153 Similarly, libjpeg-turbo has never supported MS-DOS and other platforms that
1159 12. Fixed issues that were preventing the ARM 64-bit SIMD code from compiling
1161 the "official" libjpeg-turbo SDK for OS X.
1171 - YUV planar images can now be generated with an arbitrary line padding
1172 (previously only 4-byte padding, which was compatible with X Video, was
1174 - The decompress-to-YUV function has been extended to support image
1176 - JPEG images can now be compressed from YUV planar source images.
1177 - YUV planar images can now be decoded into RGB or grayscale images.
1178 - 4:1:1 subsampling is now supported. This is mainly included for
1179 compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no
1181 - CMYK images are now supported. This feature allows CMYK source images
1186 - The handling of YUV images in the Java API has been significantly
1188 - The Java API now supports encoding a YUV image from an arbitrary
1190 - All of the YUV functions now have a corresponding function that operates
1196 2. Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up
1197 the compression of full-color JPEGs by 70-80% on such platforms and
1198 decompression by 25-35%.
1200 3. If an application attempts to decompress a Huffman-coded JPEG image whose
1201 header does not contain Huffman tables, libjpeg-turbo will now insert the
1204 successfully decompressed by libjpeg-turbo without additional work on the part
1206 instance to re-use tables from a previous frame of the same video.
1210 OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo,
1218 loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with
1221 code (~10-20%) when enabling the feature. Actual mileage may vary.
1224 pixels to be generated when decompressing a JPEG image to a 256-color bitmap,
1225 if compiler optimization was enabled when libjpeg-turbo was built. This caused
1229 7. Improved the accuracy and performance of the non-SIMD implementation of the
1238 for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not
1239 used, then this code path is SIMD-accelerated on ARM platforms.
1241 9. Numerous obsolete features, such as support for non-ANSI compilers and
1242 support for the MS-DOS memory model, were removed from the libjpeg code,
1255 13. Restored 12-bit-per-component JPEG support. A 12-bit version of
1256 libjpeg-turbo can now be built by passing an argument of `--with-12bit` to
1257 configure (Unix) or `-DWITH_12BIT=1` to cmake (Windows.) 12-bit JPEG support
1259 performance features in libjpeg-turbo, as well as arithmetic coding and the
1260 TurboJPEG API. The resulting library still contains the other libjpeg-turbo
1264 14. Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion
1269 15. Fixed an extremely rare bug (CVE-2014-9092) that could cause the Huffman
1270 encoder's local buffer to overrun when a very high-frequency MCU is compressed
1273 even with a test program specifically designed to make the bug occur (by
1274 injecting random high-frequency YUV data into the compressor), it was
1279 automatically-allocated destination buffer, then TurboJPEG would erroneously
1292 1. On Un*x systems, `make install` now installs the libjpeg-turbo libraries
1293 into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86,
1294 and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just
1295 x86-64. You can override this by overriding either the `prefix` or `libdir`
1299 directory as the rest of the libjpeg-turbo binaries. This was mainly done
1301 When using a 32-bit version of CMake on 64-bit Windows, it is impossible to
1303 TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL.
1306 entropy coding (by passing arguments of `-progressive -arithmetic` to cjpeg or
1310 4. Fixed a couple of issues (CVE-2013-6629 and CVE-2013-6630) whereby malformed
1311 JPEG images would cause libjpeg-turbo to use uninitialized memory during
1316 source image, and added a unit test to check for this error.
1321 7. Fixed an issue that prevented SRPMs generated using the in-tree packaging
1334 1. `make test` now works properly on FreeBSD, and it no longer requires the
1339 - To avoid conflict with vendor-supplied libjpeg-turbo packages, the
1340 official RPMs and DEBs for libjpeg-turbo have been renamed to
1341 "libjpeg-turbo-official".
1342 - The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the
1343 official Linux and Mac packages, to avoid conflict with vendor-supplied
1345 - Release packages are now created with the directory structure defined
1351 - To avoid confusion, official libjpeg-turbo packages on Linux/Unix
1352 platforms (except for Mac) will always install the 32-bit libraries in
1353 /opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64.
1354 - Fixed an issue whereby, in some cases, the libjpeg-turbo executables on
1357 - Fixed an issue whereby building the "installer" target on Windows when
1359 - Building the "install" target on Windows now installs files into the
1373 not be SIMD-accelerated when using any of these new scaling factors.
1377 changes in an ABI-incompatible way, that function is renamed and a legacy
1388 5. The 32-bit supplementary package for amd64 Debian systems now provides
1389 symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32.
1390 This allows those libraries to be used on MultiArch-compatible systems (such as
1394 without having to pass `-Djava.library.path=/usr/lib` to java.
1398 `java -cp turbojpeg.jar TJBench`.
1401 (feature ported from jpeg-8d.)
1403 9. The width and height in the `-crop` argument passed to jpegtran can now be
1408 bottom right corner (feature ported from jpeg-8d.)
1411 images (feature ported from jpeg-8d.)
1415 SIMD code with NASM 0.98.
1417 12. The in-memory source/destination managers (`jpeg_mem_src()` and
1418 `jpeg_mem_dest()`) are now included by default when building libjpeg-turbo with
1420 functions without requiring the use of the backward-incompatible libjpeg v8
1421 ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been
1424 libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See
1428 libjpeg-turbo binary package for OS X, so that those libraries can be used to
1438 properly work when the input or output colorspace is one of the libjpeg-turbo
1441 2. When libjpeg-turbo was built without SIMD support and merged (non-fancy)
1442 upsampling was used along with an alpha-enabled colorspace during
1444 0xFF. This has been fixed. TJUnitTest has also been extended to test for the
1447 3. Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the
1451 4. Fixed a regression (CVE-2012-2806) caused by 1.2.0[6] whereby decompressing
1453 erroneously set to a large value) would cause libjpeg-turbo to segfault.
1456 processors. The `MASKMOVDQU` instruction, which was used by the libjpeg-turbo
1457 SSE2 SIMD code, is apparently implemented in microcode on AMD processors, and
1462 6. Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM
1463 platforms. This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such
1467 running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or
1468 4:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy
1469 upsampling would produce several incorrect columns of pixels at the right-hand
1473 8. Fixed an issue whereby attempting to build the SIMD extensions with Xcode
1486 1. Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system
1490 2. Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
1493 actual run-time problems, but the issue showed up when running libjpeg-turbo in
1496 3. Added a compile-time macro (`LIBJPEG_TURBO_VERSION`) that can be used to
1497 check the version of libjpeg-turbo against which an application was compiled.
1501 when decompressing to a 4-component RGB buffer, the unused byte should be set
1504 5. Fixed regression issue whereby DevIL failed to build against libjpeg-turbo
1505 because libjpeg-turbo's distributed version of jconfig.h contained an `INLINE`
1507 internally when building libjpeg-turbo, so it was moved into config.h.
1509 6. libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose
1515 the official libjpeg-turbo binary package for OS X, so that those libraries can
1530 3. Added SIMD routines for RGB-to-grayscale color conversion, which
1535 on platforms for which SIMD acceleration is not available.
1552 8. All legacy VirtualGL code has been re-factored, and this has allowed
1553 libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license.
1555 9. libjpeg-turbo can now be built with YASM.
1557 10. Added SIMD acceleration for ARM Linux and iOS platforms that support
1563 version of `TJBUFSIZE()` that computes a worst-case JPEG size based on the
1573 support in libjpeg-turbo v1.1.0 introduced several new error constants in
1575 the error enum in libjpeg-turbo to sometimes have different values than the
1581 14. Fixed an issue whereby Windows applications that used libjpeg-turbo would
1585 15. Fixed 32-bit supplementary package for amd64 Debian systems, which was
1590 libjpeg-turbo will now set the unused byte to 0xFF, which allows applications
1599 1. Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated
1602 2. libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected
1609 default, which differed from the behavior of 64-bit Visual C++. MinGW64 1.0
1610 has adopted the behavior of 64-bit Visual C++ as the default, so to accommodate
1611 this, the libjpeg-turbo SIMD function names are no longer prefixed with an
1613 libjpeg-turbo with older versions of MinGW64, you will now have to add
1614 `-fno-leading-underscore` to the `CFLAGS`.
1620 `cinfo->image_width` and `cinfo->image_height` if libjpeg v7 or v8 emulation
1622 linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8
1637 1. The algorithm used by the SIMD quantization function cannot produce correct
1639 used. Thus, the non-SIMD quantization function is now used for those cases,
1640 and libjpeg-turbo should now produce identical output to libjpeg v6b in all
1647 high-quality images but is necessary to ensure that the images are perceptually
1654 the RGB-to-luminance lookup tables.
1656 5. The Windows distribution packages now include the libjpeg run-time programs
1676 2. Created a new CMake-based build system for the Visual C++ and MinGW builds.
1681 4. jpgtest can now be used to test decompression performance with existing
1684 5. If the default install prefix (/opt/libjpeg-turbo) is used, then
1685 `make install` now creates /opt/libjpeg-turbo/lib32 and
1686 /opt/libjpeg-turbo/lib64 sym links to duplicate the behavior of the binary
1689 6. All symbols in the libjpeg-turbo dynamic library are now versioned, even
1711 from a corrupt JPEG image.) Previously, these would cause libjpeg-turbo to
1714 2. Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to
1727 `--host` when configuring on a 64-bit system)
1730 include file can always be found in /opt/libjpeg-turbo/include, the 32-bit
1731 static libraries can always be found in /opt/libjpeg-turbo/lib32, and the
1732 64-bit static libraries can always be found in /opt/libjpeg-turbo/lib64.
1734 3. The Unix/Linux distribution packages now include the libjpeg run-time
1737 4. Created a 32-bit supplementary package for amd64 Debian systems, which
1738 contains just the 32-bit libjpeg-turbo libraries.
1744 7. No longer necessary to specify `--without-simd` on non-x86 architectures,
1753 1. 2982659: Fixed x86-64 build on FreeBSD systems
1755 2. 2988188: Added support for Windows 64-bit systems
1766 and/or using buffered I/O with the libjpeg-turbo decompressor