libjpeg-turbo

Rating: 
5
Your rating: None Average: 5 (1 vote)

The libjpeg-turbo package contains a library of functions for manipulating
JPEG images. It supports architecture-specific SIMD instructions,
such as NEON.

The libjpeg-static package contains the statically linkable version of libjpeg.
Linking to static libraries is discouraged for most applications, but it is
necessary for some boot packages.

The libjpeg-turbo-tools package contains client programs for libjpeg-turbo.
You'll also need to have the libjpeg-turbo package installed.
It also includes the following command line utilities:
djpeg - decompress a JPEG file to an image file
jpegtran - lossless transformation of JPEG files
rdjpgcom - display text comments from a JPEG file
wrjpgcom - insert text comments into a JPEG file
tjbench - a JPEG decompression/compression benchmark

Provides: libjpeg-turbo-jpeg8

sha256sum filename:
455e637a083eb29b7efa49d808ada2e9e3fea0e5b8752bb138adbff9b138024d libjpeg-turbo-2.1.0-1.armv7hl.rpm
cc154687017f8856e405e0178e1ccce96ff3169b8f6d1680d24ca12bb8bdb70f libjpeg-turbo-devel-2.1.0-1.armv7hl.rpm
c183286fd05b780db252c128386639fd19be9299f44285778aaf2667d389d238 libjpeg-turbo-doc-2.1.0-1.armv7hl.rpm
f8ec78597723dd7da5011aed25a0a6cbac78e7acb657460c9a406427730bc3b7 libjpeg-turbo-jpeg8-2.1.0-1.armv7hl.rpm
c4fd9cad051eb51232c578107e6afbb2231c064bb73ff5417f718d04ebcb5771 libjpeg-turbo-static-2.1.0-1.armv7hl.rpm
590974d7a750629925e83cd5adeffa1e876592b04cb09a0f1dc19ac028de5c8d libjpeg-turbo-tools-2.1.0-1.armv7hl.rpm

Category:

Application versions: 
AttachmentSizeDate
File libjpeg-turbo-doc-2.0.4-1.armv7hl.rpm236.53 KB07/06/2020 - 19:27
File libjpeg-turbo-static-2.0.4-1.armv7hl.rpm385.4 KB07/06/2020 - 19:27
File libjpeg-turbo-devel-2.0.4-1.armv7hl.rpm43.4 KB07/06/2020 - 19:27
File libjpeg-turbo-tools-2.0.4-1.armv7hl.rpm101.24 KB07/06/2020 - 19:28
File libjpeg-turbo-2.0.4-1.armv7hl.rpm368.21 KB07/06/2020 - 19:29
File libjpeg-turbo-jpeg8-2.0.4-1.armv7hl.rpm159.31 KB07/06/2020 - 19:29
File libjpeg-turbo-doc-2.0.5-1.armv7hl.rpm236.54 KB24/06/2020 - 23:57
File libjpeg-turbo-static-2.0.5-1.armv7hl.rpm385.53 KB24/06/2020 - 23:57
File libjpeg-turbo-devel-2.0.5-1.armv7hl.rpm43.44 KB24/06/2020 - 23:58
File libjpeg-turbo-tools-2.0.5-1.armv7hl.rpm101.19 KB24/06/2020 - 23:58
File libjpeg-turbo-2.0.5-1.armv7hl.rpm368.38 KB24/06/2020 - 23:59
File libjpeg-turbo-jpeg8-2.0.5-1.armv7hl.rpm159.31 KB25/06/2020 - 00:00
File libjpeg-turbo-doc-2.0.6-1.armv7hl.rpm260.82 KB17/11/2020 - 22:32
File libjpeg-turbo-static-2.0.6-1.armv7hl.rpm385.74 KB17/11/2020 - 22:34
File libjpeg-turbo-devel-2.0.6-1.armv7hl.rpm43.45 KB17/11/2020 - 22:35
File libjpeg-turbo-tools-2.0.6-1.armv7hl.rpm101.38 KB17/11/2020 - 22:36
File libjpeg-turbo-2.0.6-1.armv7hl.rpm368.94 KB17/11/2020 - 22:36
File libjpeg-turbo-jpeg8-2.0.6-1.armv7hl.rpm159.23 KB17/11/2020 - 22:36
File libjpeg-turbo-doc-2.1.0-1.armv7hl.rpm75.73 KB24/04/2021 - 04:05
File libjpeg-turbo-static-2.1.0-1.armv7hl.rpm448.49 KB24/04/2021 - 04:08
File libjpeg-turbo-devel-2.1.0-1.armv7hl.rpm121.53 KB24/04/2021 - 04:09
File libjpeg-turbo-tools-2.1.0-1.armv7hl.rpm110.22 KB24/04/2021 - 04:09
File libjpeg-turbo-2.1.0-1.armv7hl.rpm248 KB24/04/2021 - 04:10
File libjpeg-turbo-jpeg8-2.1.0-1.armv7hl.rpm372.33 KB24/04/2021 - 04:10
Changelog: 

