Log Message:
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.