- 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 · 11 years ago
- a6ef282 Some of the IJG headers say "Modified by", so clarify that our "Modifications" are not referring to these. by DRC · 11 years ago
- 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
- efe28ce Compiler warnings by DRC · 13 years ago
- bc51580 Re-factor and re-license under the libjpeg BSD-style license. Justification: the accelerated Huffman decoding optimizations in libjpeg-turbo were all developed by me as an independent developer. The structure of the inline Huffman decoding 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
- 051d962 The previous attempt to handle unexpected markers in the data stream caused breakage in applications that attempted to set bytes_in_buffer to a larger value than the actual size of the JPEG image. The latter behavior was causing the fast decoder to be used for the last MCU in the image under certain circumstances, and this sometimes caused the EOI marker to be encountered by the fast decoder, which was treating it as an "unexpected" marker and throwing an error. Now, the fast decoder simply hands off the decoding of the block to the slow decoder if any marker is encountered. by DRC · 13 years ago
- df1c38d Throw a warning if an unexpected marker is found in the middle of the JPEG data stream by DRC · 13 years ago
- fe6a2ee Throw a warning if an unexpected marker is found in the middle of the JPEG data stream by DRC · 13 years ago
- fa1d183 Further protect against invalid Huffman codes by DRC · 14 years ago
- 49aedf4 Further protect against invalid Huffman codes by DRC · 14 years ago
- 49967cd Improve readability and flexibility of compatibility macros by DRC · 14 years ago
- 36a6eec Added optional emulation of the jpeg-7 or jpeg-8b API/ABI's by DRC · 14 years ago
- 989630f The Independent JPEG Group's JPEG software v8 by Guido Vollbeding · 15 years ago
- 5996a25 The Independent JPEG Group's JPEG software v7 by Guido Vollbeding · 15 years ago
- 5ead57a The Independent JPEG Group's JPEG software v6b by Thomas G. Lane · 26 years ago
- 489583f The Independent JPEG Group's JPEG software v6a by Thomas G. Lane · 29 years ago
- bc79e06 The Independent JPEG Group's JPEG software v6 by Thomas G. Lane · 29 years ago
- a8b67c4 The Independent JPEG Group's JPEG software v5b by Thomas G. Lane · 29 years ago
- 36a4ccc The Independent JPEG Group's JPEG software v5 by Thomas G. Lane · 30 years ago
- cc7150e The Independent JPEG Group's JPEG software v4a by Thomas G. Lane · 32 years ago
- 88aeed4 The Independent JPEG Group's JPEG software v4 by Thomas G. Lane · 32 years ago
- 4a6b730 The Independent JPEG Group's JPEG software v3 by Thomas G. Lane · 32 years ago
- bd543f0 The Independent JPEG Group's JPEG software v2 by Thomas G. Lane · 33 years ago
- 2cbeb8a The Independent JPEG Group's JPEG software v1 by Thomas G. Lane · 33 years ago
- 0fbb28e Handle erroneous Huffman codes by DRC · 14 years ago
- 830d5fc Use 64-bit holding buffer on Win64 for increased performance by DRC · 14 years ago
- 97f8ec4 I'm not sure why, but this was necessary in order to return the 32-bit performance to the 0.0.90 baseline by DRC · 14 years ago
- e885a8b Fix data corruption issues when decompressing large JPEG images and/or using buffered I/O. Specifically, decode_mcu_fast() can potentially process more than 1 MCU, so make sure there is enough space in the buffer to accommodate this case. Otherwise, the buffer pointer goes negative, and bad mojo ensues. Also, the fast decoder's method of handling unread markers doesn't make libjpeg's restart handler happy, so disable fast decode when restarts are used. by DRC · 14 years ago
- e281664 Greatly improve performance of Huffman decoding by DRC · 15 years ago