kc3-lang/libjpeg-turbo

Log

Author Commit Date CI Message
DRC 875e873f 2019-07-11T17:05:15 tjutil.c: Fix compiler warning with Visual Studio Apparently windows.h includes stdlib.h, which defines the max() and min() macros, so we need to ensure that tjutil.h is included after that.
DRC 2a9e3bd7 2019-07-11T15:30:04 TurboJPEG: Properly handle gigapixel images Prevent several integer overflow issues and subsequent segfaults that occurred when attempting to compress or decompress gigapixel images with the TurboJPEG API: - Modify tjBufSize(), tjBufSizeYUV2(), and tjPlaneSizeYUV() to avoid integer overflow when computing the return values and to return an error if such an overflow is unavoidable. - Modify tjunittest to validate the above. - Modify tjCompress2(), tjEncodeYUVPlanes(), tjDecompress2(), and tjDecodeYUVPlanes() to avoid integer overflow when computing the row pointers in the 64-bit TurboJPEG C API. - Modify TJBench (both C and Java versions) to avoid overflowing the size argument to malloc()/new and to fail gracefully if such an overflow is unavoidable. In general, this allows gigapixel images to be accommodated by the 64-bit TurboJPEG C API when using automatic JPEG buffer (re)allocation. Such images cannot currently be accommodated without automatic JPEG buffer (re)allocation, due to the fact that tjAlloc() accepts a 32-bit integer argument (oops.) Such images cannot be accommodated in the TurboJPEG Java API due to the fact that Java always uses a signed 32-bit integer as an array index. Fixes #361
DRC f37b7c1f 2019-07-02T11:28:26 Build: Fix build/install with Xcode IDE Closes #355
Jonathan Wright 509c2680 2019-05-09T13:46:53 Use bias pattern for 4:4:0 (h1v2) fancy upsampling This commit modifies h1v2_fancy_upsample() so that it uses an ordered dither pattern, similar to that of h2v1_fancy_upsample(), rounding up or down the result for alternate pixels rather than always rounding down. This ensures that the decompression error pattern for a 4:4:0 JPEG image will be similar to the rotated decompression error pattern for a 4:2:2 JPEG image. Thus, the final result will be similar regardless of whether a 4:2:2 JPEG image is rotated or transposed before or after decompression. Closes #356
DRC ec5adb83 2019-05-18T17:58:50 Build/packaging: Support macOS package/DMG signing
DRC c8e52741 2019-05-09T09:11:09 Travis: Use xcode8.3 image xcode7.3 is based on El Capitan, which is EOL, and Homebrew no longer provides El Cap bottles (pre-compiled binaries.) Thus, Homebrew was trying to build GCC 5, YASM, and the other packages we need from source, which caused the Mac CI builds to time out. I tried goading Homebrew into installing GCC 5.5.0_2 and YASM 1.3.0_1, which still have El Cap bottles available, by using the URLs of those specific versions of the formulae (from the Homebrew GitHub repository) as package names. This failed, however, because 'brew bundle' converted the URLs to all lowercase. I then tried explicitly installing the old formulae by using 'brew install' with the aforementioned URLs (bypassing the Travis Homebrew addon), but Homebrew still tried to build all of the dependencies from source. Upgrading to Xcode 8.3.x necessitated regression testing the performance on iOS, but that proved less of a pain than figuring out how to install all of the old Homebrew bottles we needed. Also, this future-proofs the CI builds against the inevitable discontinuation of the xcode7.3 image. Note that Xcode 8.3.x improves iOS 64-bit decompression performance significantly relative to Xcode 7.2.x or 7.3.x. iOS 32-bit performance unfortunately regresses by as much as 5%, but it can't be helped (32-bit iOS apps are no longer supported on iOS 11+ anyhow, and the next major release of libjpeg-turbo will remove support for them as well.)
DRC 6399d0a6 2019-04-23T14:10:04 Fix code formatting/style issues ... ... including, but not limited to: - unused macros - private functions not marked as static - unprototyped global functions - variable shadowing (detected by various non-default GCC 8 warning options)
Chris Blume aa9db616 2019-04-15T17:55:47 x86 SIMD: Check for CPUID leaf 07H before using According to Intel's manual [1], "If a value entered for CPUID.EAX is higher than the maximum input value for basic or extended function for that processor then the data for the highest basic information leaf is returned." Right now, libjpeg-turbo doesn't first check that leaf 07H is supported before attempting to use it, so the ostensible AVX2 bit (Bit 05) of the CPUID result might actually be Bit 05 from a lower leaf. That bit might be set, even if the CPU doesn't support AVX2. This commit modifies the x86 and x86-64 SIMD feature detection code so that it first checks whether CPUID leaf 07H is supported before attempting to use it to check for AVX2 instruction support. DRC: This commit should fix https://bugzilla.mozilla.org/show_bug.cgi?id=1520760 However, I have not personally been able to reproduce that issue, despite using a Nehalem (pre-AVX2) CPU on which the maximum CPUID leaf has been limited via a BIOS setting. Closes #348 [1] "Intel® 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (2A, 2B, 2C & 2D): Instruction Set Reference, A-Z", https://software.intel.com/sites/default/files/managed/a4/60/325383-sdm-vol-2abcd.pdf, page 3-192.
DRC 2b05d47b 2019-04-15T13:38:15 ChangeLog.md: Document 33011754
DRC 7bc9fca4 2019-04-12T09:07:35 jdhuff.c: Silence UBSan signed int overflow err #2 Same as d3a3a73f64041c6a6905faf6f9f9832e735fd880 but in the fast decode path. It was necessary to use a different-sized test image in order to trigger the error in this location. Refer to #347
DRC bb16b944 2019-04-12T08:53:45 GitHub: Remove new lines from feature-request.md (to make checkstyle happy)
DRC 33011754 2019-04-12T08:47:28 Android: Fix "using JNI after critical get" errors 5ea77d8b771bf7b0be7acc7fb70c255f8c9c8f77 was insufficient to fix all of these. In particular, we need to always release the primitive arrays before throwing an exception, because throwing an exception qualifies as "using JNI." Refer to #300
DRC bce58f48 2019-04-12T07:49:35 Consistify formatting of macros in TurboJPEG code
DRC ce067a6c 2019-04-10T15:16:55 GitHub: Template tweaks CONTRIBUTING.md: Correct misuse of "as such" (Grammar Police) bug-report.md: Clarify that the submitter should always test against the latest stable code base.
DRC 58a3975e 2019-04-10T14:35:45 Bump version to 2.0.3 to prepare for new commits
DRC d3a3a73f 2019-04-10T14:28:47 jdhuff.c: Silence UBSan signed int overflow error Some pathological test images have been created that can cause s to overflow or underflow the signed int data type during decompression. This is technically undefined behavior according to the C spec, although every modern implementation I'm aware of will treat the signed int as a 2's complement unsigned int, thus causing the value to wrap around to INT_MIN if it exceeds INT_MAX. This commit simply makes that behavior explicit in order to shut up UBSan. At least when building for x86-64 or i386 using Clang or GCC, this commit does not change the compiler-generated assembly code at all. The code that triggered this error has existed in the libjpeg code base for at least 20 years (and probably much longer), so the fact that it hasn't produced a user-visible problem in all of that time strongly suggests that UBSan is being overly pedantic here. But if someone can cough up a platform that doesn't wrap around to INT_MIN when 1 is added to INT_MAX, then I'll happily change my opinion. Fixes #347
DRC 5857929f 2019-03-05T17:48:20 GitHub: Formatting tweak to CONTRIBUTING.md
DRC 70947727 2019-03-01T13:13:27 GitHub: Tweak bug report template
DRC 1af712c1 2019-03-01T13:11:11 GitHub: Add feature request template
DRC ec90cd0f 2019-03-01T12:29:41 GitHub: Add contributor guidelines
DRC ce76ffac 2019-03-01T10:07:51 GitHub: Add bug report template
DRC 500b5ece 2019-02-17T09:06:42 turbojpeg.c: Fix compiler warning w/ -DNO_GETENV
DRC 87ab3360 2019-02-14T10:01:16 appveyor.yml: Cache NASM binary package ... since www.nasm.us seems to be down frequently. This doesn't help us at the moment, but hopefully once the site is back up this will prevent future build failures.
Chris Blume b46af82c 2019-02-12T17:35:10 ARMv7 NEON: #ifdef unused funcs/vars w/ -mfpu=neon When simd/arm/jsimd.c is compiled with __ARM_NEON__ defined (which will be the case if -mfpu=neon is passed to the compiler), the parse_proc_cpuinfo() and check_feature() functions and the bufsize variable are unused and thus need to be #ifdef'ed out in order to avoid compiler warnings. Note that the bufsize variable was already #ifdef'ed out on Linux but not on Android due to lack of parentheses (&& takes precedence over ||.) Closes #331
DRC a4aa30d9 2019-02-13T22:03:31 ChangeLog.md: "floating-point"="floating point"
DRC 0d7818d1 2019-02-13T16:22:18 rpm.spec.in: Fix "File listed twice" warning/error %{_libdir}/pkgconfig is a directory and should thus be prefixed by %{dir} (oops.) This issue caused the debuginfo build under RHEL 8 (which is apparently now enabled by default-- regardless of whether the RPM actually contains debug info, but that's another matter) to fail with: RPM build errors: File listed twice: /opt/libjpeg-turbo/lib64/pkgconfig/libjpeg.pc File listed twice: /opt/libjpeg-turbo/lib64/pkgconfig/libturbojpeg.pc
DRC 4b67db4d 2019-02-13T15:20:34 rpm.spec.in: Fix doc packaging issues w/ RHEL 7+ On RHEL 7 and later (not sure exactly whether this is a product of the newer RPM release or something distro-specific), macros are lazily expanded, so we need to set _docdir using %global (which expands at definition time) and prior to _prefix and _datarootdir (which affect _defaultdocdir.) Otherwise, _docdir is set to a subdirectory of /opt/libjpeg-turbo/share/doc or /opt/libjpeg-turbo/doc. The former (which happens on RHEL 7) leads to incorrect documentation packaging (the docs should be packaged under /usr/share/doc per Red Hat standards), and the latter (which happens on RHEL 8) leads to an RPM build error.
DRC f70a7e1e 2019-02-12T15:37:21 rpm.spec.in: Update deprecated [Build]Prereq tags AFAICT, Requires and BuildRequires subsumed the functionality of Prereq and BuildPrereq in RPM 4.0, and none of the platforms we support with libjpeg-turbo 2.0.x has RPM < 4.4.
DRC 6a8421fb 2019-02-12T13:30:15 GNUInstallDirs.cmake: Silence CMP0054 warning ... in CMake 3.11 and later
DRC 031e16ec 2019-02-11T22:43:15 tjbench.c: Fix GCC 8 compiler warning
DRC 75be88cf 2019-02-11T13:10:09 Build: Optionally install PDB files for MSVC DLLs Based on https://github.com/Youw/libjpeg-turbo/commit/333a36ae984a52e547ddeb23848873d3cc798047 Closes #329 Closes #324
DRC e2442e07 2019-02-01T00:56:02 MMI: Fix unaligned comp. perf. for 32-bit PFs also (Oversight from 1c2d3cfaaf7324d9091ba3cc4e900f60a16fe1aa)
DRC 1c2d3cfa 2019-01-30T12:43:45 MMI: Fix comp. perf. issue w/ unaligned image rows Using ldc1 with a non-64-bit-aligned memory location causes as much as a 10x slow-down in overall compression performance.
DRC 2d0b675a 2019-01-25T16:46:02 Build: Fix install of static build w/ VStudio IDE Unfortunately, this hack is necessary because: - install(TARGETS, ...) doesn't support the RENAME option. - We can't modify OUTPUT_NAME for the "-static" targets without breaking the regression tests. - ${CMAKE_CFG_INTDIR} doesn't seem to work properly in an install() command. Refer to #307
DRC 90e2d7f3 2019-01-23T08:27:45 LICENSE.md: Clarifications RE: BSD & zlib licenses Including the license templates was confusing to some, since it made it appear as if the copyright year and author were unspecified for the libjpeg-turbo source. Thus, rather than include the zlib License template, link to that template on opensource.org. For the Modified BSD License, include a roll-up of copyright years and authors, since the terms of that license require the text of it to be included in product documentation for binary distributions without accompanying source code.
DRC 5308c1a0 2019-01-22T12:11:03 BUILDING.md: Update/simplify Android build instr. Use the android.toolchain.cmake toolchain file in the NDK (v13b or later), since this toolchain file generally takes care of setting the approprate compiler flags and dealing with the differences between GCC and Clang. Our custom Android build procedure did not work with Clang-based NDK toolchains, which meant that it could not be made to work with NDK v18b or later. Fixes #309
Orivej Desh ce90ab5d 2019-01-21T22:56:56 Build: Fix regression test failure w/ ctest -j The djpeg rgb-islow-icc-cmp test must run after the djpeg rgb-islow test, since the latter generates testout_rgb_islow.icc.
DRC 1ee87a9e 2019-01-21T16:25:02 djpeg: Fix PPM output regression w/ color quant. Regression caused by aa7459050d7a50e1d8a99488902d41fbc118a50f Fix based on: https://github.com/sinic/libjpeg-turbo/commit/03fbacb8ebf1fffc3f2d2db26ddf4db8b1f6aa7b Closes #310
DRC 479501b0 2019-01-21T13:57:55 TurboJPEG: Decompress 4:4:4 JPEGs with unusual SFs Normally, 4:4:4 JPEGs have horizontal x vertical luminance & chrominance sampling factors of 1x1. However, it is technically legal to create 4:4:4 JPEGs with sampling factors of 2x1, 1x2, 3x1, or 1x3, since the sums of the products of those sampling factors are still <= 10. The libjpeg API correctly decodes such images, so the TurboJPEG API should as well. Fixes #323
Stephen 9bc8eb64 2019-01-01T19:36:03 Travis: Use Homebrew addon to improve performance
DRC 0fa5ae6b 2019-01-01T21:16:33 TJBench Java: Properly handle transform warnings + warnings from TJDecompressor.decompressHeader()
DRC 1ff90822 2019-01-01T21:08:27 TJBench: Fix FPE when decompressing 0-width JPEG Fixes #319
DRC f8cca819 2019-01-01T20:32:40 wrbmp.c: Don't allow quantization w/ non-RGB CS If cinfo->quantize_colors == 1, then jpeg_calc_output_dimensions() will set cinfo->output_components to 1, and if cinfo->out_color_space is not RGB (or extended RGB), hilarity will ensue. Fixes #305
DRC beefb62a 2019-01-01T20:15:25 wrbmp.c: Use IsExtRGB() macro where appropriate (to improve readability)
DRC 3d9c64e9 2019-01-01T18:57:36 tjLoadImage(): Fix int overflow/segfault w/big BMP Fixes #304
DRC 23e8e0ff 2019-01-01T18:29:55 jversion.h: Bump copyright year to 2019
DRC c868e41b 2019-01-01T14:26:48 Build: Fix regr. that nuked RPATH in Mac/iOS build Caused by 950580eb0c020598a4c6c8aa46c86e31062e1ddc. Since the code that sets CMAKE_INSTALL_RPATH now depends on ENABLE_SHARED, that code needed to be moved to after the point at which ENABLE_SHARED is defined.
DRC 0696b0a4 2019-01-01T13:55:01 Bump version to 2.0.2 to prepare for new commits
DRC aa829dcf 2018-11-20T22:52:36 Travis: Fetch GPG key from libjpeg-turbo.org I give up on the public keyserver. It inexplicably just fails sometimes. I was trying to use it out of an abundance of caution (<cough> paranoia <cough>), but it seems like most open source projects just serve up their public keys from their project web sites. The private and public pre-release keys are still stored on separate sites, the private key is still strongly encrypted by Travis, and we use a separate key for pre-releases anyhow, so even if it's compromised, we can quickly and easily deploy a new one.
DRC 43ce78e0 2018-11-15T11:54:20 Build: Fix issue with HAVE_MAPFILE test on Solaris We have to link the test code into a shared library, or else the mapfile prevents necessary libc symbols from being exposed.
DRC bb3d3256 2018-11-12T13:20:28 Travis: Try high-availability SKS keyserver pool The saga continues ...
DRC c701014d 2018-11-12T12:27:23 tjbench.c: Fix compiler warnings with GCC 8 strncpy() may fail to truncate dst if len == strlen(dst).
DRC 950580eb 2018-11-12T11:22:07 Build: Fix install error with fully static build Closes #273
DRC 2b1c9c68 2018-11-02T11:55:29 Travis: Don't check key server SSL certificate ... when downloading the RPM signing key. Apparently the key server URL sometimes redirects to an https URL, which may explain why fetching the RPM signing keys failed frequently when we used to run wget inside of the CentOS 5 Docker container.
DRC 07e304c3 2018-10-26T09:29:09 Travis: Work around frequent build failures The build will consistently fail for days at a time with: error: http://pool.sks-keyservers.net/pks/lookup?op=get&search=0x0575F26BD5B3FDB1: import read failed(-1). I have a hunch that this is related to the CentOS 5 Docker container, so this commit causes Travis to download the RPM signing key outside of the container and share it with the container.
DRC 5ea77d8b 2018-10-26T08:55:22 Android: Fix "using JNI after critical get" error We shouldn't be making JNI calls between GetPrimitiveArrayCritical() and ReleasePrimitiveArrayCritical(). Apparently Android is stricter about this than desktop Java. Issue was introduced in 0713c1bb542672257c08782a5a930a577eb20167. Fixes #300
DRC 504a295c 2018-10-11T15:13:34 Include .pc files in LJT SDKs for Visual C++ These are apparently useful in certain esoteric build environments. Closes #296
DRC d00d7d8c 2018-10-05T16:13:07 cjpeg: Fix OOB read caused by malformed 8-bit TGA ... in which one or more of the color indices is out of range for the number of palette entries. Fix partly borrowed from jpeg-9c. Fixes #295
DRC aaffc14f 2018-09-30T11:56:08 Clarify that Win7 SP0 crash was a regression
DRC d5f281b7 2018-09-28T15:46:35 SIMD: Fix c000001d exception on Win 7 w/o SP1 Apparently Windows 7 without SP1 has O/S support for XSAVE but not for YMM registers, and this exposed a bug in our usage of xgetbv. The test instruction will set ZF only if none of the bits match between the two operarands, so in effect, we were enabling AVX2 instructions if the O/S supported XSAVE and the CPU supported AVX2 but the O/S only supported XMM registers. This bug was not exposed on, for instance, Windows XP or RHEL 5 because those O/S's do not support XSAVE. Fixes #288
DRC f2729c98 2018-09-21T15:50:08 Build: Update javah target to work with JDK 10+ javah is no longer a thing, but 'javac -h' can accomplish the same task.
DRC c1f07a9f 2018-09-21T15:12:38 BUILDING.md: Correct/update Java information - CMake 3.10.x or later must be used with JDK 11, or an error ("regex not supported") will occur when CMake tries to parse the Java version number. - The JDK is no longer available at java.com.
Rosen Penev 4f943644 2018-09-04T19:17:58 Enable DSPr2 SIMD extensions if CPU type is mipsel The DSPr2 extensions have been verified to work with little endian MIPS. Whether or not CMAKE_SYSTEM_PROCESSOR is set to "mips" or "mipsel" in a little endian MIPS environment seems to be inconsistent, but our build system needs to handle both cases.
DRC 3bef88f6 2018-09-04T17:33:12 Fix MIPS DSPr2 build when using soft float ABI (for instance, when passing -msoft-float to the compiler) The instructions used by jsimd_quantize_float_dspr2() and jsimd_convsamp_float_dspr2() don't work with the soft float ABI, so disable those functions when soft float is enabled. Based on: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/272/commits/129a739bfabe1568d078eb2719691a76db128185 Closes #272
DRC 2260b66e 2018-08-31T12:55:33 jconfig.h: restore Autotools compatibility (regression introduced with the CMake-based Un*x build system) Refer to change log for more details. Based on: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/275/commits/d992d12bc7631c29ab4adc42a7c5b4273fe2d56e Closes #275
DRC a861cc2f 2018-08-31T12:54:09 Bump version to 2.0.1 to prepare for new commits
luzpaz 43c58ff9 2018-07-31T21:59:16 Correct various typos in code comments Found via `codespell -q 3` Closes #263
DRC 574f3a77 2018-07-27T11:44:46 Clarify Android Windows build instructions (must add .exe to CMAKE_C_COMPILER) Addresses a concern raised in #245, #260
DRC ad6c3161 2018-07-25T11:03:20 Bump revision to 2.0.0
DRC 8d95be3a 2018-07-24T21:16:00 Build: Don't use @rpath with OS X 10.4 builds @rpath is only supported with 10.5 and later deployment targets. libjpeg-turbo hasn't supported 10.4 "Tiger" since prior to 1.4, but I still sometimes use the 10.4 SDK to test PowerPC code in a Snow Leopard VM.
DRC a6289526 2018-07-24T18:36:51 Fix JPEG spec references per ISO/ITU-T suggestions - When referring to specific clauses, annexes, tables, and figures, a "timed reference" (a reference that includes the year) must be used in order to avoid confusion. - "CCITT" = "ITU-T" - Replace ambiguous "JPEG spec" with the specific document number.
Even Rouault 9ab569e6 2018-07-20T18:04:15 Fix int overflow when decompr. corrupt prog. JPEG No discernible performance regression Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9447 Credit to OSS Fuzz Closes #259
DRC 9c78a04d 2018-07-20T17:21:36 cjpeg: Fix OOB read caused by malformed 8-bit BMP ... in which one or more of the color indices is out of range for the number of palette entries. Fix partly borrowed from jpeg-9c. This commit also adopts Guido's JERR_PPM_OUTOFRANGE enum value in lieu of our project-specific JERR_PPM_TOOLARGE enum value. Fixes #258
DRC 0fa7850a 2018-07-20T11:30:04 Build: Preserve CMake exe suffix from cmd line Normally the value of CMAKE_EXECUTABLE_SUFFIX is clobbered by project(). This allows for specifying an executable suffix of .html with Emscripten builds, which causes Emscripten to build standalone HTML versions of the libjpeg-turbo test programs.
DRC 0c8eb5b4 2018-07-19T17:01:42 Honor CMake exe suffix when inst. static builds This specifically allows an Emscripten (WASM) static build (for which CMAKE_EXECUTABLE_SUFFIX=.js) to be properly installed.
DRC 84893085 2018-07-10T15:06:46 README.ijg: Clarification regarding JPEG 2000/XR The sentence: "Indeed, one of the original reasons for developing this free software was to help force convergence on common, interoperable format standards for JPEG files." might be seen to imply that JPEG 2000 and JPEG XR are not interoperable with themselves, although it is certainly the case that those formats are not interoperable with each other, nor with ITU T.81 | ISO/IEC 10918. They are also certainly not as common as ITU T.81 | ISO/IEC 10918, and (as an example) popular web browsers will not display JPEG 2000 files. The sentence in question was originally referring to proprietary, non-standard formats and was meant to provide historical context. libjpeg was originally released prior to the adoption of JFIF as an official standard, so it encouraged adoption of JFIF as a de facto standard by providing, under a business-friendly free software license, a library for reading and writing images in that format.
DRC f4b8a5cf 2018-07-02T11:42:06 BUILDING.md: Correct iOS/Android examples toolchain.cmake should be created in the build directory, so the scripts need to cd to that directory before generating that file. Closes #254
DRC 6d8caa9f 2018-06-29T12:45:57 Build: Detect whether compiler supports DSPr2 This is basically the same test that was performed in acinclude.m4 in the old autotools-based build system. It was not ported to the CMake-based build system because I previously had no way of testing a non-DSPr2 build environment. Fixes #248
Darrell Walisser 398c1e9a 2018-06-16T18:31:35 Fix jpeg_skip_scanlines() segfault w/merged upsamp Fixes NULL pointer reference when decompressing 4:2:2 or 4:2:0 JPEG images with cinfo.do_fancy_upsampling = FALSE. Closes #244
DRC 26f10929 2018-06-24T17:31:15 Fix infinite loop in partial image decompression ... caused by using certain specific combinations of jpeg_skip_scanlines() and jpeg_read_scanlines() calls with progressive, vertically-subsampled JPEG images. Fixes #237
DRC 43e84cff 2018-06-12T20:27:00 tjLoadImage(): Fix FPE triggered by malformed BMP In rdbmp.c, it is necessary to guard against 32-bit overflow/wraparound when allocating the row buffer, because since BMP files have 32-bit width and height fields, the value of biWidth can be up to 4294967295. Specifically, if biWidth is 1073741824 and cinfo->input_components = 4, then the samplesperrow argument in alloc_sarray() would wrap around to 0, and a division by zero error would occur at line 458 in jmemmgr.c. If biWidth is set to a higher value, then samplesperrow would wrap around to a small number, which would likely cause a buffer overflow (this has not been tested or verified.)
DRC 696e754e 2018-06-12T18:49:37 TurboJPEG: Handle JERR_BMP*,JERR_PPM* error codes ... in tjLoadImage()/tjSaveImage(). These error codes require an add-on message table, and if it isn't initialized, then format_message() produces "Bogus message code XXXX" instead.
DRC 909a8cfc 2018-06-12T16:08:26 Fix CVE-2018-11813 Refer to change log for details. Fixes #242
DRC 3041cf67 2018-05-21T22:52:39 Travis: Use SKS keyserver pool pgp.mit.edu seems to be frequently down, which was causing the PR builds to fail.
DRC 1a85fc49 2018-05-21T12:07:40 Additional code formatting tweaks ... detected with an improved version of our checkstyle script
DRC eb8bba62 2018-05-16T10:49:09 Java: Further style refinements (detected by enabling additional checkstyle modules) This commit also removes unnecessary uses of the "private" modifier in the Java tests/examples. The default access modifier disallows access outside of the package, and none of these classes is in a package. The only reason we use "private" with member variables in these classes is to make checkstyle happy, because we want it to enforce that behavior in the TurboJPEG API code.
DRC 53bb9418 2018-05-15T14:51:49 Java: Reformat code per checkstyle recommendations ... and modify tjbench.c to match the variable name changes made to TJBench.java ("checkstyle" = http://checkstyle.sourceforge.net, not our regex-based checkstyle script)
DRC 2401e4d1 2018-04-26T18:01:52 TurboJPEG: Handle CMYK JPEGs w/ subsampled M, Y Arguably it doesn't make much sense for non-chroma components to be subsampled (which is why this type of image was overlooked in cd7c3e6672cce3779450c6dd10d0d70b0c2278b2-- I didn't realize it was a thing), but certain Adobe applications apparently generate these images. Fixes #236
DRC 34e9d7e3 2018-04-26T17:33:52 Bump revision to 1.5.91 for post-beta fixes
DRC dc9bdf14 2018-04-12T17:02:10 Additional code formatting tweaks ... detected with an improved version of our checkstyle script
DRC b2d000e6 2018-04-11T10:47:16 "Further" = "Furthermore" Grammar Police. Has Ray Stevens taught me nothing?
DRC bfc3ce31 2018-04-10T15:50:22 x86[-64] SIMD: Don't auto-generate jsimdcfg.inc The old Un*x (autotools-based) build system always auto-generated this file, but that behavior was more or less a relic of the days before the libjpeg-turbo colorspace extensions were implemented. The thinking was that, if a particular developer wanted to change RGB_RED, RGB_GREEN, RGB_BLUE, or RGB_PIXELSIZE in order to compress from/decompress to different RGB pixel layouts, then the SIMD extensions should automatically respond to those changes whenever they were made to jmorecfg.h. The modern reality is that changing RGB_* is no longer necessary because of the libjpeg-turbo colorspace extensions, and changing any of the other constants in jsimdcfg.inc can't be done without making deeper modifications to the SIMD extensions. In general, we treat RGB_* as a de facto, immutable part of the legacy libpjeg API. Realistically, since the values of those constants have been the same in every Un*x distribution released in the past 20-30 years, any software that uses a system-supplied build of libjpeg must assume that those constants will have default values. Furthermore, even if it made sense to auto-generate jsimdcfg.inc, it was never possible to do so on Windows, so it was always going to be necessary to manually generate the Windows version of the file whenever any of the constants changed. This commit introduces a new custom CMake target called "jsimdcfg" that can be used, on Un*x platforms, to generate jsimdcfg.inc on demand, although this should only be necessary when introducing new x86 SIMD instructions or making other deep modifications, such as SIMD acceleration for 12-bit JPEGs. For those who may be wondering why we don't do the same thing for win/jconfig.h.in, it's because performing all of the necessary CMake checks to populate that file is very slow on Windows.
mayeut 269e84c9 2018-04-10T00:02:57 jsimd_can_encode_mcu_AC_*(): Remove useless checks These were necessary for the first iteration of the feature (see #46), which provided a different C front end for the SIMD version of the function. The final version of the feature uses a common C front end for both SIMD and non-SIMD implementations, so these checks are no longer necessary. Closes #231
DRC b628d693 2018-04-08T12:49:05 Additional code formatting tweaks ... detected with an improved version of our checkstyle script
DRC 450306a8 2018-04-06T18:31:17 READMEs: Mention that prog JPEG is now accelerated
DRC ed3c5273 2018-04-06T17:07:56 README.ijg: Wordsmith per ISO/ITU-T suggestions This commit merges the following paragraph from the latest libjpeg release: https://github.com/libjpeg-turbo/ijg/blob/jpeg-9c/README#L222-L229 which takes into account the fact that JFIF is now an official ISO/ITU-T standard. I also included the ISO/IEC document number for the JFIF spec (jpeg-9c included only the ITU-T rec number.) This commit also heavily wordsmiths the "FILE FORMAT WARS" section. In jpeg-7 and later, this section has become somewhat impolitic, referring to JPEG 2000 and JPEG XR as "faulty technologies" and "momentary mistakes." The original intent of this section, which was introduced in jpeg-5 and refined in jpeg-6 (https://github.com/libjpeg-turbo/ijg/blob/jpeg-5/README#L317-L338, https://github.com/libjpeg-turbo/ijg/blob/jpeg-6b/README#L335-L367) was to highlight the problem of JPEG file format divergence that existed in the 1990s prior to the adoption of JFIF as an official ISO/ITU-T standard. That problem is fortunately no longer a problem, thanks in part to the existence of libjpeg. I have attempted to preserve Tom's intent of using this section to describe which file formats the code is compatible with and why it isn't compatible with some file formats bearing the name "JPEG." Such modifications always put our project in a very awkward position, because we are not the IJG and do not claim to be, but it is still necessary for us to modify the IJG README file from time to time to eliminate obsolete information while attempting to remain as neutral as possible.
DRC 4a275cf0 2018-03-31T21:48:20 Fix compiler warning w/ 32-bit MSVC builds
DRC 13e4803e 2018-03-31T16:19:01 Fix build errors when C flags include -Werror Instructing the compiler to treat warnings as errors caused some of the compiler tests to fail, because the test code was not 100% clean. Note that we now use check_symbol_exists() to check for memset() and memcpy(), since the test code for check_function_exists() produces a compiler warning due to not including <string.h>.
DRC a74655af 2018-03-31T15:34:23 CMakeLists.txt: Move intrin.h header check It is more readable for this to be next to the __builtin_ctzl() check, since both are used by the accelerated progressive Huffman code.
DRC 58cb10ee 2018-03-31T13:51:31 Eliminate compiler warnings w/ Solaris Studio
kmx.io     mail     discord kmxgit v0.4.0