#91 Loading and dumping indexed transparent pngs corrupts image

Algorithms (87)

Using version 1.1.11 on Ubuntu Hardy Heron.

$ ldd /usr/lib/libGraphicsMagick.so.1.0.11
linux-gate.so.1 => (0xb7f36000)
liblcms.so.1 => /usr/lib/liblcms.so.1 (0xb7c49000)
libtiff.so.4 => /usr/lib/libtiff.so.4 (0xb7bf6000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7b85000)
libjasper.so.1 => /usr/lib/libjasper.so.1 (0xb7b38000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7b18000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7af5000)
libwmflite-0.2.so.7 => /usr/lib/libwmflite-0.2.so.7 (0xb7adb000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb7ad3000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb7aba000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb79d3000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb79c3000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb78a4000)
libz.so.1 => /usr/lib/libz.so.1 (0xb788f000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb786a000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7851000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb784d000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb76fe000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb76fc000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb76e4000)
/lib/ld-linux.so.2 (0xb7f37000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb76e0000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb76db000)

The problem I seem to run into is the following:
1. Load an indexed PNG with transparency.
2. Export it to file.
3. Repeat 10 times.

The first copy is correct, but after that all copies are corrupt in random ways. Its as if the transparency layer got completely messed up.

I have attached a q&d test program and a test image. Compiling with:
gcc -W -Wall -O2 -I /usr/include/GraphicsMagick -lGraphicsMagick -o test test.c
./test test.png

This will simply load the input image and export if 10 times. If the engine initialization and shutdown are moved out of the loop the resulting images are not as badly damaged but are changed. The problem might be related to bug 1867168.

I tested this by compiling against ImageMagick libraries:
$ ldd /usr/lib/libMagick.so.10.0.9
linux-gate.so.1 => (0xb7f39000)
liblcms.so.1 => /usr/lib/liblcms.so.1 (0xb7cfc000)
libtiff.so.4 => /usr/lib/libtiff.so.4 (0xb7ca9000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b59000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7b39000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7b0f000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7b01000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb7af9000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb7ae1000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb79fa000)
libXt.so.6 => /usr/lib/libXt.so.6 (0xb79a8000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb7998000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7973000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb795b000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb78eb000)
libz.so.1 => /usr/lib/libz.so.1 (0xb78d6000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb78d1000)
/lib/ld-linux.so.2 (0xb7f3a000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb78b0000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb78ad000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb78ab000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7893000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb788d000)

and this problem does not come up.


  • Nobody/Anonymous

    Test code and sample image

  • Bob Friesenhahn

    Bob Friesenhahn - 2008-07-08
  • Bob Friesenhahn

    Bob Friesenhahn - 2008-07-08

    Logged In: YES
    Originator: NO

    After porting the code to standard APIs I am able to reproduce the bug with the latest code on the 1.1 CVS branch, but the bug does not occur in GM 1.2.X. Are you able to update to GM 1.2.4? Given that the 1.1 branch has gone through 15 releases spanning four years, I am not particularly eager to debug this issue and produce yet another release. There was an earlier PNG bug report which seemed similar but it was exercised via PerlMagick and I did not reproduce the bug at that time.

    I have attached a more portable version of your test.c
    File Added: test-port.c

  • Bob Friesenhahn

    Bob Friesenhahn - 2008-07-08

    Logged In: YES
    Originator: NO

    Note that running the test program under valgrind may reveal the source of the bug. I do not currently have valgrind here although I ran the test program under a different memory checker.

  • Glenn Randers-Pehrson

    Logged In: YES
    Originator: NO

    No libpng is listed in the second list???? Perhaps ImageMagick was
    not even trying to decode the image. With the GraphicsMagick version,
    what is the output of "gm convert -list format | grep NG" (should
    give you the version of libpng that you are using).

  • Nobody/Anonymous

    Logged In: NO

    WFM on 1.2.4, I will upgrade to that.
    Thanks for the quick turnaround.

  • Bob Friesenhahn

    Bob Friesenhahn - 2009-04-16

    GraphicsMagick 1.1.X is no longer supported. Please use GraphicsMagick 1.2.X or 1.3.X.

  • Bob Friesenhahn

    Bob Friesenhahn - 2009-04-16
    • status: open --> closed-wont-fix

Log in to post a comment.