Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Releases: libjpeg-turbo/libjpeg-turbo

3.1.90 (3.2 beta1)

27 Mar 21:58
@dcommander dcommander
3.1.90
e1dbfa7

Choose a tag to compare

View all tags
3.1.90 (3.2 beta1) Pre-release
Pre-release

Assets

Support

Code Quality: Beta
Current Support Category: Active

Release Notes

Significant changes relative to 3.1.4.1:

  1. The legacy GNU Assembler (GAS) implementation of the Arm Neon SIMD extensions has been removed. Arm builds of libjpeg-turbo must now use GCC 12 or later or Clang in order to achieve full performance.

  2. The SIMD dispatchers have been overhauled so that the list of supported SIMD instruction sets is initialized on a per-instance basis rather than a per-thread basis, thus eliminating the need for thread-local storage in the libjpeg API library. The overhaul also streamlines and modernizes the dispatcher architecture, eliminates redundant and unnecessary code, and generally simplifies the process of adding new SIMD extensions. A new test program (simdcoverage) can be used to validate the correctness of a particular dispatcher.

  3. If the WITH_PROFILE CMake variable is enabled, libjpeg-turbo now measures the cumulative average throughput of each lossy JPEG compression and decompression algorithm and reports it to the command line when jpeg_destroy_compress(), jpeg_destroy_decompress(), or tj3Destroy() is called.

  4. jpegtran now honors the -trim and -perfect options when expanding the image size using the -crop option. If -trim is specified, then partial iMCUs from the source image are discarded in the expanded image (equivalent to the previous behavior.) If -trim is not specified, then partial iMCUs are left in place. If -perfect is specified, then expanding the image size using the -crop option will fail if there are any partial iMCUs in the source image. The new default behavior is useful, in combination with the -drop option, for reversibly combining multiple JPEG source images into a single composite JPEG image.

  5. The MIPS DSPr2 SIMD extensions have been removed. Justifications:

    • MIPS Technologies deprecated the MIPS architecture in favor of RISC-V in 2021.
    • The DSPr2 instruction set was already obsolete at that point, having been superseded by the MSA instruction set (which is now also deprecated.)
    • The overall speedup from the DSPr2 SIMD extensions was never compelling, in part because some of the modules were implemented using scalar (non-SIMD) instructions and were thus no faster than the equivalent C modules.
    • Some of the DSPr2 SIMD modules had long-standing bugs, and it was necessary to disable those modules in order to prevent accuracy issues with libjpeg-turbo on MIPS CPUs.
    • The DSPr2 SIMD extensions only worked with 32-bit MIPS applications.
    • The libjpeg-turbo Project has never had access to a MIPS test platform, which limited our ability to maintain the DSPr2 SIMD extensions.

    Even before the MIPS architecture was deprecated, the aforementioned limitations had already reduced the number of platforms and applications that could benefit from the DSPr2 SIMD extensions to near zero. The DSPr2 SIMD extensions will continue to be maintained in the 3.1.x branch on a break/fix basis.

  6. Added RISC-V Vector (RVV) SIMD implementations of the colorspace conversion, chroma downsampling and upsampling, integer quantization and sample conversion, and integer DCT/IDCT algorithms. When using the accurate integer DCT/IDCT algorithms, RGB-to-baseline JPEG compression is approximately 149-246% (avg. 201%) faster relative to libjpeg-turbo 3.1.x, and baseline-to-RGB JPEG decompression is approximately 48-180% (avg. 115%) faster. (Tested on a 1.6 GHz Ky X1 CPU. Actual mileage may vary.)

  7. The TurboJPEG Java API has been moved to a dedicated repository where it can evolve independently of the TurboJPEG C API based on demand. Justifications:

    • The TurboJPEG Java API was designed around the needs of Java Web Start, an obsolete "zero-install" method of Java application deployment. The idea was that JWS applications could be deployed along with JAR files containing the TurboJPEG Java API and TurboJPEG API library, which contained Java Native Interface (JNI) bindings to support the former. It made sense for our project to package those resources so downstream developers could easily sign and deploy them via JWS. These days, however, Java applications are more frequently deployed as standalone applications.
    • The TurboJPEG Java API was designed at a time when libjpeg-turbo was not ubiquitous and JNA was nascent. These days, libjpeg-turbo is used by most operating systems, so there is less of a need for us to package an end-to-end solution for high-speed JPEG support in Java.
    • The Java-friendly design of the TurboJPEG Java API (specifically, the requirement that it work directly with Java arrays rather than NIO buffers) necessitated allocating all buffers on the Java heap in order to avoid buffer copies. That necessitated using fixed-size JPEG buffers (the equivalent of TJPARAM_NOREALLOC), which meant that all JPEG buffers had to be big enough to account for the size of the ICC profile and the possibility of zero compression. Some of the proposed new TurboJPEG API features would have been impossible to implement in the TurboJPEG Java API without completely redesigning it.
    • The Java-friendly design of the TurboJPEG Java API made it more difficult to maintain, document, and extend than the C API, which reduced our ability to add needed features in a timely manner.

    Example code (TurboJPEG/JNA) demonstrating how to use the TurboJPEG C API through Java Native Access (JNA) has been added to the source tree and can be built, tested, and installed by setting the WITH_JNA CMake variable. TurboJPEG/JNA generally performs as well as the TurboJPEG C API, whereas compressing JPEG images with the TurboJPEG Java API was slower on some platforms.

  8. To facilitate shadow recovery in underexposed images, the libjpeg and TurboJPEG APIs and associated programs now allow an 8-bit-per-sample lossy JPEG image to be decompressed to a 12-bit-per-sample output image. This is enabled in the libjpeg API by setting cinfo->data_precision = 12 after calling jpeg_read_header(), and in the TurboJPEG API by calling tj3Decompress12() after calling tj3DecompressHeader().

  9. cjpeg, djpeg, tj3LoadImage*(), and tj3SaveImage*() now support 8-bit-per-channel and 16-bit-per-channel PNG images.

    • By default, cjpeg transfers the embedded ICC profile from a PNG input image to the JPEG image, and djpeg transfers the embedded ICC profile from the JPEG image to a PNG output image. A new option (-noicc) can be used to disable that behavior.
    • If called with a TurboJPEG compression instance, tj3LoadImage*() extracts the embedded ICC profile from a PNG image and associates it with the TurboJPEG instance if TJPARAM_SAVEMARKERS is set to 2 or 4.
    • If called with a TurboJPEG decompression instance, tj3SaveImage*() transfers the ICC profile that was previously extracted from the JPEG image to a PNG image if TJPARAM_SAVEMARKERS is set to 2 or 4.
    • The PNG writer upscales images with 2-7 and 9-15 bits of data precision to, respectively, 8-bit-per-channel and 16-bit-per-channel PNG images. The upscaling algorithm is reversible, so a lossless JPEG image with a non-standard data precision can be losslessly converted to a PNG image and back to a lossless JPEG image with the same data precision.

  10. The TurboJPEG API has been improved in the following ways:

    • tj3GetICCProfile() can now be called multiple times to retrieve the ICC profile that was previously extracted from a JPEG image.
    • tj3GetICCProfile() can now be used to retrieve the ICC profile associated with a TurboJPEG compression instance (including an ICC profile extracted from a PNG image by tj3LoadImage*().)
    • The JPEG colorspace can now be reset to the default, using a new TJPARAM_COLORSPACE value (TJCS_DEFAULT.)
    • 4:1:0 and 2:4 subsampling are now supported.

  11. Added a new cjpeg, djpeg, and jpegtran option (-nooverwrite) that causes the programs to fail if the specified output file exists.

  12. jpegtran now includes a -roll option that performs a lossless roll transform (shift with wraparound), which is similar in concept to the -roll option in ImageMagick and the Offset filter/tool in Photoshop and GIMP.

