(1)  Short note on the antecedents of TIFF

It is perhaps odd that the only standard for storing faxes that
has achieved any significant acceptance in the software and standards
communities wasn't sponsored by an international standards body like
the ITU, or by a national body such as ANSI, or even produced by a
trade association like the TIA/EIA.  It was developed by an ad-hoc
committee of manufacturers and developers co-ordinated by Aldus
Corporation, who are better known as the publishers of the PageMaker
desktop publishing program.  Aldus have since merged with Adobe, the
developers of the PostScript page description language.  TIFF was
developed in co-operation with representatives from such major
computer industry names as Apple, Hewlett-Packard, IBM, Microsoft (who
originally co- sponsored the TIFF format), Sun, and Xerox.  A request
appeared in the 1988 TIFF 5.0 specification that "fax people ... get
together and decide what should be in TIFF Class F files".  The first
version of Class F was defined the following year by Joe Campbell, of
Cygnet Technologies (a subsidiary of Everex).  It was developed more
or less in parallel with the work that the EIA/TIA TR 29.2 committee
was putting in on the various fax modem specifications. Fax images
are a subset of what the TIFF specifications used to call Class B but
now calls bilevel images, where one bit in an image represents either
a black or a white element.  While a modified version of the 1-D
CCITT compression scheme defined in the T.4 recommendation is
available as a baseline option it is easier to use the recognised
TIFF subset known as Class F, which more specifically defines the way
that fax images are to be stored as TIFF files.

The tag method isn't unique to TIFF, as it is used in a number of ISO
protocols.  It is even possible to view the FCF octets used to
identify different HDLC frames as a sort of frame tag.  The
distinctiveness of TIFF lies in its comprehensive application of this
idea to graphics images in a way that permits relatively painless
expansion of the format specification.  The unique features of any
type of data are stored in an ordered list, with each entry in the
list having a special tag indicating what sort of information it
contains.  For example, a tagged image format would need to define
tags for entries indicating image height and width, scales,
compression methods, and so on.  As well as the tag, entries contain
information on the type, length, and location of each piece of
information.

(2)  Short note on the current state of TIFF fax usage

For information purposes only, this directory includes version 6 of
the TIFF specification (in Postscript form, alas) together with TIFF
Class F specification (as a text file) in the file TIFF.ZIP.

We referred to the recognition given to TIFF by the ITU (see
Recommendation T.611 section 9.1.3).  Despite this, and the manifold
virtues listed at the start of this chapter, it is true to say that
the use of  TIFF as a native fax format has not been an overwhelming
success so far.  Most commercial fax applications software still
prefers to use proprietary file formats for saving raw fax images,
and get round portability problems by providing a number of
conversion routine to and from common graphics formats.  The reasons
for this lack of commercial success are as complex as anything else
in the computer industry, but it is probably true to say that there
has been a greater need for computer fax users to exchange images
with their own graphics programs than there has been for them the
exchange fax data with other fax processes.  So, especially on PC
systems, you'll generally find that applications save faxes by
default in a proprietary form, and that options are given to convert
to common formats for screen graphics such as PCX, or for printer
output such as EPS.  Even where an application states that TIFF file
formats are supported, it is often unclear as to which of the TIFF
options are covered.  TIFF is as much a way of bringing formats under
a common umbrella as it is a format in its own right. This is one of
its strengths, but also one of its weaknesses.

(3)  Short note on TIFF information types

Though the TIFF version 6.0 specification expanded the range to
twelve types, fax images only need the ones used in earlier TIFF
versions, which made do with five.

(4)  Short note on the dimensions of an image in a TIFF file

Note that the IFD doesn't contain the A4 physical dimension of the
page we started with (210 mm x 297 mm). These values have to be
inferred by dividing the entries for ImageWidth by Xresolution, and
the entry for ImageLength by Yresolution, and even when we do that,
we lose the information that the original was 210 mm wide because a
fax is always 215 mm wide.

(5)  Extended note giving a complete TIFF reference for fax

Full information concerning the TIFF specification, including the
details of the tags used for gray scale and colour images (which are
rather more complicated than faxable bilevel images) can be found in
the TIFF specification. This is available directly from Aldus, or
alternatively, it can be downloaded from many Internet FTP sites.

In this reference, you should note that where fields are specified as
being either LONG or SHORT, readers should be prepared to accept
either type.  Where a default value is indicated, this should be
assumed to hold for all unspecified fields.  TIFF readers must also
be able to accept files written using either big-endian or
little-endian byte ordering. A reader coming across a field with an
unknown tag should issue a warning but otherwise assume it is safe to
ignore it.


 ImageWidth    
 ImageLength      
 ResolutionUnit  
 RowsPerStrip
 StripOffsets  
 StripByteCounts  
 XResolution     
 YResolution

The following fields and values are additional requirements for
baseline TIFF Bilevel images (formerly known as TIFF Class B) :

 SamplesPerPixel = 1
 BitsPerSample = 1
 Compression = 1 or 2 or 32773
 PhotometricInterpretation = 0 or 1

The TIFF Class F specification requires the following fields in
addition to the ones listed above :

 FillOrder  
 T4Options  
 PageNumber  
 NewSubfileType

It further restricts the values that fields may have in line with the
CCITT T.4 fax recommendation as follows :

1. ImageWidth, XResolution and YResolution must all conform to valid
T.4 resolutions and dimensions.

2. Compression must have the value 3 or 4 (indicating a T.4 or T.6
fax image).

3. All EOL codes in the file must be byte aligned (which is specified
via the T4Option field).

These issues are discussed further in our coverage of each field.

All the other fields listed below are optional, while fields with
unknown tags should be ignored by TIFF readers.  However, where
fields are specified as being either LONG or SHORT, reader should be
prepared to accept either type.  Where a default value is indicated,
this should be assumed to hold for all unspecified fields.  TIFF
readers must also be able to accept files written using either
big-endian or little-endian byte ordering.


 Tag   = 254
 Name  = NewSubfileType
 Type  = LONG
 Count = 1


