Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / libjpeg-turbo / cce13c767e93eaed019a8d443dea21835499efcc
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. f6d7b77 Wordsmithing & clarifications by DRC · 10 years ago
  8. bc3c168 Document the existence of the new ARM64 SIMD code by DRC · 10 years ago
  9. 19224b2 Properly detect the need for gas-preprocessor.pl when building for ARM64 by DRC · 10 years ago
  10. 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
  11. 5d87f6d Make the wrapped functions static by DRC · 10 years ago
  12. d2a7495 Make the wrapped functions static by DRC · 10 years ago
  13. b7c8c86 Whitespace formatting tweaks by DRC · 10 years ago
  14. 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
  15. 80cb264 Whitespace formatting tweaks by DRC · 10 years ago
  16. a4940d1 Add descriptions to help sort out which function goes with which version of the API. by DRC · 10 years ago
  17. 3276045 Add descriptions to help sort out which function goes with which version of the API. by DRC · 10 years ago
  18. fa8bcb8 Compiler warnings by DRC · 10 years ago
  19. 580f391 Fix build broken by r1349 by DRC · 10 years ago
  20. 46a0392 Compiler warnings by DRC · 10 years ago
  21. 26dd86b Restore backward compatibility between libjpeg-turbo 1.3.x JAR and the new JNI library by DRC · 10 years ago
  22. 927a10d 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
  23. cdcac99 Clean up exception handling in the JNI code. The exception is actually not thrown until the function exits, so we can let the code fall through to bailout: if the TurboJPEG C function fails. Also, per the JNI spec, no other JNI functions can be called between GetPrimitiveArrayCritical() and ReleasePrimitiveArrayCritical(). This hasn't caused any problems thus far, but better safe than sorry. by DRC · 10 years ago
  24. 8951cf0 Clean up exception handling in the JNI code. The exception is actually not thrown until the function exits, so we can let the code fall through to bailout: if the TurboJPEG C function fails. Also, per the JNI spec, no other JNI functions can be called between GetPrimitiveArrayCritical() and ReleasePrimitiveArrayCritical(). This hasn't caused any problems thus far, but better safe than sorry. by DRC · 10 years ago
  25. f7c1105 Oops. Parameter name is "strides", not "stride" by DRC · 10 years ago
  26. 9d77dad Reformat TurboJPEG C API documentation to improve ease of maintenance and to make it more consistent with the javadoc formatting; fix minor error in tjCompressFromYUV() prototype. by DRC · 10 years ago
  27. 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
  28. 493be61 Clean up and consolidate notes regarding the YUV image format. This also corrects a factual error regarding the padding of the luminance plane-- because we now support 4:1:1, the component width is not necessarily padded to the nearest multiple of 2 if horizontal subsampling is used. by DRC · 10 years ago
  29. 779bd68 Clean up notes using the doxygen @note command by DRC · 10 years ago
  30. d13df21 Clean up notes using the doxygen @note command by DRC · 10 years ago
  31. c71ab2f Make the documentation more readable by displaying fixed-width text (which is used to refer to variables and functions) in a different color. by DRC · 10 years ago
  32. 983503e Fix a display issue in the documentation for tjDecompress2() (doxygen treats a star at the beginning of the line as a list bullet); make the documentation more readable by displaying fixed-width text (which is used to refer to variables and functions) in a different color. by DRC · 10 years ago
  33. aee4f72 12-bit JPEG support by DRC · 10 years ago
  34. 5ead57a The Independent JPEG Group's JPEG software v6b by Thomas G. Lane · 27 years ago
  35. 489583f The Independent JPEG Group's JPEG software v6a by Thomas G. Lane · 29 years ago
  36. bc79e06 The Independent JPEG Group's JPEG software v6 by Thomas G. Lane · 29 years ago
  37. a8b67c4 The Independent JPEG Group's JPEG software v5b by Thomas G. Lane · 30 years ago
  38. 9ba2f5e The Independent JPEG Group's JPEG software v5a by Thomas G. Lane · 30 years ago
  39. 36a4ccc The Independent JPEG Group's JPEG software v5 by Thomas G. Lane · 30 years ago
  40. cc7150e The Independent JPEG Group's JPEG software v4a by Thomas G. Lane · 32 years ago
  41. 88aeed4 The Independent JPEG Group's JPEG software v4 by Thomas G. Lane · 32 years ago
  42. 4a6b730 The Independent JPEG Group's JPEG software v3 by Thomas G. Lane · 33 years ago
  43. bd543f0 The Independent JPEG Group's JPEG software v2 by Thomas G. Lane · 33 years ago
  44. 2cbeb8a The Independent JPEG Group's JPEG software v1 by Thomas G. Lane · 33 years ago
  45. 8a74848 Oops. The Windows version of collect_args/uncollect_args uses rsp, so we still need the rsp prologue/epilogue, despite the fact that we aren't using the stack as a work area. This fixes a segfault on Windows caused by r1335. by DRC · 10 years ago
  46. a8ab342 Attempt to improve performance by refactoring the compression-side color conversion and DCT algorithms so that they take full advantage of the additional registers available with 64-bit SSE2. This produces a somewhat yawn-worthy speedup of 2-3%, but at least the code is a lot more readable now. by DRC · 10 years ago
  47. 3728aa0 Fix performance and other issues uncovered in testing with actual ARM64 hardware; formatting tweaks; remove NEON platform check (NEON is always available with ARMv8) by DRC · 10 years ago
  48. 8214555 Include "Installed-Size" field in the deb-control file to prevent Ubuntu from complaining by DRC · 10 years ago
  49. d762c19 Include "Installed-Size" field in the deb-control file to prevent Ubuntu from complaining by DRC · 10 years ago
  50. 2472bc7 Add proper support for Borland compilers (Borland needs section names to be prefixed with an underscore, and it needs OMF object files.) by DRC · 10 years ago
  51. 3da1033 Big oops. wrjpgcom on Windows was being built using the rdjpgcom source. by DRC · 10 years ago
  52. a81f542 Big oops. wrjpgcom on Windows was being built using the rdjpgcom source. by DRC · 10 years ago
  53. 73821bf Big oops. wrjpgcom on Windows was being built using the rdjpgcom source. by DRC · 10 years ago
  54. 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
  55. 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
  56. a8fb48b Remove VMS-specific code by DRC · 10 years ago
  57. 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
  58. 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
  59. 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
  60. fced14c We don't support non-ANSI C compilers by DRC · 10 years ago
  61. 495e434 Allow for building the MIPS DSPr2 extensions if the host is mips-* as well as mipsel-*. The DSPr2 extensions are little endian, so we still have to check that the compiler defines __MIPSEL__ before enabling them. This paves the way for supporting big-endian MIPS, and in the near term, it allows the SIMD extensions to be built with Sourcery CodeBench. by DRC · 10 years ago
  62. 5ef4630 SIMD-accelerated int upsample routine for MIPS DSPr2 by DRC · 10 years ago
  63. c728cfd Fix MIPS build by DRC · 10 years ago
  64. 5de454b libjpeg-turbo has never supported non-ANSI compilers, so get rid of the crufty SIZEOF() macro. It was not being used consistently anyhow, so it would not have been possible to build prior releases of libjpeg-turbo using the broken compilers for which that macro was designed. by DRC · 10 years ago
  65. 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
  66. 7f4a81b Further copyright header cleanup by DRC · 10 years ago
  67. da13af6 Further copyright header cleanup by DRC · 10 years ago
  68. d88f7dd Further copyright header cleanup by DRC · 10 years ago
  69. bc56b75 Get rid of the HAVE_PROTOTYPES configuration option, as well as the related JMETHOD and JPP macros. libjpeg-turbo has never supported compilers that don't handle prototypes. Doing so requires ansi2knr, which isn't even supported in the IJG code anymore. by DRC · 10 years ago
  70. 52ded87 Remove all of the NEED_SHORT_EXTERNAL_NAMES stuff. There is scant information available as to which linkers ever had a 15-character global symbol name limit. AFAICT, it might have been a VMS and/or a.out BSD thing, but none of those platforms have ever been supported by libjpeg-turbo (nor are such systems supported by other open source libraries of this nature.) by DRC · 10 years ago
  71. 6408628 Clean up code formatting in the SIMD interface functions by DRC · 10 years ago
  72. 1419852 Clean up code formatting in the SIMD interface functions by DRC · 10 years ago
  73. 1b3fd7e SIMD-accelerated NULL convert routine for MIPS DSPr2 by DRC · 10 years ago
  74. a3c3bbc Fix build, which was broken by the checkin of the MIPS DSPr2 accelerated smooth downsampling routine. Until/unless other platforms include SIMD support for that function, it's just easier to #ifdef around it rather than adding stubs for the other platforms. by DRC · 10 years ago
  75. 0bf325b Fix error in MIPS DSPr2 accelerated smooth downsample routine by DRC · 10 years ago
  76. 6a61c1e SIMD-accelerated h2v2 smooth downsampling routine for MIPS DSPr2 by DRC · 10 years ago
  77. 1e9cbba Minor tweak to improve code readability by DRC · 10 years ago
  78. 3b489c3 Minor tweak to improve code readability by DRC · 10 years ago
  79. 976fd96 The x86/x86-64 SIMD extensions were originally designed to accommodate changing the value of RGB_*, but this apparently broke when RGB-to-gray colorspace conversion was accelerated. Further, the ARM NEON extensions have always assumed that JCS_RGB behaves identically to JCS_EXT_RGB. Rather than fix these issues, it makes more sense to just stop claiming that we support changing the values of RGB_*, since doing so is no longer necessary. by DRC · 10 years ago
  80. b844eaa SIMD-accelerated merged upsampling routines for MIPS DSPr2 by DRC · 10 years ago
  81. 3402a66 The x86/x86-64 SIMD extensions were originally designed to accommodate changing the value of RGB_*, but this apparently broke when RGB-to-gray colorspace conversion was accelerated. Further, the ARM NEON extensions have always assumed that JCS_RGB behaves identically to JCS_EXT_RGB. Rather than fix these issues, it makes more sense to just stop claiming that we support changing the values of RGB_*, since doing so is no longer necessary. by DRC · 10 years ago
  82. 78df2e6 Add support for decompressing to RGB565 (16-bit) pixels by DRC · 10 years ago
  83. 6e8220e Document -rgb option in djpeg man page; "gray-scale"="grayscale" by DRC · 10 years ago
  84. 90d6c38 Document -rgb option in djpeg man page; "gray-scale"="grayscale" by DRC · 10 years ago
  85. 2a9f0cf Use 2-space indentation for the enums, to be consistent with the structs by DRC · 10 years ago
  86. 333e918 Use 2-space indentation for the enums, to be consistent with the structs by DRC · 10 years ago
  87. e3cb4eb Document the fact that the fast integer FDCT is not fully accelerated for quality levels above 97 + additional wordsmithing by DRC · 10 years ago
  88. 05524e6 Document the fact that the fast integer FDCT is not fully accelerated for quality levels above 97 + additional wordsmithing by DRC · 10 years ago
  89. 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
  90. 5829cb2 The Independent JPEG Group's JPEG software v8d by Guido Vollbeding · 13 years ago
  91. c39ec14 The Independent JPEG Group's JPEG software v8c by Guido Vollbeding · 14 years ago
  92. a4ecaac The Independent JPEG Group's JPEG software v8b by Guido Vollbeding · 14 years ago
  93. f18f81b The Independent JPEG Group's JPEG software v8a by Guido Vollbeding · 15 years ago
  94. 989630f The Independent JPEG Group's JPEG software v8 by Guido Vollbeding · 15 years ago
  95. 5996a25 The Independent JPEG Group's JPEG software v7 by Guido Vollbeding · 15 years ago
  96. 1e247ac The Independent JPEG Group's JPEG software v6b with arithmetic coding support by Guido Vollbeding · 27 years ago
  97. a758460 Provide a more thorough description of the trade-offs between the various DCT/IDCT algorithms, based on new resarch by DRC · 10 years ago
  98. 8940e6c Provide a more thorough description of the trade-offs between the various DCT/IDCT algorithms, based on new resarch by DRC · 10 years ago
  99. b775351 Convert tabs to spaces in the libjpeg code and the SIMD code (TurboJPEG retains the use of tabs for historical reasons. They were annoying in the libjpeg code primarily because they were not consistently used and because they were used to format as well as indent the code. In the case of TurboJPEG, tabs are used just to indent the code, so even if the editor assumes a different tab width, the code will still be readable.) by DRC · 10 years ago
  100. e47364a Modify Windows build system to take into account new assembly file names by DRC · 10 years ago