Assets 19
Loading

3.1.4.1

27 Mar 20:28
@dcommander dcommander
3.1.4.1
9217719

Choose a tag to compare

View all tags
3.1.4.1 Latest
Latest

Assets

Support

Code Quality: Stable
Current Support Category: Active

Release Notes

Significant changes relative to 3.1.4:

  1. Fixed multiple issues, some long-standing and some that were regressions introduced in 3.1.4, that made the CMake package config files non-relocatable and broke the --prefix option to cmake --install.

Significant changes relative to 3.1.3:

  1. Fixed an issue in the TurboJPEG 2.x compatibility wrapper whereby, if a calling program attempted to decompress a lossless JPEG image using tjDecompress2() with decompression scaling, the decompressed image was unexpectedly unscaled. This could have led to a buffer overrun if the caller allocated the packed-pixel destination buffer based on the assumption that the decompressed image would be scaled down.

  2. The SIMD dispatchers now use getauxval() or elf_aux_info(), if available, to detect support for Neon and AltiVec instructions on AArch32 and PowerPC Linux, Android, and *BSD systems.

  3. Hardened the libjpeg API against hypothetical applications that may erroneously set one of the exposed quantization table values to 0 just before calling jpeg_start_compress(). (This would never happen in a correctly-written program, because jpeg_add_quant_table() clamps all values less than 1.)

  4. Fixed a division-by-zero error that occurred when attempting to use the jpegtran -drop option with a specially-crafted malformed drop image (specifically an image in which one or more of the quantization table values was 0.)

  5. Fixed an issue in the TurboJPEG API library's data destination manager that manifested as:

    • a memory leak that occurred if a pre-allocated JPEG destination buffer was passed to tj3Compress*() or tj3Transform(), TJPARAM_NOREALLOC was unset, and it was necessary for the library to re-allocate the buffer to accommodate the destination image, and
    • a potential caller double free that occurred if pre-allocated JPEG destination buffers were passed to tj3Transform(), multiple lossless transform operations were performed, and it was necessary for the library to re-allocate the second buffer to accommodate the second destination image.

  6. Fixed an issue in tj3Transform() whereby, if TJPARAM_SAVEMARKERS was set to 2 or 4, TJXOPT_COPYNONE was not specified, an ICC profile was extracted from the source image, and another ICC profile was associated with the TurboJPEG instance using tj3SetICCProfile(), both profiles were embedded in the destination image. The documented API behavior is for TJXOPT_COPYNONE to take precedence over TJPARAM_SAVEMARKERS and for TJPARAM_SAVEMARKERS to take precedence over the associated ICC profile. Thus, tj3Transform() now ignores the associated ICC profile unless TJXOPT_COPYNONE is specified or TJPARAM_SAVEMARKERS is set to something other than 2 or 4.

  7. Fixed an oversight in the libjpeg API whereby, if a calling application manually set cinfo.Ss (the predictor selection value) to a value less than 1 or greater than 7 after calling jpeg_enable_lossless() and prior to calling jpeg_start_compress(), an incorrect (all white) lossless JPEG image was silently generated.

  8. Further hardened the TurboJPEG Java API against hypothetical applications that may erroneously pass huge values to one of the compression, YUV encoding, decompression, YUV decoding, or packed-pixel image I/O methods, leading to signed integer overflow in the JNI wrapper's buffer size checks that rendered those checks ineffective.

Assets 19

3.1.4

26 Mar 20:13
@dcommander dcommander
3.1.4
e352b02

Choose a tag to compare

View all tags
3.1.4

Assets

Support

Code Quality: Stable
Current Support Category: Active

Release Notes

Significant changes relative to 3.1.3:

  1. Fixed an issue in the TurboJPEG 2.x compatibility wrapper whereby, if a calling program attempted to decompress a lossless JPEG image using tjDecompress2() with decompression scaling, the decompressed image was unexpectedly unscaled. This could have led to a buffer overrun if the caller allocated the packed-pixel destination buffer based on the assumption that the decompressed image would be scaled down.

  2. The SIMD dispatchers now use getauxval() or elf_aux_info(), if available, to detect support for Neon and AltiVec instructions on AArch32 and PowerPC Linux, Android, and *BSD systems.

  3. Hardened the libjpeg API against hypothetical applications that may erroneously set one of the exposed quantization table values to 0 just before calling jpeg_start_compress(). (This would never happen in a correctly-written program, because jpeg_add_quant_table() clamps all values less than 1.)

  4. Fixed a division-by-zero error that occurred when attempting to use the jpegtran -drop option with a specially-crafted malformed drop image (specifically an image in which one or more of the quantization table values was 0.)

  5. Fixed an issue in the TurboJPEG API library's data destination manager that manifested as:

    • a memory leak that occurred if a pre-allocated JPEG destination buffer was passed to tj3Compress*() or tj3Transform(), TJPARAM_NOREALLOC was unset, and it was necessary for the library to re-allocate the buffer to accommodate the destination image, and
    • a potential caller double free that occurred if pre-allocated JPEG destination buffers were passed to tj3Transform(), multiple lossless transform operations were performed, and it was necessary for the library to re-allocate the second buffer to accommodate the second destination image.

  6. Fixed an issue in tj3Transform() whereby, if TJPARAM_SAVEMARKERS was set to 2 or 4, TJXOPT_COPYNONE was not specified, an ICC profile was extracted from the source image, and another ICC profile was associated with the TurboJPEG instance using tj3SetICCProfile(), both profiles were embedded in the destination image. The documented API behavior is for TJXOPT_COPYNONE to take precedence over TJPARAM_SAVEMARKERS and for TJPARAM_SAVEMARKERS to take precedence over the associated ICC profile. Thus, tj3Transform() now ignores the associated ICC profile unless TJXOPT_COPYNONE is specified or TJPARAM_SAVEMARKERS is set to something other than 2 or 4.

  7. Fixed an oversight in the libjpeg API whereby, if a calling application manually set cinfo.Ss (the predictor selection value) to a value less than 1 or greater than 7 after calling jpeg_enable_lossless() and prior to calling jpeg_start_compress(), an incorrect (all white) lossless JPEG image was silently generated.

  8. Further hardened the TurboJPEG Java API against hypothetical applications that may erroneously pass huge values to one of the compression, YUV encoding, decompression, YUV decoding, or packed-pixel image I/O methods, leading to signed integer overflow in the JNI wrapper's buffer size checks that rendered those checks ineffective.

Assets 19
Loading

3.1.3

10 Dec 21:19
@dcommander dcommander
3.1.3
af9c1c2

Choose a tag to compare

View all tags
3.1.3

Assets

Support

Code Quality: Stable
Current Support Category: Active

Release Notes

Significant changes relative to 3.1.2:

  1. Hardened the TurboJPEG API against hypothetical applications that may erroneously call tj*Compress*() or tj*Transform() with a reused JPEG destination buffer pointer while specifying a destination buffer size of 0.

  2. Hardened the TurboJPEG API against hypothetical applications that may erroneously set TJPARAM_LOSSLESS or TJPARAM_COLORSPACE prior to calling tj3EncodeYUV*8() or tj3CompressFromYUV*8(). tj3EncodeYUV*8() and tj3CompressFromYUV*8() now ignore TJPARAM_LOSSLESS and TJPARAM_COLORSPACE.

  3. Hardened the TurboJPEG Java API against hypothetical applications that may erroneously pass huge X or Y offsets to one of the compression, YUV encoding, decompression, or YUV decoding methods, leading to signed integer overflow in the JNI wrapper's buffer size checks that rendered those checks ineffective.

  4. Fixed an issue in the TurboJPEG Java API whereby TJCompressor.getSourceBuf() sometimes returned the buffer from a previous invocation of TJCompressor.loadSourceImage() if the target data precision was changed before the most recent invocation.

  5. Fixed an issue in the PPM reader that caused incorrect pixels to be generated when using tj3LoadImage*() or TJCompressor.loadSourceImage() to load a PBMPLUS (PPM/PGM) file into a CMYK buffer with a different data precision than that of the file.

