Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx010.isp.belgacom.be (inmx010.isp.belgacom.be [195.238.2.73])
        by mailst034.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i8DF3xRr020985
        for <joris.at.lebbeke@skynet.be>; Mon, 13 Sep 2004 17:03:59 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx010.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i8DF3rHO000826
        for <joris.at.lebbeke@skynet.be>; Mon, 13 Sep 2004 17:03:54 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id A94E82D97D5; Mon, 13 Sep 2004 11:03:34 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205])
	by xserve.flids.com (Postfix) with ESMTP id C2ED42D97C3
	for <tiff@remotesensing.org>; Mon, 13 Sep 2004 11:03:32 -0400 (EDT)
Received: from pobox.com (H156.C195.tor.velocet.net [216.138.195.156])
	by sabre.velocet.net (Postfix) with ESMTP
	id F037513875E; Mon, 13 Sep 2004 11:03:23 -0400 (EDT)
Message-ID: <4145B6BF.6070200@pobox.com>
Date: Mon, 13 Sep 2004 11:03:27 -0400
From: Frank Warmerdam <warmerdam@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Matthew R. Kivela" <mkivela@telegram.com>
Subject: Re: [Tiff] Segmentation fault with tifflook
References: <6.1.0.6.0.20040910164203.00da71a8@bgm3.globe.com>
In-Reply-To: <6.1.0.6.0.20040910164203.00da71a8@bgm3.globe.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tiff@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: f2b988e054d4cc498731af151833a043

Matthew R. Kivela wrote:
> Hi Guys:
> 
> We're setting up a new RIP system, and the vendor sent us tifflook and a 
> script to use it to remove "blank" tiffs before they're sent to our 
> printing plant (i.e. we rip a B&W page, we still get blank TIFFs 
> generated for Cyan, Magenta, and Yellow).  Tried using, got core dump 
> messages (can't remember specific text).
> 
> I believe we're their first Solaris 9 site, so I said I bet it's not 
> compiled for that!
> 
> Downloaded LibTIFF v3.6.1, and got gcc 3.4.1 and the current libiconv 
> packages.  Installed the packages, then made LibTIFF.
> 
> Darn it...still get (even using sample tiffs so it's not our files doing 
> it!):
> 
> #/usr/local/bin/tifflook -t635 -b635 -l635 -r635 ./pics-3.6.1/text.tif
> Segmentation Fault (core dumped)
> 
> Same error w/o the t/b/l/r switches, too.
> 
> Any ideas where I should go with this?  I'll be working with the vendor, 
> too but I'm not sure this is exactly their cup of tea either.

Matt,

Tifflook is not a libtiff utility as far as I know.  I presume it was
written by your vendor?  Did you recompile it for use with libtiff 3.6.1?
Depending on how the libtiff API is used by the application, it may
be required.

Assuming you have done that, you will likely need to get a traceback.  You
should also try with some other files ... hopefully some "simple" files,
to see if the problem is universal.  There were also some issues with some
fax compressed images in at least one of the 3.6.x releases so it is possible
you are running into that - which is one of the reasons I sugest trying some
other simple images.

> Absent a fix for this, any other ideas of how to identify TIFFs that are 
> essentially just white space from a Shell script so they can go to the 
> happy hunting grounds of /dev/null?

I can't think of anything non-obvious.  The obvious is to convert them RGBA
and check that all pixels are near-white.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
