Opened 7 years ago

Closed 7 years ago

#9460 closed enhancement (fixed)

libjpeg-turbo-1.5.2

Reported by: bdubbs@… Owned by: bdubbs@…
Priority: normal Milestone: 8.1
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

New point version.

Change History (3)

comment:1 by bdubbs@…, 7 years ago

Owner: changed from blfs-book@… to bdubbs@…
Status: newassigned

comment:2 by bdubbs@…, 7 years ago

1.5.2 =====

### Significant changes relative to 1.5.1:

  1. Fixed a regression introduced by 1.5.1[7] that prevented libjpeg-turbo from building with Android NDK platforms prior to android-21 (5.0).
  1. Fixed a regression introduced by 1.5.1[1] that prevented the MIPS DSPR2 SIMD code in libjpeg-turbo from building.
  1. Fixed a regression introduced by 1.5 beta1[11] that prevented the Java version of TJBench from outputting any reference images (the -nowrite switch was accidentally enabled by default.)
  1. libjpeg-turbo should now build and run with full AltiVec SIMD acceleration on PowerPC-based AmigaOS 4 and OpenBSD systems.
  1. Fixed build and runtime errors on Windows that occurred when building libjpeg-turbo with libjpeg v7 API/ABI emulation and the in-memory source/destination managers. Due to an oversight, the jpeg_skip_scanlines() and jpeg_crop_scanlines() functions were not being included in jpeg7.dll when libjpeg-turbo was built with -DWITH_JPEG7=1 and -DWITH_MEMSRCDST=1.
  1. Fixed "Bogus virtual array access" error that occurred when using the lossless crop feature in jpegtran or the TurboJPEG API, if libjpeg-turbo was built with libjpeg v7 API/ABI emulation. This was apparently a long-standing bug that has existed since the introduction of libjpeg v7/v8 API/ABI emulation in libjpeg-turbo v1.1.
  1. The lossless transform features in jpegtran and the TurboJPEG API will now always attempt to adjust the EXIF image width and height tags if the image size changed as a result of the transform. This behavior has always existed when using libjpeg v8 API/ABI emulation. It was supposed to be available with libjpeg v7 API/ABI emulation as well but did not work properly due to a bug. Furthermore, there was never any good reason not to enable it with libjpeg v6b API/ABI emulation, since the behavior is entirely internal. Note that -copy all must be passed to jpegtran in order to transfer the EXIF tags from the source image to the destination image.
  1. Fixed several memory leaks in the TurboJPEG API library that could occur if the library was built with certain compilers and optimization levels (known to occur with GCC 4.x and clang with -O1 and higher but not with GCC 5.x or 6.x) and one of the underlying libjpeg API functions threw an error after a TurboJPEG API function allocated a local buffer.
  1. The libjpeg-turbo memory manager will now honor the max_memory_to_use structure member in jpeg\_memory\_mgr, which can be set to the maximum amount of memory (in bytes) that libjpeg-turbo should use during decompression or multi-pass (including progressive) compression. This limit can also be set using the JPEGMEM environment variable or using the -maxmemory switch in cjpeg/djpeg/jpegtran (refer to the respective man pages for more details.) This has been a documented feature of libjpeg since v5, but the malloc()/free() implementation of the memory manager (jmemnobs.c) never implemented the feature. Restricting libjpeg-turbo's memory usage is useful for two reasons: it allows testers to more easily work around the 2 GB limit in libFuzzer, and it allows developers of security-sensitive applications to more easily defend against one of the progressive JPEG exploits (LJT-01-004) identified in [this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About /TwoIssueswiththeJPEGStandard.pdf).
  1. TJBench will now run each benchmark for 1 second prior to starting the timer, in order to improve the consistency of the results. Furthermore, the -warmup option is now used to specify the amount of warmup time rather than the number of warmup iterations.
  1. Fixed an error (short jump is out of range) that occurred when assembling the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a regression introduced by 1.5 beta1[12].

comment:3 by bdubbs@…, 7 years ago

Resolution: fixed
Status: assignedclosed

Fixed at revision 18929.

Note: See TracTickets for help on using tickets.