Assets 19
Loading

3.1.2

03 Sep 16:39
@dcommander dcommander
3.1.2
4e151a4

Choose a tag to compare

View all tags
3.1.2

Assets

Support

Code Quality: Stable
Current Support Category: Active

Release Notes

Significant changes relative to 3.1.1:

  1. Fixed a regression introduced by 3.1 beta1[5] that caused a segfault in TJBench if -copy or -c was passed as the last command-line argument.

  2. The build system now uses wrappers rather than CMake object libraries to compile source files for multiple data precisions. This improves code readability and facilitates adapting the libjpeg-turbo source code to non-CMake build systems.

  3. Fixed an issue whereby decompressing a 4:2:0 or 4:2:2 JPEG image with merged upsampling disabled/one-pass color quantization enabled, then reusing the same API instance to decompress a 4:2:0 or 4:2:2 JPEG image with merged upsampling enabled/color quantization disabled, caused jpeg_skip_scanlines() to use freed memory. In practice, the freed memory was not reclaimed before it was used. Thus, this issue did not cause a segfault or other user-visible errant behavior (it was only detectable with ASan), and it did not likely pose a security risk.

  4. The AArch64 (Arm 64-bit) Neon SIMD extensions and accelerated Huffman codec now support the Arm64EC ABI on Windows, which allows Windows/x64 applications to call native Arm64 functions when running under the Windows/x64 emulator on Windows/Arm.

Assets 19
Loading

3.1.1

10 Jun 15:46
@dcommander dcommander
3.1.1
7723f50

Choose a tag to compare

View all tags
3.1.1

Assets

Packaging Changes

  • The macOS packages are now notarized, which eliminates a Gatekeeper warning with recent macOS releases. (Previously, installing libjpeg-turbo on recent macOS releases required overriding the warning in the Privacy & Security pane under System Settings.)
  • A Windows/Arm package is now provided.
  • New builds of libjpeg-turbo-3.1.1-vc-x64.exe and libjpeg-turbo-3.1.1-vc-arm64.exe built with clang-cl were uploaded on 2025-06-18. Relative to the Visual C++ compiler, clang-cl improves the overall performance of libjpeg-turbo by approximately 10% on average for x64 systems and 30-35% on average for Arm64 systems.
  • A new build of libjpeg-turbo-3.1.1.dmg was uploaded on 2025-08-13 to address an issue whereby the TurboJPEG Java wrapper could not be used with the x86-64 architecture.

Support

Code Quality: Stable
Current Support Category: Active

Release Notes

Significant changes relative to 3.1.0:

  1. Hardened the libjpeg API against hypothetical calling applications that may erroneously change the value of the data_precision field in jpeg_compress_struct or jpeg_decompress_struct after calling jpeg_start_compress() or jpeg_start_decompress().
Assets 19
Loading

3.1.0

12 Dec 22:25
@dcommander dcommander
3.1.0
20ade4d

Choose a tag to compare

View all tags
3.1.0

Assets

Packaging Changes

  • The RPM packages now contain SHA-256 header and payload digests. This fixes an issue whereby the RPM signatures could not be verified on Red Hat Enterprise Linux with FIPS mode enabled. The RPM packages now require GLIBC 2.17 or later.
  • A new build of libjpeg-turbo-3.1.0.dmg was uploaded on 2025-08-13 to address an issue whereby the TurboJPEG Java wrapper could not be used with the x86-64 architecture.

Support

Code Quality: Stable
Current Support Category: Active

Release Sponsors

This release was made possible via funding from MathWorks.

