Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / libjpeg-turbo / refs/tags/rel/11/fp3/8901.4.A.0017.3 / jchuff.c
  1. 6399d0a Fix code formatting/style issues ... by DRC · 5 years ago
  2. a628952 Fix JPEG spec references per ISO/ITU-T suggestions by DRC · 6 years ago
  3. 293263c Format preprocessor macros more consistently by DRC · 6 years ago
  4. 19c791c Improve code formatting consistency by DRC · 6 years ago
  5. 123f725 Format copyright headers more consistently by DRC · 8 years ago
  6. f76c01d Use consistent/modern code formatting for dbl ptrs by DRC · 8 years ago
  7. bd49803 Use consistent/modern code formatting for pointers by DRC · 8 years ago
  8. f3a8684 SSE2 SIMD implementation of Huffman encoding by DRC · 8 years ago
  9. 2111c5a Merge branch '1.4.x' by DRC · 8 years ago
  10. 5a3b4fe Regression: Allow co-install of 32-bit/64-bit RPMs by DRC · 8 years ago
  11. 1e32fe3 Replace INT32 with a new internal datatype (JLONG) by DRC · 9 years ago
  12. 7e3acc0 Rename README, LICENSE, BUILDING text files by DRC · 9 years ago
  13. 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
  14. 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
  15. 96869f4 Restore backward compatibility with MSVC < 2010 (broken by r1541) by DRC · 9 years ago
  16. 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
  17. 402a715 Fix Huffman local buffer overrun discovered by Debian developers when attempting to transform a junk image using ImageMagick: by DRC · 10 years ago
  18. 803b5d2 Uses clz and bsr instructions for bit counting on ARM64 platforms as well. by DRC · 10 years ago
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. e5eaf37 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
  27. ef9a4e0 Integrate a slightly modified version of Mozilla's patch for precomputing the bit-counting LUT. This is useful if the table needs to be shared among multiple processes, although the primary reason for doing that is reduced footprint on mobile devices, which are probably already covered by the clz intrinsic code. by DRC · 10 years ago
  28. 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
  29. a6ef282 Some of the IJG headers say "Modified by", so clarify that our "Modifications" are not referring to these. by DRC · 11 years ago
  30. 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
  31. a73e870 Change the copyright notices to make it clear that our modified files are not part of the IJG's software. by DRC · 11 years ago
  32. ac906c5 Change the name of the pre-computed bits table to match its actual function by DRC · 13 years ago
  33. 6bb57b7 Re-factor and re-license under the libjpeg BSD-style license. Justification: the accelerated Huffman encoding optimizations in libjpeg-turbo were all developed by me as an independent developer. The structure of the inline Huffman encoding macros was originally borrowed from similar routines in the TurboJPEG/mediaLib codec, which is part of VirtualGL and TurboVNC. Thus, although the code for these macros was not copied verbatim, they were still thought to be a derivative work of TurboJPEG/mediaLib, and I assigned the copyright and license from TurboJPEG/mediaLib to them. I have re-written these routines from first principles by breaking down the libjpeg out-of-line routines. Although the new code bears algorithmic similarities to the TurboJPEG/mediaLib macros, it can now clearly be shown to be derived from the out-of-line routines and thus, in my opinion, it can no longer be considered a derivative of TurboJPEG/mediaLib. -- DRC by DRC · 13 years ago
  34. a46830b Eliminate spurious global symbols by DRC · 14 years ago
  35. 830d5fc Use 64-bit holding buffer on Win64 for increased performance by DRC · 14 years ago
  36. 0489909 Bleepin' Windows uses LLP64, not LP64 by DRC · 14 years ago
  37. dae4474 Unfortunately, the previous enhancements made an invalid assumption about the code sizes, which caused "DCT out of range" errors in the decoder. Was able to fix 64-bit without losing any performance, but unfortunately had to revert 32-bit back to its previous behavior for now. by DRC · 15 years ago
  38. 8443e52 Improve compression performance by 15-20% by DRC · 15 years ago
  39. 3cba8db Eliminate backward incompatibility that required empty_output_buffer() to handle cases in which the buffer wasn't 100% full by DRC · 15 years ago
  40. 5ead57a The Independent JPEG Group's JPEG software v6b by Thomas G. Lane · 26 years ago
  41. 489583f The Independent JPEG Group's JPEG software v6a by Thomas G. Lane · 28 years ago
  42. bc79e06 The Independent JPEG Group's JPEG software v6 by Thomas G. Lane · 29 years ago
  43. 36a4ccc The Independent JPEG Group's JPEG software v5 by Thomas G. Lane · 30 years ago
  44. cc7150e The Independent JPEG Group's JPEG software v4a by Thomas G. Lane · 31 years ago
  45. 88aeed4 The Independent JPEG Group's JPEG software v4 by Thomas G. Lane · 31 years ago
  46. 4a6b730 The Independent JPEG Group's JPEG software v3 by Thomas G. Lane · 32 years ago
  47. bd543f0 The Independent JPEG Group's JPEG software v2 by Thomas G. Lane · 32 years ago
  48. 2cbeb8a The Independent JPEG Group's JPEG software v1 by Thomas G. Lane · 33 years ago
  49. 8629988 Fix broken buffered I/O (to make cjpeg work) by DRC · 15 years ago
  50. 9931338 Include Huffman codec optimizations borrowed from TurboJPEG by DRC · 15 years ago
  51. 0ca4425 Merged changes from branches/1.5-xserver (revision range 2432:2631) back to trunk. by Constantin Kaplinsky · 16 years ago