Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / libjpeg-turbo / db6d8fca591c924ba3da8ef525925b92e261e66a
  1. db6d8fc Now that the TurboJPEG API is reporting libjpeg warnings as errors, an "Invalid SOS parameters for sequential JPEG" warning surfaced in tjDecodeYUV*(). This was caused by the Se member of jpeg_decompress_struct being set to 0 (it is normally set to a non-zero value when the start-of-scan markers are read, but there are no SOS markers in this case, because we're not actually decompressing a JPEG file.) by DRC · 9 years ago
  2. f15ef33 Fix a segfault that occured in the MIPS DSPr2 fancy upsampling routine when downsampled_width==3. Because the DSPr2 code unrolls the loop for the middle columns (refer to jdsample.c), it has the effect of performing two column iterations, and that only works properly if the number of columns (minus the first and last) is >= 2. For the specific case of downsampled_width==3, this patch skips to the second iteration of the unrolled column loop. by DRC · 9 years ago
  3. 1f79c7c If a warning (such as "Premature end of JPEG file") is triggered in the underlying libjpeg API, make sure that the TurboJPEG API function returns -1. Unlike errors, however, libjpeg warnings do not make the TurboJPEG functions abort. by DRC · 9 years ago
  4. bec45b1 Back out r1555 and r1548. Using setenv() didn't fix the iOS simulator issue. It just replaced an undefined _putenv$UNIX2003 symbol with an undefined _setenv$UNIX2003 symbol. The correct solution seems to be to use -D_NONSTD_SOURCE when generating our official builds. by DRC · 10 years ago
  5. 80bbd39 Fix the Windows build. I remember now why I used putenv() originally-- because Windows doesn't have setenv(). We could use _putenv_s(), but older versions of MinGW don't have that either. Fortunately, since all of the environment values we're setting in turbojpeg.c are static, we can just map setenv() to putenv() using a macro. NOTE: we still have to use _putenv_s() in turbojpeg-jni.c, but at least people who may need to build with an older version of MinGW can still do so by disabling the Java build. by DRC · 10 years ago
  6. 665c96e Allow building only static or only shared libraries on Windows by DRC · 10 years ago
  7. 3ebcc32 __WORDSIZE doesn't seem to be available on platforms other than Mac or Linux, and best practices are for user-level code not to rely on it anyhow, since it's meant to be an internal macro. Fortunately, autoconf already has a way of determining the word size at configure time, so it can be passed into the compiler. This should work on any platform and has been tested on all of the Un*x platforms we support (Linux, Mac, FreeBSD, Solaris.) by DRC · 10 years ago
  8. 44320a2 Unless you define _ANSI_SOURCE, then putenv() on Mac is renamed to putenv$UNIX2003(), and this causes problems when trying to link an i386 iOS application (for the simulator) against the TurboJPEG static library. It's easiest to just use setenv() instead. by DRC · 10 years ago
  9. a8b6ea2 Fix a bug in the 64-bit Huffman encoder that Google discovered when encoding some very specific (and proprietary) aerial images using quality=98, an optimized Huffman table, and the ISLOW DCT. These images were causing the Huffman bit buffer to overflow, because the code for encoding the DC coefficient was using the equivalent of the 32-bit version of EMIT_BITS(). Thus, when 64-bit code was used, the DC coefficient code was not properly checking how many bits were in the buffer before attempting to add more bits to it. This issue appears to have existed in all versions of libjpeg-turbo. by DRC · 10 years ago
  10. 96869f4 Restore backward compatibility with MSVC < 2010 (broken by r1541) by DRC · 10 years ago
  11. f64b36f Oops. OS X doesn't define __WORDSIZE unless you include stdint.h, so apparently the Huffman codec hasn't ever been fully accelerated on 64-bit OS X. by DRC · 10 years ago
  12. 89a3f97 Allow the executables and libraries outside of the sharedlib/ directory to be linked against msvcr*.dll instead of libcmt*.lib. This is reported to be necessary when building libjpeg-turbo for use with C#. by DRC · 10 years ago
  13. feccdcf Surround the usage of getenv() in the TurboJPEG API with #ifndef NO_GETENV so that developers can add -DNO_GETENV to the C flags when building for platforms that don't have getenv(). Currently this is known to be necessary when building for Windows Phone. by DRC · 10 years ago
  14. c69a1cd If libjpeg-turbo is configured with a non-default prefix, such as /usr, then use the docdir variable defined by autoconf 2.60 and later, if available. This will, for instance, install the documentation under /usr/share/doc/libjpeg-turbo by default if prefix=/usr, unless docdir is overridden. When using earlier versions of autoconf, docdir is set to ${datadir}/doc, as it always has been. by DRC · 10 years ago
  15. 3b7015d Enable silent build rules for the NASM objects, if the source is configured with automake 1.11 or later. NOTE: the build still spits out "error: ignoring unknown tag NASM" for each object, but unfortunately, if we remove "--tag NASM" from the command line, the build breaks under older versions of automake (it aborts with "unable to infer tagged configuration.") by DRC · 10 years ago
  16. cab2a85 Set the RPM and deb architecture properly on non-x86 platforms. by DRC · 10 years ago
  17. eb319ed Come on, Cohaagen, you got what you want. Give these people air! by DRC · 10 years ago
  18. dcf9f15 Oops. Need to set the alpha channel when using TYPE_4BYTE_ABGR*. This has no bearing on the actual tests, but it prevents the PNG pre-encode reference images for those tests from being blank. by DRC · 10 years ago
  19. 8b5a009 Oops. The MIPS SIMD implementations of h2v1 and h2v2 upsampling were not checking for DSPr2 support, so running 'djpeg -nosmooth' on a non-DSPr2-enabled platform caused an "illegal instruction" error. by DRC · 10 years ago
  20. 0e94025 Introduce fast paths to speed up NULL color conversion somewhat, particularly when using 64-bit code; on the decompression side, the "slow path" also now use an approach similar to that of the compression side (with the component loop outside of the column loop rather than inside.) This is faster when using 32-bit code. by DRC · 10 years ago
  21. c60d662 Some clarifications (actually MIPS doesn't implement the float DCT/IDCT using SIMD instructions) by DRC · 10 years ago
  22. 3af282d Make the floating point regression tests optional. It has been known for quite some time that these tests do not always generate the same results unless there is full SIMD coverage of the floating point algorithms in libjpeg-turbo. Further research reveals that there are basically three expected results: the results from our SSE SIMD extensions (which are slightly more accurate than the C code), results from the C code when running on a 32-bit FPU (or when using SSE instructions on an x86-64 CPU, which is the default with GCC), and results from the C code when running on a 64-bit FPU (which presumably uses double-precision arithmetic by default.) There is basically no way to determine which type of math will be used prior to run time, so it's best to just let the developers specify which result they expect on their particular system. by DRC · 10 years ago
  23. dd7f03b In the process of developing the AltiVec extensions, it was discovered that the normal regression tests aren't sufficient to test the behavior of the library with very small image sizes and when compressing from/decompressing to a subregion of a larger image buffer. Thus, an additional regression test was added that takes advantage of the tiled compression/decompression feature in tjbench. This is being back-ported to the 1.4.x branch primarily to verify that there are no lingering issues in the existing SIMD extensions. by DRC · 10 years ago
  24. cbc4b53 Add separate pseudo-targets for the TurboJPEG and libjpeg regression tests, for those times when you just don't want to sit through 11 iterations of TJUnitTest to find out that your algorithm is broken. by DRC · 10 years ago
  25. ffd9d05 Bump copyright year by DRC · 10 years ago
  26. cbc9970 Add the ability to benchmark YCCK JPEG compression/decompression. This is particularly useful since that is the only way to test the performance of the "plain" upsampling routines, which are accelerated on some platforms. by DRC · 10 years ago
  27. 2b7a391 1.4.1 by DRC · 10 years ago
  28. 8f7f49a by DRC · 10 years ago
  29. c4930d8 Oops. Delete the duplicate copy of [lib]turbojpeg.dll in the binary directory when uninstalling the package. by DRC · 10 years ago
  30. d51e6c2 Document that the ARMv8/iOS issues are now fixed by DRC · 10 years ago
  31. 6842c7c Remove reference to install.txt, which we do not include from the IJG distribution by DRC · 10 years ago
  32. 6e6b28c Include ARMv8 binaries when generating a combined OS X/iOS package using 'make iosdmg' by DRC · 10 years ago
  33. b9c4b58 In the output of the configure script, indicate whether gas-preprocessor.pl is being used along with the assembler. by DRC · 10 years ago
  34. 62999d7 Modify the ARM64 assembly file so that it uses only syntax that the clang assembler in XCode 5.x can understand. These changes should all be cosmetic in nature-- they do not change the meaning or readability of the code nor the ability to build it for Linux. Actually, the code is now more in compliance with the ARM64 programming manual. In addition to these changes, there were a couple of instructions that clang simply doesn't support, so gas-preprocessor.pl was modified so that it now converts those into equivalent instructions that clang can handle. by DRC · 10 years ago
  35. ceb552a Add iOS architectures to the shared libraries generated by the Mac/iOS packaging system. I have no idea how useful this is for "standard" iOS application development, but it is useful in a jailbreak environment, and iOS 8 supposedly allows shared libs in "official" apps as well. by DRC · 10 years ago
  36. e59196d 1.4.0 by DRC · 10 years ago
  37. 3f764b7 Fix 'make dist' by DRC · 10 years ago
  38. 4c773cf Fix typos in test names by DRC · 10 years ago
  39. a29d6b4 Remove unused code by DRC · 10 years ago
  40. b329697 Fix build when INPUT_SMOOTHING_SUPPORTED is undefined by DRC · 10 years ago
  41. 2a6b831 Some software also needs the FAR macro. Ugh. Also wordsmithing. by DRC · 10 years ago
  42. e2dd3e3 Restore the JPP() and JMETHOD() macros. Even though libjpeg-turbo doesn't use them anymore, other software apparently does: by DRC · 10 years ago
  43. 0f4469c Oops. Include the tjPlane*() functions in the mapfile so that they are exposed in the shared library on ELF systems. by DRC · 10 years ago
  44. 402a715 Fix Huffman local buffer overrun discovered by Debian developers when attempting to transform a junk image using ImageMagick: by DRC · 10 years ago
  45. 306add8 Fix whitespace issues introduced with previous commit. by DRC · 10 years ago
  46. 9665f5e Print the library version and exit whenever -version is passed to cjpeg, djpeg, or jpegtran. by DRC · 10 years ago
  47. ea1eea4 Sometimes the sampling factors in grayscale images can be > 1 (for instance, if compressing using 'cjpeg -sample 2x2 -grayscale'.) Technically, sampling factors have no meaning with grayscale JPEGs, and the libjpeg decompressor ignores them in that case. Thus, the TurboJPEG decompressor should ignore them as well. by DRC · 10 years ago
  48. 3ebcf7c Make TJCompressor.close() and TJDecompressor.close() idempotent by DRC · 10 years ago
  49. 803b5d2 Uses clz and bsr instructions for bit counting on ARM64 platforms as well. by DRC · 10 years ago
  50. eca0637 Remove trailing spaces by DRC · 10 years ago
  51. 55620c6 Another oops. tjBufSizeYUV2() should return -1 if width < 1. by DRC · 10 years ago
  52. 2240974 Oops. tjPlaneSizeYUV() should return -1 if componentID > 0 and subsamp==TJSAMP_GRAY. by DRC · 10 years ago
  53. bbd9b71 When building libjpeg-turbo on Un*x systems, INT32 is usually typedef'ed to long, not int, so we need to specify an int pointer when doing a 4-byte write to the RGB565 output buffer. On little endian systems, this doesn't matter, but when you write a 32-bit int to a 64-bit long pointer address on a big endian system, you are writing to the upper 4 bytes, not the lower 4 bytes. NOTE: this will probably break on big endian systems that use 16-bit ints (are there any of those still around?) by DRC · 10 years ago
  54. 1d4c51a Fix Windows build by DRC · 10 years ago
  55. 72a3cc0 Fix issues with RGB565 color conversion on big endian machines. The RGB565 routines are now abstracted in a separate file, with separate little-endian and big-endian versions defined at compile time through the use of macros (this is similar to how the colorspace extension routines work.) This allows big-endian machines to take advantage of the same performance optimizations as little-endian machines, and it retains the performance on little-endian machines, since the conditional branch for endianness is at a very coarse-grained level. by DRC · 10 years ago
  56. eb8d096 Fix build on OS X PowerPC platforms by DRC · 10 years ago
  57. 339589f Fix build on OS X PowerPC platforms by DRC · 10 years ago
  58. fe77fa2 Oops. Forgot to alter the version header in the change log to indicate the release of 1.4 beta. by DRC · 10 years ago
  59. 88b6c97 Create 1.4.x branch by DRC · 10 years ago
  60. 0a9a252 Rename the ARM64 assembly file to match the C file by DRC · 10 years ago
  61. de26249 Fix several mathematical issues discovered in the ARM64 NEON code while running the extended regression tests introduced in r1267. Specific comments can be found in the original patches: by DRC · 10 years ago
  62. a6efae1 Reformat code per Siarhei's original patch (to clearly indicate that the offset instructions are completely independent) and add Siarhei as an individual author (he no longer works for Nokia.) by DRC · 10 years ago
  63. e947139 Clarify forward compatibility of iOS/ARM builds by DRC · 10 years ago
  64. bdc7650 ARM64 NEON SIMD support for YCC-to-RGB565 conversion by DRC · 10 years ago
  65. d729f4d ARM NEON SIMD support for YCC-to-RGB565 conversion, and optimizations to the existing YCC-to-RGB conversion code: by DRC · 10 years ago
  66. eb66974 Ensure that tjFree() is used for any JPEG buffers that might have been dynamically allocated by the compress/transform functions. To keep things simple, we use tjAlloc() for the statically-allocated buffer as well, so that tjFree() can always be used to free the buffer, regardless of whether it was allocated by tjbench or by the TurboJPEG library. This fixes crashes that occurred on Windows when running tjunittest or tjbench with the -alloc flag. by DRC · 10 years ago
  67. f5644c3 Ensure that tjFree() is used for any JPEG buffers that might have been dynamically allocated by the compress/transform functions. To keep things simple, we use tjAlloc() for the statically-allocated buffer as well, so that tjFree() can always be used to free the buffer, regardless of whether it was allocated by tjbench or by the TurboJPEG library. This fixes crashes that occurred on Windows when running tjunittest or tjbench with the -alloc flag. by DRC · 10 years ago
  68. 55e328e Revert r1335 and r1336. It was a valiant effort, but on Windows, xmm8-xmm15 are non-volatile, and the overhead of pushing them onto the stack at the beginning of each function and popping them at the end was causing worse performance (in the neighborhood of 3-5%) than just using the work areas and limiting the register usage to xmm0-xmm7. Best to leave the SSE2 code alone. We can optimize the register usage for AVX2, once that port takes place. by DRC · 10 years ago
  69. 3d51898 Don't use sudo when building a Debian package unless the user is non-root by DRC · 10 years ago
  70. bdb36e1 Windows doesn't have setenv(). Go, go Gadget Macros. by DRC · 10 years ago
  71. 022a901 1.4 beta1 by DRC · 10 years ago
  72. e408761 Fix 'make dist' by DRC · 10 years ago
  73. 9b012bd Don't use sudo when building a Debian package unless the user is non-root by DRC · 10 years ago
  74. 0713c1b Add a set of undocumented environment variables and Java system properties that allow compression features of libjpeg that are not normally exposed in the TurboJPEG API to be enabled. These features are not normally exposed because, for the most part, they aren't "turbo" features, but it is still useful to be able to benchmark them without modifying the code. by DRC · 10 years ago
  75. 2e2ce5a .func/.endfunc are only necessary when generating STABS debug info, which basically went out of style with parachute pants and Rick Astley. At any rate, none of the platforms for which we're building the ARM code use it (DWARF is the common format these days), and the .func/.endfunc directives cause the clang integrated assembler to fail (http://llvm.org/bugs/show_bug.cgi?id=20424). by DRC · 10 years ago
  76. 684ace1 Extend tjbenchtest so that it tests the dynamic JPEG buffer allocation feature in TurboJPEG. Disable the tiling feature in TJBench whenever dynamic buffer allocation is enabled (because the tiling feature requires a separate buffer for each tile, using it successfully with dynamic buffer allocation would require a separate TurboJPEG compressor instance for each tile, and it's not worth going to that trouble right now.) by DRC · 10 years ago
  77. d92949b Run the TurboJPEG conformance tests out of a directory in /tmp (for improved performance, if the source directory is on a remote file share.) Fix an issue in TJBench.java that prevented it from working properly if the source image resided in a directory with a dot in the name. by DRC · 10 years ago
  78. 4351389 Extend tjbenchtest so that it tests the dynamic JPEG buffer allocation feature in TurboJPEG. Disable the tiling feature in TJBench whenever dynamic buffer allocation is enabled (because the tiling feature requires a separate buffer for each tile, using it successfully with dynamic buffer allocation would require a separate TurboJPEG compressor instance for each tile, and it's not worth going to that trouble right now.) by DRC · 10 years ago
  79. a1a920c Run the TurboJPEG conformance tests out of a directory in /tmp (for improved performance, if the source directory is on a remote file share.) Fix an issue in TJBench.java that prevented it from working properly if the source image resided in a directory with a dot in the name. by DRC · 10 years ago
  80. 88b90bd Oops by DRC · 10 years ago
  81. cce13c7 Subtle point, but dest->outbuffer is a pointer to the address of the JPEG buffer, which is stored in the calling program. Thus, *(dest->outbuffer) will always equal *outbuffer. We need to compare *outbuffer with dest->buffer instead to determine if the pointer is being reused. by DRC · 10 years ago
  82. fe80ec2 If the output buffer in the TurboJPEG destination manager was allocated by the destination manager and is being reused from a previous compression operation, then we need to get the buffer size from the previous operation, since the calling program doesn't know the actual buffer size. by DRC · 10 years ago
  83. 2261e1e Actually, we need to increase the size of BUFSIZE, not just the size of _buffer. The previous patch might have cause problems if, for instance, state->free_in_buffer was 127 but 129 bytes were compressed. In that case, only 127 of the 129 bytes would have been written to the file. Also document the fix. by DRC · 10 years ago
  84. eddc355 Actually, we need to increase the size of BUFSIZE, not just the size of _buffer. The previous patch might have cause problems if, for instance, state->free_in_buffer was 127 but 129 bytes were compressed. In that case, only 127 of the 129 bytes would have been written to the file. Also document the fix. by DRC · 10 years ago
  85. 29823fa Fix an extremely rare crash that can occur when compressing a very high-frequency MCU using quality 100 and no subsampling, and when dynamically allocating the JPEG buffer in the destination manager. Even with a test program designed specifically to reproduce the crash, it only occurred once in about 25 million iterations. More details here: https://sourceforge.net/p/libjpeg-turbo/bugs/64 by DRC · 10 years ago
  86. 9c168ad Fix an extremely rare crash that can occur when compressing a very high-frequency MCU using quality 100 and no subsampling, and when dynamically allocating the JPEG buffer in the destination manager. Even with a test program designed specifically to reproduce the crash, it only occurred once in about 25 million iterations. More details here: https://sourceforge.net/p/libjpeg-turbo/bugs/64 by DRC · 10 years ago
  87. f6d7b77 Wordsmithing & clarifications by DRC · 10 years ago
  88. bc3c168 Document the existence of the new ARM64 SIMD code by DRC · 10 years ago
  89. 19224b2 Properly detect the need for gas-preprocessor.pl when building for ARM64 by DRC · 10 years ago
  90. 40dd314 Refactored YUVImage Java class so that it supports both unified YUV image buffers as well as separate YUV image planes; modified the JNI functions accordingly and added new helper functions to the TurboJPEG C API (tjPlaneWidth(), tjPlaneHeight(), tjPlaneSizeYUV()) to facilitate those modifications; changed potentially confusing "component width" and "component height" terms to "plane width" and "plane height" and modified variable names in turbojpeg.c to reflect this; numerous other documentation tweaks by DRC · 10 years ago
  91. 5d87f6d Make the wrapped functions static by DRC · 10 years ago
  92. d2a7495 Make the wrapped functions static by DRC · 10 years ago
  93. b7c8c86 Whitespace formatting tweaks by DRC · 10 years ago
  94. e31e494 Allow the int pixel versions of the various TurboJPEG JNI functions to share the same code as the byte pixel versions. by DRC · 10 years ago
  95. 80cb264 Whitespace formatting tweaks by DRC · 10 years ago
  96. a4940d1 Add descriptions to help sort out which function goes with which version of the API. by DRC · 10 years ago
  97. 3276045 Add descriptions to help sort out which function goes with which version of the API. by DRC · 10 years ago
  98. fa8bcb8 Compiler warnings by DRC · 10 years ago
  99. 580f391 Fix build broken by r1349 by DRC · 10 years ago
  100. 46a0392 Compiler warnings by DRC · 10 years ago