The MathWorks, Inc.

Release Notes

Significant changes relative to 3.1 beta1:

  1. Fixed an issue in the TurboJPEG API whereby, when generating a lossless JPEG image with more than 8 bits per sample, specifying a point transform value greater than 7 resulted in an error ("Parameter value out of range") unless TJPARAM_PRECISION/TJ.PARAM_PRECISION was specified before TJPARAM_LOSSLESSPT/TJ.PARAM_LOSSLESSPT.

  2. Fixed a regression introduced by 1.4 beta1[3] that prevented jpeg_set_defaults() from resetting the Huffman tables to default (baseline) values if Huffman table optimization or progressive mode was previously enabled in the same libjpeg instance.

  3. Fixed an issue whereby lossless JPEG compression could not be disabled if it was previously enabled in a libjpeg or TurboJPEG instance. jpeg_set_defaults() now disables lossless JPEG compression in a libjpeg instance, and setting TJPARAM_LOSSLESS/TJ.PARAM_LOSSLESS to 0 now disables lossless JPEG compression in a TurboJPEG instance.

Assets 18
Loading

3.0.90 (3.1 beta1)

14 Sep 21:01
@dcommander dcommander
3.0.90
a9f7490

Choose a tag to compare

View all tags
3.0.90 (3.1 beta1) Pre-release
Pre-release

Assets

Packaging Changes

  • The RPM packages now contain SHA-256 header and payload digests. This fixes an issue whereby the RPM signatures could not be verified on Red Hat Enterprise Linux with FIPS mode enabled. The RPM packages now require GLIBC 2.17 or later.

Support

Code Quality: Beta
Current Support Category: EOL

Release Sponsors

This release was made possible via funding from MathWorks.

The MathWorks, Inc.

Release Notes

