Skip to content

3.0.4

Choose a tag to compare

@dcommander dcommander released this 14 Sep 19:46
· 133 commits to main since this release

Assets

Packaging Changes

  • A new build of libjpeg-turbo-3.0.4.dmg was uploaded on 2025-08-13 to address an issue whereby the TurboJPEG Java wrapper could not be used with the Arm64 architecture.

Support

Code Quality: Stable
Current Support Category: Maintenance

Release Notes

Significant changes relative to 3.0.3:

  1. Fixed an issue whereby the CPU usage of the default marker processor in the decompressor grew exponentially with the number of markers. This caused an unreasonable slow-down in jpeg_read_header() if an application called jpeg_save_markers() to save markers of a particular type and then attempted to decompress a JPEG image containing an excessive number of markers of that type.

  2. Hardened the default marker processor in the decompressor to guard against an issue (exposed by 3.0 beta2[6]) whereby attempting to decompress a specially-crafted malformed JPEG image (specifically an image with a complete 12-bit-per-sample Start Of Frame segment followed by an incomplete 8-bit-per-sample Start Of Frame segment) using buffered-image mode and input prefetching caused a segfault if the fill_input_buffer() method in the calling application's custom source manager incorrectly returned FALSE in response to a prematurely-terminated JPEG data stream.

  3. Fixed an issue in cjpeg whereby, when generating a 12-bit-per-sample or 16-bit-per-sample lossless JPEG image, specifying a point transform value greater than 7 resulted in an error ("Invalid progressive/lossless parameters") unless the -precision option was specified before the -lossless option.

  4. Fixed a regression introduced by 3.0.3[3] that made it impossible for calling applications to generate 12-bit-per-sample arithmetic-coded lossy JPEG images using the TurboJPEG API.

  5. Fixed an error ("Destination buffer is not large enough") that occurred when attempting to generate a full-color lossless JPEG image using the TurboJPEG Java API's byte[] TJCompressor.compress() method if the value of TJ.PARAM_SUBSAMP was not TJ.SAMP_444.

  6. Fixed a segfault in djpeg that occurred if a negative width was specified with the -crop option. Since the cropping region width was read into an unsigned 32-bit integer, a negative width was interpreted as a very large value. With certain negative width and positive left boundary values, the bounds checks in djpeg and jpeg_crop_scanline() overflowed and did not detect the out-of-bounds width, which caused a buffer overrun in the upsampling or color conversion routine. Both bounds checks now use 64-bit integers to guard against overflow, and djpeg now checks for negative numbers when it parses the crop specification from the command line.

  7. Fixed an issue whereby the TurboJPEG lossless transformation function and methods checked the specified cropping region against the source image dimensions and level of chrominance subsampling rather than the destination image dimensions and level of chrominance subsampling, which caused some cropping regions to be unduly rejected when performing 90-degree rotation, 270-degree rotation, transposition, transverse transposition, or grayscale conversion.

  8. Fixed a regression, introduced by 3.0 beta2[4], that prevented the tjTransform() backward compatibility function from copying extra markers from the source image to the destination image.

  9. Fixed an issue whereby the TurboJPEG lossless transformation function and methods did not honor TJXOPT_COPYNONE/TJTransform.OPT_COPYNONE unless it was specified for all lossless transforms.