Received: from mailgate002.isp.belgacom.be (mailgate002.isp.belgacom.be [195.238.6.87])
	by maildelivery021.isp.belgacom.be (Postfix) with ESMTP id E8B103C4065
	for <joris.at.lebbeke@skynet.be>; Mon, 19 May 2008 13:49:02 +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; 19 May 2008 13:49:02 +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 m4JBOIaU017319;
	Mon, 19 May 2008 07:25:33 -0400
Received: from cgp2.pu.ru (cgp2.pu.ru [195.70.197.22])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m4JBOGnB017316
	for <tiff@lists.maptools.org>; Mon, 19 May 2008 07:24:17 -0400
Received: from [195.70.196.218] (HELO wg.pu.ru)
	by cgp2.pu.ru (CommuniGate Pro SMTP 5.2.0)
	with ESMTP id 32112581 for tiff@lists.maptools.org;
	Mon, 19 May 2008 15:24:15 +0400
Received: (from uucp@localhost)
	by wg.pu.ru (8.9.1a/8.9.1) with UUCP id LAA25968
	for tiff@lists.maptools.org; Mon, 19 May 2008 11:24:15 GMT
Received: from ak4719.spb.edu (localhost.localdomain [127.0.0.1])
	by ak4719.spb.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m4JB80Q6021367
	for <tiff@lists.maptools.org>; Mon, 19 May 2008 15:08:00 +0400
Received: (from dron@localhost)
	by ak4719.spb.edu (8.13.8/8.13.8/Submit) id m4JB80Bu021366
	for tiff@lists.maptools.org; Mon, 19 May 2008 15:08:00 +0400
From: Andrey Kiselev <dron@ak4719.spb.edu>
Date: Mon, 19 May 2008 15:08:00 +0400
To: tiff@lists.maptools.org
Subject: Re: [Tiff] GDAL vs LibTiff?
Message-ID: <20080519110800.GA21315@ak4719.spb.edu>
Mail-Followup-To: tiff@lists.maptools.org
References: <200805181600.m4IG0BdH020142@duke.maptools.org>
	<0eee01c8b974$8b291750$a17b45f0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0eee01c8b974$8b291750$a17b45f0$@net>
X-GnuPG-Key: http://www.srces.spb.org/dron/export.home.key
X-Face: "t+se9s~+y~[XUH]L|pmeO3Pt/Q@DNv**S, d@_1-C=}/,
	c%<3Qp]eu!ok<"2lYJm$!9qVcg F?7o*L; |$`6|Q|>Rt-cU%2_y@6tQ|`!Li}TsvZvEKx;
	>fuY=fc(=sX^`7Wmw8%SsR`AvM$a; 0U/eN\ P?B\FTyqD, 0np$U2!*'z_4D,
	VPlFf?bN0&zYf"zF0s!7Tl7?$we)xD0@lL>[h|8bhys0i.g|zLnu@C
	Ti@d]i=[!:j1CB\5/TF[m]`lfHfaqSN[0qn@T3zeosV/[LAss{@p_?],x*j8P_9t[}uHD^X-;
	j~\M! gyTly;fj`}&Y~i{<#bN.#QmkE}#T`dxP.I1\.)_MEN{@#W
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Null-Tag: 277800ffb2da5ca22322b1b478cd7fb5
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
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.00002caa
X-MSP-STORE: Mon, 19 May 2008 13:47:44 +0200
Status:   

Garry,

On Sun, May 18, 2008 at 10:52:37PM -0700, Garry Petrie wrote:
> I recently posted a question regarding reading 32bit sample size for a
> DEM geotiff file. The offending code appears in
> 
> TIFFRGBAImageOK
> 
> which on the onset seemed odd, since I expected the file to be
> interpreted as a black/white image.

This is RGBA interface and image will be read into 3-band RGB array in
any case. Just don't use it, it is useless for your application and
never meant to be used that way.

> At this point I can not tell if I got to this point in the code by
> taking a wrong branch, or if correct, the code can not handle the data
> type. It was suggested I look at GDAL. I pulled the 1.5.1 version and
> scanned through the zip archive. The archive contains the same code as
> LibTiff (less a version or two). I would expect the same problem using
> GDAL.

Why do you expecting so? GDAL uses libtiff in the right way (i.e. using
the low-level functions TIFFReadTile()/TIFFReadStrip(), not the
high-level TIFFRGBA API). I am recommending to use GDAL, not libtiff,
because it is not easy to write an application that deals with all
possible TIFF variants.

> I guess I could try the OpenEV executable to see if it can read my
> test geotiff.

OpenEV uses GDAL to read image files, which is in turn uses libtiff for
TIFFs. So you will get the same results using the plain libtiff if you
need so.

> I am pretty much a hobbyist here, no big corporate backer, and usually
> don't spend a lot of time in open-source forums. I would appreciate
> any insight as to the best approach into processing these DEM files
> and whether folks are more synched with GDAL.

By the way, GDAL has Python bindings and can be easily utilized for
small processing tasks via this interface. Other bindings also available
(e.g., Perl and C#). Some docs available here:

 http://trac.osgeo.org/gdal/wiki/GdalOgrInPython

Best regards,
Andrey


-- 
Andrey V. Kiselev
ICQ# 26871517
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
