Lines Matching +full:1 +full:- +full:installer +full:- +full:linux +full:- +full:x86_64
4 ### Significant changes relative to 2.0.1:
6 1. Fixed a regression introduced by 2.0.1[5] that prevented a runtime search
7 path (rpath) from being embedded in the libjpeg-turbo shared libraries and
11 libjpeg-turbo shared libraries.
13 2. Fixed an integer overflow and subsequent segfault (CVE-2018-20330) that
14 occurred when attempting to load a BMP file with more than 1 billion pixels
17 3. Fixed a buffer overrun (CVE-2018-19664) that occurred when attempting to
18 decompress a specially-crafted malformed JPEG image to a 256-color BMP using
22 decompress a specially-crafted malformed JPEG image with a specified image
25 5. The TurboJPEG API will now decompress 4:4:4 JPEG images with 2x1, 1x2, 3x1,
26 or 1x3 luminance and chrominance sampling factors. This is a non-standard way
27 of specifying 1x subsampling (normally 4:4:4 JPEGs have 1x1 luminance and
32 incorrect PPM images when used with the `-colors` option.
34 7. Fixed an issue whereby a static build of libjpeg-turbo (a build in which
38 occurred when compressing RGB images whose image rows were not 64-bit-aligned.
41 2.0.1
46 1. Fixed a regression introduced with the new CMake-based Un*x build system,
48 `"HAVE_*_H" redefined` if it was included by downstream Autotools-based
58 the AVX2 SIMD extensions (2.0 beta1[1]), that caused libjpeg-turbo to crash on
59 Windows 7 if Service Pack 1 was not installed.
61 4. Fixed out-of-bounds read in cjpeg that occurred when attempting to compress
62 a specially-crafted malformed color-index (8-bit-per-sample) Targa file in
66 5. Fixed an issue whereby installing a fully static build of libjpeg-turbo
67 (a build in which `CFLAGS` contains `-static` and `ENABLE_SHARED` is `0`) would
76 1. The TurboJPEG API can now decompress CMYK JPEG images that have subsampled M
84 2. Fixed an issue (CVE-2018-11813) whereby a specially-crafted malformed input
94 the underlying library, and because it did not involve any out-of-bounds reads
103 4. Fixed an issue whereby a specially-crafted malformed BMP file, one in which
106 when attempting to load the BMP file into a 4-component image buffer.
114 a 4:2:2 or 4:2:0 JPEG image using the merged (non-fancy) upsampling algorithms
117 7. The new CMake-based build system will now disable the MIPS DSPr2 SIMD
120 8. Fixed out-of-bounds read in cjpeg that occurred when attempting to compress
121 a specially-crafted malformed color-index (8-bit-per-sample) BMP file in which
127 attempting to decompress a specially-crafted malformed JPEG image. This issue
137 1. Added AVX2 SIMD implementations of the colorspace conversion, chroma
140 algorithms on AVX2-equipped CPUs, the compression of RGB images is
141 approximately 13-36% (avg. 22%) faster (relative to libjpeg-turbo 1.5.x) with
142 64-bit code and 11-21% (avg. 17%) faster with 32-bit code, and the
143 decompression of RGB images is approximately 9-35% (avg. 17%) faster with
144 64-bit code and 7-17% (avg. 12%) faster with 32-bit code. (As tested on a
148 autotools-based build system. This decision resulted from extensive
149 discussions within the libjpeg-turbo community. libjpeg-turbo traditionally
156 of our build system, owing to CMake's built-in support for various assemblers,
166 libjpeg-turbo to be configured without the use of a terminal/command prompt.
168 autotools-based build system are provided by the new build system.
170 3. The libjpeg API in this version of libjpeg-turbo now includes two additional
179 - Introduced a new function (`tjGetErrorStr2()`) in the TurboJPEG C API
181 in a thread-safe manner. Retrieving error messages from global functions, such
182 as `tjInitCompress()` or `tjBufSize()`, is still thread-unsafe, but since those
185 - Introduced a new function (`tjGetErrorCode()`) in the TurboJPEG C API
189 choose whether to ignore warnings (non-fatal errors) from the underlying
191 - Introduced a new flag (`TJFLAG_STOPONWARNING` in the TurboJPEG C API and
203 enabled for selected transforms in a multi-transform operation.
213 replace the project-private (and slow) bmp API, which was previously used by
214 TJBench, and they also provide a convenient way for first-time users of
215 libjpeg-turbo to quickly develop a complete JPEG compression/decompression
219 that contains the alpha component index for each pixel format (or -1 if the
222 the `tjRedOffset[]`, `tjGreenOffset[]`, and `tjBlueOffset[]` arrays-- and the
224 `TJ.getBlueOffset()` methods-- now return -1 for `TJPF_GRAY`/`TJ.PF_GRAY`
230 Both files are now included in the libjpeg-turbo documentation.
234 to decompress a specially-crafted malformed JPEG image. These issues did not
240 now produces bitwise-identical results to the unmerged algorithms.
242 12. The SIMD function symbols for x86[-64]/ELF, MIPS/ELF, macOS/x86[-64] (if
243 libjpeg-turbo is built with YASM), and iOS/ARM[64] builds are now private.
245 libraries that link statically with libjpeg-turbo.
247 13. Added Loongson MMI SIMD implementations of the RGB-to-YCbCr and
248 YCbCr-to-RGB colorspace conversion, 4:2:0 chroma downsampling, 4:2:0 fancy
251 images by approximately 70-100% and the decompression of RGB images by
252 approximately 2-3.5x.
255 caused by 1.5.1[7].)
257 15. Added SIMD acceleration for progressive Huffman encoding on SSE2-capable
258 x86 and x86-64 platforms. This speeds up the compression of full-color
259 progressive JPEGs by about 85-90% on average (relative to libjpeg-turbo 1.5.x)
268 1. Fixed a NullPointerException in the TurboJPEG Java wrapper that occurred
276 PPM/PGM was selected along with the `-crop` option. The `-crop` option now
279 write scanlines in bottom-up order.) djpeg will now exit gracefully if an
281 `-crop` option.
287 command-line argument is unrecognized. This prevents the program from silently
295 with 4:1:1 chrominance subsampling.
298 end of a single-scan (non-progressive) image, subsequent calls to
303 JPEG images that were compressed with a sampling factor other than 1 (for
304 instance, with `cjpeg -grayscale -sample 2x2`).
310 ### Significant changes relative to 1.5.1:
312 1. Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from
313 building with Android NDK platforms prior to android-21 (5.0).
315 2. Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD
316 code in libjpeg-turbo from building.
319 version of TJBench from outputting any reference images (the `-nowrite` switch
322 4. libjpeg-turbo should now build and run with full AltiVec SIMD acceleration
323 on PowerPC-based AmigaOS 4 and OpenBSD systems.
326 libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory
329 libjpeg-turbo was built with `-DWITH_JPEG7=1` and `-DWITH_MEMSRCDST=1`.
332 lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was
333 built with libjpeg v7 API/ABI emulation. This was apparently a long-standing
335 in libjpeg-turbo v1.1.
344 `-copy all` must be passed to jpegtran in order to transfer the EXIF tags from
349 (known to occur with GCC 4.x and clang with `-O1` and higher but not with
353 9. The libjpeg-turbo memory manager will now honor the `max_memory_to_use`
355 of memory (in bytes) that libjpeg-turbo should use during decompression or
356 multi-pass (including progressive) compression. This limit can also be set
357 using the `JPEGMEM` environment variable or using the `-maxmemory` switch in
361 implemented the feature. Restricting libjpeg-turbo's memory usage is useful
363 in libFuzzer, and it allows developers of security-sensitive applications to
364 more easily defend against one of the progressive JPEG exploits (LJT-01-004)
366 [this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf).
368 10. TJBench will now run each benchmark for 1 second prior to starting the
370 `-warmup` option is now used to specify the amount of warmup time rather than
374 the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a
378 1.5.1
383 1. Previously, the undocumented `JSIMD_FORCE*` environment variables could be
384 used to force-enable a particular SIMD instruction set if multiple instruction
389 since the ARM implementations of libjpeg-turbo can only use one SIMD
397 ARM and MIPS builds of libjpeg-turbo in QEMU, which passes through
400 2. libjpeg-turbo previously assumed that AltiVec instructions were always
403 and newer e5500 series.) libjpeg-turbo now examines /proc/cpuinfo on
404 Linux/Android systems and enables AltiVec instructions only if the CPU supports
406 `JSIMD_FORCENONE`, to force-enable and force-disable AltiVec instructions in
408 detection (such as when running in QEMU.) On OS X, libjpeg-turbo continues to
409 assume that AltiVec support is always available, which means that libjpeg-turbo
411 `JSIMD_FORCENONE` to `1`.
413 3. Fixed an issue whereby 64-bit ARM (AArch64) builds of libjpeg-turbo would
415 caused by an ABI conformance issue in some of libjpeg-turbo's 64-bit NEON SIMD
416 routines. Those routines were incorrectly using 64-bit instructions to
417 transfer a 32-bit JDIMENSION argument, whereas the ABI allows the upper
418 (unused) 32 bits of a 32-bit argument's register to be undefined. The new
419 Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit
420 structure members into a single 64-bit register, and this exposed the ABI
426 The h1v2 fancy upsampling algorithm is not currently SIMD-accelerated.
428 5. If merged upsampling isn't SIMD-accelerated but YCbCr-to-RGB conversion is,
429 then libjpeg-turbo will now disable merged upsampling when decompressing YCbCr
432 upsampling is not used (for example, if the `-nosmooth` option to djpeg is
436 2x2 luminance sampling factors and 2x1 or 1x2 chrominance sampling factors.
437 This is a non-standard way of specifying 2x subsampling (normally 4:2:2 JPEGs
438 have 2x1 luminance and 1x1 chrominance sampling factors, and 4:4:0 JPEGs have
439 1x2 luminance and 1x1 chrominance sampling factors), but the JPEG format and
444 attempting to decompress a specially-crafted malformed JPEG image. This issue
445 affected only 32-bit code and did not pose a security threat, but removing the
451 specially-crafted malformed JPEG images. None of these issues posed a security
455 9. Fixed an out-of-bounds array reference, introduced by 1.4.90[2] (partial
457 that could be triggered by a specially-crafted malformed JPEG image with more
458 than four components. Because the out-of-bounds reference was still within the
463 10. Fixed another ABI conformance issue in the 64-bit ARM (AArch64) NEON SIMD
474 1. Fixed an issue whereby a malformed motion-JPEG frame could cause the "fast
475 path" of libjpeg-turbo's Huffman decoder to read from uninitialized memory.
477 2. Added libjpeg-turbo version and build information to the global string table
485 maximum value defined in the file's header. libjpeg-turbo 1.4.2 already
488 affect any of the libjpeg-turbo libraries.
498 5. Fixed an issue in the ARM 32-bit SIMD-accelerated Huffman encoder that
515 1. Added full SIMD acceleration for PowerPC platforms using AltiVec VMX
516 (128-bit SIMD) instructions. Although the performance of libjpeg-turbo on
519 3-4x and decompression by about 2-2.5x (relative to libjpeg v6b) through the
528 try-with-resources statement.
537 pointers. This facilitates passing read-only buffers to those functions and
539 not create any backward API or ABI incompatibilities with prior libjpeg-turbo
542 6. The MIPS DSPr2 SIMD code can now be compiled to support either FR=0 or FR=1
547 32-bit code, and none of them was known to pose a security threat, but removing
555 9. Fixed a regression caused by 1.4.1[6] that prevented 32-bit and 64-bit
556 libjpeg-turbo RPMs from being installed simultaneously on recent Red Hat/Fedora
559 that macro differs between 32-bit and 64-bit builds, this caused a conflict
560 between the i386 and x86_64 RPMs (any differing files, other than executables,
561 are not allowed when 32-bit and 64-bit RPMs are installed simultaneously.)
564 10. The x86-64 SIMD code can now be disabled at run time by setting the
565 `JSIMD_FORCENONE` environment variable to `1` (the other SIMD implementations
568 11. Added a new command-line argument to TJBench (`-nowrite`) that prevents the
573 12. Added SIMD acceleration for Huffman encoding on SSE2-capable x86 and x86-64
574 platforms. This speeds up the compression of full-color JPEGs by about 10-15%
575 on average (relative to libjpeg-turbo 1.4.x) when using modern Intel and AMD
580 benchmarking or regression testing, SIMD-accelerated Huffman encoding can be
581 disabled by setting the `JSIMD_NOHUFFENC` environment variable to `1`.
583 13. Added ARM 64-bit (ARMv8) NEON SIMD implementations of the commonly-used
585 downsampling algorithms, which are not accelerated in the 32-bit NEON
586 implementation.) This speeds up the compression of full-color JPEGs by about
587 75% on average on a Cavium ThunderX processor and by about 2-2.5x on average on
588 Cortex-A53 and Cortex-A57 cores.
590 14. Added SIMD acceleration for Huffman encoding on NEON-capable ARM 32-bit
591 and 64-bit platforms.
593 For 32-bit code, this speeds up the compression of full-color JPEGs by
594 about 30% on average on a typical iOS device (iPhone 4S, Cortex-A9) and by
595 about 6-7% on average on a typical Android device (Nexus 5X, Cortex-A53 and
596 Cortex-A57), relative to libjpeg-turbo 1.4.x. Note that the larger speedup
600 For 64-bit code, NEON-accelerated Huffman encoding speeds up the
601 compression of full-color JPEGs by about 40% on average on a typical iOS device
602 (iPhone 5S, Apple A7) and by about 7-8% on average on a typical Android device
603 (Nexus 5X, Cortex-A53 and Cortex-A57), in addition to the speedup described in
606 For the purposes of benchmarking or regression testing, SIMD-accelerated
608 variable to `1`.
610 15. pkg-config (.pc) scripts are now included for both the libjpeg and
613 with libjpeg or with a prior version of libjpeg-turbo.
615 16. Optimized the ARM 64-bit (ARMv8) NEON SIMD decompression routines to
616 improve performance on CPUs with in-order pipelines. This speeds up the
617 decompression of full-color JPEGs by nearly 2x on average on a Cavium ThunderX
618 processor and by about 15% on average on a Cortex-A53 core.
622 specially-crafted JPEG image was being decompressed. In prior versions of
623 libjpeg-turbo, the accelerated Huffman decoder was invoked (in most cases) only
626 long, so this version of libjpeg-turbo activates the accelerated Huffman
630 with the `-yuv` option.
636 ### Significant changes relative to 1.4.1:
638 1. Fixed an issue whereby cjpeg would segfault if a Windows bitmap with a
640 a negative height if they are stored in top-down order, but such files are
641 rare and not supported by libjpeg-turbo.)
643 2. Fixed an issue whereby, under certain circumstances, libjpeg-turbo would
646 library was built with `-march=haswell` on x86 systems.
648 3. Fixed an issue whereby libjpeg-turbo would crash when built with the latest
650 an x86-64 ABI conformance issue in some of libjpeg-turbo's 64-bit SSE2 SIMD
651 routines. Those routines were incorrectly using a 64-bit `mov` instruction to
652 transfer a 32-bit JDIMENSION argument, whereas the x86-64 ABI allows the upper
653 (unused) 32 bits of a 32-bit argument's register to be undefined. The new
654 Clang/LLVM optimizer uses load combining to transfer multiple adjacent 32-bit
655 structure members into a single 64-bit register, and this exposed the ABI
658 4. Fixed a bug in the MIPS DSPr2 4:2:0 "plain" (non-fancy and non-merged)
662 decompressing a non-YCbCr JPEG image, but they are also used when decompressing
663 a JPEG image whose scaled output height is 1.
671 1.4.1
676 1. tjbench now properly handles CMYK/YCCK JPEG files. Passing an argument of
677 `-cmyk` (instead of, for instance, `-rgb`) will cause tjbench to internally
681 passed to tjbench as a source image.) The CMYK<->RGB conversion operation is
682 not benchmarked. NOTE: The quick & dirty CMYK<->RGB conversions that tjbench
694 re-enable the tests and to specify an expected result for them based on the
698 which speeds up the compression of RGB and CMYK JPEGs by 5-20% when using
699 64-bit code and 0-3% when using 32-bit code, and the decompression of those
700 images by 10-30% when using 64-bit code and 3-12% when using 32-bit code.
703 SIMD-enabled libjpeg-turbo MIPS build was executed with the `-nosmooth` option
708 6. Performance has been improved significantly on 64-bit non-Linux and
709 non-Windows platforms (generally 10-20% faster compression and 5-10% faster
710 decompression.) Due to an oversight, the 64-bit version of the accelerated
711 Huffman codec was not being compiled in when libjpeg-turbo was built on
712 platforms other than Windows or Linux. Oops.
714 7. Fixed an extremely rare bug in the Huffman encoder that caused 64-bit
715 builds of libjpeg-turbo to incorrectly encode a few specific test images when
720 shared libraries. This is accomplished by adding either `-DENABLE_STATIC=0` or
721 `-DENABLE_SHARED=0` to the CMake command line.
726 as much of the image as possible, but those functions will now return -1 to
731 in which the right-most MCU was 5 or 6 pixels wide.
739 1. Fixed a build issue on OS X PowerPC platforms (md5cmp failed to build
742 2. The non-SIMD RGB565 color conversion code did not work correctly on big
745 3. Fixed an issue in `tjPlaneSizeYUV()` whereby it would erroneously return 1
746 instead of -1 if `componentID` was > 0 and `subsamp` was `TJSAMP_GRAY`.
749 instead of -1 if `width` was < 1.
763 images that were compressed with a sampling factor other than 1 (for instance,
764 with `cjpeg -grayscale -sample 2x2`). Subsampling technically has no meaning
767 was being too rigid and was expecting the sampling factors to be equal to 1
770 8. cjpeg, djpeg, and jpegtran now accept an argument of `-version`, which will
776 extremely-high-frequency block (basically junk image data) is being encoded.
780 setting alternating AC coefficients to 32767 and -32768 in the JPEG scanning
783 256 bytes, which should prevent any such issue from re-occurring in the future.
790 11. Restored the `JPP()`, `JMETHOD()`, and `FAR` macros in the libjpeg-turbo
792 in libjpeg as a way of supporting non-ANSI compilers that lacked support for
793 prototype parameters. libjpeg-turbo has never supported such compilers, but
795 Similarly, libjpeg-turbo has never supported MS-DOS and other platforms that
801 12. Fixed issues that were preventing the ARM 64-bit SIMD code from compiling
803 the "official" libjpeg-turbo SDK for OS X.
809 ### Significant changes relative to 1.3.1:
811 1. New features in the TurboJPEG API:
813 - YUV planar images can now be generated with an arbitrary line padding
814 (previously only 4-byte padding, which was compatible with X Video, was
816 - The decompress-to-YUV function has been extended to support image
818 - JPEG images can now be compressed from YUV planar source images.
819 - YUV planar images can now be decoded into RGB or grayscale images.
820 - 4:1:1 subsampling is now supported. This is mainly included for
821 compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no
823 - CMYK images are now supported. This feature allows CMYK source images
828 - The handling of YUV images in the Java API has been significantly
830 - The Java API now supports encoding a YUV image from an arbitrary
832 - All of the YUV functions now have a corresponding function that operates
838 2. Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up
839 the compression of full-color JPEGs by 70-80% on such platforms and
840 decompression by 25-35%.
842 3. If an application attempts to decompress a Huffman-coded JPEG image whose
843 header does not contain Huffman tables, libjpeg-turbo will now insert the
846 successfully decompressed by libjpeg-turbo without additional work on the part
848 instance to re-use tables from a previous frame of the same video.
852 OS X 10.6 "Snow Leopard" or later must be used when packaging libjpeg-turbo,
860 loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with
863 code (~10-20%) when enabling the feature. Actual mileage may vary.
866 pixels to be generated when decompressing a JPEG image to a 256-color bitmap,
867 if compiler optimization was enabled when libjpeg-turbo was built. This caused
871 7. Improved the accuracy and performance of the non-SIMD implementation of the
880 for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not
881 used, then this code path is SIMD-accelerated on ARM platforms.
883 9. Numerous obsolete features, such as support for non-ANSI compilers and
884 support for the MS-DOS memory model, were removed from the libjpeg code,
897 13. Restored 12-bit-per-component JPEG support. A 12-bit version of
898 libjpeg-turbo can now be built by passing an argument of `--with-12bit` to
899 configure (Unix) or `-DWITH_12BIT=1` to cmake (Windows.) 12-bit JPEG support
901 performance features in libjpeg-turbo, as well as arithmetic coding and the
902 TurboJPEG API. The resulting library still contains the other libjpeg-turbo
906 14. Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion
912 buffer to overrun when a very high-frequency MCU is compressed using quality
916 high-frequency YUV data into the compressor), it was reproducible only once in
921 automatically-allocated destination buffer, then TurboJPEG would erroneously
929 1.3.1
934 1. On Un*x systems, `make install` now installs the libjpeg-turbo libraries
935 into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, not just x86,
936 and into /opt/libjpeg-turbo/lib64 by default on any 64-bit system, not just
937 x86-64. You can override this by overriding either the `prefix` or `libdir`
940 2. The Windows installer now places a copy of the TurboJPEG DLLs in the same
941 directory as the rest of the libjpeg-turbo binaries. This was mainly done
943 When using a 32-bit version of CMake on 64-bit Windows, it is impossible to
945 TurboVNC build scripts to bundle the 64-bit TurboJPEG DLL.
948 entropy coding (by passing arguments of `-progressive -arithmetic` to cjpeg or
953 libjpeg-turbo to use uninitialized memory during decompression.
962 7. Fixed an issue that prevented SRPMs generated using the in-tree packaging
963 tools from being rebuilt on certain newer Linux distributions.
975 1. `make test` now works properly on FreeBSD, and it no longer requires the
980 - To avoid conflict with vendor-supplied libjpeg-turbo packages, the
981 official RPMs and DEBs for libjpeg-turbo have been renamed to
982 "libjpeg-turbo-official".
983 - The TurboJPEG libraries are now located under /opt/libjpeg-turbo in the
984 official Linux and Mac packages, to avoid conflict with vendor-supplied
986 - Release packages are now created with the directory structure defined
992 - To avoid confusion, official libjpeg-turbo packages on Linux/Unix
993 platforms (except for Mac) will always install the 32-bit libraries in
994 /opt/libjpeg-turbo/lib32 and the 64-bit libraries in /opt/libjpeg-turbo/lib64.
995 - Fixed an issue whereby, in some cases, the libjpeg-turbo executables on
998 - Fixed an issue whereby building the "installer" target on Windows when
999 `WITH_JAVA=1` would fail if the TurboJPEG JAR had not been previously built.
1000 - Building the "install" target on Windows now installs files into the
1001 same places that the installer does.
1010 ### Significant changes relative to 1.2.1:
1012 1. Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4,
1014 not be SIMD-accelerated when using any of these new scaling factors.
1018 changes in an ABI-incompatible way, that function is renamed and a legacy
1020 Linux distro maintainers have a policy against accepting any library that isn't
1029 5. The 32-bit supplementary package for amd64 Debian systems now provides
1030 symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries in /usr/lib32.
1031 This allows those libraries to be used on MultiArch-compatible systems (such as
1035 without having to pass `-Djava.library.path=/usr/lib` to java.
1039 `java -cp turbojpeg.jar TJBench`.
1042 (feature ported from jpeg-8d.)
1044 9. The width and height in the `-crop` argument passed to jpegtran can now be
1049 bottom right corner (feature ported from jpeg-8d.)
1052 images (feature ported from jpeg-8d.)
1054 11. Fixed a regression caused by 1.2.1[7] whereby the build would fail with
1058 12. The in-memory source/destination managers (`jpeg_mem_src()` and
1059 `jpeg_mem_dest()`) are now included by default when building libjpeg-turbo with
1061 functions without requiring the use of the backward-incompatible libjpeg v8
1062 ABI. The "age number" of the libjpeg-turbo library on Un*x systems has been
1063 incremented by 1 to reflect this. You can disable this feature with a
1065 libjpeg v6b or v7 API/ABI (or with previous versions of libjpeg-turbo.) See
1069 libjpeg-turbo binary package for OS X, so that those libraries can be used to
1073 1.2.1
1078 1. Creating or decoding a JPEG file that uses the RGB colorspace should now
1079 properly work when the input or output colorspace is one of the libjpeg-turbo
1082 2. When libjpeg-turbo was built without SIMD support and merged (non-fancy)
1083 upsampling was used along with an alpha-enabled colorspace during
1088 3. Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not preserve the
1094 to a large value) would cause libjpeg-turbo to segfault.
1097 processors. The `MASKMOVDQU` instruction, which was used by the libjpeg-turbo
1103 6. Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM
1104 platforms. This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such
1107 7. Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86 platforms
1108 running the 32-bit SSE2 SIMD code in libjpeg-turbo, decompressing a 4:2:0 or
1109 4:2:2 JPEG image into a 32-bit (RGBX, BGRX, etc.) buffer without using fancy
1110 upsampling would produce several incorrect columns of pixels at the right-hand
1127 1. Fixed build issue with YASM on Unix systems (the libjpeg-turbo build system
1131 2. Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
1134 actual run-time problems, but the issue showed up when running libjpeg-turbo in
1137 3. Added a compile-time macro (`LIBJPEG_TURBO_VERSION`) that can be used to
1138 check the version of libjpeg-turbo against which an application was compiled.
1142 when decompressing to a 4-component RGB buffer, the unused byte should be set
1145 5. Fixed regression issue whereby DevIL failed to build against libjpeg-turbo
1146 because libjpeg-turbo's distributed version of jconfig.h contained an `INLINE`
1148 internally when building libjpeg-turbo, so it was moved into config.h.
1150 6. libjpeg-turbo will now correctly decompress erroneous CMYK/YCCK JPEGs whose
1151 K component is assigned a component ID of 1 instead of 4. Although these files
1156 the official libjpeg-turbo binary package for OS X, so that those libraries can
1163 ### Significant changes relative to 1.1.1:
1165 1. Added a Java wrapper for the TurboJPEG API. See [java/README](java/README)
1171 3. Added SIMD routines for RGB-to-grayscale color conversion, which
1193 8. All legacy VirtualGL code has been re-factored, and this has allowed
1194 libjpeg-turbo, in its entirety, to be re-licensed under a BSD-style license.
1196 9. libjpeg-turbo can now be built with YASM.
1198 10. Added SIMD acceleration for ARM Linux and iOS platforms that support
1204 version of `TJBUFSIZE()` that computes a worst-case JPEG size based on the
1214 support in libjpeg-turbo v1.1.0 introduced several new error constants in
1216 the error enum in libjpeg-turbo to sometimes have different values than the
1222 14. Fixed an issue whereby Windows applications that used libjpeg-turbo would
1226 15. Fixed 32-bit supplementary package for amd64 Debian systems, which was
1231 libjpeg-turbo will now set the unused byte to 0xFF, which allows applications
1235 1.1.1
1240 1. Fixed a 1-pixel error in row 0, column 21 of the luminance plane generated
1243 2. libjpeg-turbo's accelerated Huffman decoder previously ignored unexpected
1250 default, which differed from the behavior of 64-bit Visual C++. MinGW64 1.0
1251 has adopted the behavior of 64-bit Visual C++ as the default, so to accommodate
1252 this, the libjpeg-turbo SIMD function names are no longer prefixed with an
1254 libjpeg-turbo with older versions of MinGW64, you will now have to add
1255 `-fno-leading-underscore` to the `CFLAGS`.
1257 4. Fixed a regression bug in the NSIS script that caused the Windows installer
1261 `cinfo->image_width` and `cinfo->image_height` if libjpeg v7 or v8 emulation
1263 linked against a version of libjpeg-turbo that was built with libjpeg v7 or v8
1278 1. The algorithm used by the SIMD quantization function cannot produce correct
1280 used. Thus, the non-SIMD quantization function is now used for those cases,
1281 and libjpeg-turbo should now produce identical output to libjpeg v6b in all
1288 high-quality images but is necessary to ensure that the images are perceptually
1290 created by [1].
1295 the RGB-to-luminance lookup tables.
1297 5. The Windows distribution packages now include the libjpeg run-time programs
1311 ### Significant changes relative to 1.0.1:
1313 1. Added emulation of the libjpeg v7 and v8 APIs and ABIs. See
1317 2. Created a new CMake-based build system for the Visual C++ and MinGW builds.
1325 5. If the default install prefix (/opt/libjpeg-turbo) is used, then
1326 `make install` now creates /opt/libjpeg-turbo/lib32 and
1327 /opt/libjpeg-turbo/lib64 sym links to duplicate the behavior of the binary
1330 6. All symbols in the libjpeg-turbo dynamic library are now versioned, even
1346 1.0.1
1351 1. The Huffman decoder will now handle erroneous Huffman codes (for instance,
1352 from a corrupt JPEG image.) Previously, these would cause libjpeg-turbo to
1367 1. 2983700: Further FreeBSD build tweaks (no longer necessary to specify
1368 `--host` when configuring on a 64-bit system)
1370 2. Created symlinks in the Unix/Linux packages so that the TurboJPEG
1371 include file can always be found in /opt/libjpeg-turbo/include, the 32-bit
1372 static libraries can always be found in /opt/libjpeg-turbo/lib32, and the
1373 64-bit static libraries can always be found in /opt/libjpeg-turbo/lib64.
1375 3. The Unix/Linux distribution packages now include the libjpeg run-time
1378 4. Created a 32-bit supplementary package for amd64 Debian systems, which
1379 contains just the 32-bit libjpeg-turbo libraries.
1385 7. No longer necessary to specify `--without-simd` on non-x86 architectures,
1394 1. 2982659: Fixed x86-64 build on FreeBSD systems
1396 2. 2988188: Added support for Windows 64-bit systems
1404 1. Added documentation to .deb packages
1407 and/or using buffered I/O with the libjpeg-turbo decompressor