release

Branch :

Log

Commit	Date	Message
2f26b48f	2025-04-02 13:59:17	Mac pkg: Fix issues that prevent notarization - Explicitly sign all binaries included in the package. - Enable the hardened runtime.
cc095fee	2024-12-18 09:39:53	Build: Generate 32-bit supplementary ppc64 .deb As with x86-64, the Power ISA basically implements 64-bit instructions as extensions of their 32-bit counterparts. Thus, 64-bit Power ISA CPUs can natively execute legacy 32-bit PowerPC instructions when running in big-endian mode. Most Power ISA support has shifted (pun intended) to little-endian mode, so there are few remaining operating systems that support big-endian mode. Debian is one of them, however (albeit unofficially.)
be7a0c8b	2024-12-11 12:25:16	Build: Make Mac packaging architecture-agnostic Rename the ARMV8_BUILD CMake variable to SECONDARY_BUILD, and modify the makemacpkg script so that it allows any architecture in a primary or secondary build. The idea is that Apple Silicon users can package an arm64 primary build and a secondary x86_64 build, and Intel users can package an x86_64 primary build and a secondary arm64 build, using the same procedure. Also simplify the iOS build instructions, using the CMAKE_OSX_ARCHITECTURES variable rather than a toolchain.
fad61007	2024-08-20 18:52:53	Replace TJExample with IJG workalike programs
e69dd40c	2024-01-23 13:26:41	Reorganize source to make things easier to find - Move all libjpeg documentation, except for README.ijg, into the doc/ subdirectory. - Move the TurboJPEG C API documentation from doc/html/ into doc/turbojpeg/. - Move all C source code and headers into a src/ subdirectory. - Move turbojpeg-jni.c into the java/ subdirectory. Referring to #226, there is no ideal solution to this problem. A semantically ideal solution would have involved placing all source code, including the SIMD and Java source code, under src/ (or perhaps placing C library source code under lib/ and C test program source code under test/), all header files under include/, and all documentation under doc/. However: - To me it makes more sense to have separate top-level directories for each language, since the SIMD extensions and the Java API are technically optional features. src/ now contains only the code that is relevant to the core C API libraries and associated programs. - I didn't want to bury the java/ and simd/ directories or add a level of depth to them, since both directories already contain source code that is 3-4 levels deep. - I would prefer not to separate the header files from the C source code, because: 1. It would be disruptive. libjpeg and libjpeg-turbo have historically placed C source code and headers in the same directory, and people who are familiar with both projects (self included) are used to looking for the headers in the same directory as the C source code. 2. In terms of how the headers are used internally in libjpeg-turbo, the distinction between public and private headers is a bit fuzzy. - It didn't make sense to separate the test source code from the library source code, since there is not a clear distinction in some cases. (For instance, the IJG image I/O functions are used by cjpeg and djpeg as well as by the TurboJPEG API.) This solution is minimally disruptive, since it keeps all C source code and headers together and keeps java/ and simd/ as top-level directories. It is a bit awkward, because java/ and simd/ technically contain source code, even though they are not under src/. However, other solutions would have been more awkward for different reasons. Closes #226
abeca1f0	2023-11-30 09:35:11	Move official releases to GitHub
762f8b4f	2023-07-05 10:55:07	Doc: Mention that we are a JPEG ref implementation
b5a9ef64	2022-11-13 13:00:26	Don't allow 12-bit JPEG support to be disabled In libjpeg-turbo 2.1.x and prior, the WITH_12BIT CMake variable was used to enable 12-bit JPEG support at compile time, because the libjpeg API library could not handle multiple JPEG data precisions at run time. The initial approach to handling multiple JPEG data precisions at run time (7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac) created a whole new API, library, and applications for 12-bit data precision, so it made sense to repurpose WITH_12BIT to allow 12-bit data precision to be disabled. e8b40f3c2ba187ba95c13c3e8ce21c8534256df7 made it so that the libjpeg API library can handle multiple JPEG data precisions at run time via a handful of straightforward API extensions. Referring to 6c2bc901e27b047440ed46920c4d3f0480b48268, it hasn't been possible to build libjpeg-turbo with both forward and backward libjpeg API/ABI compatibility since libjpeg-turbo 1.4.x. Thus, whereas we retain full backward API/ABI compatibility with libjpeg v6b-v8, forward libjpeg API/ABI compatibility ceased being realistic years ago, so it no longer makes sense to provide compile-time options that give a false sense of forward API/ABI compatibility by allowing some (but not all) of our libjpeg API extensions to be disabled. Such options are difficult to maintain and clutter the code with #ifdefs.
e8b40f3c	2022-11-01 21:45:39	Vastly improve 12-bit JPEG integration The Gordian knot that 7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac attempted to unravel was caused by the fact that there are several data-precision-dependent (JSAMPLE-dependent) fields and methods in the exposed libjpeg API structures, and if you change the exposed libjpeg API structures, then you have to change the whole API. If you change the whole API, then you have to provide a whole new library to support the new API, and that makes it difficult to support multiple data precisions in the same application. (It is not impossible, as example.c demonstrated, but using data-precision-dependent libjpeg API structures would have made the cjpeg, djpeg, and jpegtran source code hard to read, so it made more sense to build, install, and package 12-bit-specific versions of those applications.) Unfortunately, the result of that initial integration effort was an unreadable and unmaintainable mess, which is a problem for a library that is an ISO/ITU-T reference implementation. Also, as I dug into the problem of lossless JPEG support, I realized that 16-bit lossless JPEG images are a thing, and supporting yet another version of the libjpeg API just for those images is untenable. In fact, however, the touch points for JSAMPLE in the exposed libjpeg API structures are minimal: - The colormap and sample_range_limit fields in jpeg_decompress_struct - The alloc_sarray() and access_virt_sarray() methods in jpeg_memory_mgr - jpeg_write_scanlines() and jpeg_write_raw_data() - jpeg_read_scanlines() and jpeg_read_raw_data() - jpeg_skip_scanlines() and jpeg_crop_scanline() (This is subtle, but both of those functions use JSAMPLE-dependent opaque structures behind the scenes.) It is much more readable and maintainable to provide 12-bit-specific versions of those six top-level API functions and to document that the aforementioned methods and fields must be type-cast when using 12-bit samples. Since that eliminates the need to provide a 12-bit-specific version of the exposed libjpeg API structures, we can: - Compile only the precision-dependent libjpeg modules (the coefficient buffer controllers, the colorspace converters, the DCT/IDCT managers, the main buffer controllers, the preprocessing and postprocessing controller, the downsampler and upsamplers, the quantizers, the integer DCT methods, and the IDCT methods) for multiple data precisions. - Introduce 12-bit-specific methods into the various internal structures defined in jpegint.h. - Create precision-independent data type, macro, method, field, and function names that are prefixed by an underscore, and use an internal header to convert those into precision-dependent data type, macro, method, field, and function names, based on the value of BITS_IN_JSAMPLE, when compiling the precision-dependent libjpeg modules. - Expose precision-dependent jinit() functions for each of the precision-dependent libjpeg modules. - Abstract the precision-dependent libjpeg modules by calling the appropriate precision-dependent jinit() function, based on the value of cinfo->data_precision, from top-level libjpeg API functions.
6c2bc901	2022-11-03 14:39:19	Don't allow disabling in-memory src/dest managers By default, libjpeg-turbo 1.3.x and later have enabled the in-memory source/destination manager functions from libjpeg v8 when emulating the libjpeg v6b or v7 API/ABI, which has allowed operating system distributors to provide those functions without adopting the backward-incompatible libjpeg v8 API/ABI. Prior to libjpeg-turbo 1.5.x, it made sense to allow users to disable the in-memory source/destination manager functions at build time and thus retain both backward and forward API/ABI compatibility relative to libjpeg v6b or v7. Since then, however, we have introduced several new libjpeg API functions that break forward API/ABI compatibility, so it no longer makes sense to allow the in-memory source/destination managers to be disabled. libjpeg-turbo only claims to be backward-API/ABI-compatible, i.e. to allow applications built against libjpeg or an older version of libjpeg-turbo to work properly with the current version of libjpeg-turbo.