Log

Author Commit Date CI Message
DRC c0ca354e 2018-03-22T16:04:29 Label this release 2.0 instead of 1.6 This also pulls the formatting changes from 19c791cdac6df84418c66eb9d67cfa9703bc2461 into the TurboJPEG C API docs.
DRC 2e90ccac 2018-03-22T15:56:09 ChangeLog.md: clarification regarding AVX2
mayeut 5b177b3c 2018-03-22T11:36:43 C/SSE2 optimization of encode_mcu_AC_first() This commit adds C and SSE2 optimizations for the encode_mcu_AC_first() function used in progressive Huffman encoding. The image used for testing can be retrieved from this page: https://blog.cloudflare.com/doubling-the-speed-of-jpegtran All timings done on `Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz` clang version is `Apple LLVM version 9.0.0 (clang-900.0.39.2)` gcc-5 version is `gcc-5 (Homebrew GCC 5.5.0) 5.5.0` gcc-7 version is `gcc-7 (Homebrew GCC 7.2.0) 7.2.0` Here are the results in comparison to libjpeg-turbo@293263c using `time ./jpegtran -outfile /dev/null -progressive -optimise -copy none print_poster_0025.jpg` C clang x86_64: +19% gcc-5 x86_64: +80% gcc-7 x86_64: +57% clang i386: +5% gcc-5 i386: +59% gcc-7 i386: +51% SSE2 clang x86_64: +79% gcc-5 x86_64: +158% gcc-7 x86_64: +122% clang i386: +71% gcc-5 i386: +134% gcc-7 i386: +135% Discussion in libjpeg-turbo/libjpeg-turbo#46
mayeut 16bd9845 2018-03-02T22:33:19 C/SSE2 optimization of encode_mcu_AC_refine() This commit adds C and SSE2 optimizations for the encode_mcu_AC_refine() function used in progressive Huffman encoding. The image used for testing can be retrieved from this page: https://blog.cloudflare.com/doubling-the-speed-of-jpegtran All timings done on `Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz` clang version is `Apple LLVM version 9.0.0 (clang-900.0.39.2)` gcc-5 version is `gcc-5 (Homebrew GCC 5.5.0) 5.5.0` gcc-7 version is `gcc-7 (Homebrew GCC 7.2.0) 7.2.0` Here are the results in comparison to libjpeg-turbo@3c54642 using `time ./jpegtran -outfile /dev/null -progressive -optimise -copy none print_poster_0025.jpg` C clang x86_64: +7% gcc-5 x86_64: +30% gcc-7 x86_64: +33% clang i386: +0% gcc-5 i386: +24% gcc-7 i386: +23% SSE2 clang x86_64: +42% gcc-5 x86_64: +53% gcc-7 x86_64: +64% clang i386: +35% gcc-5 i386: +46% gcc-7 i386: +49% Discussion in libjpeg-turbo/libjpeg-turbo#46
DRC 81baa1b5 2018-03-21T13:03:30 simd/i386/jchuff-sse2.asm: Minor formatting tweak
DRC 293263c3 2018-03-17T15:14:35 Format preprocessor macros more consistently Within the libjpeg API code, it seems to be more the convention than not to separate the macro name and value by two or more spaces, which improves general readability. Making this consistent across all of libjpeg-turbo is less about my individual preferences and more about making it easy to automatically detect variations from our chosen formatting convention. I intend to release the script I'm using to validate this stuff, once it matures and stabilizes a bit.
DRC 09497c1a 2018-03-16T18:20:05 Additional code formatting tweaks Missed by previous analysis
DRC 84fbd4f1 2018-03-17T00:27:49 Merge branch 'master' into dev
DRC bd96b30b 2018-03-17T00:06:10 Make all get/putenv() calls compile-time optional * Modify the SIMD dispatchers so they guard their usage of getenv() with the existing NO_GETENV preprocessor definition. * Introduce a new NO_PUTENV preprocessor definition to guard the usage of putenv() in the TurboJPEG API library. This at least puts Windows Store compatibility within the realm of possibility, although further steps are required.
DRC 25758055 2018-03-16T20:34:18 Win installer: allow install directories w/ spaces
Cameron Cawley c7430097 2018-03-06T22:10:14 Fix build with older MinGW releases Some MinGW implementations need stdint.h in order to define SIZE_MAX. Regression caused by a09ba29a55b9a43d346421210d94370065eeaf53 and not fully fixed by a0047bdea4d11dfeefb9ea797865b1a2ea0a665e. Closes #220
DRC 29e453f7 2018-03-16T14:09:53 turbojpeg.c: Fix Windows build Broken by previous commit. Although turbojpeg.c no longer needs tjutil.h on Un*x, it still needs to include that file on Windows in order to use snprintf() and strcasecmp() (which, on Windows, are macros that wrap _snprintf_s() and stricmp().)
DRC a4da0750 2018-03-16T02:16:41 Merge branch 'master' into dev
DRC 19c791cd 2018-03-08T10:55:20 Improve code formatting consistency With rare exceptions ... - Always separate line continuation characters by one space from preceding code. - Always use two-space indentation. Never use tabs. - Always use K&R-style conditional blocks. - Always surround operators with spaces, except in raw assembly code. - Always put a space after, but not before, a comma. - Never put a space between type casts and variables/function calls. - Never put a space between the function name and the argument list in function declarations and prototypes. - Always surround braces ('{' and '}') with spaces. - Always surround statements (if, for, else, catch, while, do, switch) with spaces. - Always attach pointer symbols ('*' and '**') to the variable or function name. - Always precede pointer symbols ('*' and '**') by a space in type casts. - Use the MIN() macro from jpegint.h within the libjpeg and TurboJPEG API libraries (using min() from tjutil.h is still necessary for TJBench.) - Where it makes sense (particularly in the TurboJPEG code), put a blank line after variable declaration blocks. - Always separate statements in one-liners by two spaces. The purpose of this was to ease maintenance on my part and also to make it easier for contributors to figure out how to format patch submissions. This was admittedly confusing (even to me sometimes) when we had 3 or 4 different style conventions in the same source tree. The new convention is more consistent with the formatting of other OSS code bases. This commit corrects deviations from the chosen formatting style in the libjpeg API code and reformats the TurboJPEG API code such that it conforms to the same standard. NOTES: - Although it is no longer necessary for the function name in function declarations to begin in Column 1 (this was historically necessary because of the ansi2knr utility, which allowed libjpeg to be built with non-ANSI compilers), we retain that formatting for the libjpeg code because it improves readability when using libjpeg's function attribute macros (GLOBAL(), etc.) - This reformatting project was accomplished with the help of AStyle and Uncrustify, although neither was completely up to the task, and thus a great deal of manual tweaking was required. Note to developers of code formatting utilities: the libjpeg-turbo code base is an excellent test bed, because AFAICT, it breaks every single one of the utilities that are currently available. - The legacy (MMX, SSE, 3DNow!) assembly code for i386 has been formatted to match the SSE2 code (refer to ff5685d5344273df321eb63a005eaae19d2496e3.) I hadn't intended to bother with this, but the Loongson MMI implementation demonstrated that there is still academic value to the MMX implementation, as an algorithmic model for other 64-bit vector implementations. Thus, it is desirable to improve its readability in the same manner as that of the SSE2 implementation.
DRC d45434fe 2018-03-16T02:13:03 usage.txt: Remove Alt-Space non-ASCII character
DRC 4508ab3e 2018-03-13T10:54:57 Fix build when RGB_{RED,GREEN,BLUE}!={0,1,2} Broken by aa7459050d7a50e1d8a99488902d41fbc118a50f
DRC 87bc8721 2018-03-05T12:50:19 Travis: OS X official builds now use YASM Because 367a838626576b4ff2a47cbd5a494199b800dc48
DRC 33ce0b5e 2018-03-01T10:38:17 Loongson MMI SIMD extensions Based on: https://github.com/zhuchen1911/libjpeg-turbo/commit/42aff4497bdaca3258279cafc74511e3c25454b8 Closes #158
DRC 35ed3c97 2018-02-28T16:24:03 SIMD: Formatting tweaks + remove unnecessary code + "JSIMD_ARM_NEON" = "JSIMD_NEON" + "JSIMD_MIPS_DSPR2" = "JSIMD_DSPR2" + "*_mips_dspr2" = "*_dspr2" It's obvious that "NEON" refers to Arm and "DSPr2" refers to MIPS, and this naming convention is consistent with the other SIMD extensions.
DRC 3c54642c 2018-02-27T11:36:43 Fix iOS/ARM[-64] build w/ newer versions of CMake Newer versions of CMake (known to be the case with 3.7.x and 3.10.x) fail to add a space between CMAKE_C_FLAGS and CMAKE_ASM_FLAGS, which causes the build to fail when using the official build procedure. Closes #216
DRC 367a8386 2018-02-26T19:41:59 Make SIMD syms private for x86[-64]/Mach-O builds ... if building with YASM. NASM doesn't currently support the necessary directives. Closes #212
DRC 7c2bfdb0 2018-02-26T18:43:40 Merge branch 'master' into dev Closes #214
mayeut 0dd9a2c1 2018-02-24T14:50:56 Fix Win64 ABI conformance when using xmm8-xmm11 Referring to https://docs.microsoft.com/en-US/cpp/build/stack-usage: "All memory beyond the current address of RSP is considered volatile: The OS, or a debugger, may overwrite this memory during a user debug session, or an interrupt handler. Thus, RSP must always be set before attempting to read or write values to a stack frame." Basically, if-- under extremely rare circumstances-- a context swap were to occur between saving the values of xmm8-xmm11 and setting the new value of rsp, the O/S might not preserve that area of the stack. In general, libjpeg-turbo should not be using xmm8-xmm11 before or after the call to jsimd_huff_encode_one_block_sse2(), so this is probably a non-issue, but it's still a good idea to fix it. Based on https://github.com/mayeut/libjpeg-turbo/commit/ff7d2030dd26c7b8c37ff540c594490198843f15
Matthieu Darbois 32eaeeac 2018-02-24T18:00:51 Fix BUILDING.md buglet ("--mfloat-abi=softfp") (Introduced with the build system overhaul) Closes #215
mayeut 4c4dc614 2018-02-24T12:07:34 Fix Win64 ABI conformance issue in AVX2 ISLOW IDCT xmm8-xmm11 must be saved and restored, since the function uses ymm8-ymm11. Closes #211
mayeut feaec37d 2018-02-24T14:20:59 Fix build with YASM vinserti128 requires all operands to be specified
mayeut b6909ab3 2018-02-24T00:02:27 Make SIMD symbols private for MIPS ELF builds Closes #210
mayeut 9bef5df7 2018-02-23T23:31:02 Make SIMD symbols private for iOS ARM/ARM64 builds
mayeut 88421563 2018-02-23T21:56:32 Make SIMD symbols private for x86[-64] ELF builds
DRC 9cdec16c 2018-02-23T13:58:24 32-bit AVX2 implementation of slow int inverse DCT
DRC 845fe8bf 2018-02-23T12:24:10 32-bit AVX2 buglet: IS_ALIGNED_SSE=IS_ALIGNED_AVX
DRC de9e9db6 2018-02-23T11:50:11 64-bit AVX2 implementation of slow int inverse DCT
DRC 715b7c38 2018-02-17T22:15:58 32-bit AVX2 implementation of int sample conv.
DRC ca387e7f 2018-02-17T20:31:30 32-bit AVX2 implementation of slow int forward DCT
DRC 39e9e65c 2018-02-17T19:39:53 64-bit AVX2 implementation of int sample conv.
DRC 264dd42a 2018-02-17T17:32:25 64-bit AVX2 implementation of slow int forward DCT
DRC ff392d81 2018-02-17T17:29:38 AVX2: Introduce YMMBLOCK macro for readability
DRC 37bae1a0 2018-02-14T17:22:00 Prog Huff enc: bit count/branchless abs val opts Ported from baseline Huffman encoder. This improves overall compression performance by ~3-9% in my testing.
DRC 985ef4f9 2018-02-14T14:50:04 Merge branch 'master' into dev
Ben Boeckel 700de8aa 2018-02-14T15:41:36 README.md: Fix permissions
DRC 4e240795 2018-02-13T16:34:21 Merge branch 'master' into dev
DRC d4859558 2018-02-13T16:14:03 Fix dithering bug in merged 4:2:0/RGB565 algorithm d0 should always be used for the first row, and d1 should always be used for the second row. Addresses concerns raised in #95, #81.
DRC 289014d4 2018-01-05T12:05:43 Merge branch 'master' into dev
Stephen 3847f911 2018-01-03T07:56:12 Travis/OS X: Use 'brew bundle' + Brewfile This ensures that the build script will not fail if the Homebrew dependencies are already installed.
DRC bd544e28 2017-12-16T09:34:28 Merge branch 'master' into dev
DRC 0e2bca07 2017-12-15T20:37:02 jdarith.c: Fix two signed integer overflows I guess I have to fix these, or Google Autofuzz is going to keep bugging me about them. Fixes #171 Fixes #197 Fixes #198
DRC 0fba3c19 2017-12-15T20:05:58 Bump version to 1.5.4 to prepare for new commits
DRC 7d3feda7 2017-12-15T16:45:25 BUILDING.md: Adjust Android recipes for NDK r16+ NDK r16b moved some things around, so modify the Android build recipes to take that into account while preserving compatibility with previous NDK releases. NOTE: the GCC 4.9 NDK toolchain is deprecated, so we will need to develop new Android build recipes for libjpeg-turbo 1.6 that use the Clang toolchain. Closes #196
DRC bf6c7743 2017-12-07T19:29:42 Fix whitespace errors
DRC afdd7999 2017-12-06T12:20:24 Merge branch 'master' into dev + acknowledge 1.5.3 release
DRC c308d434 2017-12-06T11:59:04 jpeg_crop_scanlines: Handle gray images w/ samp!=1 Since the sampling factor has no meaning for single-component images, the decompressor ignores it, and jpeg_crop_scanlines() should as well. Fixes #195
DRC 773040f9 2017-12-05T15:27:34 Fix lib state when skipping to end of 1-scan image If jpeg_skip_scanlines() is used to skip to the end of a single-scan image, then we need to change the library state such that subsequent calls to jpeg_consume_input() will return JPEG_REACHED_EOI rather than JPEG_SUSPENDED. (NOTE: not necessary for multi-scan images, since the scans are processed prior to any call to jpeg_skip_scanlines().) Unless I miss my guess, using jpeg_skip_scanlines() in this manner will prevent any markers at the end of the JPEG image from being read, but I don't think there is any way around that without actually reading the data, which would defeat the purpose of jpeg_skip_scanlines(). Fixes #194
DRC c05d1249 2017-11-29T14:36:39 Merge branch 'master' into dev
DRC a831b5a9 2017-11-29T14:23:31 Travis: Work around xcode7.3 image bug Refer to travis-ci/travis-ci#8552. This was supposed to be fixed on November 15, then on November 28. Travis blew through both deadlines, so I have no confidence that the issue will be fixed as promised in a timely manner. Adding 'brew update' to .travis.yml slows the OS X build, but there is no choice at the moment.
DRC 9f1f86bf 2017-11-19T09:18:36 tjLoadImage(): Fix OOB array access w/TJPF_UNKNOWN Because the previous commit added a test for TJPF_UNKNOWN to tjunittest, the ASAN CI build detected this issue.
DRC e817c077 2017-11-19T08:43:07 tjLoadImage(): return TJPF_GRAY for grayscale BMPs ... if *pixelFormat=TJPF_UNKNOWN is passed to the function.
DRC 479fa1d8 2017-11-18T11:33:05 tjLoadImage(): Don't convert RGB to grayscale Loading RGB image files into a grayscale buffer isn't a particularly useful feature, given that libjpeg-turbo can perform this conversion much more optimally (with SIMD acceleration on some platforms) during the compression process. Also, the RGB2GRAY() macro was not producing deterministic cross-platform results because of variations in the round-off behavior of various floating point implementations, so `tjunittest -bmp` was failing in i386 builds.
DRC 8c40ac8a 2017-11-16T18:46:01 Add TurboJPEG C example and clean up Java example Also rename example.c --> example.txt and add a disclaimer to that file so people will stop trying to compile it.
DRC dc4b9002 2017-11-16T20:43:12 TurboJPEG: Add alpha offset array/method Also, set the red/green/blue offsets for TJPF_GRAY to -1 rather than 0. It was undefined behavior for an application to use those arrays/methods with TJPF_GRAY anyhow, and this makes it easier for applications to programmatically detect whether a given pixel format has red, green, and blue components.
DRC aa745905 2017-11-16T18:09:07 TurboJPEG C API: Add BMP/PPM load/save functions The main justification for this is to provide new libjpeg-turbo users with a quick & easy way of developing a complete JPEG compression/decompression program without requiring them to build libjpeg-turbo from source (which was necessary in order to use the project-private bmp API) or to use external libraries. These new functions build upon significant enhancements to rdbmp.c, wrbmp.c, rdppm.c, and wrppm.c which allow those engines to convert directly between the native pixel format of the file and a pixel format ("colorspace" in libjpeg parlance) specified by the calling program. rdbmp.c and wrbmp.c have also been modified such that the calling program can choose to read or write image rows in the native (bottom-up) order of the file format, thus eliminating the need to use an inversion array. tjLoadImage() and tjSaveImage() leverage these new underlying features in order to significantly improve upon the performance of the old bmp API. Because these new functions cannot work without the libjpeg-turbo colorspace extensions, the libjpeg-compatible code in turbojpeg.c has been removed. That code was only there to serve as an example of how to use the TurboJPEG API on top of libjpeg, but more specific, buildable examples now exist in the https://github.com/libjpeg-turbo/ijg repository.
DRC 087ec126 2017-11-15T20:50:53 tjbenchtest: Test new TurboJPEG progressive flag
DRC cd8a1258 2017-11-15T09:19:27 Build: Fix 'tjtest' target on Windows tjbenchtest and its Java derivatives are useful for rooting out hidden problems with the more esoteric TJBench and TurboJPEG features. For instance, on Windows, running tjbenchtest uncovered 5fce2e942136cb70e5a30ff15a2d58b07947aa84. This commit also causes tjbenchtest and tjbenchtest.java to append -yuv and -alloc to their log file names, depending on the arguments passed, and it causes the build system to clean up those log files when the 'testclean' target is built.
DRC 4893e5d8 2017-11-17T19:00:53 Merge branch 'master' into dev
DRC 19b393b6 2017-11-17T18:45:08 TJExample: Fix array index OOB w/ 4:1:1 JPEG input
DRC 9d9d8fe6 2017-11-17T18:15:42 Code formatting tweaks
DRC 78e97e38 2017-11-15T19:39:45 Uniquify tjbenchtest log file names based on args + clean up log files when 'make testclean' is invoked + fix 'tjbenchtest -yuv -alloc' + fix tjexampletest so that it creates images under /tmp + clean up tjexampletest
DRC 468f2fed 2017-11-15T19:33:06 TJExample.java: Don't ignore mistyped args
DRC 5abf2536 2017-11-14T16:12:13 Doc tweak: TJFLAG_ACCURATEDCT is the first flag
DRC 5fce2e94 2017-11-14T15:30:06 tjbench.exe: Fix decompression access violation The program crashed when a JPEG image was passed on the command line, because we were mixing our metaphors vis-a-vis malloc()/free() and tjAlloc()/tjFree() (malloc()/free() uses the tjbench.exe heap, whereas tjAlloc()/tjFree() uses the turbojpeg.dll heap.)
DRC 907dd683 2017-11-13T21:46:07 ChangeLog.md: buglet
DRC f008876c 2017-11-13T21:24:05 Build: Fix `make dist` Broken by previous commit
DRC 5bc43c78 2017-11-13T21:01:53 Further partial image decompression fixes - Referring to 073b0e88a192adebbb479ee2456beb089d8b5de7 and #185, the reason why BMP and RLE didn't (and won't) work with partial image decompression is that the output engines for both formats maintain a whole-image buffer, which is used to reverse the order of scanlines. However, it was straightforward to add -crop support for GIF and Targa, which is useful for testing partial image decompression along with color quantization. - Such testing reproduced a bug reported by Mozilla (refer to PR #182) whereby jpeg_skip_scanlines() would segfault if color quantization was enabled. To fix this issue, read_and_discard_scanlines() now sets up a dummy quantize function in the same manner that it sets up a dummy color conversion function. Closes #182
DRC f3ad13e3 2017-11-13T16:00:35 TJBench/TJUnitTest: Don't ignore mistyped args
DRC 94e152b1 2017-11-13T08:15:50 TurboJPEG C: Code formatting tweaks
DRC 073b0e88 2017-11-08T21:01:57 djpeg -crop: Exit gracefully with non-PPM formats ... and document that only PPM/PGM output images are supported with the -crop option for the moment. I investigated the possibility of supporting -crop with -bmp, but even after resetting the buffer dimensions, I still kept getting virtual array access errors. It seems that doing this the "right way" would require creating a re-initialization function for each image format's destination manager. I'm disinclined to do that right now, given that this feature was Google's baby (developed as a prerequisite for including libjpeg-turbo in Android), and the -crop option in djpeg is intended only as an example of how to use the partial image decompression API. Real-world applications would need to handle this in their own destination managers. It would probably be possible to make this work with Targa by employing a similar hack to the one we used with PPM, but Targa isn't popular enough to bother. Fixes #185
DRC 616b4e2d 2017-09-20T19:55:54 TurboJPEG C: Compiler warnings Introduced in b9ab64d8dbee2db829e59357d335c151680f44f0.
DRC 3d72522a 2017-09-20T18:11:03 SRPM build: Define _libdir based on build arch Setting _libdir to CMAKE_INSTALL_FULL_LIBDIR only works when doing an in-tree RPM build. SRPMs are architecture-agnostic, so the spec needs to compute_libdir at the time the SRPM is rebuilt, not at the time it is generated. This is a regression introduced when implementing the new CMake-based cross-platform build system.
DRC f0dd80f2 2017-09-20T17:13:46 Merge branch 'master' into dev
DRC 1b385f37 2017-09-20T16:52:48 Prevent "unmappable character" error in Java build This was causing the build to fail when rebuilding libjpeg-turbo from a source RPM.
DRC fd778bba 2017-09-19T20:01:34 Fix PowerPC 32-bit RPM build
DRC 8d403aeb 2017-09-19T13:03:49 Fix 32-bit RPM build w/ newer RHEL/Fedora releases The version of RPM on RHEL 5 and older platforms defines _libdir as %{_exec_prefix}/%{_lib}, so defining _lib in the spec file redefined _libdir. However, newer versions of RPM (probably >= 4.6, since that was the version that introduced the ISA macros) define _libdir as either %{_prefix}/lib or %{_prefix}/lib64. Thus, we need to explicitly override _libdir in our spec file.
DRC 01b74c10 2017-09-11T10:06:22 Packaging: Use parallel make when rebuilding SRPM
DRC db0dec3c 2017-09-11T09:48:33 Travis: Limit parallel make jobs to # of CPU cores This tends to be faster than 'make -j', since it is making more wise use of the available resources.
nyg ba6e9d8a 2017-09-05T18:23:04 wrjpgcom: Fix comment typo Comment was copied/pasted from skip_variable() without making the necessary modifications.
DRC 7106ffe5 2017-09-02T04:20:03 Merge branch 'master' into dev
DRC 5426a4cb 2017-09-02T04:08:06 TJUnitTest: Usage formatting tweaks
DRC d0bac69a 2017-09-02T03:40:46 Java: Fix TJUnitTest on big endian platforms It is necessary for the C code to be aware of the machine's endianness, which is why the TurboJPEG Java wrapper sets a different pixel format for integer BufferedImages depending on ByteOrder.nativeOrder(). However, it isn't necessary to handle endianness in pure Java code such as TJUnitTest (d'oh!) This was a product of porting the C version of TJUnitTest too literally, and of insufficient testing (historically, the big endian systems I had available for testing didn't have Java.)
DRC 59322e09 2017-09-01T21:57:48 Build: Change ppc64le DEB arch to ppc64el This is the convention among Debian-based distros.
DRC 51cc89fa 2017-09-01T09:02:55 Merge branch 'master' into dev
DRC 4ded4dfa 2017-09-01T09:01:00 Build: Fix AltiVec detection on OS X Leopard The ability to directly access elements of an AltiVec vector is apparently a more recent thing.
DRC 1d935416 2017-09-01T13:52:21 Build: Use -maltivec when testing AltiVec support Doesn't seem to be necessary with recent Linux/GCC configurations, but it is definitely necessary with OS X.
DRC c0f3512d 2017-08-31T20:57:19 Merge branch 'master' into dev
DRC 02fa8f24 2017-09-01T01:10:08 Fix build on PowerPC SPE systems SPE systems don't support AltiVec instructions. Fixes #172
DRC 32120054 2017-08-14T10:54:27 Java: Fix NullPointerException in YUVImage planes == null is a valid argument to setBuf() if alloc == true, so we need to make sure that planes is non-null before validating its length. We also need to allocate one dimension of the planes array if it's null. Fixes #168
DRC 14783612 2017-08-14T11:18:35 Bump version to 1.5.3 to prepare for new commits
DRC e5c1613c 2017-07-07T15:15:19 x86: Fix "short jump is out of range" w/ NASM<2.04
DRC c9453121 2017-06-29T16:49:09 TJBench: Recover from non-fatal errors if possible Previously, -stoponwarning only had an effect on the underlying TurboJPEG C functions, but TJBench still aborted if a non-fatal error occurred. This commit modifies the C version of TJBench such that it always recovers from a non-fatal error unless -stoponwarning is specified. Furthermore, the benchmark stores the details of the last non-fatal error and does not print any subsequent non-fatal error messages unless they differ from the last one. Due to limitations in the Java API (specifically, the fact that it cannot communicate errors, fatal or otherwise, to the calling program without throwing a TJException), it was only possible to make decompression operations fully recoverable within TJBench. With other operations, -stoponwarning still has an effect on the underlying C library but has no effect at the Java level. The Java API documentation has been amended to reflect that only certain methods are truly recoverable, regardless of the state of TJ.FLAG_STOPONWARNING.
DRC 9baef107 2017-06-29T12:08:02 TurboJPEG: Don't make STOPONWARNING persistent Due to an oversight in d4092f6b4dd94c64864662987b070d517c399490, the state of TJFLAG_STOPONWARNING persisted beyond the function it was passed to.
DRC dadebcd7 2017-06-28T11:43:08 TurboJPEG: Add "copy none", progressive xform opts Allow progressive entropy coding to be enabled on a transform-by-transform basis, and implement a new transform option for disabling the copying of markers. Closes #153
DRC dedce66e 2017-06-28T15:30:41 Merge branch 'master' into dev