2.1.0
=====

### Significant changes relative to 2.1 beta1

1. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to
decompress certain progressive JPEG images with one or more component planes of
width 8 or less caused a buffer overrun.

2. Fixed a regression introduced by 2.1 beta1[6(b)] whereby attempting to
decompress a specially-crafted malformed progressive JPEG image caused the
block smoothing algorithm to read from uninitialized memory.

3. Fixed an issue in the Arm Neon SIMD Huffman encoders that caused the
encoders to generate incorrect results when using the Clang compiler with
Visual Studio.

4. Fixed a floating point exception (CVE-2021-20205) that occurred when
attempting to compress a specially-crafted malformed GIF image with a specified
image width of 0 using cjpeg.

5. Fixed a regression introduced by 2.0 beta1[15] whereby attempting to
generate a progressive JPEG image on an SSE2-capable CPU using a scan script
containing one or more scans with lengths divisible by 32 and non-zero
successive approximation low bit positions would, under certain circumstances,
result in an error ("Missing Huffman code table entry") and an invalid JPEG
image.

6. Introduced a new flag (`TJFLAG_LIMITSCANS` in the TurboJPEG C API and
`TJ.FLAG_LIMIT_SCANS` in the TurboJPEG Java API) and a corresponding TJBench
command-line argument (`-limitscans`) that causes the TurboJPEG decompression
and transform functions/operations to return/throw an error if a progressive
JPEG image contains an unreasonably large number of scans. This allows
applications that use the TurboJPEG API to guard against an exploit of the
progressive JPEG format described in the report
["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStand...).

7. The PPM reader now throws an error, rather than segfaulting (due to a buffer
overrun) or generating incorrect pixels, if an application attempts to use the
`tjLoadImage()` function to load a 16-bit binary PPM file (a binary PPM file
with a maximum value greater than 255) into a grayscale image buffer or to load
a 16-bit binary PGM file into an RGB image buffer.

8. Fixed an issue in the PPM reader that caused incorrect pixels to be
generated when using the `tjLoadImage()` function to load a 16-bit binary PPM
file into an extended RGB image buffer.

9. Fixed an issue whereby, if a JPEG buffer was automatically re-allocated by
one of the TurboJPEG compression or transform functions and an error
subsequently occurred during compression or transformation, the JPEG buffer
pointer passed by the application was not updated when the function returned.

2.0.90 (2.1 beta1)
==================

### Significant changes relative to 2.0.6:

1. The build system, x86-64 SIMD extensions, and accelerated Huffman codec now
support the x32 ABI on Linux, which allows for using x86-64 instructions with
32-bit pointers. The x32 ABI is generally enabled by adding `-mx32` to the
compiler flags.

Caveats:
- CMake 3.9.0 or later is required in order for the build system to
automatically detect an x32 build.
- Java does not support the x32 ABI, and thus the TurboJPEG Java API will
automatically be disabled with x32 builds.

2. Added Loongson MMI SIMD implementations of the RGB-to-grayscale, 4:2:2 fancy
chroma upsampling, 4:2:2 and 4:2:0 merged chroma upsampling/color conversion,
and fast integer DCT/IDCT algorithms. Relative to libjpeg-turbo 2.0.x, this
speeds up:

- the compression of RGB source images into grayscale JPEG images by
approximately 20%
- the decompression of 4:2:2 JPEG images by approximately 40-60% when
using fancy upsampling
- the decompression of 4:2:2 and 4:2:0 JPEG images by approximately
15-20% when using merged upsampling
- the compression of RGB source images by approximately 30-45% when using
the fast integer DCT
- the decompression of JPEG images into RGB destination images by
approximately 2x when using the fast integer IDCT

The overall decompression speedup for RGB images is now approximately
2.3-3.7x (compared to 2-3.5x with libjpeg-turbo 2.0.x.)

3. 32-bit (Armv7 or Armv7s) iOS builds of libjpeg-turbo are no longer
supported, and the libjpeg-turbo build system can no longer be used to package
such builds. 32-bit iOS apps cannot run in iOS 11 and later, and the App Store
no longer allows them.

4. 32-bit (i386) OS X/macOS builds of libjpeg-turbo are no longer supported,
and the libjpeg-turbo build system can no longer be used to package such
builds. 32-bit Mac applications cannot run in macOS 10.15 "Catalina" and
later, and the App Store no longer allows them.

5. The SSE2 (x86 SIMD) and C Huffman encoding algorithms have been
significantly optimized, resulting in a measured average overall compression
speedup of 12-28% for 64-bit code and 22-52% for 32-bit code on various Intel
and AMD CPUs, as well as a measured average overall compression speedup of
0-23% on platforms that do not have a SIMD-accelerated Huffman encoding
implementation.

6. The block smoothing algorithm that is applied by default when decompressing
progressive Huffman-encoded JPEG images has been improved in the following
ways:

- The algorithm is now more fault-tolerant. Previously, if a particular
scan was incomplete, then the smoothing parameters for the incomplete scan
would be applied to the entire output image, including the parts of the image
that were generated by the prior (complete) scan. Visually, this had the
effect of removing block smoothing from lower-frequency scans if they were
followed by an incomplete higher-frequency scan. libjpeg-turbo now applies
block smoothing parameters to each iMCU row based on which scan generated the
pixels in that row, rather than always using the block smoothing parameters for
the most recent scan.
- When applying block smoothing to DC scans, a Gaussian-like kernel with a
5x5 window is used to reduce the "blocky" appearance.

7. Added SIMD acceleration for progressive Huffman encoding on Arm platforms.
This speeds up the compression of full-color progressive JPEGs by about 30-40%
on average (relative to libjpeg-turbo 2.0.x) when using modern Arm CPUs.

8. Added configure-time and run-time auto-detection of Loongson MMI SIMD
instructions, so that the Loongson MMI SIMD extensions can be included in any
MIPS64 libjpeg-turbo build.

9. Added fault tolerance features to djpeg and jpegtran, mainly to demonstrate
methods by which applications can guard against the exploits of the JPEG format
described in the report
["Two Issues with the JPEG Standard"](https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStand...).

- Both programs now accept a `-maxscans` argument, which can be used to
limit the number of allowable scans in the input file.
- Both programs now accept a `-strict` argument, which can be used to
treat all warnings as fatal.

10. CMake package config files are now included for both the libjpeg and
TurboJPEG API libraries. This facilitates using libjpeg-turbo with CMake's
`find_package()` function. For example:

find_package(libjpeg-turbo CONFIG REQUIRED)

add_executable(libjpeg_program libjpeg_program.c)
target_link_libraries(libjpeg_program PUBLIC libjpeg-turbo::jpeg)

add_executable(libjpeg_program_static libjpeg_program.c)
target_link_libraries(libjpeg_program_static PUBLIC
libjpeg-turbo::jpeg-static)

add_executable(turbojpeg_program turbojpeg_program.c)
target_link_libraries(turbojpeg_program PUBLIC
libjpeg-turbo::turbojpeg)

add_executable(turbojpeg_program_static turbojpeg_program.c)
target_link_libraries(turbojpeg_program_static PUBLIC
libjpeg-turbo::turbojpeg-static)

11. Since the Unisys LZW patent has long expired, cjpeg and djpeg can now
read/write both LZW-compressed and uncompressed GIF files (feature ported from
jpeg-6a and jpeg-9d.)

12. jpegtran now includes the `-wipe` and `-drop` options from jpeg-9a and
jpeg-9d, as well as the ability to expand the image size using the `-crop`
option. Refer to jpegtran.1 or usage.txt for more details.

13. Added a complete intrinsics implementation of the Arm Neon SIMD extensions,
thus providing SIMD acceleration on Arm platforms for all of the algorithms
that are SIMD-accelerated on x86 platforms. This new implementation is
significantly faster in some cases than the old GAS implementation--
depending on the algorithms used, the type of CPU core, and the compiler. GCC,
as of this writing, does not provide a full or optimal set of Neon intrinsics,
so for performance reasons, the default when building libjpeg-turbo with GCC is
to continue using the GAS implementation of the following algorithms:

- 32-bit RGB-to-YCbCr color conversion
- 32-bit fast and accurate inverse DCT
- 64-bit RGB-to-YCbCr and YCbCr-to-RGB color conversion
- 64-bit accurate forward and inverse DCT
- 64-bit Huffman encoding

A new CMake variable (`NEON_INTRINSICS`) can be used to override this
default.

Since the new intrinsics implementation includes SIMD acceleration
for merged upsampling/color conversion, 1.5.1[5] is no longer necessary and has
been reverted.

14. The Arm Neon SIMD extensions can now be built using Visual Studio.

15. The build system can now be used to generate a universal x86-64 + Armv8
libjpeg-turbo SDK package for both iOS and macOS.