This tag indicates a field showing the kind of data in an image.  The
original TIFF specification included a field with the tag number 255
and the name SubfileType.  It consisted of a SHORT integer, where the
value 1 indicated a full-resolution image, the value 2 indicated a
reduced-resolution image, and the value 3 indicated one page of a
multi-page image.  However, the TIFF specification states that the
use of SubfileType is "deprecated", and NewSubfileType should be used
instead.  The difference between the two is that while the old
version was a short integer that held mutually exclusive values,
NewSubfiletype is a set of 32 bits, each of which can be set
independently.  In general, bitfields are much more flexible than
numeric fields, since they can combine many related items into one
coherent value.

Bit 0 is set to 1 if the image is a reduced-resolution version of
another image in the same file.  Bit 1 is set if the image is a
single page of a multi-page image, while bit 2 is set to indicate
that an image defines a transparency mask, and is not used in black
and white fax applications.  To re-iterate a point that we mentioned
earlier in this chapter, there's no reason why a single TIFF file
can't include (say) a full colour file size JPEG version and faxable
black and white A4 version of the same picture.  The IFD for the fax
image would have both bit 0 and bit 1 of the NewSubfiletype field set
in this case.

The field is not compulsory, and there is a default of 0.  In fact,
baseline TIFF readers are not compelled to read beyond the first
image in a file.  However, the authors of the TIFF Class F document
viewed the ability of a TIFF file to hold multiple images as being
such a benefit when applied to fax pages that they specified the
NewSubfileType field as compulsory with a value of 2 (bit 1 = 1).  My
own personal view is the setting of the next IFD pointer to a
non-zero value is itself sufficient indication of a multi-page
document, and the NewSubfileType field isn't needed even in this
case.  However, the wisest practise for file export purposes is to
include this field even if you don't think it is needed, especially
since there is a specification that says you ought to.

One general point concerning all TIFF fields containing individual
flag bits is that the specification is silent as to whether the bit
ordering within this field is sensitive to whether the TIFF header
says the file byte ordering is big- or little-endian.  In fact, there
are three possible interpretations here, for both "II" and "MM" files
have a big-endian bit order within bytes.  It could be argued that no
matter what the byte ordering might be, bit fields should always have
a little-endian order, so that bit 0 should obviously be the first
bit of the value given in the field.  This gives us the following
three possible representation of the actual sequence of bits in value
with bit 0 set to 1.


0001 = 00000000 00000000 00000000 00000001 = MM
0001 = 00000001 00000000 00000000 00000000 = II
0001 = 10000000 00000000 00000000 00000000 = ??


The interpretation that all TIFF readers and writers seem to give to
bitfields is that since they are defined as 32-bit integer types, it
should be possible to set bit zero simply by doing a logical OR with
a binary 1.  This means that the order of the bits in bitfield does
depend on the "endian-ness" of the file.  For a little-endian file,
this gives the rather counter-intuitive result that the first bit in
the bitfield is going to be bit 7.  This is outweighed by the
benefits of the fact the simple logical operations on integers can be
used to find the contents of any single bit.  People using the bit
field structures in C to analyse or create these values should also
note that the ordering of bit-fields within a byte is unspecified in
the language, and that while many compilers regard bit 0 as being the
rightmost bit in a byte, this is by no means guaranteed to be true of
all C implementations.  A fail-safe practise would be to check the
bits at both ends of the datum.  This guards against the possibility
of either a TIFF writer or a C compiler implementing a different bit
order, but it does depends on the fact that only the lowest three
bits of this field are defined, with all unused ones being set to 0.


 Tag   = 256
 Name  = ImageWidth
 Type  = SHORT or LONG
 Count = 1


We described the ImageWidth field earlier.  The only peculiar thing
about it is the fact that (like a few other fields) it can take
either a SHORT or a LONG integer value.  As far as I can tell, this
is an option that serves no useful purpose.  The existence of
multiple possibilities for values serves only to complicate the task
of TIFF readers and writers, and to introduce an additional source of
error.  Storing any single value as a SHORT rather than a LONG saves
no space, as 32 IFD bits are reserved in any case.  Having multiple
options increases the time taken for a reader to digest the field, as
an additional test is needed for which the different value
possibilities is to be used.  Version 5.0 of TIFF recommended that
ImageWidth be stored as a LONG.  However, the Version 6.0
specification states that TIFF readers should accept either BYTE,
SHORT or LONG types for any integer, effectively collapsing all these
into a single INTEGER type, which means that it's largely irrelevant
how these values are stored.  There isn't a lot that applications
writers can do except to make their own decision.  For illustrative
reasons, our sample IFD earlier in the chapter used a SHORT while the
TIFF writer code which appears later in the book uses a LONG.

TIFF Class F originally restricted the value of this field to the
valid widths of faxes, and only values of 1728, 2048 and 2482 were
consequently allowed.  Widths of 864 and 1216 have subsequently been
added.  Since the intention in using TIFF is to have a file format
that can contain immediately faxable data, this requirement must be
strictly followed.


 Tag   = 257
 Name  = ImageLength
 Type  = SHORT or LONG
 Count = 1


This is apparently a quite straightforward field and has already been
used in our sample TIFF file.  However, I think it needs to be looked
at a little more closely.  Unlike the mandatory ImageWidth value, a
valid ImageLength is not actually essential for fax data.  In
particular, knowing what the length of a file is going to be in
advance isn't necessary for single strip fax files.  They can be
decoded one line at a time from top left to the bottom right of an
image, in precisely the same way that a fax machine can print out
each line of a fax as received without needing to know what the total
number of lines is going to be.

TIFF Class F adheres strictly to the baseline TIFF specification and
makes ImageLength a required tag.  This is defensible when writing an
ImageLength value for T.4 encoding schemes, as all that we need to do
is count up the number of EOL codes received.  While constructing an
algorithm to detect an EOL in real-time is a bit of a chore, it isn't
terribly difficult and doesn't impose too much of a computational
burden - we just have to keep track of the number of consecutive zero
bits received.  However, T.6 data has no EOL codes at all, and to
write a count of lines in the file would require that the image is
decoded as it is received.  This is not as straightforward a task as
counting zero bits, and requires rather more computational resources
- in other words, you'll need want a faster machine and more memory.

Therefore I would favour a relaxation of the mandatory nature of this
field for fax applications that want to receive and write
single-strip T.6 encoded files.  I've already done this myself, and
the code for receiving T.6 encoded faxes in this book inserts a dummy
value for ImageLength when writing TIFF IFDs in these circumstances.
This unilateral relaxation of the rules can be defended on the
grounds that the real-time burden of computing of an accurate value
for the number of lines in a T.6 page is not feasible for many
computers, and knowing an ImageLength in advance is in any case not
really required for decoding the data.

However, it must be recognized that while an algorithm can be
constructed and used for successful decoding of a fax image without
knowing either how many lines it covers or how many bytes it
contains, knowing only the width is insufficient if the multi-strip
option in TIFF is being used.  It is also insufficient if the length
of the single strip fax image (as recorded in the StripByteCounts
field) is unknown.  However, in contrast to the complexities of
knowing how many lines are in the image, knowing the size of an image
in bytes is trivial for both fax image generators receive fax
applications, which can always keep track of the number of characters
written to disk.  It therefore makes sense to regard ImageLength as
being optional for T.6 images provided that they are written as a
single strip, and that the length of the strip is accurately
reflected in the StripByteCounts field.


 Tag   = 258
 Name  = BitsPerSample
 Type  = SHORT
 Count = SamplesPerPixel


The BitsPerSample and the SamplesPerPixel (tag 277) fields, when
multiplied together, indicates the number of bits needed to represent
one pixel on the screen.  For a normal black and white fax image,
both fields must be set to the default value of 1 indicating that one
pixel represents one bit.  This can be accomplished (as in our
example IFD) simply by leaving the fields out, as the default is
precisely what is required.  However, where BitsPerSample is present
it must be checked.

BitsPerSample values of 4 or 8 with SamplesPerPixel values of 1 are
commonly used for grayscale images.  RGB colour images, which have a
SamplesPerPixel value of 3, needs to specify the number of bits for
each sample.  They therefore have a BitsPerSample field with COUNT=3
which contains a pointer to an array with the values 8,8,8.

See also : SamplesPerPixel


 Tag   = 259
 Name  = Compression
 Type  = SHORT
 Count = 1


The baseline bilevel TIFF specification states that this field takes
only one of three possible values.  The value 1 indicates an
uncompressed bitmap, the value 2 indicates a bitmap compression
scheme based on CCITT one-dimensional bit-oriented encoding, while
the value 32773 (8005 hex) indicates PackBits compression.  This is a
simple byte-oriented run-length encoding scheme originating with the
Apple Macintosh system.  Our sample IFD used the value 3, which is
used for T.4 fax encoding, while the value 4 is used for T.6
encoding.

Compression=3 was originally a required value for TIFF Class F files.
Such files conform strictly to the CCITT T.4 recommendation.  It is
important to appreciate the differences between CCITT 1-D TIFF
Compression=2 encoding and T.4 fax TIFF Compression=3 encoding, which
are small but significant.  While both use the same run-length code
tables, CCITT 1-D Compression=2 encoding differs from raw fax data in
much the same way as T.4 coding differs from T.6 encoding.  The key
differences are as follows :

1. EOL code words and fill bits aren't used.

2. The end of each row is determined by adding up the decoded run
lengths until the ImageWidth value is reached.

3. If the sum of the run lengths fail to equal the value of the
ImageWidth field then the whole file is lost.

4. Each scan line begins on the next available byte boundary, with
bits at the end of each row being ignored.

The modified fax-incompatible version of 1-D encoding isn't confined
to TIFF files, as (like T.6 encoding) it is also found in Postscript.
Though the differences are small, they are sufficient to ruin
attempts at successful decoding if the wrong compression value is
used.  A fax image decoder will flag the lack of an EOL code as a
fatal error as soon as the first line ends, while a Compression=2
decoder will start interpreting an EOL code as the start of the next
line.

None of the CCITT-based methods Compression=2, Compression=3 and
Compression=4 ought to include any RTC or EOFB codes in the image.
These should be seen purely as a fax transmission requirement which
indicates that a receiver should move to Phase D of a T.30 session,
and therefore these codes must be considered out of place in a disk
image.  I ought to add that in practise, I've never found that
including RTC codes in TIFF images causes any significant problems
with either decoding images or with sending them.

While all TIFF Class F compatible readers will understand files with
Compression set to 3, some TIFF aware applications without Class F
support will be able neither to read nor to write such files. 
Luckily, it is a relatively simple matter to include conversion
routines to and from uncompressed TIFF images (Compression=0).  This
enables any fax application to use an uncompressed TIFF file as an
intermediate step in coding or decoding unusable images.

As we pointed out earlier, Compression isn't a compulsory field for
baseline TIFF, and it has a default value of 1.  However, this is a
required field for TIFF Class F.  While it originally has a mandatory
value of 3, a recent addition to Class F has been support for the
already existing TIFF value Compression=4.  This indicates that CCITT
Group 4 compression is used, conforming to the specifications of
recommendation T6.  Such files can now be transmitted and received
using Group 3 fax machines, but only if error correction is being
used.

See also : FillOrder, T4Options


 Tag   = 262
 Name  = PhotometricInterpretation
 Type  = SHORT
 Count = 1


This is one of the compulsory fields found in every TIFF file.  For
bilevel images, the only two possible values are 0 and 1.  A value of
0 is called WhiteIsZero, while a value of 1 is called BlackIsZero.
While these names makes sense for uncompressed files, they can't be
used in the same way in 1-D coded images, as the codes for white run
lengths are not the logical complements of the matching black runs,
and all lines must begin with a white run.  The
PhotometricInterpretation of the bits is therefore to be applied at
the point they are displayed or printed, not at the point where they
are read from the file.  As we pointed out earlier, screen images
commonly require PhotometricInterpretation to be set to 1, since a
memory-mapped screen full of 0s is generally black.  Conversely, a
blank page is all white, so printed images require
PhotometricInterpretation to be set to 0.


 Tag   = 266
 Name  = FillOrder
 Type  = SHORT
 Count = 1