Significant changes relative to 3.0.4:

  1. The libjpeg-turbo source tree has been reorganized to make it easier to find the README files, license information, and build instructions. The documentation for the libjpeg API library and associated programs has been moved into the doc/ subdirectory, all C source code and headers have been moved into a new src/ subdirectory, and test scripts have been moved into a new test/ subdirectory.

  2. cjpeg no longer allows GIF input files to be converted into 12-bit-per-sample JPEG files. That was never a useful feature, since GIF images have at most 256 colors referenced from a palette of 8-bit-per-component RGB values.

  3. Added support for lossless JPEG images with 2 to 15 bits per sample to the libjpeg and TurboJPEG APIs. When creating or decompressing a lossless JPEG image and when loading or saving a PBMPLUS image, functions/methods specific to 8-bit samples now handle 8-bit samples with 2 to 8 bits of data precision (specified using the data_precision field in jpeg_compress_struct or jpeg_decompress_struct or using TJPARAM_PRECISION/TJ.PARAM_PRECISION), functions/methods specific to 12-bit samples now handle 12-bit samples with 9 to 12 bits of data precision, and functions/methods specific to 16-bit samples now handle 16-bit samples with 13 to 16 bits of data precision. Refer to libjpeg.txt, usage.txt, and the TurboJPEG API documentation for more details.

  4. All deprecated constants and methods in the TurboJPEG Java API have been removed.

  5. TJBench command-line arguments are now more consistent with those of cjpeg, djpeg, and jpegtran. More specifically:

    • -copynone has been replaced with -copy none.
    • -fastdct has been replaced with -dct fast.
    • -fastupsample has been replaced with -nosmooth.
    • -hflip and -vflip have been replaced with -flip {horizontal|vertical}.
    • -limitscans has been replaced with -maxscans, which allows the scan limit to be specified.
    • -rgb, -bgr, -rgbx, -bgrx, -xbgr, -xrgb, and -cmyk have been replaced with -pixelformat {rgb|bgr|rgbx|bgrx|xbgr|xrgb|cmyk}.
    • -rot90, -rot180, and -rot270 have been replaced with -rotate {90|180|270}.
    • -stoponwarning has been replaced with -strict.
    • British spellings for gray (grey) and optimize (optimise) are now allowed.

    The old command-line arguments are deprecated and will be removed in a future release. TJBench command-line arguments can now be abbreviated as well. (Where possible, the abbreviations are the same as those supported by cjpeg, djpeg, and jpegtran.)

  6. Added a new TJBench option (-pixelformat gray) that can be used to test the performance of compressing/decompressing a grayscale JPEG image from/to a packed-pixel grayscale image.

  7. Fixed an issue whereby, if TJPARAM_NOREALLOC was set, TurboJPEG compression and lossless transformation functions ignored the JPEG buffer size(s) passed to them and assumed that the JPEG buffer(s) had been allocated to a worst-case size returned by tj3JPEGBufSize(). This behavior was never documented, although the documentation was unclear regarding whether the JPEG buffer size should be specified if a JPEG buffer is pre-allocated to a worst-case size.

  8. The TurboJPEG C and Java APIs have been improved in the following ways:

    • New image I/O methods (TJCompressor.loadSourceImage() and TJDecompressor.saveImage()) have been added to the Java API. These methods work similarly to the tj3LoadImage*() and tj3SaveImage*() functions in the C API.
    • The TurboJPEG lossless transformation function and methods now add restart markers to all destination images if TJPARAM_RESTARTBLOCKS/TJ.PARAM_RESTARTBLOCKS or TJPARAM_RESTARTROWS/TJ.PARAM_RESTARTROWS is set.
    • New functions/methods (tj3SetICCProfile() / TJCompressor.setICCProfile() / TJTransformer.setICCProfile() and tj3GetICCProfile() / TJDecompressor.getICCProfile()) can be used to embed and retrieve ICC profiles.
    • A new parameter (TJPARAM_SAVEMARKERS/TJ.PARAM_SAVEMARKERS) can be used to specify the types of markers that will be copied from the source image to the destination image during lossless transformation if TJXOPT_COPYNONE/TJTransform.OPT_COPYNONE is not specified.
    • A new convenience function/method (tj3TransformBufSize() / TJTransformer.bufSize()) can be used to compute the worst-case destination buffer size for a given lossless transform, taking into account cropping, transposition of the width and height, grayscale conversion, and the embedded or extracted ICC profile.

  9. TJExample has been replaced with three programs (TJComp, TJDecomp, and TJTran) that demonstrate how to approximate the functionality of cjpeg, djpeg, and jpegtran using the TurboJPEG C and Java APIs.

Assets 18
Loading

3.0.4

14 Sep 19:46
@dcommander dcommander
3.0.4
f29eda6

Choose a tag to compare

View all tags
3.0.4

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.

Assets 18
Loading

3.0.3

08 May 16:37
@dcommander dcommander
3.0.3
7fa4b5b

Choose a tag to compare

View all tags
3.0.3

Assets

Support

Code Quality: Stable
Current Support Category: Maintenance

Release Notes

Significant changes relative to 3.0.2:

  1. Fixed an issue in the build system, introduced in 3.0.2, that caused all libjpeg-turbo components to depend on the Visual C++ run-time DLL when built with Visual C++ and CMake 3.15 or later, regardless of value of the WITH_CRT_DLL CMake variable.

  2. The x86-64 SIMD extensions now include support for Intel Control-flow Enforcement Technology (CET), which is enabled automatically if CET is enabled in the C compiler.

  3. Fixed a regression introduced by 3.0 beta2[6] that made it impossible for calling applications to supply custom Huffman tables when generating 12-bit-per-component lossy JPEG images using the libjpeg API.

  4. Fixed a segfault that occurred when attempting to use the jpegtran -drop option with a specially-crafted malformed input image or drop image (specifically an image in which all of the scans contain fewer components than the number of components specified in the Start Of Frame segment.)

Assets 18
Loading
Morty Proxy This is a proxified and sanitized view of the page, visit original site.