tests/jpeg/jpeg_read.c fails with libjpeg8/9 due different subsampling method
On Debian Wheezy amd64 the jpeg_read.c test fails with:
jpeg/jpeg_read.c:28: Total pixels changed: 18218 with a maximum channel difference of 0. jpeg/jpeg_read.c:29: gdAssertImageEqualsToFile failed.
Comments (14)
-
Account Deleted reporter -
Not sure I can do anything for that, the difference is too big to be correct. Maybe default params, not sure :)
-
Account Deleted reporter Well, I might as well fill a bug in libjpeg8(?) in Debian, since GD probably won't be a single libjpeg8 user to be hit by the difference.
-
Tests pass with libjpeg latest v9 and v8 (win and linux) here, self built. I suspect a bad patch in the distro package..
-
Account Deleted reporter There are no distro patches. It still might be something broken on my system. I'll try it in clean chroot.
-
Account Deleted reporter Still failing, even with custom (latest) libjpeg and libpng... any other idea what might be causing the difference?
root@howl:/tmp/buildd/gd-libgd/tests# LD_LIBRARY_PATH=../src/.libs/ jpeg/.libs/jpeg_read jpeg/jpeg_read.c:28: Total pixels changed: 18218 with a maximum channel difference of 0. jpeg/jpeg_read.c:29: gdAssertImageEqualsToFile failed. root@howl:/tmp/buildd/gd-libgd/tests# ldd jpeg/.libs/jpeg_read linux-vdso.so.1 => (0x00007fffaebee000) /usr/lib/cowdancer/libcowdancer.so (0x00007f5a39424000) libgd.so.3 => not found libvpx.so.1 => /usr/lib/x86_64-linux-gnu/libvpx.so.1 (0x00007f5a39180000) libXpm.so.4 => /usr/lib/x86_64-linux-gnu/libXpm.so.4 (0x00007f5a38f6f000) libjpeg.so.9 => /usr/local/lib/libjpeg.so.9 (0x00007f5a38d34000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f5a38afc000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f5a388e5000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5a38663000) libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x00007f5a38430000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f5a38191000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5a37e07000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5a37c02000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5a379e6000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f5a376aa000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f5a3747f000) /lib64/ld-linux-x86-64.so.2 (0x00007f5a3962a000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f5a3725f000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f5a3705b000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f5a36e56000)
-
Account Deleted reporter JFTR It's definitely something in the Debian wheezy, because the failure doesn't happen in squeeze.
-
Account Deleted reporter So I can reproduce the bug by linking to libjpeg8 on Debian squeeze (current stable) as well, so it has to be something which has changed in libjpeg8.
Debian squeeze libjpeg62 (OK):
# LD_LIBRARY_PATH=../src/.libs jpeg/.libs/jpeg_read GD Debug: gd-jpeg: gd JPEG version 1.0 GD Debug: gd-jpeg: JPEG library version 80, 8-bit sample values GD Debug: sizeof: 656 GD Debug: gd-jpeg: JPEG image information:GD Debug: JFIF version 1.01GD Debug: 256x256 (raw) / 256x256 (scaled) 8-bitGD Debug: baselineGD Debug: image, 0 quantized colors, GD Debug: YCbCr (a.k.a. YUV)GD Debug: colorspace jpeg/jpeg_read.c:28: Total pixels changed: 18218 with a maximum channel difference of 0. jpeg/jpeg_read.c:29: gdAssertImageEqualsToFile failed.
Debian squeeze libjpeg8 (FAIL):
# LD_LIBRARY_PATH=../src/.libs jpeg/.libs/jpeg_read GD Debug: gd-jpeg: gd JPEG version 1.0 GD Debug: gd-jpeg: JPEG library version 80, 8-bit sample values GD Debug: sizeof: 656 GD Debug: gd-jpeg: JPEG image information:GD Debug: JFIF version 1.01GD Debug: 256x256 (raw) / 256x256 (scaled) 8-bitGD Debug: baselineGD Debug: image, 0 quantized colors, GD Debug: YCbCr (a.k.a. YUV)GD Debug: colorspace jpeg/jpeg_read.c:28: Total pixels changed: 18218 with a maximum channel difference of 0. jpeg/jpeg_read.c:29: gdAssertImageEqualsToFile failed.
Debian wheezy libjpeg8 (FAIL):
# LD_LIBRARY_PATH=../src/.libs jpeg/.libs/jpeg_read GD Debug: gd-jpeg: gd JPEG version 1.0 GD Debug: gd-jpeg: JPEG library version 80, 8-bit sample values GD Debug: sizeof: 656 GD Debug: gd-jpeg: JPEG image information:GD Debug: JFIF version 1.01GD Debug: 256x256 (raw) / 256x256 (scaled) 8-bitGD Debug: baselineGD Debug: image, 0 quantized colors, GD Debug: YCbCr (a.k.a. YUV)GD Debug: colorspace jpeg/jpeg_read.c:28: Total pixels changed: 18218 with a maximum channel difference of 0. jpeg/jpeg_read.c:29: gdAssertImageEqualsToFile failed.
Ubuntu precise (OK) uses libjpeg-turbo8 and does not fail.
E.g. I am pretty sure there's something in libjpeg8 which makes the test incompatible with our current tests.
Maybe we should just create two independent test jpegs and #ifdef the file based on JPEG library version?
-
Yes it makes sense to have two tests then,
-
Ok, this test fails now too on Windows with current master. Not sure why, did we change something lately?
-
Account Deleted reporter Just those Ex functions, which add a message handler, but I don't think this should change anything in the image :). Maybe you were linking to some other jpeg library before?
-
Sorry, can't try with jpeg8 or jpeg9 ad Fedora doesn't support this.
FYI : http://lists.fedoraproject.org/pipermail/devel/2013-January/176281.html and http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
... was rejected by ISO ...
-
Account Deleted reporter -
- changed status to resolved
tests pass already.
- Log in to comment
So far the only difference I have noticed might be the library version:
Debian wheezy (FAIL): libpng12-0 1.2.49-1 libjpeg8 8d-1
Ubuntu precise (PASS): libjpeg8 8c-2ubuntu7 libpng12-0 1.2.46-3ubuntu4