This is probably the most confusing and awkward field in the whole
set that we need to consider.  FillOrder is a field with the default
value of 1.  This value means that the first sequential bit in an
image is stored in the most significant bit of the first byte of the
stored bitmap.  Another way of putting it is that the order of bits
in a byte when read normally from right to left directly corresponds
to the order of the bits in the image when they are displayed as
normal from right to left.  Therefore the bit sequence
1111000000000001 (which is a T.4 white run of 7 followed by an EOL
code) would be represented by the two bytes 11110000 and 00000001.

The problem with the default FillOrder value of 1 is that T.4 data is
generally transmitted by a computer to a fax modem in bytes rather
than bits, and the almost universal method of sending a byte is to
send the least significant bit first.  We described this convention
briefly in chapter 1, where we said it caused problems that would
crop up again and again when dealing with fax-related issues.  This
is the first of those occasions.  The difficulty is that though we
start with the sequence 1111000000000001, the bits would get sent in
the order 0000111110000000, and would be received in that order by an
fax machine.  A fax machine is designed for bit-oriented transmission
and would always see a bit sequence.  It doesn't assemble the receive
bits back into bytes with the least significant bit first, and the
data received would not be recognizable as a white run of 7 followed
by an EOL.

The same problem would happen when a fax was being received by a
computer.  The bits received would be assembled into bytes with the
first bit received becoming the least significant bit of the byte.  A
sequence of eight bits received in the order 00000011 would be passed
to the computer as the byte 11000000.  In other words, we have two
equally natural bit orderings for asynchronous fax data bytes,
depending on whether we are interpreting the data or transferring it.
The natural order for interpretation of a bitmap is the same as the
usual order for representating it.  This is FillOrder=1.  On the
other hand, the natural order for a bitmap transferred over a
communications link as a series of bytes would be FillOrder=2.

This field has a somewhat patchy pedigree.  By the time the time TIFF
version 5.0 came out, it was so out of favour that it was placed
(like SubfileType) in the No Longer Recommended category, and the
default of Fillorder=1 was suggested for all documents.  However, the
field was resurrected by the TIFF Class F specification, which
comments that "the vast majority of facsimile products store data LSB
first, exactly as it appears on the telephone line" and went on to
make both the use of tag 266 and the support of either bit order
mandatory.  The TIFF 6.0 specification concurs with this view, further
stating that the FillOrder value for facsimile images files should be
made explicit rather than the default being assumed, but further
states that "FillOrder=2 should occur only in highly-localized and
preferably transient material" and that "FillOrder=1 should be
employed wherever possible in persistent material that is intended
for interchange".

We didn't use the FillOrder field in our sample IFD, but in view of
the fact that we are dealing with facsimile data, it is clear that it
would have done no harm to have specified a value.  If our raw fax
data had been captured directly off the telephone line, this would
have been a fatal error.  While having the wrong value for the
required PhotometricInterpretation field gives the relatively
innocuous result of a negative image, having the wrong value for the
FillOrder field results in total garbage as each octet in the bit
stream becomes reversed.

Every fax application author has to make their own decision as to
which order to use.  My own personal preference is to use the natural
representational bit sequence with FillOrder=1.  It is the default,
it offers the most opportunities for data interchange with other
applications, and I find it easier to visualize and work with.  This
makes software easier to write and debugging much smoother.  However,
the trade-off is that each byte may have to be reversed before
transmission and on reception.  This isn't a lengthy process and
doesn't take much in the way of code to reverse the order of bits in
a byte.  Using a lookup table is even quicker, and on many systems
can be implemented using only two machine instructions.  While it is
possible to conceive of an environment where every clock cycle is
crucial, I would think that if the overhead involved in reversing the
bit order was considered too great then faxing on such a system must
be a pretty borderline activity.  I don't think that deciding to use
FillOrder=2 on the basis that it is quicker makes an awful lot of
sense.


 Tag  = 269
 Name = DocumentName
 Type = ASCII
 

DocumentName is an ASCII field containing a string which identifies
the original document, or source file, from which the image was
generated.  It is an optional field which can be ignored, but is
clearly useful in fax and document management.


 Tag  = 270
 Name = ImageDescription
 Type = ASCII


ImageDescription is another ASCII field describing the contents of
the image, which presumably is useful for scanned images where
DocumentName is inapplicable.  It is an optional field which can be
ignored.


 Tag   = 273
 Name  = StripOffsets
 Type  = SHORT or LONG
 Count = StripsPerImage


Our sample IFD which was constructed earlier stored one image as a
single strip, and therefore the StripOffsets field effectively became
an ImageOffset field.  However, had we wished to, we could have made
use of the stripping facility in the TIFF specification.  The concept
of strips in TIFF files is quite straightforward, and is based on the
possibility that TIFF readers and writers might be unable to handle
complete images in one chunk.  They therefore allow for an image to
be broken up into horizontal strips, each of which is stored
separately.  If we wanted to, we could divide our fax into strips
containing 100 rows each by setting RowsPerStrip to 100.  Since the
ImageLength entry contains 1143, we therefore would have a
StripsPerImage value of 12 strips (with the last strip being a short
one). StripsPerImage isn't a field and has no tag, but has to be
computed for each image in a TIFF file by dividing ImageLength by
RowsPerStrip.

The offsets of the data for the 12 strips would be stored as an array
(a list) of 12 long or short integers, and the start of the array
would be pointed at by the StripOffsets entry.  The number of bytes
in each strip (after any compression) stored as another array of 12
long or short integers pointed at by the StripByteCounts entry.

However, the authors of the TIFF Class F document which is devoted to
the application of TIFF to faxes state that

"research failed to  uncover a single existing application that could
not read a single-strip page where they could read the same file in a
multi-strip format.  Indeed, applications seem to be more sensitive
to the total size of the decoded image and are not particularly fussy
about banding.  This result is not surprising, considering that most
desktop publishing programs are prepared to deal with massively
larger images than those one finds in facsimile.  In short, each page
may be represented as a single strip of any length."

