Libtiff 4.0.0 Released

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Libtiff 4.0.0 Released

Frank Warmerdam
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,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: Libtiff 4.0.0 Released

Fred Rothganger-2
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,

_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: Libtiff 4.0.0 Released

Frank Warmerdam
On Tue, Jan 31, 2012 at 7:42 AM, Fred Rothganger <[hidden email]> wrote:
> * 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()

Fred,

There is an enumerated list of geokeys with their numeric
value and textual name in the _keyInfo[] array declared in
geonames.h.  I think you could use it as a list.  But this
does not include the types, and in fact there is no
enforcement of particular keys having particular types in the
library.  It is entirely dependent on applications doing the right
thing.

I imagine geonames.h is not public.  If necessary I'd consider
providing a public function that exposes these declarations
in some fashion so it would be easy (easier) to turn numeric
values into names, and to see the list of valid numeric values.

> * 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.

I believe Joris reworked the TIFFField / TIFFFieldInfo stuff for 4.0
and made TIFFField private so that the physical layout of the structure
would not be built into the ABI which was very fragile.   I'd be open to
the addition of one or a few accessors to TIFFField objects.

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

:-)

I'm willing to collaborate on accessors and perhaps we could use
successful migration of tiffset to public interfaces as a test case for
our success.  Would you be willing to propose accessors and provide
a patch or would you prefer I take the lead?

PS. I happen to be working on libtiff right now so this is good time
to keep after me on these points.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: Libtiff 4.0.0 Released

Fred Rothganger-2
On 01/31/2012 10:42 AM, Frank Warmerdam wrote:

> Fred, There is an enumerated list of geokeys with their numeric value
> and textual name in the _keyInfo[] array declared in geonames.h. I
> think you could use it as a list. But this does not include the types,
> and in fact there is no enforcement of particular keys having
> particular types in the library. It is entirely dependent on
> applications doing the right thing. I imagine geonames.h is not
> public. If necessary I'd consider providing a public function that
> exposes these declarations in some fashion so it would be easy
> (easier) to turn numeric values into names, and to see the list of
> valid numeric values.

Frank,

Looked at my code a little more closely.  It's been a few years since I
wrote it, so I didn't understand it correctly.  :)  Anyway, I'm actually
using GTIFKeyCode() to translate a string into an integer ID.  After
that, I'm using my own lookup table to find the type of the key
(TYPE_SHORT, TYPE_DOUBLE, TYPE_ASCII).  What would be nice is a function
that would tell me the type of a key.  Apparently I tried to use
GTIFKeyInfo() to do this, but it will only return info for keys actually
present in the file.  Could we have a function like

tagtype_t GTIFKeyType (geokey_t)

that takes an arbitrary key and returns its type?

> I'm willing to collaborate on accessors and perhaps we could use
> successful migration of tiffset to public interfaces as a test case
> for our success. Would you be willing to propose accessors and provide
> a patch or would you prefer I take the lead?

Following the principle of laziness, I would rather you take the lead.  
:)  However, I'm willing to help if necessary.  As for accessors, here
are the fields I actually use:

field_type
field_tag
field_readcount
field_writecount
field_passcount

In addition, tiffset.c uses

field_name

-- Fred


_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff