Received: from mailgate002.isp.belgacom.be (mailgate002.isp.belgacom.be [195.238.6.87])
	by maildelivery005.isp.belgacom.be (Postfix) with ESMTP id 4554C16405F
	for <joris.at.lebbeke@skynet.be>; Sat, 24 May 2008 05:27:18 +0200 (CEST)
Authentication-Results: in.mx.skynet.be; dkim=neutral (message not signed) header.i=none
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 24 May 2008 05:27:16 +0200
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m4O35bK1005476;
	Fri, 23 May 2008 23:07:07 -0400
Received: from netserver.pc-backup.net (netserver.pc-backup.net [65.86.65.107])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m4O35XIG005473
	for <tiff@lists.maptools.org>; Fri, 23 May 2008 23:05:34 -0400
Received: from [192.168.1.101] (pcbr.pc-backup.net [65.86.65.110])
	by netserver.pc-backup.net (8.11.6/8.11.3/SuSE Linux 8.11.1-0.5) with
	ESMTP id m4O31oe07799; Fri, 23 May 2008 23:01:50 -0400
Subject: Re: [Tiff] Unitialized Variable Caused a Problem in TIFFCP
From: Gene Amtower <gene@pc-backup.com>
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
In-Reply-To: <Pine.SOC.4.64.0805232011240.14523@freddy.simplesystems.org>
References: <1211568911.4192.237.camel@PCB-Bench-01>
	<Pine.SOC.4.64.0805231634110.14523@freddy.simplesystems.org>
	<1211586647.4192.244.camel@PCB-Bench-01>
	<Pine.SOC.4.64.0805232011240.14523@freddy.simplesystems.org>
Content-Type: text/plain
Organization: PC Backup
Date: Fri, 23 May 2008 23:05:28 -0400
Message-Id: <1211598328.8384.26.camel@PCB-Bench-01>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-7) 
Content-Transfer-Encoding: 7bit
Cc: tiff@lists.maptools.org
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: gene@pc-backup.com
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.00002cf9
X-MSP-STORE: Sat, 24 May 2008 05:27:18 +0200
Status:   

On Fri, 2008-05-23 at 20:15 -0500, Bob Friesenhahn wrote:
> There is about 3 years of difference.  But both of them are old now. 
> Needless to say, fixes appear in subsequent releases, so it is best to 
> see if the problem still exists in 3.9.0beta and 4.0.0beta1 so that it 
> can be fixed before the next release.
> 
> What does 'tiffinfo' report for the problem files?  Are you able to 
> provide one of the problem files as a test case?
> 
> Bob

Bob,

I can't share any of the files because they're customer material, but
here's a copy of the tiffinfo output from one of them...

TIFF Directory at offset 0x2267c
  Subfile Type: (0 = 0x0)
  Image Width: 6904 Image Length: 4888
  Resolution: 200, 200 pixels/inch
  Compression Scheme: CCITT Group 4
  Photometric Interpretation: min-is-white
  FillOrder: msb-to-lsb
  Make: "Alpharel Incorporated"
  Model: "optirastoras"
  Orientation: row 0 top, col 0 lhs
  Rows/Strip: 4888
  Planar Configuration: single image plane
  Software: optirastoras: 1.6.5(beta), 2

I can tell you that these are engineering drawing images, some from
scans of original paper documents some years back.  Since these are
monochrome prints, a fax-type format seems logical, but the program that
creates them might be a bit old and incomplete in it's handling of tiff
tags.  I don't have access to that program; I'm just working with this
material downstream in the business process, so I'm forced to work with
what I'm getting out of it.

Of course, 'tiffcp' is working fine for me with my modified copy, once I
initialized the "samples/pixel" variable to "1" just before trying to
load the image tag for it, and as you can see from the tiffinfo output,
these images seem to be missing the samples/pixel tag.  I don't know if
that's typical, and that's really my question to the list.  As TIFF
users, does anyone else see this situation--images that don't have a
samples/pixel tag?  I think it only causes a problem with the transform
functions like "bias", as I was able to perform merges of these files
from individual tiffs into a multi-page tiff without any modification.

For my purposes, I'm focused on making the watermark functionality.
I've got a first cut that allows me to offset the watermark anywhere on
the source images, from the upper-left corner, using two new "-x" and "-
y" parameters to indicate the offset values.  I also created a new
watermark option "-m" followed by the watermark file spec.  This is
working great, and I'm now working on how to push it to the middle of
each image and then offset it in any direction from there, using an
additional option parameter for centering.  "-c" is already used...

    (:

so I gotta come up with something else, or I could try to include it
with the offset values with a "," separator.  I'm still working on my
options.  I could include a scaling feature, but that's really more than
my current needs.  Of course, I would be happy to share my improvements
with the world, but this could be my first hack at contributing to the
open-source community.

You mentioned that 3.8.2 is old?  That doesn't seem too far from 3.9.0,
so has the package been dormant for a little while, or just in an
enhancement-bake mode of operation?  I guess I should go download the
3.9.0beta code just to see what's different.

Thanks for your interest, and I'll be anxious to share what I'm doing
with the libtiff code.

    Gene


_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