I've never found any problems arising from taking this advice, and it
certainly simplifies writing fax data as TIFF images.  If you think
about it, even the simplest fax machine can print out fax data a line
at a time while it is still receiving the rest of the page.  It is
simply not necessary to have the complete image before attempting to
decode a part of it.  There are some techniques supported within the
TIFF specification which do require a whole strip to be available,
such as the zig-zag scanning method used in JPEG images.  It is
probably images such as these that give rise to the warnings you
might find about large strips.  There is one in version 6.0 of the
TIFF specification stating that compatibility with operating systems
such as MSDOS and Windows requires that strips in both compressed and
uncompressed forms, should not be larger than 64K bytes.  Despite
these scare stories, decoding methods such as those used in the code
section of this book should give rise to no problems no matter what
operating system is being used, as they work on the fly ; they only
require as much memory as is needed for storing a single scan line
from an image.

See also : RowsPerStrip, StripByteCounts


 Tag   = 274
 Name  = Orientation
 Type  = SHORT
 Count = 1


This is an optional field with a default value of 1, which indicates
that the first bit of the bitmap is the top left hand corner of the
image, and that the image is coded row by row, using standard
portrait orientation.  All fax scanners start at the top left corner
and work their way across and down, so the default suits us quite
well.  The complete set of values for this field is as follows :

Ŀ
1  top left corner      portrait  
2  top right corner     portrait  
3  bottom right corner  portrait  
4  bottom left corner   portrait  
5  top left corner      landscape 
6  top right corner     landscape 
7  bottom right corner  landscape 
8  bottom left corner   landscape 


Faxes fed into a scanner upside down have an orientation of 3.  None
of the other values make a lot of sense in a fax context, but TIFF
Class F suggests this field might be useful for correcting things
like upside-down faxes.  Personally I'm not convinced.  An major
problem would be that there would be no obvious way of a computer
working out for itself whether a fax was upside down or not.  Given
the ease with which a page can be turned upside down, the coding
effort involved in devising a suitable algorithm seems out of
proportion to the difficulties that upside down faxes cause their
recipients.


 Tag   = 277
 Name  = SamplesPerPixel
 Type  = SHORT
 Count = 1


This is used in conjunction with the BitsPerSample field.  If the
values for the two are multiplied together, the result is the number
of bits needed to represent one pixel on the screen.  Like
BitsPerSample, this is a field has a default value of 1.   It is not
optional, as there must always be a value for SamplesPerPixel.
However, if the default is what is required then the field need not
be spelt out.

Both bilevel black and white and monochrome grayscale images have
SamplesPerPixel=1.  (They can be distinguished by the fact that only
grayscale images have a BitsPerSample value greater than 1.)

Colour images have SamplesPerPixel values greater than 1, in which
case the COUNT in the BitsPerSample field is set to the same number,
and the BitsPerSample field has to point to an array rather than
containing a simple number.

(If you get the impression that all images apart from fax are
hideously complicated by comparison, you are probably correct. )

See also : BitsPerSample


 Tag   = 278
 Name  = RowsPerStrip
 Type  = SHORT or LONG
 Count = 1


The TIFF specification states that the RowsPerStrip entry (tag 278)
has a default value of 2^32-1, effectively indicating that the
default image consists of a single strip.  If this is a suitable
value, the field need not be included in an IFD.  Our sample IFD took
this view and left the field out on the basis that as the file
consisted of a single-strip image, the default was perfectly
adequate.

However, the TIFF Class F document states that RowsPerStrip is a
required field which should have a value equal to that of
ImageLength.  While I haven't seen a TIFF reader that failed to
understand that an IFD with no RowsPerStrip field was a single strip,
the cautious approach dictates that the equality between ImageLength
and RowsPerStrip be made explicit.  In any event, a TIFF reader which
couldn't handle multiple strips would need to know what this field
meant so that incompatible TIFF files could be rejected.

See also : StripOffsets


 Tag   = 279
 Name  = StripByteCounts
 Type  = SHORT or LONG
 Count = StripsPerImage


For a single strip file (such as our sample IFD) this field contains
the number of byte, after compression, in the image.  For a
multi-strip file this field would needs to point to an array (a list)
of the number of bytes in each strip.  Note that StripsPerImage isn't
a field but has to be computed for each image in a TIFF file by
dividing ImageLength by RowsPerStrip.

There is obviously no default for this field.  However, there is some
confusion as to whether it is an optional field or not.  The TIFF
version 6.0 specification states that it is required for all TIFF
files.  Earlier versions simply stated that it made the chore of
buffering compressed data easier.  The version 5.0 specification
points out that many TIFF images don't contain this field and that in
a strict sense it isn't necessary, but nevertheless declared it as
required for all classes.  TIFF Class F also lists this field as one
that is required.

The sample IFD which we constructed earlier in the chapter didn't use
the StripByteCounts field, and it describes a perfectly valid TIFF
image which many readers will accept without a quibble.  Readers that
reject images like this generally do so only because they don't
support the compression method, and while some other readers might
warn about single strip images, they don't usually fail.  However, it
is clear that a reader would be perfectly entitled to reject a file
that didn't contain this field.  The fact that a TIFF file is valid
doesn't imply that every TIFF reader must be able to read it.  So for
maximum flexibility if for no other reason, this field should always
be included.  Keeping track of the number of bytes written to an
image ought to trivial for a TIFF writer in any case.

There are better reasons for including this field however.  One we
have already come across is that having a value for StripByteCounts
makes decoding an image possible in cases where the length may not be
known.  As we have seen, writing a valid value for ImageLength on
reception of T.6 fax data presents definite difficulties, while
writing a valid value for StripByteCounts is much more
straightforward.

This is a specific instance of a more general phenomenon, which is
that reading an image without a StripByteCounts field always requires
that the number of lines in the Imagelength field is used to work out
when to stop reading the image.  While it is true that file with only
a single image can simply be read until the end of file is
encountered, if neither StripByteCounts nor Imagelength is present,
there is no way of telling whether the image is a complete or a
partial one.  If we were starting from scratch, we might consider
including the RTC code at the end of the fax as an extra check on
image integrity, but TIFF class F files explicitly prohibit this.

Including either StripbyteCounts or ImageLength is especially
important for multi-image files, where the lack of an end-of-file
marker may cause us to run over the end of an image and inadvertently
displaying part of the next one.  If ImageLength is being used to
work out the size of a page in a T.4 one-dimensionally compressed
file, this means either decoding the file as it is being read and
counting up the run lengths for each line until ImageWidth is
reached, or else bit-shifting each byte of data in search of EOL
codes and counting those up instead.  Both these routes are
computationally far more expensive than simply using a value in
StripByteCounts to read a known number of bytes from the file.

Since there is every likelihood that the image will be read in
real-time while it is being transmitted to another fax machine, the
presence of StripByteCounts is of great benefit, as anything that
decreases the load on the CPU means a greater likelihood of more
reliable communications, especially in multi-tasking environments.
This is the prime reason in my view for insisting that
StripByteCounts should be a required field even for T.4 images.

Another reason, applicable to fax receivers, is that storing multiple
pages as images in a single TIFF file means that an application would
usually need to keep track of the number of bytes in each image in
any case.  It is easiest for a receiver, which doesn't know in
advance how many pages a fax will contain, to store each page
sequentially with an IFD followed by the image data, followed by the
next IFD and image, and so on.  Since one of the requirements of a
TIFF file is that an IFD must begin on a word boundary, our
hypothetical receiver would need to keep some sort of track of
whether the last byte in an image written to a file was on an odd or
even offset.  Keeping a count of bytes is as easy a way of making
this essential check as any other, and since the value for
StripByteCounts is known if this strategy is adopted, then it may as
well be included in the IFD.

See also : ImageLength, RowsPerStrip, StripByteCounts


 Tag   = 282
 Name  = XResolution
 Type  = RATIONAL
 Count = 1


This field contains the horizontal resolution of the image.  The
ResolutionUnit field specifies what units are to be used.  TIFF Class
F originally required that the only XResolution permissible should be
204 dots per inch, as this was the horizontal resolution of most
Group 3 fax machines.  Resolutions of 300 dpi and 400 dpi were later
added (see below).

The two resolution fields are the only ones in our restricted set to
have the RATIONAL type.  Since this consists of a fraction defined as
two LONG integers in numerator/denominator order, it is 8 bytes long
and the resolution fields must therefore contain an offset to the
location of this value in the file.  There is no room for the value
itself.  This is clearly shown in our sample IFD.

Note also that the horizontal resolution of 1728 dots per 215 mm
approximates to 8.0372 dots per centimetre.  Applying a conversion
factor of 1 centimetre=.394 inches gave us the fraction 80327/394
dots per inch, which we stored as the horizontal resolution in the
example.  This is 203.94 dots per inch rather than the exact 204
requires by Class F, so readers need to be a little flexible and
round up any fractions they might find stored as resolution values.

The TIFF reader on the accompanying disk is much more flexible than
Class F specified, and will accept images of any resolution. We take
the view that provided the ImageWidth is 1728, the precise horizontal
resolution is immaterial.  It is the responsibility of the user to
take account of any enlargement or reduction in image size that may
result from not adhering to a resolution of 204 dpi.

See also : YResolution, ResolutionUnit


 Tag   = 283
 Name  = YResolution
 Type  = RATIONAL
 Count = 1


This field contains the vertical resolution of the image.  The
ResolutionUnit field specifies what units are to be used.  TIFF Class
F originally required that the only YResolution permissible should be
98 and 196 dots per inch, as these are the normal and fine vertical
resolutions of most Group 3 fax machines.

When the Group 4 compatible resolutions of 300 x 300 dpi and 400 x
400 dpi were added to the T.30 specification in 1993, the TIFF Class
F definition was revised to include these resolutions, though with a
warning that applications which supported them risked incompatibility
with other fax applications.  However, Microsoft have made a point of
supporting 300 x 300 dpi in their fax software, so the Group 4
resolutions must now be considered respectable.

As with the horizontal resolution, the example IFD stored the exact
vertical resolution of 3.85 lines/mm with the conversion factor of 1
centimetre=.394 inches as the fraction 38500/394 dots per inch.  This
is 97.7 dots per inch rather than 98 dpi, which reinforces the point
that Class F readers need to round up any fractions they might find
stored as a resolution value.

As with the horizontal resolution, the TIFF reader on the
accompanying disk doesn't really care about the resolution at all,
and takes the view that sorting out incompatabilities is the user's
responsibility.  Mandating a fixed resolution in the manner of TIFF
class F is rather too stringent, and simply prohibits the sending of
images that might otherwise be perfectly acceptable.

One thing that does need to be done for all faxes is to compare the
horizontal and vertical resolutions to determine the most suitable
mode to send the fax in.  Comparing the horizontal and vertical
resolutions in this way gives us what is termed an aspect ratio.  A
normal resolution fax has an aspect ratio of approximately 2:1
(204:98) while a fine resolution fax has an aspect ratio of
approximately 1:1 (204:198).  A decision as to whether an image
should be sent in normal or fine resolution should be made on the
basis of which one most closely maintains the original aspect ratio.

Images converted from devices such as scanners typically have a 1:1
aspect ration.  While images with other proportions are faxable, they
become unduly distorted on reception, and will be either squashed or
stretched. This sometimes makes a difference ; sometimes it is
immaterial.  For instance, images converted to TIFF from screen-based
formats usually maintain the same aspect ratio as the original
screen, which never matches either of the fax options.  In general,
screens are wider than they are long, but higher resolution models
are more likely to approach a 1:1 ratio.  The PC standard has been
moving in this direction, from the 8:5 ratio of the CGA (320 x 200)
through the 4:3 VGA ratio (640 x 480) to the top-end SVGA ratio of
5:4 (1280 x 1024).  

See also : ResolutionUnit, XResolution


 Tag   = 292
 Name  = T4Options
 Type  = LONG
 Count = 1


This optional field was formerly known as Group3Options.  It is made
up of a set of 32 flag bit fields, and has a default of 0.  It is
only read if Compression=3.

Bit 0 is set to 1 if two-dimensional coding is being used, otherwise
it is set to 0 for one-dimensional coding.  If both 2-D coding and
strips are being used, the first line of each strip must be coded
1-dimensionally.  This means that RowsPerStrip must be a multiple of
the T.4 K parameter which controls how often a 1-D line must occur. 
K is set to 2 for normal resolution and 4 for fine resolution.

Bit 1 is set to 1 if uncompressed mode data might be present in the
compressed image data.

Bit 2 is set to 1 if fills bit have been added before any EOL codes,
to ensure that the EOL always ends on a byte boundary.

The default for tag 292 is 0, for 1-dimensional coding without
byte-aligned EOL codes.  This is of course exactly what was assumed
in our sample TIF header.  However, TIFF Class F restricts the values
of this field to either 4 (100) or 5 (101) and makes it required
rather than optional.  In other words, uncompressed mode is not valid
for TIFF Class F files, and all EOLs must be byte-aligned.  The field
is therefore used only to indicate whether an image is coded using
one-dimensional modified Huffman coding, or coded using
two-dimensionally modified READ coding.

The reason for uncompressed mode being disallowed is stated in the
Class F documentation as being "due to the disruptive effect to
application software of line-length errors and because such errors
are likely in everyday facsimile transmissions".  TIFF version 6.0
also states that "uncompressed mode is not well specified and many
applications discourage its usage".  Whether or not you think this
rationale makes sense, it is probably not a good idea to use
uncompressed mode if it can be avoided as the 6.0 specification goes
on to point out that "readers that have no provision for uncompressed
mode will generally reject any case in which the flag is set".  In
other words, Caveat Receptor.

The Class F requirement that all compressed images have byte-aligned
EOLs presents something more of a problem.  The only reason given for
it is that it is "in the Spirit of Tiff".  This somewhat metaphysical
explanation is amplified by the statement that "byte alignment
relieves applications software of the burden of bit-shifting every
byte".  However, while there is no difficulty in ensuring byte
alignment for images that are computer-generated, data coming in over
a phone line from a remote fax cannot be guaranteed to contain only
byte-aligned EOLs.  Therefore meeting this limitation in software
imposes an extra bit-shifting burden on a fax receiver.  It is true
that easy detection of EOL codes makes life simpler for a transmitter
when fill bits needed to be inserted before an EOL to ensure that a
minimum scan line time is met.  However, it makes life that much more
difficult for a receiver which normally has no need to detect EOL
codes at all.  My own view is that the decision as the where the
responsibility for EOL detection ought to lie is something that
needn't necessarily have been a part of a standard specification, as
it surely would vary from one application to another.


 Tag   = 293
 Name  = T6Options
 Type  = LONG
 Count = 1


This optional field was formerly known as Group4Options.  It is made
up of a set of 32 flag bit fields, and has a default of 0.  It is
only read if Compression=4.  The only bit used in the value for this
field is bit 1, which is set to 1 if uncompressed mode data might be
present in the compressed image data.  All other bits, including bit
0, have the value 0.

See also : T4Options


 Tag   = 296
 Name  = ResolutionUnit
 Type  = SHORT
 Count = 1


The units used for defining XResolution and YResolution are indicated
by the value stored in this field.  There are three possibilities.
The only ones we need to concern ourselves with are 2, indicating
Dots Per Inch, and 3 Indicating Dots Per Centimetre.  The default is
2.  This field is not optional, as units of resolution are always
needed, but as with our sample IFD, if the default fits, the field
may be omitted.

A value of 1 for ResolutionUnit indicates that there is no unit of
measurement.  This means that the two resolution fields simply define
the aspect ration of the image, and it can be scaled as desired.  
While this is probably not a value that a fax application would use
when creating a file, it is quite acceptable when reading a TIFF
image prior to faxing.  In this case, the actual units used for the
resolution are in practise less important than the aspect ratio, as
the only real decision to be taken is whether to fax an image in
normal resolution with an aspect ratio of 2:1 or fine resolution,
with an aspect ration of 1:1.

See also : XResolution, YResolution




  Tag  = 297
 Name  = PageNumber
 Type  = SHORT
 Count = 2


The page number of an image within a fax document can be saved using
this field.  The field comprises two SHORT values, and though it has
a COUNT of 2, both values can be stored in the 8-byte space available
at the end of the field.  The first SHORT is the page number and the
second SHORT is the total number of pages.  The page numbering begins
with page 0.  This is normally an optional field, and there is no
default, though if the second SHORT is 0, it is assumed that the
total number of pages is unavailable.  A single-page document would
therefore have a PageNumber field with the SHORT-SHORT hex values of
either 0001-0001 or 0001-0000.  However, the PageNumber field is
required for TIFF Class F.


 Tag  = 305
 Name = Software
 Type = ASCII


The name, and possibly the release number, of the software package
that created the image can be to stored using this optional field.


 Tag   = 306
 Name  = DateTime
 Type  = ASCII
 Count = 20


This optional field contains the date and time of the creation of the
image in the format YYYY:MM:DD HH:MM:SS.  The space between the date
and time together with the trailing 0 at the end of all ASCII data
types makes up the 20 bytes.  The time should be given in 24-hour
format.  TIFF Class F recommends the use of this field, presumably
for storing the reception time of an incoming fax or the transmission
time of an outgoing fax.


 Tag   = 326
 Name  = BadFaxLines
 Type  = LONG
 Count = 1


Faxes are usually received over a telephone line.  There is every
likelihood that such files received in this way will contain errors,
which manifest themselves as scan lines with run lengths that don't
add up to the image width.  Such lines are often replaced with the
last good line received, but whether or not this is done, the
BadFaxLines field can be used to store the number of lines affected.
A comparison of the value in this field with ImageLength would give a
reader an idea of the quality of the fax image.  Of course, there is
generally no way of knowing that it wasn't an EOL code that was
destroyed, and therefore if there is a value in this field it might
not be entirely accurate.

This field is only valid for TIFF Class F files, where it is optional
but recommended.

See also : CleanFaxData, ConsecutiveBadFaxLines


 Tag   = 327
 Name  = CleanFaxData
 Type  = BYTE
 Count = 1


If a TIFF file is computer-generated, then it will definitely contain
no errors at all.  In this case, CleanFaxData has a value of 0.
Presumably a file that isn't computer-generated but is received over
a phone line could also qualify for the CleanFaxData=0 accolade if it
were known to be error-free.  Faxes received via Error Corrected Mode
could qualify in this way.

A CleanFaxData value of 1 indicates that there are no bad scan lines
in the file, but it was still received corrupted.  The absence of bad
lines is the result of the receiver regenerating them, presumably by
replacing them with the previous correct line.

Finally, CleanFaxData=3 is an unashamed declaration that the data in
the image is so raw that no guarantee can be given that there are no
bad scan lines contained within it.

This field is only valid for TIFF Class F files, where it is optional
but recommended.

See also : BadFaxLines, ConsecutiveBadFaxLines


 Tag   = 328
 Name  = ConsecutiveBadFaxLines
 Type  = LONG or SHORT
 Count = 1


As its name implies, this field contains the maximum number of
consecutive bad lines (where the run lengths don't add up to the
correct width) that were received.  If CleanFaxData=1 then these
lines won't still be present in the file.  The point of this field is
that a comparison of the counts in ConsecutiveBadFaxLines and
BadFaxLines gives some indication of line quality.  For example, if
the two are identical then the file had just one error burst.
However, if ConsecutiveBadFaxLines=1, then the bad lines are
distributed throughout the file and a high BadFaxLines count
indicates a bad connection and a high probability of an unusable
image.

This field is only valid for TIFF Class F files, where it is optional
but recommended.

See also : BadFaxLines, CleanFaxData


(6)  Short notes on the TIFF reader fragment

i. The TIFF reader fragment in Listing 4-6 omits certain necessary
checks, such as ensuring that that tags appear in ascending order,
and reversing the byte order of values where the writer and reader of
the TIFF file use different conventions (see Listing 4-3). Although
we listed sixteen compulsory tags for fax images earlier in this
chapter, we only need to examine fourteen when reading an image.  We
don't bother with NewSubfileType as we assume the possibility of
multi-page images, and we don't bother with ResolutionUnits either,
as we only need the physical dimensions to work out an aspect ratio.

ii. In the T.30 fax protocol the resolution is specified as bit 15 in
the DIS frame.  TIFF requires three 12-byte IFD entries,
ResolutionUnit, Xresolution and Yresolution.  The last two of these
only containing pointers to the resolutions themselves, which are
specified as two 8-byte RATIONALs. Hence (12 x 3) + (8 x 2) = 52. The
point is that a fax only has two possible resolutions, and a fax
image writer only has two possible choices about what the put in an
IFD.  However, a TIFF image has millions of possible resolutions and
a fax image reader has to disentangle one of two choices from the
information provided in the IFD.  It is true that CPUs are fast and
memory is cheap, Even so, our fax software may well be running as a
permanently resident system utility in real time, and the last thing
we ought to do is to force our code to take up valuable time and
space with the chore of interpreting an IFD twice.  This is why the
TIFF reader in our code doesn't simply pass the IFD back, but instead
passes summary information in a structure.  

iii. Note that the unused bits in our IMAGE structure allow for
expansion to include any unsupported options, such as superfine and
inch based resolutions, or uncompressed mode when coding.

iv.  In the TIFF reader on disk, we've opted to make the use of the
IMAGE structure member rather more complex.  As well as being read by
the caller to detect whether an image is the last in a file, it can
also be set by a caller to tell tiffread_ifd which image in a file
should be read next.

When a previously unknown file has just been opened, the caller must
set the IMAGE.ifd to 0.  This is recognised by tiffread_ifd as a
special case.  When it is called with an IFD offset of 0, the
function verifies that there is a proper TIFF header in the file and
then goes on to read the first IFD.  The members of the IMAGE
structure are filled in, including IMAGE.ifd, which holds the offset
to the next IFD.  Subsequent calls to tiffread_ifd, for as long as
IMAGE.ifd is non-zero, will begin with an fseek to this offset to
obtain the location and description of the next image.  On reading
the last IFD in the file, the offset returned will be zero again ;
any subsequent read will begin at the first image again.

The advantage of returning the proper offset to an IFD (rather than a
result code) is that where a TIFF file does contain multiple images,
building a table of IFDs enables quick access to any particular one
that may be required without having to search through the links in
the file first.  Though this isn't a feature that is exploited in the
code on the accompanying disk, it isn't difficult to envisage
applications for which it is useful apart from disentangling
multiple-format TIFF images.  Fax-on- demand and selective polling
operations spring to mind immediately.  The disadvantage is that the
ifd offset might be corrupted, or set to a stupid value by mistake ;
but this applies equally to the normal file and structure pointers
used when calling the tiffread_ifd function.

In any event, the caller is relieved of the responsibility for
checking that an image is suitable for faxing as the TIFF image
descriptor is verified within tiffread_ifd.  Apart from the
possibility of an invalid offset (for which the function returns with
a 0), if an invalid or unfaxable IFD is read, IMAGE.offset returns
set to 0.  This gives a caller to tiffread_ifd the following cases to
handle :

* If ((image->offset==0) && (image->ifd==0)) then the current image
  is unsupported and there are no more in the file.

* If ((image->offset==0) && (image->ifd!=0)) then although the
  current image is unsupported, the file contains more images which
  may be readable, and the caller can continue to process the file.

* If ((image->offset!=0) && (image->ifd==0)) then the current image
  is supported but the file contains no more image after this.

* If ((image->offset!=0) && (image->ifd!=0)) then the current image
  is supported but the file contains no more images.
