From patchwork Fri Jul 3 19:41:29 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adolf Belka X-Patchwork-Id: 10009 Return-Path: Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4gsPJz4jxkz3wkB for ; Fri, 03 Jul 2026 19:41:55 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [IPv6:2001:678:b28::201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail02.haj.ipfire.org", Issuer "YE1" (not verified)) by mail01.ipfire.org (Postfix) with ESMTPS id 4gsPJx0xXwz6mP for ; Fri, 03 Jul 2026 19:41:53 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4gsPJq26vNz37BK for ; Fri, 03 Jul 2026 19:41:47 +0000 (UTC) X-Original-To: development@lists.ipfire.org Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4gsPJm35fSz34Nk for ; Fri, 03 Jul 2026 19:41:44 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4gsPJj4YLdz6xy; Fri, 03 Jul 2026 19:41:41 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1783107701; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AftrEbgL4uxiokqfgLliZG9USGBTAQZLv3D9VFpp5zI=; b=D184e75VGd+JsgpaaNZI8OMdBK9c+GjYlu8PI/w5YVYYsFlj7aqh5cVYuU87qaQe2n8lRY d4nL0S9y7PrlEHAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1783107701; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AftrEbgL4uxiokqfgLliZG9USGBTAQZLv3D9VFpp5zI=; b=cP+U9RNiaVYGaPdVP3iWuvchFISfUP7EgB/LD2xqMa3pAt730SOi6vR223tAFpN5TVKYA+ nDMYGfZFlWSo0slNHTCH1olMb2YwlZbxCCF38ro5Dkna4M2/AConRemYFTEUrYDLSZCpjq XQ9AARNDwwT5OPlXPcVkaKBDEofzRWvfCEO+l+z6ky3UMVnCygp7s+Jcw1am0/FOzvttO9 nF9JiUDb8cTrZPA1PqnCFY+8gGs+rHk6BM3QoYT5++828GMTJEvsabBd+NJxsN4nyGcQIk FSyb1J14QT56VTxqi80n4fUq5zqdkUFktqvio9sO2s2+IKEzhfdzhea67BLBlQ== From: Adolf Belka To: development@lists.ipfire.org Cc: Adolf Belka Subject: [PATCH] libjpeg: Update to version 3.2.0 Date: Fri, 3 Jul 2026 21:41:29 +0200 Message-ID: <20260703194133.2938870-15-adolf.belka@ipfire.org> In-Reply-To: <20260703194133.2938870-1-adolf.belka@ipfire.org> References: <20260703194133.2938870-1-adolf.belka@ipfire.org> Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 - Update from version 3.1.4.1 to 3.2.0 - Update of rootfile - Changelog 3.2.0 Significant changes relative to 3.2 beta1: 1. Fixed a regression introduced by 3.2 beta1[9] that broke Arm64EC Windows builds. 2. Hardened the PNG writer (which is used by djpeg and `tj3SaveImage*()`) against applications that may erroneously attempt to write sample values that are out of range for the specified output data precision. This could have caused a buffer overrun in the PNG writer's rescale array if the output data precision was not 8 or 16 bits. The buffer overrun did not likely pose a security risk, since `tj3SaveImage*()` is not exposed to arbitrary external input data and since a caller that abused the API in the aforementioned manner could never work properly. 3. Hardened the libjpeg API against hypothetical applications that may erroneously call `jpeg_crop_scanline()` with buffered-image mode and raw data output enabled. `jpeg_crop_scanline()` does not work with raw data output, but due to an oversight, it did not throw an error if both buffered-image mode and raw data output were enabled. If a hypothetical application aborted a normal decompression operation without reading any scanlines, started a new decompression operation using the same libjpeg instance with buffered-image mode and raw data output enabled, then called `jpeg_crop_scanline()` with arguments that would have caused any of the component planes to be cropped to a width of 1 sample, `jpeg_crop_scanline()` would have used freed memory. However, this did not likely pose a security risk, since an application that abused the API in the aforementioned manner could never work properly. 4. Fixed a buffer overrun and subsequent segfault in jpegtran that occurred when attempting to use the `-crop` and `-trim` options to expand the width of an image narrower than one iMCU, discard partial iMCUs, and fill each block in the expanded region with the DC coefficient of the nearest block in the input image ("flatten.") Similarly, fixed an infinite loop that occurred when attempting to use the `-crop` and `-trim` options to expand the width of an image narrower than one iMCU, discard partial iMCUs, and fill the expanded region with repeated reflections of the input image ("reflect.") When the only iMCU column in the input image is partial and partial iMCUs are trimmed, the flatten and reflect extensions cannot work properly, so jpegtran now throws an error if that is the case. These issues were confined to the jpegtran application and thus did not pose a security risk. 3.1.90 (3.2 beta1) 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](https://github.com/libjpeg-turbo/turbojpeg-java) 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. Signed-off-by: Adolf Belka --- config/rootfiles/common/libjpeg | 2 +- lfs/libjpeg | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/config/rootfiles/common/libjpeg b/config/rootfiles/common/libjpeg index 67fa34985..9cef3944e 100644 --- a/config/rootfiles/common/libjpeg +++ b/config/rootfiles/common/libjpeg @@ -19,7 +19,7 @@ usr/lib/libjpeg.so.8 usr/lib/libjpeg.so.8.3.2 #usr/lib/libturbojpeg.so usr/lib/libturbojpeg.so.0 -usr/lib/libturbojpeg.so.0.4.0 +usr/lib/libturbojpeg.so.0.5.0 #usr/lib/pkgconfig/libjpeg.pc #usr/lib/pkgconfig/libturbojpeg.pc #usr/share/doc/libjpeg-turbo diff --git a/lfs/libjpeg b/lfs/libjpeg index b03f795cf..4dcfaf4f0 100644 --- a/lfs/libjpeg +++ b/lfs/libjpeg @@ -24,7 +24,7 @@ include Config -VER = 3.1.4.1 +VER = 3.2.0 THISAPP = libjpeg-turbo-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_BLAKE2 = 7e38379b4e3bb168e6ec081be5852f9a7f4680929d42e5cccb0c00632130eee9200afdc9c2ed99250c3ddfc1cd8dd21f60da54e6c48157884c9173ae1b3f9a9f +$(DL_FILE)_BLAKE2 = c50c985f8b870ab6467181f69e10f3ec2705cb349613b9178b293f136063e302087832d87f793b3d24ab721a2f5d76271760bd244d0766ab3b8cbe48ebf50cfa install : $(TARGET)