#45 TIF conversion bug on Darwin/Mac OS X PowerPC - attachment



# gm -version
Version: GraphicsMagick 1.1.6 2005-05-01 Q8 http://
Copyright: Copyright (C) 2002, 2003, 2004 GraphicsMagick Group.
Additional copyrights and licenses apply to this software, see http://
Host type: powerpc-apple-darwin8.6.0

Configured using the command:
./configure '--prefix=/opt/local' '--with-jbig=no' '--with-wmf=no'
'--with-dps=no' '--with-lcms=no' '--with-x=no' '--with-perl=no' '--
with-trio=no' '--with-jp2=no' '--with-fpx=no' '--with-png=yes' '--
with-tiff=yes' '--with-bzlib=yes' '--with-zlib=yes' '--with-xml=yes'
'--with-ttf=yes' '--enable-shared=yes' '--mandir=/opt/local/share/
man' 'CC=/usr/bin/gcc-4.0' 'CFLAGS=-I/opt/local/include/freetype2 -
I/opt/local/include' 'CPPFLAGS=-I/opt/local/include/freetype2 -I/opt/
local/include' 'CPP=/usr/bin/cpp-4.0' 'CXX=/usr/bin/g++-4.0'
'LDFLAGS=-L/opt/local/lib' --enable-ltdl-convenience

Final Build Parameters:
CC = /usr/bin/gcc-4.0
CFLAGS = -I/opt/local/include/freetype2 -I/opt/local/include -Wall
CPPFLAGS = -I/opt/local/include/freetype2 -I/opt/local/include/
freetype2 -I/opt/local/include -I/opt/local/include/libxml2
CXX = /usr/bin/g++-4.0
LDFLAGS = -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib
LIBS = -ltiff -lfreetype -ljpeg -lpng -lbz2 -lxml2 -lz -lm -lpthread

# uname -a
Darwin Bruichladdich.local 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar
7 16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power
Macintosh powerpc

# /opt/local/bin/gm convert -geometry 170x136! -colorspace RGB -
quality 70 jesus.tif[0] install_read_tif.jpg
/opt/local/bin/gm convert: jesus.tif: unknown field with tag 37724
(0x935c) encountered. (TIFFReadDirectory).
# ll jesus.tif install_read_tif.jpg
-rw-r--r-- 1 root wheel 379175602 5 May 11:30 install_read_tif.jpg
-rw-r--r-- 1 root wheel 75412 5 May 11:30 jesus.tif

The resulting jpg file should be only a couple of KB in size, but is
> 370 MB. This bug shows in 1.1.6 and 1.1.7 on Mac OS X on PowerPC
CPUs. The same command works just fine on various FreeBSD i386
installations. Probably a problem with either some library, the compiler
version or endianess of the target platform.

I've attached the source tif image.

Patrick M. Hausen


  • Nobody/Anonymous

    source image

  • Bob Friesenhahn

    Bob Friesenhahn - 2006-05-08
    • labels: --> File Format Support
    • assigned_to: nobody --> bfriesen
  • Bob Friesenhahn

    Bob Friesenhahn - 2006-05-08

    Logged In: YES

    I am 99% sure that this problem is due to bugs in the TIFF
    directory handling within libtiff. Various bugs with
    attached profiles exist in different libtiff versions. Even
    the current release of libtiff is known to have some
    remaining bugs in its directory handling.

    The libtiff 'tiffinfo' utility behaves differently on this
    TIFF for each platform I run it on.

  • Nobody/Anonymous

    Logged In: NO

    Thanks for that information.


  • Bob Friesenhahn

    Bob Friesenhahn - 2007-04-08

    Logged In: YES
    Originator: NO

    This is definitely known to be due to a bug in the directory handling of certain versions of libtiff.
    The results are different on big/little endian CPUs since the broken libtiff is treating the passed
    size parameter as a 16-bit value rather than a 32-bit value.

  • Bob Friesenhahn

    Bob Friesenhahn - 2007-04-08
    • status: open --> open-rejected
  • Bob Friesenhahn

    Bob Friesenhahn - 2007-04-08
    • status: open-rejected --> closed-rejected

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks