different (md5sum) results for 32-bit and 64-bit

[pgajdos]

Hi,

this is rather question than description of a bug. We get different results for 32-bit (tested: i586) and 64 bit (tested: x86_64) for some formats with 7.0.8-12:

PNG

$ convert rose: rose.png
$ md5sum rose.png

gives

i586   9416d44d5aef92ca8f85830bd562652d  rose.png
x86_64 e98180eb056f693502194c0d0d8bf6a6  rose.png

GIF

$ convert rose: rose.gif
$ md5sum rose.gif
$

gives

i586   45f2bcb51b03fdfd279d97b7152c9a1b  rose.gif
x86_64 a648281ba8605074beac7e0679f4b379  rose.gif

BMP
i586

$ convert rose: rose.bmp
$ md5sum rose.bmp

gives

i586   b0a01b6a7fdadbe540ea325e134903db  rose.bmp
x86_64 b0a01b6a7fdadbe540ea325e134903db  rose.bmp

SVG

$ convert rose: rose.svg
$ md5sum rose.svg

gives

i586   652e431bc537bcc37d8511498dbffb13  rose.svg
x86_64 d3fa380468da4493fef3511b4127d3c8  rose.svg

Why is that?

[bmwiedemann]

At least in the .png and .svg cases you need to add -strip to not add the current time into the rose.png

Background is that we are packaging such .png files in noarch openSUSE packages and having these vary between architectures makes it much harder to verify that packages are really built the way they are supposed to.
See also http://bugzilla.suse.com/show_bug.cgi?id=1110149 and https://bugzilla.suse.com/show_bug.cgi?id=1109534

[bmwiedemann]

Made this nicer reproducer with ImageMagick-7.0.8.12 - still pretty much the same results:

for ext in bmp gif png pnm svg tif ; do
  for a in i586 x86_64 ; do
    r=/var/tmp/build-root/standard-$a/ ; 
    chroot $r convert -strip rose: /tmp/out.$ext &&
    md5sum $r/tmp/out.$ext; 
  done;
done

b0a01b6a7fdadbe540ea325e134903db  /var/tmp/build-root/standard-i586//tmp/out.bmp
b0a01b6a7fdadbe540ea325e134903db  /var/tmp/build-root/standard-x86_64//tmp/out.bmp
45f2bcb51b03fdfd279d97b7152c9a1b  /var/tmp/build-root/standard-i586//tmp/out.gif
a648281ba8605074beac7e0679f4b379  /var/tmp/build-root/standard-x86_64//tmp/out.gif
5f3e8d0950e52f6c61a1a78ab7704e31  /var/tmp/build-root/standard-i586//tmp/out.png
dcecde54bb93b298055c8303865cc786  /var/tmp/build-root/standard-x86_64//tmp/out.png
dab32dd26b8e536dc9e633181199a1dd  /var/tmp/build-root/standard-i586//tmp/out.pnm
dab32dd26b8e536dc9e633181199a1dd  /var/tmp/build-root/standard-x86_64//tmp/out.pnm
4bdf803a9505b4c7fdae2b38e1a9452a  /var/tmp/build-root/standard-i586//tmp/out.svg
70cbce75ad861e1a61d4f59b0a2a5ad8  /var/tmp/build-root/standard-x86_64//tmp/out.svg
9bc37477460b15c22e0416fe6880b582  /var/tmp/build-root/standard-i586//tmp/out.tif
9bc37477460b15c22e0416fe6880b582  /var/tmp/build-root/standard-x86_64//tmp/out.tif

I noticed that file sizes are very different and bit/color differs:

-rw-r--r-- 1 root root 11878 Jan 20 03:22 /var/tmp/build-root/standard-i586/tmp/out.png
-rw-r--r-- 1 root root  6799 Jan 20 03:22 /var/tmp/build-root/standard-x86_64/tmp/out.png
/var/tmp/build-root/standard-i586/tmp/out.png:   PNG image data, 70 x 46, 16-bit/color RGB, non-interlaced
/var/tmp/build-root/standard-x86_64/tmp/out.png: PNG image data, 70 x 46, 8-bit/color RGB, non-interlaced

.svg just embeds png data.

For .gif the difference is more subtle, starting with (but not limited to)

 00000000: 4749 4638 3961 4600 2e00 f700 002b 2f1e  GIF89aF......+/.
-00000010: 2d2b 2b2a 2927 322d 2b37 2c2a 2d32 2c2d  -++*)'2-+7,*-2,-
+00000010: 2d2b 2b2a 2927 332d 2b37 2c2a 2d32 2c2d  -++*)'3-+7,*-2,-
 00000020: 362a 3333 2d3a 332d 333c 2c3c 3a2d 3637  6*33-:3-3<,<:-67
 00000030: 242d 2e31 3434 313b 3532 363b 333b 3b33  $-.1441;526;3;;3
 00000040: 3b3d 3930 2f30 4439 2d43 3b32 4a3d 3243  ;=90/0D9-C;2J=2C
@@ -15,35 +15,35 @@
 000000e0: 7b47 6a63 5469 6657 6778 5774 6a53 5c58  {GjcTifWgxWtjS\X
 000000f0: 694e 4d69 6b5a 6b6a 6667 7172 7091 341d  iNMikZkjfgqrp.4.
 00000100: 843b 2c8b 3c2c 8837 2593 3d2c 993b 2a85  .;,.<,.7%.=,.;*.
-00000110: 3b34 983d 34ac 3b2b a539 28b4 3b2b bb3b  ;4.=4.;+.9(.;+.;
+00000110: 3b34 983d 34ac 3b2b a539 28b4 3b2c bb3b  ;4.=4.;+.9(.;,.;
 00000120: 2bb9 3826 b73b 33aa 3c31 cc35 2ac4 3a2b  +.8&.;3.<1.5*.:+

and a lot more +1 diffs - so could be just different rounding errors there.

[bmwiedemann]

Looking at the png.c code, the LosslessReduceDepthOK function would be a great candidate for some intense review, testing or debugging.

[bmwiedemann]

I did a git bisect run with

#!/bin/sh
export CFLAGS="-O0"
export CXXFLAGS="-O0"
time make -j7 utilities/magick || exit 125
ln -sf magick utilities/convert
utilities/convert rose: out.png || exit 125
make clean ; git checkout configure
file out.png | grep 16-bit

and found that the i586-16-bit png bug was introduced by 9b67d51 for #1305 and fixed by 0033b0e for #1343