2008.05.19 11:08 "Re: [Tiff] GDAL vs LibTiff?", by Andrey Kiselev

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