Fix the behavior of the alpha-enabled colorspace constants whenever libjpeg-turbo...

git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@810 632fc199-4ca6-4c93-a231-07263d6284db

diff --cc ChangeLog.txt
index 0f1f45c5b776c943ba13309efae04e09bf57702b,b0d06a760e34a416b46f0e3c42c5eeb5202aa78b..cab96a9aa9e3d4540a069856ecfc081d87fdd0c4
--- 1/ChangeLog.txt
--- 2/ChangeLog.txt
+++ b/ChangeLog.txt
@@@ -1,18 -1,16 +1,24 @@@
 -1.2.1
 -=====
 +1.3 pre-beta
 +============
  
 -[1] Creating or decoding a JPEG file that uses the RGB colorspace should now
 +[1] Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 9/8, 5/4,
- 11/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing.  Currently, the IDCT
- will not be SIMD-accelerated when using any of these scaling factors.
++11/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing.  Note that the IDCT will
++not be SIMD-accelerated when using any of these new scaling factors.
 +
 +[2] Added SIMD acceleration for performing 4:2:2 upsampling on NEON-capable ARM
 +platforms.  This speeds up the decompression of 4:2:2 JPEGs by 20-25% on such
 +platforms.
 +
 +[3] Creating or decoding a JPEG file that uses the RGB colorspace should now
  properly work when the input or output colorspace is one of the libjpeg-turbo
  colorspace extensions.
  
 -[2] When libjpeg-turbo was built without SIMD support and merged (non-fancy)
++[4] When libjpeg-turbo was built without SIMD support and merged (non-fancy)
+ upsampling was used along with an alpha-enabled colorspace during
+ decompression, the unused byte of the decompressed pixels was not being set to
+ 0xFF.  This has been fixed.  TJUnitTest has also been extended to test for the
+ correct behavior of the colorspace extensions when merged upsampling is used.
+ 
  
  1.2.0
  =====

diff --cc tjbench.c
Simple merge