#182 gm-1.3.13 mishandles this particular png


GraphicsMagick-1.1.13 mishandles some png's. The broken ones appear as if some vertical empty space/interlacing was added to
them. No such problems with 1.1.12.

Built on fedora 16, with libpng-1.2.46-1.fc16.x86_64

See also downstream report,

gm version
GraphicsMagick 1.3.13 2011-12-24 Q16 http://www.GraphicsMagick.org/
Copyright (C) 2002-2011 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.

Feature Support:
Thread Safe yes
Large Files (> 32 bit) yes
Large Memory (> 32 bit) yes
BZIP yes
DPS no
FlashPix no
FreeType yes
Ghostscript (Library) no
JPEG-2000 yes
JPEG yes
Little CMS yes
Loadable Modules yes
OpenMP yes (201107)
PNG yes
TIFF yes
WMF yes
X11 yes
XML yes
ZLIB yes

Host type: x86_64-redhat-linux-gnu

Configured using the command:
./configure '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--enable-shared' '--disable-static' '--with-lcms' '--with-magick_plus_plus' '--with-modules' '--with-perl' '--with-perl-options=INSTALLDIRS=vendor ' '--with-quantum-depth=16' '--with-threads' '--with-wmf' '--with-x' '--with-xml' '--without-dps' '--without-gslib' '--with-gs-font-dir=/usr/share/fonts/default/Type1' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIF

Final Build Parameters:
CC = gcc -std=gnu99
CFLAGS = -fopenmp -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -pthread
CPPFLAGS = -I/usr/include/freetype2 -I/usr/include/libxml2
CXX = g++
CXXFLAGS = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -pthread
LDFLAGS = -Wl,-z,relro -L/usr/lib -L/usr/lib
LIBS = -llcms -lfreetype -lXext -lSM -lICE -lX11 -lbz2 -lz -lm


  • Anonymous

    mishandled png test-case

    • assigned_to: bfriesen --> glennrp
    • status: open --> open-accepted
  • This is a 2-bit palette PNG with 4 color entries and 1 bit of transparency:

    % pngcheck -v VDR-logo.png
    File: VDR-logo.png (594 bytes)
    chunk IHDR at offset 0x0000c, length 13
    80 x 80 image, 2-bit palette, non-interlaced
    chunk PLTE at offset 0x00025, length 12: 4 palette entries
    chunk tRNS at offset 0x0003d, length 1: 1 transparency entry
    chunk bKGD at offset 0x0004a, length 1
    index = 0
    chunk pHYs at offset 0x00057, length 9: 2835x2835 pixels/meter (72 dpi)
    chunk tIME at offset 0x0006c, length 7: 19 Apr 2005 19:35:17 UTC
    chunk IDAT at offset 0x0007f, length 447
    zlib: deflated, 2K window, maximum compression
    chunk IEND at offset 0x0024a, length 0
    No errors detected in VDR-logo.png (8 chunks, 62.9% compression).

    I am able to reproduce the issue with libpng 1.2.46 and 1.5.6. I suspect that the PNG coder is not passing the correct bit depth and perhaps it is treated as 8-bits rather than 4. ImageMagick is able to read the file correctly.

    • summary: gm-1.1.13 mishandles this particular png --> gm-1.3.13 mishandles this particular png
    • status: open-accepted --> open-duplicate
  • Fix has been submitted for checkin, see bu #3554897

    • status: open-duplicate --> closed-duplicate