Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / libjpeg-turbo / dacf5b3a7ac23f50770aa7315c8ef55c3a95f76b / ChangeLog.txt
  1. ac30a1b Add a new libjpeg API function (jpeg_skip_scanlines()) to allow for partially decoding a JPEG image. by DRC · 9 years ago
  2. 8e9cef2 Fix various issues reported by the UB sanitizers by DRC · 9 years ago
  3. 54792ba Fix MIPS DSPr2 4:2:0 upsample bug w/ small images by James Cowgill · 9 years ago
  4. 498d9bc Fix x86-64 ABI conformance issue in SIMD code by Chandler Carruth · 9 years ago
  5. b5a55e6 Fix negative shift with IFAST FDCT and qual=100 by DRC · 9 years ago
  6. a3ef34c Fix cjpeg segfault when Windows BMP width/height<0 by DRC · 9 years ago
  7. 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
  8. 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
  9. 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 · 9 years ago
  10. 665c96e Allow building only static or only shared libraries on Windows by DRC · 9 years ago
  11. 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 · 9 years ago
  12. 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 · 9 years ago
  13. 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 · 9 years ago
  14. 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 · 9 years ago
  15. 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 · 9 years ago
  16. 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 · 9 years ago
  17. 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 · 9 years ago
  18. 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 · 9 years ago
  19. 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 · 9 years ago
  20. 8f7f49a by DRC · 9 years ago
  21. d51e6c2 Document that the ARMv8/iOS issues are now fixed by DRC · 10 years ago
  22. 6e6b28c Include ARMv8 binaries when generating a combined OS X/iOS package using 'make iosdmg' by DRC · 10 years ago
  23. 2a6b831 Some software also needs the FAR macro. Ugh. Also wordsmithing. by DRC · 10 years ago
  24. 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
  25. 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
  26. 402a715 Fix Huffman local buffer overrun discovered by Debian developers when attempting to transform a junk image using ImageMagick: by DRC · 10 years ago
  27. 9665f5e Print the library version and exit whenever -version is passed to cjpeg, djpeg, or jpegtran. by DRC · 10 years ago
  28. 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
  29. 3ebcf7c Make TJCompressor.close() and TJDecompressor.close() idempotent by DRC · 10 years ago
  30. 803b5d2 Uses clz and bsr instructions for bit counting on ARM64 platforms as well. by DRC · 10 years ago
  31. 55620c6 Another oops. tjBufSizeYUV2() should return -1 if width < 1. by DRC · 10 years ago
  32. 2240974 Oops. tjPlaneSizeYUV() should return -1 if componentID > 0 and subsamp==TJSAMP_GRAY. by DRC · 10 years ago
  33. 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
  34. eb8d096 Fix build on OS X PowerPC platforms by DRC · 10 years ago
  35. 339589f Fix build on OS X PowerPC platforms by DRC · 10 years ago
  36. 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
  37. 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
  38. 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
  39. 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
  40. 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
  41. f6d7b77 Wordsmithing & clarifications by DRC · 10 years ago
  42. bc3c168 Document the existence of the new ARM64 SIMD code by DRC · 10 years ago
  43. aecea38 Extend the TurboJPEG C API to support handling YUV images stored in separate image planes instead of a unified buffer by DRC · 10 years ago
  44. aee4f72 12-bit JPEG support by DRC · 10 years ago
  45. 3da1033 Big oops. wrjpgcom on Windows was being built using the rdjpgcom source. by DRC · 10 years ago
  46. a81f542 Big oops. wrjpgcom on Windows was being built using the rdjpgcom source. by DRC · 10 years ago
  47. 73821bf Big oops. wrjpgcom on Windows was being built using the rdjpgcom source. by DRC · 10 years ago
  48. 2384331 Prevent a buffer overrun if the comment begins with a literal quote character and the string exceeds 65k characters. Also prevent comments longer than 65k characters from being written, since this will produce an incorrect JPEG file. by DRC · 10 years ago
  49. b7d6e84 Prevent a buffer overrun if the comment begins with a literal quote character and the string exceeds 65k characters. Also prevent comments longer than 65k characters from being written, since this will produce an incorrect JPEG file. by DRC · 10 years ago
  50. 88c7e30 Our copyright string is longer than JMSG_LENGTH_MAX, and this was causing a buffer overrun if output_message() was called with msg_code set to JMSG_COPYRIGHT, or if format_message() was called with msg_code set to JMSG_COPYRIGHT and with a buffer of length JMSG_LENGTH_MAX. by DRC · 10 years ago
  51. d7a2559 Our copyright string is longer than JMSG_LENGTH_MAX, and this was causing a buffer overrun if output_message() was called with msg_code set to JMSG_COPYRIGHT, or if format_message() was called with msg_code set to JMSG_COPYRIGHT and with a buffer of length JMSG_LENGTH_MAX. by DRC · 10 years ago
  52. cf55f0b Our copyright string is longer than JMSG_LENGTH_MAX, and this was causing a buffer overrun if output_message() was called with msg_code set to JMSG_COPYRIGHT, or if format_message() was called with msg_code set to JMSG_COPYRIGHT and with a buffer of length JMSG_LENGTH_MAX. by DRC · 10 years ago
  53. 5033f3e Remove MS-DOS code and information, and adjust copyright headers to reflect the removal of features in r1307 and r1308. libjpeg-turbo has never supported MS-DOS, nor is it even possible for us to do so. by DRC · 10 years ago
  54. 78df2e6 Add support for decompressing to RGB565 (16-bit) pixels by DRC · 10 years ago
  55. 715bb41 Port the more accurate (and slightly faster) floating point IDCT implementation from jpeg-8a and later. New research revealed that the SSE/SSE2 floating point IDCT implementation was actually more accurate than the jpeg-6b implementation, not less, which is why its mathematical results have always differed from those of the jpeg-6b implementation. This patch brings the accuracy of the C code in line with that of the SSE/SSE2 code. by DRC · 10 years ago
  56. beb0b33 Work around an issue in Visual C++ 2010 and 2013 that was causing the 256-bit bitmap test in the regression tests to fail. More specifically, when optimization is enabled in these versions of Visual C++, the optimizer seems to get confused by the following code block: by DRC · 10 years ago
  57. ac9a92e Work around an issue in Visual C++ 2010 and 2013 that was causing the 256-bit bitmap test in the regression tests to fail. More specifically, when optimization is enabled in these versions of Visual C++, the optimizer seems to get confused by the following code block: by DRC · 10 years ago
  58. 0816d08 Work around an issue in Visual C++ 2010 and 2013 that was causing the 256-bit bitmap test in the regression tests to fail. More specifically, when optimization is enabled in these versions of Visual C++, the optimizer seems to get confused by the following code block: by DRC · 10 years ago
  59. fdd625e wordsmithing by DRC · 10 years ago
  60. 0cfc4c1 Use clz/bsr instructions on ARM for bit counting rather than the lookup table (reduces memory footprint and can improve performance in some cases.) by DRC · 10 years ago
  61. b1068fa Migrate Mac packaging system to pkgbuild, since PackageMaker is no longer supported. by DRC · 10 years ago
  62. de23dd8 by DRC · 10 years ago
  63. c8b0226 by DRC · 10 years ago
  64. fc26b65 Extend the YUV decode functionality to the TurboJPEG Java API, and port the TJUnitTest modifications that treat YUV encoding/decoding as an intermediate step of the JPEG compression/decompression pipeline rather than a separate test case; Add the ability to encode YUV images from an arbitrary position in a large image buffer; Significantly refactor the handling of YUV images; numerous doc tweaks; other Java API cleanup and usability improvements by DRC · 10 years ago
  65. 3bf21e0 Fix the build of the Java classes when using MSVC 2010 and later. Something in the recesses of my brain is telling me that I tried this before and it failed under some circumstances, but it must have been a bug in an older CMake implementation. CMake 2.8.8 and later seem to work fine with this patch. This patch also updates the minimum required version to 2.8.8, because 2.8.8 fixed another issue that was preventing the SIMD code from building under MSVC 2010 and later. by DRC · 10 years ago
  66. d45c549 Fix the build of the Java classes when using MSVC 2010 and later. Something in the recesses of my brain is telling me that I tried this before and it failed under some circumstances, but it must have been a bug in an older CMake implementation. CMake 2.8.8 and later seem to work fine with this patch. This patch also updates the minimum required version to 2.8.8, because 2.8.8 fixed another issue that was preventing the SIMD code from building under MSVC 2010 and later. by DRC · 10 years ago
  67. 34dca05 Implement a YUV decode function in the TurboJPEG API, to be symmetric with tjEncodeYUV(). by DRC · 10 years ago
  68. 693f4a5 Fix an issue that prevented tjEncodeYUV2() and TJCompressor.encodeYUV() from working properly if the source image was very tiny. Basically, jpeg_start_compress() was attempting to write the JPEG headers, which was overrunning the YUV buffer. This patch removes the call to jpeg_start_compress() in tjEncodeYUV2() and replaces it with calls to the individual routines that are necessary to initialize the color converter and downsampler. TJUnitTest has also been modified to test for this condition (the buffer size regression test now works in YUV mode.) by DRC · 10 years ago
  69. 2c0c807 Fix an issue that prevented tjEncodeYUV2() and TJCompressor.encodeYUV() from working properly if the source image was very tiny. Basically, jpeg_start_compress() was attempting to write the JPEG headers, which was overrunning the YUV buffer. This patch removes the call to jpeg_start_compress() in tjEncodeYUV2() and replaces it with calls to the individual routines that are necessary to initialize the color converter and downsampler. TJUnitTest has also been modified to test for this condition (the buffer size regression test now works in YUV mode.) by DRC · 10 years ago
  70. 38c9970 Fix an issue that prevented tjEncodeYUV3() and TJCompressor.encodeYUV() from working properly if the source image was very tiny. Basically, jpeg_start_compress() was attempting to write the JPEG headers, which was overrunning the YUV buffer. This patch removes the call to jpeg_start_compress() in tjEncodeYUV3() and replaces it with calls to the individual routines that are necessary to initialize the color converter and downsampler. TJUnitTest has also been modified to test for this condition (the buffer size regression test now works in YUV mode.) by DRC · 10 years ago
  71. a113506 Some motion JPEG implementations generate "abbreviated JPEG streams" (JPEG images without the default tables included) for some or all of the video frames, in order to save space. When these are encountered, it is generally expected that they will be decompressed using the default Huffman tables, so libjpeg-turbo now does this unless the tables have been explicitly specified by an application. by DRC · 10 years ago
  72. 43d8cf4 Fix CVE-2013-6629 and CVE-2013-6630 by DRC · 11 years ago
  73. 7ebf294 Fix CVE-2013-6629 and CVE-2013-6630 by DRC · 11 years ago
  74. 9f9436a Fix CVE-2013-6629 and CVE-2013-6630 by DRC · 11 years ago
  75. 910a357 Extend the TurboJPEG C API to support compressing JPEG images from YUV planar images by DRC · 11 years ago
  76. d64e23e adjust DSPr2 performance claims by DRC · 11 years ago
  77. a6b7fbd SIMD-accelerated slow integer forward DCT and quantize routines for MIPS DSPr2 by DRC · 11 years ago
  78. 982e209 Actually, the second bug was hidden by the first, so the initial ChangeLog entry was correct from the user's point of view. by DRC · 11 years ago
  79. cadabd4 Actually, the second bug was hidden by the first, so the initial ChangeLog entry was correct from the user's point of view. by DRC · 11 years ago
  80. e8be2c6 Fix an issue that resulted in an error ("Invalid SOS parameters for sequential JPEG. Didn't expect more than one scan.") when decoding progressive+arithmetic JPEGs generated by libjpeg-turbo. by DRC · 11 years ago
  81. 56e017d Fix an issue that resulted in an error ("Invalid SOS parameters for sequential JPEG. Didn't expect more than one scan.") when decoding progressive+arithmetic JPEGs generated by libjpeg-turbo. by DRC · 11 years ago
  82. e500591 SIMD-accelerated 3/4 and 3/2 decompression scaling for MIPS DSPr2 by DRC · 11 years ago
  83. 49eaa75 SIMD-optimized RGB-to-grayscale conversion for MIPS DSPr2 by DRC · 11 years ago
  84. 5d2514b We can't enable optimized entropy coding unless we're using Huffman coding. This fixes a bug whereby attempting to create a progressive JPEG with arithmetic coding would fail. by DRC · 11 years ago
  85. 2c63c00 Clarify that the bug affects cjpeg as well as jpegtran. by DRC · 11 years ago
  86. 27df2a4 Clarify that the bug affects cjpeg as well as jpegtran. by DRC · 11 years ago
  87. ba923a8 Fix I/O suspension. This little nugget of code was introduced in r30 as part of an early attempt to make buffered I/O work with the optimized Huffman codec. Ultimately, r32 reverted a lot of that mess and introduced much of the logic we now use, rendering this code unnecessary, but it was never reverted because it only causes problems when I/O suspension is used, and apparently no one has tried to do that with libjpeg-turbo until now. by DRC · 11 years ago
  88. 1370f10 We can't enable optimized entropy coding unless we're using Huffman coding. This fixes a bug whereby attempting to create a progressive JPEG with arithmetic coding would fail. by DRC · 11 years ago
  89. 216cc64 We can't enable optimized entropy coding unless we're using Huffman coding. This fixes a bug whereby attempting to create a progressive JPEG with arithmetic coding would fail. by DRC · 11 years ago
  90. ae8d0dc In the Windows installer packages, place a duplicate copy of turbojpeg.dll in c:\libjpeg-turbo[-gcc][64]\bin. This is mainly to give installers an easy way to find the DLL for the purposes of bundling it. Specifically, this was necessary for TurboVNC, becuase 32-bit CMake running on 64-bit Windows cannot ever access the "real" c:\windows\system32 directory. by DRC · 11 years ago
  91. 4d87793 In the Windows installer packages, place a duplicate copy of turbojpeg.dll in c:\libjpeg-turbo[-gcc][64]\bin. This is mainly to give installers an easy way to find the DLL for the purposes of bundling it. Specifically, this was necessary for TurboVNC, becuase 32-bit CMake running on 64-bit Windows cannot ever access the "real" c:\windows\system32 directory. by DRC · 11 years ago
  92. ce84fc8 by DRC · 11 years ago
  93. 7185b71 by DRC · 11 years ago
  94. 1f3635c Add 4:1:1 subsampling support in the TurboJPEG C API by DRC · 11 years ago
  95. 96573d0 By default, install the libraries into /opt/libjpeg-turbo/lib32 on any 32-bit system, not just x86, and into /opt/libjpeg-turbo/lib64 on any 64-bit system, not just x86-64. In particular, this addresses an issue with building TurboVNC and VirtualGL on ARM systems. by DRC · 11 years ago
  96. dadebe9 Document previous commit in the change log by DRC · 11 years ago
  97. 0be9fa5 SIMD support for performing color conversion using MIPS DSPr2 instructions by DRC · 11 years ago
  98. f610d61 Extend the TurboJPEG C API to support generating YUV images with arbitrary padding and to support image scaling when decompressing to YUV by DRC · 11 years ago
  99. 4c17a45 Fix I/O suspension. This little nugget of code was introduced in r30 as part of an early attempt to make buffered I/O work with the optimized Huffman codec. Ultimately, r32 reverted a lot of that mess and introduced much of the logic we now use, rendering this code unnecessary, but it was never reverted because it only causes problems when I/O suspension is used, and apparently no one has tried to do that with libjpeg-turbo until now. by DRC · 11 years ago
  100. d7a642b Minor doc tweaks + ChangeLog update by DRC · 11 years ago