DRC [Tue, 24 May 2011 16:52:47 +0000 (16:52 +0000)]
Add new API functions, tjAlloc() and tjFree(), which allow memory to be allocated and freed using a method of the library's choosing. At the moment, the primary purpose for this is to avoid allocating/freeing memory across the DLL boundary on Windows.
DRC [Tue, 24 May 2011 13:59:14 +0000 (13:59 +0000)]
Refactor uninstall script. No legacy code remains, so relicense under BSD-style license. Remove uninstall app from package for now, until we can come up with a new version that doesn't have any legacy code.
DRC [Tue, 24 May 2011 13:41:27 +0000 (13:41 +0000)]
Refactored to use new TurboJPEG API and new BMP library + additional cleanup. There is no legacy code remaining, so the refactored version of the program has been re-licensed under a BSD-style license.
DRC [Sun, 22 May 2011 13:55:17 +0000 (13:55 +0000)]
Refactored jpegut to test the new TurboJPEG API. There is no legacy code remaining, so the refactored version of the program has been re-licensed under a BSD-style license.
DRC [Sat, 21 May 2011 15:34:54 +0000 (15:34 +0000)]
Clean up constants so that flags, pixel formats, etc. are clearly differentiated; Update documentation accordingly; Name the enums to make it easier to reference them in the docs and clean up the references accordingly; Set Doxygen option to force a detailed description for the constants to always be generated
DRC [Sat, 21 May 2011 14:37:15 +0000 (14:37 +0000)]
Completely refactored the TurboJPEG C API so that it uses pixel formats instead of the clunky pixel size + flags combination to define the pixel size and component order. tjCompress2() and tjTransform() can also now grow the JPEG buffer as needed, which can allow programs to save memory by not pre-allocating the "worst-case" buffer size calculated by TJBUFSIZE(). Converted API documentation to Doxygen. There is no legacy code remaining, so the refactored version of the library has been re-licensed under a BSD-style license.
DRC [Tue, 7 Feb 2012 23:05:46 +0000 (23:05 +0000)]
Merge copyright messages into one string and change the run-time messages to avoid confusion (we are not technically based on the latest libjpeg, although we do borrow some code from it)
DRC [Thu, 1 Dec 2011 11:11:29 +0000 (11:11 +0000)]
Fixed non-fatal out-of-bounds read in SSE2 SIMD code reported by valgrind when decompressing a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes.
DRC [Thu, 1 Dec 2011 11:14:18 +0000 (11:14 +0000)]
Fixed non-fatal out-of-bounds read in SSE2 SIMD code reported by valgrind when decompressing a JPEG image to a bitmap buffer whose size was not a multiple of 16 bytes.
Trying to out-clever ourselves by having autotools generate the deb-control file broke the 32-bit supplementary DEB, so revert to the method we used in LJT 1.0 to generate this file.
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
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
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.
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.
This is subtle, but an unread marker is not an error unless we run out of bits, which may not occur in the same MCU in which the unread marker is encountered. Thus, don't try to use the fast decoder as long as there is an outstanding unread marker.
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.
projects / libjpeg-turbo / log