Template:IFD format: Difference between revisions
mNo edit summary |
mNo edit summary |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
<noinclude>[[Category:IFD]]</noinclude> | |||
A TIFF field is a logical entity consisting of TIFF tag and its value. This logical concept is implemented as an IFD Entry, plus the actual value if it doesn’t fit into the value/offset part, the last 4 bytes of the IFD Entry. The terms TIFF field and IFD entry are interchangeable in most contexts. | |||
=== IFD format === | === IFD format === | ||
An Image File Directory (IFD) consists of a 2-byte count of the number of | An Image File Directory (IFD) consists of a 2-byte count of the number of directory entries (i.e., the number of fields), followed by a sequence of 12-byte field | ||
entries, followed by a 4-byte offset of the next IFD (or 0 if none). (Do not forget to | entries, followed by a 4-byte offset of the next IFD (or 0 if none). (Do not forget to | ||
write the 4 bytes of 0 after the last IFD. | write the 4 bytes of 0 after the last IFD. | ||
Line 61: | Line 64: | ||
|- | |- | ||
|} | |} | ||
Latest revision as of 23:14, 28 January 2015
A TIFF field is a logical entity consisting of TIFF tag and its value. This logical concept is implemented as an IFD Entry, plus the actual value if it doesn’t fit into the value/offset part, the last 4 bytes of the IFD Entry. The terms TIFF field and IFD entry are interchangeable in most contexts.
IFD format[edit source]
An Image File Directory (IFD) consists of a 2-byte count of the number of directory entries (i.e., the number of fields), followed by a sequence of 12-byte field entries, followed by a 4-byte offset of the next IFD (or 0 if none). (Do not forget to write the 4 bytes of 0 after the last IFD.
IFD entry | |
bytes field (h) | Format |
---|---|
0-1 | IFD Entry: The Tag that identifies the field |
2-3 | IFD Entry: The field Type
The value of the Count part of an ASCII field entry includes the NUL. If padding is necessary, the Count does not include the pad byte. Note that there is no initial “count byte” as in Pascal-style strings. Any ASCII field can contain multiple strings, each terminated with a NUL. A single string is preferred whenever possible. The Count for multi-string fields is the number of bytes in all the strings in that field plus their terminating NUL bytes. Only one NUL is allowed between strings, so that the strings following the first string will often begin on an odd byte. The reader must check the type to verify that it contains an expected value. TIFF currently allows more than 1 valid type for some fields. For example, ImageWidth and ImageLength are usually specified as having type SHORT. But images with more than 64K rows or columns must use the LONG field type. TIFF readers should accept BYTE, SHORT, or LONG values for any unsigned integer field. This allows a single procedure to retrieve any integer value, makes reading more robust, and saves disk space in some situations.
the definition of the field.
fraction, the second the denominator.
These new field types are also governed by the byte order (II or MM) |
4-7 | IFD Entry: The number of values, Count of the indicated Type |
8-11 | IFD Entry: The Value Offset ((in bytes from the TIFF header))
The Value is expected to begin on a word boundary; the correspond- ing Value Offset will thus be an even number. This file offset may point anywhere in the file, even after the image data. |