Actually, the issue with nightshot_iso_100 is unrelated to the image size. Reducing...

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

diff --git a/tjbenchtest.in b/tjbenchtest.in
index e143fcdd18042ae68d227c6f02b45eb8a5b1d628..1ebd0b8f3502c86906cd573efbefb7b99a071462 100755 (executable)
--- a/tjbenchtest.in
+++ b/tjbenchtest.in
@@ -51,12 +51,12 @@ if [ $# -gt 0 ]; then
 # each downsampled dimension is an odd number or is evenly divisible by the MCU
 # width/height.  This disagreement basically amounts to a round-off error, but
 # there is no easy way around it, so for now, we just test the only image that
-# works.  (NOTE: nightshot_iso_100 seems to exhibit a similar phenomenon when
-# decompressing.  If it is scaled by a factor, such as 7/8, that causes the
-# scaled width to no longer be an even multiple of the MCU width, then the
-# combination of tjDecompressToYUV*() and tjDecodeYUV*() do not produce
-# bitwise-identical results to tjDecompress*().  This latter phenomenon is not
-# yet fully understood.)
+# works.  (NOTE: nightshot_iso_100 does not suffer from the above issue, but
+# it suffers from an unrelated problem whereby the combination of
+# tjDecompressToYUV*() and tjDecodeYUV*() do not produce bitwise-identical
+# results to tjDecompress*() if decompression scaling is enabled.  This latter
+# phenomenon is not yet fully understood but is also believed to be some sort
+# of round-off error.)
                IMAGES="vgl_6548_0026a.${EXT}"
        fi
 fi