Reading the Value/Offset of an IFD Entry

ClassicListThreaded

3 messages  Options 

Tillerson, Clint

Reply | Threaded | More    

Oct 26, 2007; 11:10pm

Reading the Value/Offset of an IFD Entry

4 posts

When reading the value/offset attribute for an IFD entry (Tiff tag), I’m confused about how you to know whether the offset should be read as a short integer vs. a long integer.  Does that make sense?  In other words, when the actual value of the tag will not fit into 4 bytes, then the number represents the offset (in bytes) to where the value or values are stored.

If I understand correctly (and perhaps I do not), the offset will always be either a 2-byte or 4-byte integer.  Is that true.   However, I have no way of knowing whether to read only the first 2 bytes to get the offset or read all 4 bytes.  The field type attribute tells you the data type of the tag value, not the data type of offset value.

Here’s some background:  I’m writing a Fortran program that extracts land cover data from GEOTIFF files.  Depending on the source of the GEOTIFF file, it could be either big endian or little endian thus, I cannot use a compiler switch to deal with the byte swapping and must handle byte swapping in my Fortran code when necessary.    The problem I’m running into is reading the offset value and swapping bytes appropriately.  If the offset value fits into two bytes, I’ve discovered that I must read only the first two bytes and ignore the second two, else I’m including bytes that aren’t part of the offset value.  There does not seem to be a way to determine whether the offset is stored in only the first two bytes or all four.

Thanks!

Clint

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

Remove Ads

Niles Ritter

Reply | Threaded | More    

Oct 27, 2007; 12:54am

Re: Reading the Value/Offset of an IFD Entry

6 posts

On Fri, 2007-10-26 at 10:10 -0400, Tillerson, Clint wrote: 
> When reading the value/offset attribute for an IFD entry (Tiff tag), 
> I’m confused about how you to know whether the offset should be read 
> as a short integer vs. a long integer. 

TIFF is based from the ground-up on offsets to data, which can be 
anywhere in the file. Since TIFF files can be up to 4GB in size, 
all offsets stored in TIFF are always LONG (4-byte unsigned integers 
in the byte-order specified by the TIFF header). 

http://partners.adobe.com/public/developer/tiff/index.html

> Here’s some background:  I’m writing a Fortran program that extracts 
> land cover data from GEOTIFF files. 

Ah, youth and high spirits. FORTRAN! It makes me nostalgic. 

I wrote a FORTRAN TIFF parser back in the 80's, when I worked at 
NASA/JPL's image-processing center (MIPL). Believe me, you don't 
want to write a FORTRAN TIFF: that path is clouded by the Dark Side, 
and will only lead you to suffering, and countless hours of 
debugging (FORTRAN!). It's a good CS homework assignment, but not 
a good investment of your (or your company's) developer time. 

Do what I eventually did, abandon the FORTRAN TIFF project and 
just use the (C-based)  "libtiff" library. It's as gold-plated 
as you can get. All Fortran compilers in this millennium 
support calls to C functions.  Reference: 

http://www-mipl.jpl.nasa.gov/vicar/vicar250/html/vichelp/vtiff.html

Count your blessings; at least you weren't asked to write it in ADA ! 

--Niles. 


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

noelkhan

Reply | Threaded | More    

Dec 15, 2007; 11:07am

Re: Reading the Value/Offset of an IFD Entry

8 posts

In reply to this post by Tillerson, Clint

Quote "...how you to know whether the offset should be read as a 
short integer vs. a long integer...."

All pointers are 4-byte LONG values; regardless of whether the pointer is pointing to the next IFD or pointing to some tag's value. 

Quote "...when the actual value of the tag will not fit into 4 bytes, then 
the number represents the offset (in bytes) to where the value or values 
are stored...."

Correct, the "Value" is actually a pointer if the size of the value is > 4 bytes.Note that this pointer is base-0 and from the beginning of the tiff file, not from the current file position. 

Quote "...the offset will always be either a 2-byte or 4-byte integer.  Is that true...."
  
Negative. The offset/pointer will always be a LONG (4-bytes). 

Quote "...The field type attribute tells you the data type of the tag value, not the data type of offset value...."

See page 15 of the TIFF6 spec for a listing of data types and their sizes in terms of bytes (hereinafter, "ByteSize"). Once you've read the field Type and Count (a.k.a., "N"), the size of the tag's "Value" is calculated as: ByteSize*N. 

If (ByteSize*N) > 4 bytes, then the "Value" is in fact a pointer to a value. 

If (ByteSize*N) <= 4, then parse N number of DataTypes. Again, the number of bytes per data type is known.   

Quote "I'm writing a Fortran program .... must handle byte swapping in my Fortran code when necessary."

:)   I'm writing a program in VB6 that reads TIFF/GeoTIFF headers. To handle byte order I: [1] utilize a function ReadNBytes(N) that reads N number of bytes into a byte array. [2] That byte array is then passed by reference to a function ByteArrayToNumber. It is here that I handle byte order: for MM, I iterate through the bytes from 1...N; and for II from N...1. [3] Each iteration, I pass each byte to a function named ByteToBitPattern, which converts the byte into a string representation of bits. [4] Finally, I pass my bit-string to a function BitPatternToValue that converts the bit-string to a numerical value. 

It may seem round-about, but it's the only way (I thought of) to create a generic function that can read and return numerical values of any byte size and in either order (MM/II) using Visual Basic 6. 

So much fun. 

However, I've been tearing my forlock out trying to figure out how Model coordinates are encoded into the GeoTiff tags. If you've figured that out, please share how. 

Cheers, 
Noel