Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / libjpeg-turbo / 189ee81b58f03eb271f9cb8f09d7c94d61f33dca
  1. 189ee81 Oops. Separate .def file is not needed when compiling with jpeg-8 API/ABI emulation. by DRC · 12 years ago
  2. 0f7ff71 Wordsmith the project description by DRC · 12 years ago
  3. bdfcb74 Actually, turbojpeg.c works with libjpeg as well by DRC · 12 years ago
  4. 5039d73 Eliminated the awkward and confusing "TurboJPEG/OSS" designation, since there are no other active implementations of the TurboJPEG API anymore; don't refer to the libjpeg API library as "libjpeg-turbo" anymore, since that can be confusing; ARM v7s build instructions by DRC · 12 years ago
  5. 98ca1c3 ImageIO.read() returns null if the input image type is not supported (which occurs when trying to read a PPM file), so output a friendly error instead of letting the next line throw a null pointer exception. by DRC · 12 years ago
  6. 2e22eb6 New year, new copyright message by DRC · 12 years ago
  7. 6da61db Fix several issues with SRPM generation: (1) ensure that all relevant configure arguments get passed down to the configure command line in the generated spec file, (2) adjust the file manifest in the spec to accommodate the differing "age" version whenever the in-memory source/dest managers are used, and (3) fix an issue with the value of SO_MAJOR_VERSION passed down to the configure command line in the generated spec file (SO_MAJOR_VERSION has to remain pure, so we use a different variable to pass down the combined "current+age" value to libtool in Makefile.am.) by DRC · 12 years ago
  8. dc4645d Since Windows doesn't use lazy loading, clarify that a Windows application that uses jpeg_mem_dest() or jpeg_mem_src() must use the DLL containing those functions at run time. Other wordsmithing by DRC · 12 years ago
  9. 736fb06 Compiler warnings on Windows by DRC · 12 years ago
  10. ab70623 Implement in-memory source/destination managers even when not emulating the libjpeg v8 API/ABI by DRC · 12 years ago
  11. b87136c Include justification for not supporting SmartScale, DCT scaling, and the libjpeg v9 ABI by DRC · 12 years ago
  12. eff4f95 Subtle point, but the libjpeg v7+ API is not backward incompatible. That is, programs that were built against jpeg-6b can still build against jpeg-7+ with no issues. It's only the ABI that is backward incompatible, so the primary justification for implementing the emulation feature was to provide run-time (ABI) compatibility. by DRC · 12 years ago
  13. cb2036f Say "do not include" rather than "omit", to be consistent with the CMake build system and the output of the configure script. by DRC · 12 years ago
  14. 7c39e3a Include full readme for nightshot_iso_100 by DRC · 12 years ago
  15. 1f4cc44 The GNU version of md5sum is picky about the spacing by DRC · 12 years ago
  16. 00c2cf3 Fix the x86 build with NASM 0.98. Since NASM 0.98 is the default version on OS X, we want to at least allow people to build 32-bit code with it, even though it can't properly build 64-bit code. by DRC · 12 years ago
  17. b87a0b4 Fix the x86 build with NASM 0.98. Since NASM 0.98 is the default version on OS X, we want to at least allow people to build 32-bit code with it, even though it can't properly build 64-bit code. by DRC · 12 years ago
  18. 0f43551 Fix 'make dist' by DRC · 12 years ago
  19. c5052c7 Acknowledge the source of nightshot_iso_100.bmp by DRC · 12 years ago
  20. 211d1e7 Consolidate the MD5 sums into one location and add a --without-turbojpeg switch to the Un*x build to allow building libjpeg-turbo without the TurboJPEG/OSS wrapper library. These modifications were supposed to lay the ground work for adding compile-time-selectable 12-bit JPEG support, but unfortunately there are deeper issues that prevent the implementation of that feature right now (namely, some of the modifications made to the C code to support the SIMD code are apparently not 12-bit-friendly.) by DRC · 12 years ago
  21. 5815699 In all fairness, breaking backward ABI compatibility was necessary in jpeg-7 and jpeg-8 due to the fact that the caller allocates the struct. by DRC · 12 years ago
  22. f29ffd3 Modify 'make test' so that it uses MD5 sums instead of reference images. This eliminates the need to check most of the test images into the repository, which keeps the source tarball to a reasonable size. by DRC · 12 years ago
  23. 2f12d7a Also remove mention of install.txt and filelist.txt in the build system and README. by DRC · 12 years ago
  24. 6f96153 install.txt contains no information relevant to libjpeg-turbo, and filelist.txt does not give any information that can't be gleaned by looking at the headers in the various source files. by DRC · 12 years ago
  25. e54d31a by DRC · 12 years ago
  26. 6b638a6 by DRC · 12 years ago
  27. d211eff by DRC · 12 years ago
  28. dad4d2e by DRC · 12 years ago
  29. d5e964c Wordsmithing; Remove mention of TurboJPEG/IPP-- it is no longer a relevant comparison, since the version of IPP on which TurboJPEG/IPP was based is now quite old, and TurboJPEG/IPP is no longer distributed or supported by The VirtualGL Project; Include information about mathematical incompatibilities with jpeg-8 by DRC · 12 years ago
  30. c168d96 Prevent compiler warning on Windows if jmorecfg.h is included after the Windows headers, which also define FAR. by DRC · 12 years ago
  31. 6a32d04 Prevent compiler warning on Windows if jmorecfg.h is included after the Windows headers, which also define FAR. by DRC · 12 years ago
  32. 2870131 Spacing tweak by DRC · 12 years ago
  33. d7ca17b We support arithmetic coding, which is a feature of libjpeg v7/v8 by DRC · 12 years ago
  34. ac51438 Indicate our support for some of the jpeg-8d features, as well as arithmetic coding by DRC · 12 years ago
  35. 966d8b7 Undocument ansi2knr.c, since we don't include it by DRC · 12 years ago
  36. c137f0f Merge some of the README changes from jpeg-8d and change the copyright and version strings to reflect that we use some of that code. by DRC · 12 years ago
  37. 5829cb2 The Independent JPEG Group's JPEG software v8d by Guido Vollbeding · 13 years ago
  38. c39ec14 The Independent JPEG Group's JPEG software v8c by Guido Vollbeding · 14 years ago
  39. a4ecaac The Independent JPEG Group's JPEG software v8b by Guido Vollbeding · 14 years ago
  40. f18f81b The Independent JPEG Group's JPEG software v8a by Guido Vollbeding · 15 years ago
  41. 989630f The Independent JPEG Group's JPEG software v8 by Guido Vollbeding · 15 years ago
  42. 5996a25 The Independent JPEG Group's JPEG software v7 by Guido Vollbeding · 15 years ago
  43. 1e247ac The Independent JPEG Group's JPEG software v6b with arithmetic coding support by Guido Vollbeding · 27 years ago
  44. 5ead57a The Independent JPEG Group's JPEG software v6b by Thomas G. Lane · 27 years ago
  45. 489583f The Independent JPEG Group's JPEG software v6a by Thomas G. Lane · 29 years ago
  46. bc79e06 The Independent JPEG Group's JPEG software v6 by Thomas G. Lane · 29 years ago
  47. a8b67c4 The Independent JPEG Group's JPEG software v5b by Thomas G. Lane · 30 years ago
  48. 9ba2f5e The Independent JPEG Group's JPEG software v5a by Thomas G. Lane · 30 years ago
  49. 36a4ccc The Independent JPEG Group's JPEG software v5 by Thomas G. Lane · 30 years ago
  50. cc7150e The Independent JPEG Group's JPEG software v4a by Thomas G. Lane · 32 years ago
  51. 88aeed4 The Independent JPEG Group's JPEG software v4 by Thomas G. Lane · 32 years ago
  52. 4a6b730 The Independent JPEG Group's JPEG software v3 by Thomas G. Lane · 33 years ago
  53. bd543f0 The Independent JPEG Group's JPEG software v2 by Thomas G. Lane · 33 years ago
  54. 2cbeb8a The Independent JPEG Group's JPEG software v1 by Thomas G. Lane · 33 years ago
  55. f37e4da Port RGB-to-Grayscale color transform from jpeg-8d by DRC · 12 years ago
  56. 251db63 Further changes to the copyright/attribution notices to make it clear that our modified files are not part of the IJG's software. by DRC · 12 years ago
  57. a9d39ce Further changes to the copyright/attribution notices to make it clear that our modified files are not part of the IJG's software. by DRC · 12 years ago
  58. e0634b1 We now support the additional decompression scaling factors from jpeg-7 by DRC · 12 years ago
  59. 8cbf893 Port the width/height force feature from jpegtran v8d. by DRC · 12 years ago
  60. f73a27c Add cjpeg -rgb option from jpeg-8d by DRC · 12 years ago
  61. b5f2e45 Minor modifications from jpeg-8d by DRC · 12 years ago
  62. b24a722 Further changes to the copyright/attribution notices to make it clear that our modified files are not part of the IJG's software. by DRC · 12 years ago
  63. 6d6e37d Further changes to the copyright/attribution notices to make it clear that our modified files are not part of the IJG's software. by DRC · 12 years ago
  64. cf763c0 Further changes to the copyright/attribution notices to make it clear that our modified files are not part of the IJG's software. by DRC · 12 years ago
  65. 03badea Further changes to the copyright/attribution notices to make it clear that our modified files are not part of the IJG's software. by DRC · 12 years ago
  66. 84f7122 1.2.90 (1.3 beta1) by DRC · 12 years ago
  67. a73e870 Change the copyright notices to make it clear that our modified files are not part of the IJG's software. by DRC · 12 years ago
  68. 0bfb780 Change the copyright notices to make it clear that our modified files are not part of the IJG's software. by DRC · 12 years ago
  69. 2dcd4b5 Fix bug in unused code by DRC · 12 years ago
  70. 152e4c5 Fix bug in unused code by DRC · 12 years ago
  71. 75cf497 Use a more robust method of obtaining the build timestamp on Windows. 'wmic os get LocalDateTime' will always return the timestamp in the format we want (YYYYMMDD), whereas date /t is sensitive to locale. If wmic fails, then we fall back to using date /t, even though this means that the BUILD variable will end up in the incorrect format on some systems. by DRC · 12 years ago
  72. 5e3bb3e Use a more robust method of obtaining the build timestamp on Windows. 'wmic os get LocalDateTime' will always return the timestamp in the format we want (YYYYMMDD), whereas date /t is sensitive to locale. If wmic fails, then we fall back to using date /t, even though this means that the BUILD variable will end up in the incorrect format on some systems. by DRC · 12 years ago
  73. de924b8 Use a more robust method of obtaining the build timestamp on Windows. 'wmic os get LocalDateTime' will always return the timestamp in the format we want (YYYYMMDD), whereas date /t is sensitive to locale. If wmic fails, then we fall back to using date /t, even though this means that the BUILD variable will end up in the incorrect format on some systems. by DRC · 12 years ago
  74. bc2e66c Fix MinGW build and remove duplication of effort by DRC · 12 years ago
  75. d9d1d67 by DRC · 12 years ago
  76. fac3bea Add a Java version of TJBench and extend the TurboJPEG Java API to support it (this involved adding a polymorphic method in TJCompressor that accepts x and y offsets into a larger buffer, similar to the previous modification that had been done to TJDecompressor.) by DRC · 12 years ago
  77. 61e1341 If libturbojpeg.jnilib is not found on Mac systems, specifically look for it under /usr/lib, since /usr/lib isn't part of the default java.library.path on that platform. by DRC · 12 years ago
  78. 29d8f25 Fix build issues that occurred whenever the source directory contained the letters "col", "mer", or "gra". by DRC · 12 years ago
  79. 8fd7221 Fix build issues that occurred whenever the source directory contained the letters "col", "mer", or "gra". by DRC · 12 years ago
  80. a394bf7 Allow the libjpeg-turbo32 package to be used on MultiArch-compatible systems without overriding the linker path or LD_LIBRARY_PATH. by DRC · 12 years ago
  81. 0a0f8d1 Allow the libjpeg-turbo32 package to be used on MultiArch-compatible systems without overriding the linker path or LD_LIBRARY_PATH. by DRC · 12 years ago
  82. 2186809 Oops. Add support for TJFLAG_FASTDCT to tjDecompressToYUV() as well. by DRC · 12 years ago
  83. e0419b5 Oops. Add support for TJFLAG_FASTDCT to tjDecompressToYUV() as well. by DRC · 12 years ago
  84. 3367f40 1.2.2 by DRC · 12 years ago
  85. cc336e7 Cosmetic fixes to argument lists by DRC · 12 years ago
  86. 73d74c1 Add flags to the TurboJPEG API that allow the caller to force the use of either the fast or the accurate DCT/IDCT algorithms in the underlying codec. by DRC · 12 years ago
  87. e0a0151 Re-generate docs to pick up new API version by DRC · 12 years ago
  88. fd3aba3 Added flags to the TurboJPEG API that allow the caller to force the use of either the fast or the accurate DCT/IDCT algorithms in the underlying codec. by DRC · 12 years ago
  89. 112a0bb More recent versions of autoconf add -traditional-cpp to the CPP flags, which causes jsimdcfg.inc.h to not preprocess correctly unless we expand all of the instances of the #definev macro. by DRC · 12 years ago
  90. ea505e7 More recent versions of autoconf add -traditional-cpp to the CPP flags, which causes jsimdcfg.inc.h to not preprocess correctly unless we expand all of the instances of the #definev macro. by DRC · 12 years ago
  91. 5950c5d Later versions of autoconf (specifically, the one shipped with Xcode 4.3) default to building x86-64, so it is necessary to override the host_alias to get a 32-bit build. by DRC · 12 years ago
  92. ea7bb7b Later versions of autoconf (specifically, the one shipped with Xcode 4.3) default to building x86-64, so it is necessary to override the host_alias to get a 32-bit build. by DRC · 12 years ago
  93. 98eecb8 Fixed regression caused by a bug in the 32-bit strict memory access code in jdmrgss2.asm (contributed by Chromium to stop valgrind from whining whenever the output buffer size was not evenly divisible by 16 bytes.) On Linux/x86, this regression caused incorrect pixels on the right-hand side of images whose rows were not 16-byte aligned, whenever fancy upsampling was used and when decompressing to a 32-bit (RGBX, etc.) buffer. by DRC · 12 years ago
  94. 13c318d Fixed regression caused by a bug in the 32-bit strict memory access code in jdmrgss2.asm (contributed by Chromium to stop valgrind from whining whenever the output buffer size was not evenly divisible by 16 bytes.) On Linux/x86, this regression caused incorrect pixels on the right-hand side of images whose rows were not 16-byte aligned, whenever fancy upsampling was used and when decompressing to a 32-bit (RGBX, etc.) buffer. by DRC · 12 years ago
  95. 14e8225 Provide further details about the regression by DRC · 12 years ago
  96. de37e07 Provide further details about the regression by DRC · 12 years ago
  97. 575317b Acknowledge the existence of 1.2.1 by DRC · 12 years ago
  98. df0babc Fixed regression caused by a bug in the 32-bit strict memory access code in jdmrgss2.asm (contributed by Chromium to stop valgrind from whining whenever the output buffer size was not evenly divisible by 16 bytes.) On Linux/x86, this regression caused incorrect pixels on the right-hand side of images whose rows were not 16-byte aligned, whenever fancy upsampling was used. This patch also enables the strict memory access code on all platforms, not just Linux (it does no harm on other platforms) and removes a couple of pcmpeqb instructions that were rendered unnecessary by r836. by DRC · 12 years ago
  99. 8126d0c Fixed regression caused by a bug in the 32-bit strict memory access code in jdmrgss2.asm (contributed by Chromium to stop valgrind from whining whenever the output buffer size was not evenly divisible by 16 bytes.) On Linux/x86, this regression generated incorrect pixels on the right-hand side of images whose rows were not 16-byte aligned, whenever fancy upsampling was used. This patch also enables the strict memory access code on all platforms, not just Linux (it does no harm on other platforms) and removes a couple of pcmpeqb instructions that were rendered unnecessary by r835. by DRC · 12 years ago
  100. 316617f Accelerated 4:2:2 upsampling routine for ARM (improves performance ~20-30% when decompressing 4:2:2 JPEGs using fancy upsampling) by DRC · 12 years ago