GNOME Bugzilla – Bug 666417
FAIL: run-gamma.xml.sh
Last modified: 2013-02-07 05:27:18 UTC
Created attachment 203748 [details] output/gamma.png from 0.1.8 Using the latest release (0.1.8, i couldn't select it in the version box): /var/tmp/paludis/build/media-libs-gegl-0.1.8/work/gegl-0.1.8/tests/compositions/reference/gamma.png and /var/tmp/paludis/build/media-libs-gegl-0.1.8/work/gegl-0.1.8/tests/compositions/output/gamma.png differ wrong pixels : 17886/31680 (56.46%) max Δe : 29.894 avg Δe (wrong) : 1.482(wrong) 0.837(total) I've backported the test to 0.1.6 to see if it was any different there but i got roughly the same so it doesnt appear to be anything new: /var/tmp/paludis/build/media-libs-gegl-0.1.6/work/gegl-0.1.6/tests/compositions/reference/gamma.png and /var/tmp/paludis/build/media-libs-gegl-0.1.6/work/gegl-0.1.6/tests/compositions/output/gamma.png differ wrong pixels : 18160/31680 (57.32%) max Δe : 30.400 avg Δe (wrong) : 1.439(wrong) 0.825(total) Ive attached the gamma.png created by version 0.1.8 If you need any more information id be happy to provide it.
I have been seeing similar results, while the test is passing on our continous integration server in australia... I suspect different versions of the C library contain different implementations of pow that behave differently... The test was marked as broken for the 0.2.0 release. Leaving the issue open, as it is unresolved.
*** Bug 693120 has been marked as a duplicate of this bug. ***
Yes, I'm also under the impression that newer versions of glibc fail on 64 bit, see also some bugreports in the glibc bugtracker [1],[2] Is there any glibc version known to work or could using a local 32 bit build of glibc on this 64 bit platform solve/alleviate the problem? [1] http://sourceware.org/bugzilla/show_bug.cgi?id=1161 [2] http://sourceware.org/bugzilla/show_bug.cgi?id=14473
I think it is more likely a difference in libjpeg that is causing the failure. It is (was) possible to configure libjpeg to use a float or integer or fast discrete cosine transform implementation, and probably nowadays also mmx or sse are causing other slight differences. These differences are hardly noticeable visually, but raising them to the gamma amplify them. The errors in powf are really small (I'd say at most 1/65535 once saved in a 16 bit png). I suggest to use jpegs only to test loading and saving them, for all other operations it is better to use a lossless format. Another variable that possibly causes different GEGL renderings is BABL_TOLERANCE, I don't know whether it is set during make check, but it should, particularly if every now and then, its default value is changed. Anyway on my x86_64 fedora core 18 run-gamma.xml.sh is NOT failing: glibc.x86_64 2.16-28.fc18 glibc-common.x86_64 2.16-28.fc18 glibc-devel.x86_64 2.16-28.fc18 glibc-headers.x86_64 2.16-28.fc18 glibc.x86_64 2.16-28.fc18 libjpeg-turbo.x86_64 1.2.1-3.fc18 libjpeg-turbo-devel.x86_64 1.2.1-3.fc18 openjpeg-libs.x86_64 1.5.1-4.fc18
The fuzz accepted by GEGLs tests should more than cover variations due to BABL_TOLERANCE. Thank you for remembering that the issue likely is in libjpeg (I recall this having been pointed out before, and now being forgotten). I'll replace the gamma test with one using a PNG source image and see how we fare.
commit ac084efe6fcb609f87b94f7ff448ea1e697c1e0d Author: Øyvind Kolås <pippin@gimp.org> Date: Thu Feb 7 09:03:48 2013 +1100 tests/gamma: do not use JPG as source image The gamma test has been failing on various machines, initial suspicions were towards the 64bit and maths implementations, it turned out that different versions of libjpeg was causing it. Using a PNG image should prove more stable for this test. Hopefully this fixes bug #666417
I tested on the buildbot and it works - thank you for fixing it so quickly! However, we're stuck now in a another failing test, see bug #693293.