AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2005.03.03 19:19 "Re: [Tiff] LibTIFF question", by Bob Friesenhahn
2005.03.03 18:11 "Re: [Tiff] LibTIFF question", by Kalman Miklos
2005.03.03 17:19 "[Tiff] LibTIFF question", by Kalman Miklos
2005.03.03 17:48 "Re: [Tiff] LibTIFF question", by Frank Warmerdam
2005.03.03 18:04 "Re: [Tiff] LibTIFF question", by Bob Friesenhahn
2005.03.03 18:28 "Re: [Tiff] LibTIFF question", by Frank Warmerdam
2005.03.15 00:38 "Re: [Tiff] LibTIFF question", by Joris
2005.03.15 07:56 "Re: [Tiff] LibTIFF question", by Frank Warmerdam
2005.03.15 16:06 "Re: [Tiff] LibTIFF question", by Joris
2005.03.15 16:15 "Re: [Tiff] LibTIFF question", by Frank Warmerdam
2005.03.15 16:34 "Re: [Tiff] LibTIFF question", by Bob Friesenhahn
2005.03.03 19:27 "Re: [Tiff] LibTIFF question", by Frank Warmerdam

2005.03.15 07:56 "Re: [Tiff] LibTIFF question", by Frank Warmerdam

On Tue, 15 Mar 2005 01:38:39 +0100, Joris <joris.at.lebbeke@skynet.be> wrote:

Frank,

Frank wrote:

I think you should be doing something like:

uint16 count;

int *data = NULL;

TIFFGetField( m_TIFF, 50653, &count, &data );

That is almost a perfect solution, thanks to the so-called auto-registration. However, one thing seems missing, being the datatype. Suppose this method is used to retrieve, for example, the ModelPixelScaleTag tag value. If the calling code simply assumes the datatype of the returned value is DOUBLE, and only double-checks the count, it's bound to overrun the buffer pointed to by 'data' and crash badly if it ever encounters a TIFF file where this same tag id stores 3 byte values.

Due to the number of private tags, and due to the fact that at one time registration was hard, I expect some tag uses are unregistered and situations like these are likely. Besides, we need to protect ourselves from this mishap even if it should not be likely.

So my question is, is there a way to retrieve the datatype of these auto-registered tags? Am I right in thinking that TIFFFindFieldInfo with TIFF_ANY for the third parameter returns the 'registration' structure as build by this auto-registration scheme? Is checking the FieldType member of this structure good and sufficient to protect the calling code from the above mentioned mishap?

Joris,

I believe you would call the _TIFFFindFieldInfo() function:

  const TIFFFieldInfo*
  _TIFFFindFieldInfo(TIFF* tif, ttag_t tag, TIFFDataType dt)

The data type can be TIFF_ANY to find any tag definition matching tag code "tag". The TIFFFieldInfo looks like this:

typedef struct {

        ttag_t  field_tag;              /* field's tag */
        short   field_readcount;        /* read count/TIFF_VARIABLE/TIFF_SPP */
        short   field_writecount;       /* write count/TIFF_VARIABLE */
        TIFFDataType field_type;        /* type of associated data */
        unsigned short field_bit;       /* bit in fieldsset bit vector */
        unsigned char field_oktochange; /* if true, can change while writing */
        unsigned char field_passcount;  /* if true, pass dir count on set */
        char    *field_name;            /* ASCII name */

} TIFFFieldInfo;

I'm not sure why the function is prefixed with an underscore. I would assume that means it isn't intended for external use, but I'm not sure why. As you note,

in the auto-registration situation application need a way of finding out how the tag has been defined in order to operate it without apriori knowledge.

I suspect we should promote TIFFFindFieldInfo to a properly supported (ie documented) externally visible function.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent