--- - branch: MAIN date: Wed Jan 28 21:51:02 UTC 2015 files: - new: '1.11' old: '1.10' path: pkgsrc/graphics/libjpeg-turbo/Makefile pathrev: pkgsrc/graphics/libjpeg-turbo/Makefile@1.11 type: modified - new: '1.8' old: '1.7' path: pkgsrc/graphics/libjpeg-turbo/distinfo pathrev: pkgsrc/graphics/libjpeg-turbo/distinfo@1.8 type: modified - new: '1.3' old: '1.2' path: pkgsrc/graphics/libjpeg-turbo/patches/patch-aa pathrev: pkgsrc/graphics/libjpeg-turbo/patches/patch-aa@1.3 type: modified - new: '1.2' old: '1.1' path: pkgsrc/graphics/libjpeg-turbo/patches/patch-configure pathrev: pkgsrc/graphics/libjpeg-turbo/patches/patch-configure@1.2 type: modified - new: '1.2' old: '1.1' path: pkgsrc/graphics/libjpeg-turbo/patches/patch-jpeglib.h pathrev: pkgsrc/graphics/libjpeg-turbo/patches/patch-jpeglib.h@1.2 type: modified id: 20150128T215102Z.c95dd32ceeb2eb59a0d8a333fc4f1fd0f118176f log: | Update to 1.4.0. Changes: 1.4.0 ===== [2] The non-SIMD RGB565 color conversion code did not work correctly on big endian machines. This has been fixed. [3] Fixed an issue in tjPlaneSizeYUV() whereby it would erroneously return 1 instead of -1 if componentID was > 0 and subsamp was TJSAMP_GRAY. [3] Fixed an issue in tjBufSizeYUV2() wherby it would erroneously return 0 instead of -1 if width was < 1. [5] The Huffman encoder now uses clz and bsr instructions for bit counting on ARM64 platforms (see 1.4 beta1 [5].) [6] The close() method in the TJCompressor and TJDecompressor Java classes is now idempotent. Previously, that method would call the native tjDestroy() function even if the TurboJPEG instance had already been destroyed. This caused an exception to be thrown during finalization, if the close() method had already been called. The exception was caught, but it was still an expensive operation. [7] The TurboJPEG API previously generated an error ("Could not determine subsampling type for JPEG image") when attempting to decompress grayscale JPEG images that were compressed with a sampling factor other than 1 (for instance, with 'cjpeg -grayscale -sample 2x2'). Subsampling technically has no meaning with grayscale JPEGs, and thus the horizontal and vertical sampling factors for such images are ignored by the decompressor. However, the TurboJPEG API was being too rigid and was expecting the sampling factors to be equal to 1 before it treated the image as a grayscale JPEG. [8] cjpeg, djpeg, and jpegtran now accept an argument of -version, which will print the library version and exit. [9] Referring to 1.4 beta1 [15], another extremely rare circumstance was discovered under which the Huffman encoder's local buffer can be overrun when a buffered destination manager is being used and an extremely-high-frequency block (basically junk image data) is being encoded. Even though the Huffman local buffer was increased from 128 bytes to 136 bytes to address the previous issue, the new issue caused even the larger buffer to be overrun. Further analysis reveals that, in the absolute worst case (such as setting alternating AC coefficients to 32767 and -32768 in the JPEG scanning order), the Huffman encoder can produce encoded blocks that approach double the size of the unencoded blocks. Thus, the Huffman local buffer was increased to 256 bytes, which should prevent any such issue from re-occurring in the future. 1.3.90 (1.4 beta1) ================== [1] New features in the TurboJPEG API: -- YUV planar images can now be generated with an arbitrary line padding (previously only 4-byte padding, which was compatible with X Video, was supported.) -- The decompress-to-YUV function has been extended to support image scaling. -- JPEG images can now be compressed from YUV planar source images. -- YUV planar images can now be decoded into RGB or grayscale images. -- 4:1:1 subsampling is now supported. This is mainly included for compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and has no significant advantages relative to 4:2:0. -- CMYK images are now supported. This feature allows CMYK source images to be compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be decompressed to CMYK destination images. Conversion between CMYK/YCCK and RGB or YUV images is not supported. Such conversion requires a color management system and is thus out of scope for a codec library. -- The handling of YUV images in the Java API has been significantly refactored and should now be much more intuitive. -- The Java API now supports encoding a YUV image from an arbitrary position in a large image buffer. -- All of the YUV functions now have a corresponding function that operates on separate image planes instead of a unified image buffer. This allows for compressing/decoding from or decompressing/encoding to a subregion of a larger YUV image. It also allows for handling YUV formats that swap the order of the U and V planes. [2] Added SIMD acceleration for DSPr2-capable MIPS platforms. This speeds up the compression of full-color JPEGs by 70-80% on such platforms and decompression by 25-35%. [3] If an application attempts to decompress a Huffman-coded JPEG image whose header does not contain Huffman tables, libjpeg-turbo will now insert the default Huffman tables. In order to save space, many motion JPEG video frames are encoded without the default Huffman tables, so these frames can now be successfully decompressed by libjpeg-turbo without additional work on the part of the application. An application can still override the Huffman tables, for instance to re-use tables from a previous frame of the same video. [5] The Huffman encoder now uses clz and bsr instructions for bit counting on ARM platforms rather than a lookup table. This reduces the memory footprint by 64k, which may be important for some mobile applications. Out of four Android devices that were tested, two demonstrated a small overall performance loss (~3-4% on average) with ARMv6 code and a small gain (also ~3-4%) with ARMv7 code when enabling this new feature, but the other two devices demonstrated a significant overall performance gain with both ARMv6 and ARMv7 code (~10-20%) when enabling the feature. Actual mileage may vary. [7] Improved the accuracy and performance of the non-SIMD implementation of the floating point inverse DCT (using code borrowed from libjpeg v8a and later.) The accuracy of this implementation now matches the accuracy of the SSE/SSE2 implementation. Note, however, that the floating point DCT/IDCT algorithms are mainly a legacy feature. They generally do not produce significantly better accuracy than the slow integer DCT/IDCT algorithms, and they are quite a bit slower. [8] Added a new output colorspace (JCS_RGB565) to the libjpeg API that allows for decompressing JPEG images into RGB565 (16-bit) pixels. If dithering is not used, then this code path is SIMD-accelerated on ARM platforms. [13] Restored 12-bit-per-component JPEG support. A 12-bit version of libjpeg-turbo can now be built by passing an argument of --with-12bit to configure (Unix) or -DWITH_12BIT=1 to cmake (Windows.) 12-bit JPEG support is included only for convenience. Enabling this feature disables all of the performance features in libjpeg-turbo, as well as arithmetic coding and the TurboJPEG API. The resulting library still contains the other libjpeg-turbo features (such as the colorspace extensions), but in general, it performs no faster than libjpeg v6b. [14] Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color conversion and IDCT algorithms (both are used during JPEG decompression.) For unknown reasons (probably related to clang), this code cannot currently be compiled for iOS. [15] Fixed an extremely rare bug that could cause the Huffman encoder's local buffer to overrun when a very high-frequency MCU is compressed using quality 100 and no subsampling, and when the JPEG output buffer is being dynamically resized by the destination manager. This issue was so rare that, even with a test program specifically designed to make the bug occur (by injecting random high-frequency YUV data into the compressor), it was reproducible only once in about every 25 million iterations. [16] Fixed an oversight in the TurboJPEG C wrapper: if any of the JPEG compression functions was called repeatedly with the same automatically-allocated destination buffer, then TurboJPEG would erroneously assume that the jpegSize parameter was equal to the size of the buffer, when in fact that parameter was probably equal to the size of the most recently compressed JPEG image. If the size of the previous JPEG image was not as large as the current JPEG image, then TurboJPEG would unnecessarily reallocate the destination buffer. 1.3.1 ===== [3] Fixed a bug whereby attempting to encode a progressive JPEG with arithmetic entropy coding (by passing arguments of -progressive -arithmetic to cjpeg or jpegtran, for instance) would result in an error, "Requested feature was omitted at compile time". [4] Fixed a couple of issues whereby malformed JPEG images would cause libjpeg-turbo to use uninitialized memory during decompression. [5] Fixed an error ("Buffer passed to JPEG library is too small") that occurred when calling the TurboJPEG YUV encoding function with a very small (< 5x5) source image, and added a unit test to check for this error. module: pkgsrc subject: 'CVS commit: pkgsrc/graphics/libjpeg-turbo' unixtime: '1422481862' user: rjs