libjpeg-turbo on Windows fails several tests
98 views
Skip to first unread message
gia
Feb 10, 2019, 9:46:01 PM2/10/19
to libjpeg-turbo User Discussion/Support
Hello, built the project (tags/1.5.90) on windows, mac and linux on Debug using cmake. The test suite (ctest -C Debug --no-compress-output -V -T Test) completed 100% on mac and linux, but windows had several failures, wondering if its normal (known failures) or perhaps I may have missed something:
The following tests FAILED:
9 - tjbench-shared-tile-gray-8x8-cmp (Failed)
10 - tjbench-shared-tile-420-8x8-cmp (Failed)
11 - tjbench-shared-tile-422-8x8-cmp (Failed)
12 - tjbench-shared-tile-444-8x8-cmp (Failed)
13 - tjbench-shared-tile-gray-16x16-cmp (Failed)
14 - tjbench-shared-tile-420-16x16-cmp (Failed)
15 - tjbench-shared-tile-422-16x16-cmp (Failed)
16 - tjbench-shared-tile-444-16x16-cmp (Failed)
17 - tjbench-shared-tile-gray-32x32-cmp (Failed)
18 - tjbench-shared-tile-420-32x32-cmp (Failed)
19 - tjbench-shared-tile-422-32x32-cmp (Failed)
20 - tjbench-shared-tile-444-32x32-cmp (Failed)
21 - tjbench-shared-tile-gray-64x64-cmp (Failed)
22 - tjbench-shared-tile-420-64x64-cmp (Failed)
23 - tjbench-shared-tile-422-64x64-cmp (Failed)
24 - tjbench-shared-tile-444-64x64-cmp (Failed)
25 - tjbench-shared-tile-gray-128x128-cmp (Failed)
26 - tjbench-shared-tile-420-128x128-cmp (Failed)
27 - tjbench-shared-tile-422-128x128-cmp (Failed)
28 - tjbench-shared-tile-444-128x128-cmp (Failed)
31 - tjbench-shared-tile-420m-8x8-cmp (Failed)
32 - tjbench-shared-tile-422m-8x8-cmp (Failed)
33 - tjbench-shared-tile-420m-16x16-cmp (Failed)
34 - tjbench-shared-tile-422m-16x16-cmp (Failed)
35 - tjbench-shared-tile-420m-32x32-cmp (Failed)
36 - tjbench-shared-tile-422m-32x32-cmp (Failed)
37 - tjbench-shared-tile-420m-64x64-cmp (Failed)
38 - tjbench-shared-tile-422m-64x64-cmp (Failed)
39 - tjbench-shared-tile-420m-128x128-cmp (Failed)
40 - tjbench-shared-tile-422m-128x128-cmp (Failed)
42 - cjpeg-shared-rgb-islow-cmp (Failed)
44 - djpeg-shared-rgb-islow-cmp (Failed)
47 - jpegtran-shared-icc-cmp (Failed)
49 - djpeg-shared-rgb-islow-565-cmp (Failed)
51 - djpeg-shared-rgb-islow-565D-cmp (Failed)
53 - cjpeg-shared-422-ifast-opt-cmp (Failed)
55 - djpeg-shared-422-ifast-cmp (Failed)
57 - djpeg-shared-422m-ifast-cmp (Failed)
59 - djpeg-shared-422m-ifast-565-cmp (Failed)
61 - djpeg-shared-422m-ifast-565D-cmp (Failed)
63 - cjpeg-shared-420-q100-ifast-prog-cmp (Failed)
65 - djpeg-shared-420-q100-ifast-prog-cmp (Failed)
67 - djpeg-shared-420m-q100-ifast-prog-cmp (Failed)
69 - cjpeg-shared-gray-islow-cmp (Failed)
71 - djpeg-shared-gray-islow-cmp (Failed)
73 - djpeg-shared-gray-islow-rgb-cmp (Failed)
75 - djpeg-shared-gray-islow-565-cmp (Failed)
77 - djpeg-shared-gray-islow-565D-cmp (Failed)
79 - cjpeg-shared-420s-ifast-opt-cmp (Failed)
81 - cjpeg-shared-3x2-float-prog-cmp (Failed)
83 - djpeg-shared-3x2-float-prog-cmp (Failed)
85 - cjpeg-shared-3x2-ifast-prog-cmp (Failed)
87 - djpeg-shared-3x2-ifast-prog-cmp (Failed)
89 - cjpeg-shared-420-islow-ari-cmp (Failed)
93 - cjpeg-shared-444-islow-progari-cmp (Failed)
138 - djpeg-shared-420-islow-prog-crop62x62_71_71-cmp (Failed)
143 - djpeg-shared-444-islow-skip1_6-cmp (Failed)
146 - djpeg-shared-444-islow-prog-crop98x98_13_13-cmp (Failed)
149 - djpeg-shared-444-islow-ari-crop37x37_0_0-cmp (Failed)
160 - tjbench-static-tile-gray-8x8-cmp (Failed)
161 - tjbench-static-tile-420-8x8-cmp (Failed)
162 - tjbench-static-tile-422-8x8-cmp (Failed)
163 - tjbench-static-tile-444-8x8-cmp (Failed)
164 - tjbench-static-tile-gray-16x16-cmp (Failed)
165 - tjbench-static-tile-420-16x16-cmp (Failed)
166 - tjbench-static-tile-422-16x16-cmp (Failed)
167 - tjbench-static-tile-444-16x16-cmp (Failed)
168 - tjbench-static-tile-gray-32x32-cmp (Failed)
169 - tjbench-static-tile-420-32x32-cmp (Failed)
170 - tjbench-static-tile-422-32x32-cmp (Failed)
171 - tjbench-static-tile-444-32x32-cmp (Failed)
172 - tjbench-static-tile-gray-64x64-cmp (Failed)
173 - tjbench-static-tile-420-64x64-cmp (Failed)
174 - tjbench-static-tile-422-64x64-cmp (Failed)
175 - tjbench-static-tile-444-64x64-cmp (Failed)
176 - tjbench-static-tile-gray-128x128-cmp (Failed)
177 - tjbench-static-tile-420-128x128-cmp (Failed)
178 - tjbench-static-tile-422-128x128-cmp (Failed)
179 - tjbench-static-tile-444-128x128-cmp (Failed)
182 - tjbench-static-tile-420m-8x8-cmp (Failed)
183 - tjbench-static-tile-422m-8x8-cmp (Failed)
184 - tjbench-static-tile-420m-16x16-cmp (Failed)
185 - tjbench-static-tile-422m-16x16-cmp (Failed)
186 - tjbench-static-tile-420m-32x32-cmp (Failed)
187 - tjbench-static-tile-422m-32x32-cmp (Failed)
188 - tjbench-static-tile-420m-64x64-cmp (Failed)
189 - tjbench-static-tile-422m-64x64-cmp (Failed)
190 - tjbench-static-tile-420m-128x128-cmp (Failed)
191 - tjbench-static-tile-422m-128x128-cmp (Failed)
193 - cjpeg-static-rgb-islow-cmp (Failed)
195 - djpeg-static-rgb-islow-cmp (Failed)
198 - jpegtran-static-icc-cmp (Failed)
200 - djpeg-static-rgb-islow-565-cmp (Failed)
202 - djpeg-static-rgb-islow-565D-cmp (Failed)
204 - cjpeg-static-422-ifast-opt-cmp (Failed)
206 - djpeg-static-422-ifast-cmp (Failed)
208 - djpeg-static-422m-ifast-cmp (Failed)
210 - djpeg-static-422m-ifast-565-cmp (Failed)
212 - djpeg-static-422m-ifast-565D-cmp (Failed)
214 - cjpeg-static-420-q100-ifast-prog-cmp (Failed)
216 - djpeg-static-420-q100-ifast-prog-cmp (Failed)
218 - djpeg-static-420m-q100-ifast-prog-cmp (Failed)
220 - cjpeg-static-gray-islow-cmp (Failed)
222 - djpeg-static-gray-islow-cmp (Failed)
224 - djpeg-static-gray-islow-rgb-cmp (Failed)
226 - djpeg-static-gray-islow-565-cmp (Failed)
228 - djpeg-static-gray-islow-565D-cmp (Failed)
230 - cjpeg-static-420s-ifast-opt-cmp (Failed)
232 - cjpeg-static-3x2-float-prog-cmp (Failed)
234 - djpeg-static-3x2-float-prog-cmp (Failed)
236 - cjpeg-static-3x2-ifast-prog-cmp (Failed)
238 - djpeg-static-3x2-ifast-prog-cmp (Failed)
240 - cjpeg-static-420-islow-ari-cmp (Failed)
244 - cjpeg-static-444-islow-progari-cmp (Failed)
289 - djpeg-static-420-islow-prog-crop62x62_71_71-cmp (Failed)
294 - djpeg-static-444-islow-skip1_6-cmp (Failed)
297 - djpeg-static-444-islow-prog-crop98x98_13_13-cmp (Failed)
300 - djpeg-static-444-islow-ari-crop37x37_0_0-cmp (Failed)
Errors while running CTest
Cmake command for windows, similar for linux and mac.
cmake --check-system-vars -DCMAKE_BUILD_TYPE=Debug -DCMAKE_SYSTEM_VERSION=10.0.17763.0 -DCMAKE_C_FLAGS="/sdl /W3 /MP /GS /D_SDL_BANNED_RECOMMENDED" -DCMAKE_C_FLAGS_DEBUG="/MDd /Od /RTC1" -DCMAKE_C_FLAGS_RELEASE="/MD" -DCMAKE_EXE_LINKER_FLAGS="/NXCOMPAT /DYNAMICBASE" -DCMAKE_SHARED_LINKER_FLAGS="/NXCOMPAT /DYNAMICBASE" -DCMAKE_MODULE_LINKER_FLAGS="/NXCOMPAT /DYNAMICBASE" -DBUILD_SHARED_LIBS=ON -DWIN32=ON -DWITH_JPEG8=1 -DCMAKE_ASM_NASM_COMPILER="S:/projects/nasm/builds/master/output/Debug/bin/nasm.exe" -DCMAKE_INSTALL_PREFIX="S:/projects/libjpeg-turbo/builds/master/output/Debug" -G "Visual Studio 15 2017 Win64" -T v141 ../../worktrees/master
cmake --build . --target ALL_BUILD --config Debug --clean-first
ctest -C Debug --no-compress-output -V -T Test
cmake --build . --target INSTALL --config Debug
DRC
Feb 11, 2019, 1:35:52 PM2/11/19
to libjpeg-t...@googlegroups.com
No idea. For starters, you're building 2.0 beta1, which ceased being
supported when 2.0.0 was released. I don't have Visual Studio 2017, but
I just tried your settings with Visual Studio 2010 and couldn't
reproduce any problems. It would help if you examined the verbose
output of ctest and posted example output from a test that failed. It
is impossible to know why the tests are failing without seeing that output.
> --
> You received this message because you are subscribed to the Google
> Groups "libjpeg-turbo User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libjpeg-turbo-u...@googlegroups.com
> <mailto:libjpeg-turbo-u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/libjpeg-turbo-users/27524514-a859-4958-bb3f-1d7cfafa1168%40googlegroups.com
> <https://groups.google.com/d/msgid/libjpeg-turbo-users/27524514-a859-4958-bb3f-1d7cfafa1168%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
supported when 2.0.0 was released. I don't have Visual Studio 2017, but
I just tried your settings with Visual Studio 2010 and couldn't
reproduce any problems. It would help if you examined the verbose
output of ctest and posted example output from a test that failed. It
is impossible to know why the tests are failing without seeing that output.
> You received this message because you are subscribed to the Google
> Groups "libjpeg-turbo User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libjpeg-turbo-u...@googlegroups.com
> <mailto:libjpeg-turbo-u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/libjpeg-turbo-users/27524514-a859-4958-bb3f-1d7cfafa1168%40googlegroups.com
> <https://groups.google.com/d/msgid/libjpeg-turbo-users/27524514-a859-4958-bb3f-1d7cfafa1168%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
gia
Feb 16, 2019, 2:03:21 PM2/16/19
to libjpeg-turbo User Discussion/Support
There are many tests failing, so I didn't collect the outputs, but I checked if md5 was correct using openssl and yes the linux and mac versions output correctly, windows doesnt.
I collected logs, I tried with nasm 2.10, 2.14rc0 and 2.14rc15, and with three libjpegturbo versions: tags/2.0.0, tags/2.0.2 and branch/1.5.x . Attached builds.rar with several build + test logs:
Used roughly these command line calls:
rm -rf *
cmake --check-system-vars -DCMAKE_BUILD_TYPE=Debug -DCMAKE_SYSTEM_VERSION=10.0.17763.0 -DWIN32=ON -DCMAKE_INSTALL_PREFIX="S:/projects/libjpeg-turbo/builds/master/output/Debug" -DWITH_ARITH_DEC=1 -DWITH_ARITH_ENC=1 -DWITH_TURBOJPEG=1 -DWITH_MEM_SRCDST=1 -DWITH_SIMD=1 -G "Visual Studio 15 2017 Win64" -T v141 ../../worktrees/master
cmake --build . --config Debug --clean-first
ctest --debug -C Debug --no-compress-output -VV -T Test
cmake --check-system-vars -DCMAKE_BUILD_TYPE=Debug -DCMAKE_SYSTEM_VERSION=10.0.17763.0 -DWIN32=ON -DCMAKE_INSTALL_PREFIX="S:/projects/libjpeg-turbo/builds/master/output/Debug" -DWITH_ARITH_DEC=1 -DWITH_ARITH_ENC=1 -DWITH_TURBOJPEG=1 -DWITH_MEM_SRCDST=1 -DWITH_SIMD=1 -G "Visual Studio 15 2017 Win64" -T v141 ../../worktrees/master
cmake --build . --config Debug --clean-first
ctest --debug -C Debug --no-compress-output -VV -T Test
The logs are named with <version of nasm>-<version of libjpegturbo>-R-<Generator x86="Visual Studio 15 2017", x64="Visual Studio 15 2017 Win64">-j6-<on/off options, n for 0, y for 1, A=with_arith, T=with_turbojpeg, M=with_mem_srcdst, S=with_simd>.log
While the most complete log set is with nasm 2.14rc0 and libjpeg-turbo 2.0.2, I did also try different jpeg emulations and Debug vs Release (but didnt automate these so I dont have them represented), no matter what I tried all builds had test errors. Also tried to remove the no compress output from ctest.
Attached two test outputs, testout_444_islow_ari_crop37x37,0,0.ppm is the result of test 300: for 214-2.0.2-R-x86-j6-yT-yA-yM-yS.log (nasm 2.14rc0, libjpeg-turbo 2.0.2, Debug, x86, jpeg 6, with turbo, with arith, with mem, with simd) which uses djpeg, and testout_444_islow_progari.jpg is test 244 which uses cjpeg. I originally thought it was a nasm problem but since it has failures for such variation I'm taking it is just some wrong define on the source code when processed for windows or something like that, I'll try to figure it out.
> an email to libjpeg-turbo-users+unsub...@googlegroups.com
> <mailto:libjpeg-turbo-users+unsub...@googlegroups.com>.
gia
Feb 17, 2019, 10:35:18 AM2/17/19
to libjpeg-turbo User Discussion/Support
Just tried the official prebuilt binaries, same problem, they generate wrong outputs.
DRC
Feb 17, 2019, 12:28:12 PM2/17/19
to libjpeg-t...@googlegroups.com
How did you try them? The official binaries are built using Visual C++
2010, and their correctness is tested automatically as part of the build
process (using the same built-in test suite that you are attempting to
run.) So the official binaries are definitely not the problem.
I strongly suspect that Visual Studio 2017 is doing something
differently than previous Visual Studio releases, and whatever it's
doing is causing libjpeg-turbo to produce different mathematical
results. Have you tried an earlier compiler? There is probably come
Visual C++ switch or option that will revert the behavior, but without
spending several hours digging into it, I have no way of knowing. And
given the funding situation with this project, I probably won't be able
to look into this until April.
DRC
> <mailto:libjpeg-turbo-u...@googlegroups.com>.
> <https://groups.google.com/d/msgid/libjpeg-turbo-users/b7adfede-2cb6-4f30-9ee0-dffae716a168%40googlegroups.com?utm_medium=email&utm_source=footer>.
2010, and their correctness is tested automatically as part of the build
process (using the same built-in test suite that you are attempting to
run.) So the official binaries are definitely not the problem.
I strongly suspect that Visual Studio 2017 is doing something
differently than previous Visual Studio releases, and whatever it's
doing is causing libjpeg-turbo to produce different mathematical
results. Have you tried an earlier compiler? There is probably come
Visual C++ switch or option that will revert the behavior, but without
spending several hours digging into it, I have no way of knowing. And
given the funding situation with this project, I probably won't be able
to look into this until April.
DRC
> --
> You received this message because you are subscribed to the Google
> Groups "libjpeg-turbo User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libjpeg-turbo-u...@googlegroups.com
> You received this message because you are subscribed to the Google
> Groups "libjpeg-turbo User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> <mailto:libjpeg-turbo-u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/libjpeg-turbo-users/b7adfede-2cb6-4f30-9ee0-dffae716a168%40googlegroups.com
> <https://groups.google.com/d/msgid/libjpeg-turbo-users/b7adfede-2cb6-4f30-9ee0-dffae716a168%40googlegroups.com?utm_medium=email&utm_source=footer>.
gia
Feb 17, 2019, 1:46:51 PM2/17/19
to libjpeg-turbo User Discussion/Support
Yes, I ran the prebuilt binary installer for the same version I built. Copied the command line ctest uses for a specific test which had an image from /testimages as input (243), ran this but using the prebuilt binary path for cjpeg. It failed to run. Used
dependency walker, was missing 2010 redistributable, installed it,
dependency walker was ok. The test ran and produced the same output as my built copy, used this output to run the next test, 244, which uses djpeg, obtained the same result as my built copy, same hash.
On Sunday, February 10, 2019 at 9:46:01 PM UTC-5, gia wrote:
gia
Feb 17, 2019, 3:03:24 PM2/17/19
to libjpeg-turbo User Discussion/Support
Just tried the other installers, all of them produce the same (wrong) hashes. 2.0.2 gcc, gcc64, vc, vc64
DRC
Feb 17, 2019, 4:04:02 PM2/17/19
to libjpeg-t...@googlegroups.com
This is a shot in the dark, but try setting JSIMD_FORCESSE2=1 in the
environment. Maybe there's something incompatible between your
machine's AVX2 implementation and our AVX2 SIMD extensions.
If doing that actually works, then please send me the specs on your CPU
and O/S (make/model of the CPU and exact O/S revision you are running.)
> <https://groups.google.com/d/msgid/libjpeg-turbo-users/79d2c8e8-97c1-41dd-ac42-0ed1d519e18f%40googlegroups.com?utm_medium=email&utm_source=footer>.
environment. Maybe there's something incompatible between your
machine's AVX2 implementation and our AVX2 SIMD extensions.
If doing that actually works, then please send me the specs on your CPU
and O/S (make/model of the CPU and exact O/S revision you are running.)
> --
> You received this message because you are subscribed to the Google
> Groups "libjpeg-turbo User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libjpeg-turbo-u...@googlegroups.com
> <mailto:libjpeg-turbo-u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/libjpeg-turbo-users/79d2c8e8-97c1-41dd-ac42-0ed1d519e18f%40googlegroups.com
> You received this message because you are subscribed to the Google
> Groups "libjpeg-turbo User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libjpeg-turbo-u...@googlegroups.com
> <mailto:libjpeg-turbo-u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/libjpeg-turbo-users/79d2c8e8-97c1-41dd-ac42-0ed1d519e18f%40googlegroups.com?utm_medium=email&utm_source=footer>.
gia
Feb 18, 2019, 12:04:59 AM2/18/19
to libjpeg-turbo User Discussion/Support
No change to hashes sadly, I'm using an i7 8th gen, os Win 10 latest update. After that also tried to forcenone, mpi and all the other define flags in that section and to combo with the no huffman setting, no changes as well.
C:\libjpeg-turbo-gcc64\bin>cjpeg.exe "-dct" "int" "-arithmetic" "-sample" "1x1" "-outfile" "testout_444_islow_ari.jpg" "testorig.ppm"
C:\libjpeg-turbo-gcc64\bin>djpeg.exe "-dct" "int" "-crop" "37x37+0+0" "-ppm" "-outfile" "testout_444_islow_ari_crop37x37,0,0.ppm" "testout_444_islow_ari.jpg"
C:\libjpeg-turbo-gcc64\bin>djpeg.exe "-dct" "int" "-crop" "37x37+0+0" "-ppm" "-outfile" "testout_444_islow_ari_crop37x37,0,0.ppm" "testout_444_islow_ari.jpg"
MD5(testout_444_islow_ari.jpg)= 2a790c72c335012c0d9668c8162fffd9
MD5(testout_444_islow_ari_crop37x37,0,0.ppm)= a8adb78fa073bdf126dd9cec56689d33
DRC
Feb 18, 2019, 12:19:28 AM2/18/19
to libjpeg-t...@googlegroups.com
Does libjpeg-turbo 1.5.3 exhibit the same issue?
> <https://groups.google.com/d/msgid/libjpeg-turbo-users/5207fa42-c90c-442d-b9db-cd8afe972af0%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google
> Groups "libjpeg-turbo User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libjpeg-turbo-u...@googlegroups.com
> <mailto:libjpeg-turbo-u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/libjpeg-turbo-users/5207fa42-c90c-442d-b9db-cd8afe972af0%40googlegroups.com
> You received this message because you are subscribed to the Google
> Groups "libjpeg-turbo User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libjpeg-turbo-u...@googlegroups.com
> <mailto:libjpeg-turbo-u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/libjpeg-turbo-users/5207fa42-c90c-442d-b9db-cd8afe972af0%40googlegroups.com?utm_medium=email&utm_source=footer>.
DRC
Feb 18, 2019, 12:40:53 AM2/18/19
to libjpeg-t...@googlegroups.com
If, by some miracle, 1.5.3 works fine, then you're going to have to use
'git bisect' to identify the commit that introduced the error. If 1.5.3
also fails in the same way, then I'm completely stymied. No one else
has reported anything like this, and bear in mind that libjpeg-turbo
2.0.x is used in Chrome and Firefox, so if those browsers work properly
for you, then I have no idea why the standalone library doesn't. The
color components in the JPEG image you sent were shifted-- red->green,
blue->red, green->blue. I can unshift them and make the decompressed
image appear correct:
convert testout_444_islow_ari_crop37x37,0,0.ppm -separate -swap 0,1
-combine testout_444_islow_ari_crop37x37,0,0-1.ppm
convert testout_444_islow_ari_crop37x37,0,0-1.ppm -separate -swap
1,2 -combine testout_444_islow_ari_crop37x37,0,0-2.ppm
but the hash is still not correct. Most of the pixels are identical to
the correct image, but a few are wildly off. If the color shifting is
occurring on the compression side, then that would affect the
subsampling, so it's not surprising that color shifting the decompressed
image doesn't produce exactly the correct result.
Hopefully this gives you some information that will help you diagnose
the problem. This is the limit of the help I can provide.
On 2/17/19 11:04 PM, gia wrote:
'git bisect' to identify the commit that introduced the error. If 1.5.3
also fails in the same way, then I'm completely stymied. No one else
has reported anything like this, and bear in mind that libjpeg-turbo
2.0.x is used in Chrome and Firefox, so if those browsers work properly
for you, then I have no idea why the standalone library doesn't. The
color components in the JPEG image you sent were shifted-- red->green,
blue->red, green->blue. I can unshift them and make the decompressed
image appear correct:
convert testout_444_islow_ari_crop37x37,0,0.ppm -separate -swap 0,1
-combine testout_444_islow_ari_crop37x37,0,0-1.ppm
convert testout_444_islow_ari_crop37x37,0,0-1.ppm -separate -swap
1,2 -combine testout_444_islow_ari_crop37x37,0,0-2.ppm
but the hash is still not correct. Most of the pixels are identical to
the correct image, but a few are wildly off. If the color shifting is
occurring on the compression side, then that would affect the
subsampling, so it's not surprising that color shifting the decompressed
image doesn't produce exactly the correct result.
Hopefully this gives you some information that will help you diagnose
the problem. This is the limit of the help I can provide.
On 2/17/19 11:04 PM, gia wrote:
gia
Feb 18, 2019, 4:16:22 PM2/18/19
to libjpeg-turbo User Discussion/Support
branch/1.5.x failed, tags/1.5.3 failed, 1.5.2, 1.51, 1.5.0, 1.4.0, 1.3.0, 1.21 failed. 1.2.0 and 1.1.0 fail to build (illegal characters in shell command). 1.0.0 doesn't use cmake and I don't have a make env for windows atm. All of these built with nasm 2.14rc0.
prebuilt 1.5.3 gave same hashes as 2.0.2
prebuilt 1.2.1 has different tests (and thus different hashes) but these failed among others:
cjpeg.exe "-dct" "int" "-outfile" "testoutint.jpg" "S:/projects/libjpeg-turbo/worktrees/master/testimages/testorig.ppm"
MD5(testoutint.jpg)= d1720a0d43135d5a894cdf23e6e5a573, expected MD5(testimgint.jpg)= 9a68f56bc76e466aa7e52f415d0f4a5f
djpeg.exe "-dct" "fast" "-ppm" "-outfile" "testoutfst.ppm" "S:/projects/libjpeg-turbo/worktrees/master/testimages/testorig.jpg"
MD5(testoutfst.ppm)= 048298a2d2410261c0533cb97bcfef23, expected MD5(testimgfst.ppm)= 1b7fb19872537aa92e331d35169b0e92
1.2.1 had virus alerts on vc, gcc and gcc64
Do you know the build env used by the official releases for windows? VS2010, what processor? os? XP? Win8? vc env or mingw64? I recall there was a big change from xp to win7/10 and many things broke, so maybe some code is not working the same as it should, the specific nasm I should be using could be helpful as well. I'll try to obtain an old computer like that to see if it works.
DRC
Feb 18, 2019, 5:26:47 PM2/18/19
to libjpeg-t...@googlegroups.com
It varies. My personal build environment, which is used to produce the
releases, is Windows 7 (latest updates) with Visual C++ 2010 from the
Windows 7 SDK: http://msdn.microsoft.com/en-us/windows/bb980924.aspx
(this is a command-line-only version.) But I've also tested with other
Visual C++ releases. Originally we were using VC++ 2008
(https://libjpeg-turbo.org/Documentation/OfficialBinaries), and I've
also tested with the full version of 2010, 2012 and 2015 (both
command-line and IDE.) I have several different machines with different
CPU types (both AMD and Intel), and which one I use depends on what I'm
doing. I've built and run libjpeg-turbo for Windows successfully on all
of them. The one I use the most often has an Intel Core i7, and I use
it the most often because that's the only machine I have access to that
supports AVX2.
Our CI build environment (AppVeyor) runs Windows Server 2012, and I use
the full version of Visual Studio 2010 that is installed in that
environment. I'll re-iterate that, every time a binary is produced of
libjpeg-turbo-- either for a release or a CI pre-release build-- the
entire test suite is run to validate its mathematical correctness.
Both my machine and the AppVeyor build environment use NASM 2.10.x,
since that is the minimum version necessary to support the AVX2 SIMD
extensions in libjpeg-turbo 2.0.x. But libjpeg-turbo 1.5.3 used an
earlier NASM version, and many people use YASM instead of NASM. I am
unaware of any problems with NASM or YASM on Windows that affects
libjpeg-turbo, other than the fact that you have to use (respectively)
2.10.x or 1.2.0 or later to get AVX2 support.
There are many many people worldwide building and running this software
on a daily basis, using many different CPUs and compilers and operating
systems. There are several projects, such as Chocolatey and vcpkg, that
release their own builds of libjpeg-turbo for Visual C++. I struggle to
imagine that someone would have run into this problem already and not
notified me about it. Then again, I struggle to imagine how the same
executable can produce swapped color channels on two different
Windows/x86 machines, and I struggle equally to imagine why only
libjpeg-turbo is experiencing that problem. It really seems to be
something with the machine, though. I am satisfied that your tests have
eliminated the compiler and the libjpeg-turbo code as causes.
> <https://groups.google.com/d/msgid/libjpeg-turbo-users/fc313335-2d6a-43ed-97b0-4d1e27cc9ed4%40googlegroups.com?utm_medium=email&utm_source=footer>.
releases, is Windows 7 (latest updates) with Visual C++ 2010 from the
Windows 7 SDK: http://msdn.microsoft.com/en-us/windows/bb980924.aspx
(this is a command-line-only version.) But I've also tested with other
Visual C++ releases. Originally we were using VC++ 2008
(https://libjpeg-turbo.org/Documentation/OfficialBinaries), and I've
also tested with the full version of 2010, 2012 and 2015 (both
command-line and IDE.) I have several different machines with different
CPU types (both AMD and Intel), and which one I use depends on what I'm
doing. I've built and run libjpeg-turbo for Windows successfully on all
of them. The one I use the most often has an Intel Core i7, and I use
it the most often because that's the only machine I have access to that
supports AVX2.
Our CI build environment (AppVeyor) runs Windows Server 2012, and I use
the full version of Visual Studio 2010 that is installed in that
environment. I'll re-iterate that, every time a binary is produced of
libjpeg-turbo-- either for a release or a CI pre-release build-- the
entire test suite is run to validate its mathematical correctness.
Both my machine and the AppVeyor build environment use NASM 2.10.x,
since that is the minimum version necessary to support the AVX2 SIMD
extensions in libjpeg-turbo 2.0.x. But libjpeg-turbo 1.5.3 used an
earlier NASM version, and many people use YASM instead of NASM. I am
unaware of any problems with NASM or YASM on Windows that affects
libjpeg-turbo, other than the fact that you have to use (respectively)
2.10.x or 1.2.0 or later to get AVX2 support.
There are many many people worldwide building and running this software
on a daily basis, using many different CPUs and compilers and operating
systems. There are several projects, such as Chocolatey and vcpkg, that
release their own builds of libjpeg-turbo for Visual C++. I struggle to
imagine that someone would have run into this problem already and not
notified me about it. Then again, I struggle to imagine how the same
executable can produce swapped color channels on two different
Windows/x86 machines, and I struggle equally to imagine why only
libjpeg-turbo is experiencing that problem. It really seems to be
something with the machine, though. I am satisfied that your tests have
eliminated the compiler and the libjpeg-turbo code as causes.
> --
> You received this message because you are subscribed to the Google
> Groups "libjpeg-turbo User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libjpeg-turbo-u...@googlegroups.com
> <mailto:libjpeg-turbo-u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/libjpeg-turbo-users/fc313335-2d6a-43ed-97b0-4d1e27cc9ed4%40googlegroups.com
> You received this message because you are subscribed to the Google
> Groups "libjpeg-turbo User Discussion/Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libjpeg-turbo-u...@googlegroups.com
> <mailto:libjpeg-turbo-u...@googlegroups.com>.
> To view this discussion on the web visit
> <https://groups.google.com/d/msgid/libjpeg-turbo-users/fc313335-2d6a-43ed-97b0-4d1e27cc9ed4%40googlegroups.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages