AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2000.08.10 22:06 "RowsPerStrip -- tiffdump vs. TIFFGetField", by Mccarty Michael J
2000.08.11 03:41 "Re: RowsPerStrip -- tiffdump vs. TIFFGetField", by Andreas R. Kleinert
2000.08.11 14:21 "Re: RowsPerStrip -- tiffdump vs. TIFFGetField", by Frank Warmerdam
2000.08.11 14:41 "Re: RowsPerStrip -- tiffdump vs. TIFFGetField", by Andreas R. Kleinert
2000.08.11 14:51 "Re: RowsPerStrip -- tiffdump vs. TIFFGetField", by Andreas R. Kleinert

2000.08.10 22:06 "RowsPerStrip -- tiffdump vs. TIFFGetField", by Mccarty Michael J

In an application I am developing that uses libtiff, I have noticed that the value for TIFFTAG_ROWSPERSTRIP (278) reported by tiffdump is different than the value returned by TIFFGetField(TIFFTAG_ROWSPERSTRIP). I have observed this behaviour on both the Win32 platform and on Unix. Has anyone else seen this behaviour?

For example:

<snip>
61 % tiffdump doctemp.tif

doctemp.tif:
Magic: 0x4949 <little-endian> Version: 0x2a
Directory 0: offset 1191608 (0x122eb8) next 0 (0)
ImageWidth (256) SHORT (3) 1<4800>
ImageLength (257) SHORT (3) 1<1986>
BitsPerSample (258) SHORT (3) 1<1>
Compression (259) SHORT (3) 1<1>
Photometric (262) SHORT (3) 1<1>
StripOffsets (273) LONG (4) 1<8>
Orientation (274) SHORT (3) 1<1>
SamplesPerPixel (277) SHORT (3) 1<1>
RowsPerStrip (278) SHORT (3) 1<1986>
StripByteCounts (279) LONG (4) 1<1191600>
PlanarConfig (284) SHORT (3) 1<1>

</snip>

However, in the following program:

<snip>
int main()
{
    TIFF * in;
    uint32 rps = 0;

    in = TIFFOpen( "doctemp.tif", "r" );

    TIFFGetField( in, TIFFTAG_ROWSPERSTRIP, &rps );

    printf( "%lu rows per strip in '%-s'\n", (unsigned long)rps,
TIFFFileName(in) );

    TIFFClose( in );

    return 0;
}
</snip>

In my test program, RowsPerStrip is invariably reported as 13. I have verified the RowsPerStrip value in the raw tiff file via a hex editor, and it matches what is reported by tiffdump.

Is this a bug in TIFFGetField() for this particular tag? I have stepped though this function in the debugger, and the value it obtains is 13. I am reasonably sure that this it not related to byte order. Is it possible that somewhere, deep in the library, data being truncated from long to short?

Does anyone have any insight as to what is occurring here? Any assistance would be greatly appreciated.

Michael J. McCarty
Sr. Programmer/Analyst, RP Systems Development and Support
Mellon Financial Corporation
Three Mellon Bank Center 153-2216
Pittsburgh, PA 15259

Phone   (412) 234-5732
Fax     (412) 234-8585
Email   mailto:mccarty.mj@mellon.com