[Geotiff] Libtiff 4.0.0 Released

[Fred Rothganger]

Frank, Bob,

I used to lurk this list a while back, and have an issue with GeoTIFF 
that has just been sitting around on the back burner.  However, the 
release of Libtiff 4.0 has brought up a related snag in that library, so 
wanted to ask you about both together.  It would be great if you could 
give me guidance on how to proceed to get these resolved...

General: I maintain a library which, in one small part, tries to give 
generic access to named-values that exist in image files.  For that 
reason, it needs to reflect into the tags know to tiff or geotiff.  IE: 
the simplest way for the code to know all the tags is to use the 
respective libraries' own functions.  By way of comparison, this is much 
like the utility tiffset, except exposed as an api.  (The alternative is 
to maintain a massive table, which would be redundant with the massive 
table already in the library, not to mention fragile.)

* In GeoTIFF, I use the GTIFKeyInfo() function to reflect on the tags 
know to the library.  However, when setting tags in a new file, the 
function doesn't find anything unless it has already been set: a "catch 
22".  Could GTIFKeyInfo() be modified so it returns known tags, 
independent of whether they are already in the file?  IE: similar to the 
function formerly known as TIFFFindFieldInfoByName()

* In libtiff...  Well, version 4.0 pretty much killed 
TIFFFindFieldInfoByName(), and the apparent replacement 
TIFFFieldWithName() is unusable because TIFFField is held 
library-private.  It would be incredibly useful to either have public 
access to the fields of TIFFField, or have accessor functions for vital 
pieces of information from it (like the name of the tag, and parameters 
that indicate how to get/set it).

The fact that access to TIFFField was hidden suggested to me that 
something like accessors were planned, but I can't find them.  OTOH, if 
there was a design decision to no longer allow clients of the library to 
reflect on tags, then I beg and plead the powers-that-be to reconsider.  
A significant part of what the tiff library does is manage tags.  
Removing reflection would be a severe lobotomy, and make my code more 
complex and fragile.

To illustrate this, imagine what would happen to tiffset.c if it had to 
use only publicly available headers.

-- Fred



On 12/22/2011 11:40 AM, Frank Warmerdam wrote:
> Folks,
>
> Of interest to many GeoTIFF and GDAL users, Bob Friesenhahn
> has announced:
>
> """
> At long last, libtiff 4.0.0 is finally released.  Libtiff 4.0.0 is the
> successor to the libtiff 3.9.X release series.  It is intended to be
> largely API compatible with the 3.9.X releases, but it is definitely
> not ABI compatible so any software which plans to use it will need to
> be recompiled.  With appropriate care, source code can easily compile
> with both the 3.9.X releases and libtiff 4.0.0.
>
> This release supports the BigTIFF TIFF format in which all offsets are
> unsigned 64-bit, supporting huge files.  APIs which deal with tag
> offsets are necessarily updated to pass 64-bit values.  I/O functions
> supporting the TIFFClientOpen() interface are updated to pass 64-bit
> offset values.
>
> Please visit the libtiff page at http://www.remotesensing.org/libtiff/
> to learn more about the release, or to download it.
> """"
>
> Note that GDAL's internal version of libtiff has tracked libtiff4 for several
> years, and it is substantially preferred to using libtiff 3.9 which
> lacks bigtiff
> and many fixes of value to GDAL.  Libgeotiff should work smoothly with
> libtiff 3.9.x or libtiff 4.0.
>
> Best regards,