author  Johann Sorel

2-3 bytes of all tiff files */

BYTE 8-bit unsigned integer. */

ASCII 8-bit byte that contains a 7-bit ASCII code; the last byte must be NUL (binary zero). */

SHORT 16-bit (2-byte) unsigned integer. */

LONG 32-bit (4-byte) unsigned integer. */

RATIONAL Two LONGs: the first represents the numerator of a
fraction; the second, the denominator.
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.
In TIFF 6.0, some new field types have been defined:

SBYTE An 8-bit signed (twos-complement) integer. */

UNDEFINED An 8-bit byte that may contain anything, depending on the definition of the field. */

SSHORT A 16-bit (2-byte) signed (twos-complement) integer. */

SLONG A 32-bit (4-byte) signed (twos-complement) integer. */

SRATIONAL Two SLONG’s: the first represents the numerator of a fraction, the second the denominator. */

FLOAT Single precision (4-byte) IEEE format.*/

DOUBLE Double precision (8-byte) IEEE format.*/