AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1997.01.08 16:58 "TIFF Class F", by Gianni Creta
1997.01.08 19:56 "TIFF Class F", by Frank Kim
1997.01.08 22:36 "Re: TIFF Class F", by Helge Blischke
1997.01.09 12:43 "Re: TIFF Class F", by Frank Kim

1997.01.08 22:36 "Re: TIFF Class F", by Helge Blischke

Can anyone please let me know where I can find the specifications for TIFF Class F. The class is a sub-class of baseline TIFF and is used for facsimiles.

TIF Class F has, as far as I know, never become part of an official TIFF specification. It was discussed as an appendix to TIFF 5.0 but then incorporated in TIFF 6.0 specification.

As the TIFF-F draft may be of some general interest nevertheless, I looked it up in my dusty paper archive and OCRed it; it is attached to this message. Hope this will help to solve your problems.

H. Blischke <H.Blischke@srz-berlin.de>

                             TIFF CLASS F

                           October 1, 1991

TIFF Class F was defined in late 1989 by Joe Campbell of Everex
Systems, Inc. from the results of a poll of the facsimile industry.
The goal was to define a file format that is simultaneously
suitable for native use in Group 3 computer facsimile products, and
as a file interchange medium with the outside world. Since that
time, there have been only three minor revisions, mostly editorial in
nature. The revision history of the specification is at the end of
this document.

TIFF Class F defines a subset (a "Class") of existing TIFF
tags, necessary to support Group 3 facsimile data. In many cases,
the values and sizes of these tags are also defined. Three new
optional tags are also defined.


TIFF Classes reduce the information burden on TIFF readers and
writers that wish to support narrow applications. For example,
Appendix G-l of TIFF 5.0 states that classes enable TIFF readers
"to know when they can stop adding TIFF features." In other
words, defining a Class enables applications interested only in
reading that Class to give up if the characteristic tags and values
are not present. Therefore, TIFF Class F insists on a rather narrow
definition of tags. In a general TIFF file, for example, the writer
would be free to create single-page documents without the
NewSubFileType and PageNumber tags. Not so for a Class F file, where
the multi-page tag is required even for a single page.

TIFF Class B (Bilevel) is a sub-class of TIFF. That is, all tags
that are required in TIFF are also required in Class B. TIFF Class F
(Facsimile) is a sub-class of Class B tBilevel). That is, all
tags that are required in Class B are also required in Class F. For
some common tags, however, Class F limits the range of acceptable
values. The YResolution tag, for example, is a Class B tag, but its
Class F value is limited to either 98 or 196 dpi. Such tags are
listed in "Required Class F Tags."

Other Class B tags have a slightly eccentric meaning when applied to
facsimile images. These are discussed in the section "Bilevel
Required." There are also tags that may be helpful but are not
required. These are listed in the "Recommended Tags" section.
A brief list of all the tags required by TIFF Class F, grouped by
class, is in the section "Required Facsimile Tags Grouped By
Class." Finally, technical topics are discussed in the sections
"Technical Points" and "Warnings."

REFERENCES

        A machine-readable copy of this document can be downloaded from
        the Aldus Forum on Compuserve. Type GO ALDUS and look through the
        "Libraries" menu. Substantive questions about TIFF Class F can
        be faxed to its author: Joe Campbell, Everex Systems, Inc:
        (510) 540-5835 or (510) 841-5441, or via Compuserve Mail
        71331,1237.


        TIFF CLASS F Revision 3: October 1, 1991 Page 1






        TIFF Class F is a parallel but unrelated effort to EIA Project Number
        2388, an industry standards group working to standardize facsimile
        hardware. For information about this standard, contact the EIA.
        Those wishing to participate in the revision and upkeep of TIFF Class
        F should read the section "Revising the TIFF Class F
        Specification," at the end of this document.

        Group 3 facsimile is described in the "Blue Book," Volume VII,
        Fascicle VII.3, Terminal Equipment and Protocols for Telematic
        Services, The International Telegraph and Telephone Consultative
        Committee (CCITT), Melbourne, 1988.


CLASS F REQUIRED


        Compression = 3 or 4. SHORT.

             3 Group 3, one-dimensional encoding with "byte-aligned"
                EOL's. An EOL is said to be byte-aligned when Fill
                bits have been added as necessary before EOL codes such
                that EOL always ends on a byte boundary, thus ensuring
                an EOL-sequence of a l byte preceded by a zero nibble:
                xxxx0000 00000001. The data in a Class F image is not
                terminated with an RTC. Please see items 4 and 5 in
                the "Warnings" section. For Group 3 two-dimensional
                encoding, set bit 1 in Group30ptions. Please see item 2
                in the "Warnings" section.


             4 Group 4 two-dimensional encoding. MMR (Modified-
                Modified READ) compression, formerly found only in
                Group 4 facsimile, are now available in Group 3
                devices. When this option is used, bits zero and one
                in the Group30ptions tag are ignored.



        FillOrder = 1, 2. SHORT. TIFF Class F readers must be able
            to read data in both bit orders, but the vast majority of
            facsimile products store data LSB first, exactly as it
            appears on the telephone line.
             1 Most Significant Bit first.
             2 Least Significant Bit first.

        Group30ptions = 4,5. LONG. Data may be one- or two-
            dimensional, but EOL's must be byte-aligned. Uncompressed
            data is not allowed. When Group 4 compression is used,
            bits zero and one in the Group30ptions tag should be
            ignored.
            bit O O for 1-Dimensional, 1 for 2-Dimensional
            bit 1 Must be O (uncompressed data not allowed)


        TIFF CLASS F Revision 3: October 1, l991 Page 2





              bit 2 1 for byte-aligned EOL's


        ImageWidth = 864, 1216, 1728, 2048, 2432. SHORT or LONG. LONG
            recommended. These are the fixed page widths in pixels
            defined in CCITT Group 3.

        NewSubFileType = 2. LONG. The value 2 identifies a single
            page of a multi-page image, even if the document contains
            only one page.

        PageNumber. SHORT/SHORT. This tag specifies the page numbers
            in the fax document. The tag comprises two SHORT values:
            the first value is the page number, the second is the
            total number of pages. The number of the first page is
            zero. Single-page documents therefore use 00000001 hex.
            The total number of pages is required only in the
            PageNumber tag associated with the first IFD, and is
            optional in subsequent IFD's. Writers utilizing this
            option should set the page count portion of the subsequent
            PageNumber tags to zero. (Please remember that the first
            IFD is not necessarily page one.)


        ResolutionUnit = 2,3. SHORT. The units of measure for
            resolution:

             2 Inch

             3 Centimeter

        XResolution = 204, 300, 400 (inches). RATIONAL. The horizontal
                resolution of the image expressed in pixels per
                resolution unit. See "Technical Point #6," below.

        YResolution = 98, 196, 300, 400 (inches). RATIONAL. The
                vertical resolution of the image expressed in pixels
                per resolution unit. See "Technical Point #6," below.


BILEVEL REQUIRED

        Although these tags are already required in Class B (Bi-Level)
        files, an explanation of their usage for facsimile images may be
        helpful.


        BitsPerSample = 1. SHORT. Since facsimile is a black-and-
            white medium, this must be 1 (the default) for all files.

        ImageLength. SHORT or LONG. LONG recommended. The total
            number of scan lines in the image.

        PhotometricInterp = O,1. SHORT. This tag allows notation of
            an inverted ("negative") image:



        TIFF CLASS F Revision 3: October 1, 1991 Page 3





            0 Normal

            1 Inverted


        RowsPerStrip. SHORT or LONG. LONG recommended. The number of
                scan lines per strip. When a page is expressed as one
                large strip, this is the same as the ImageLength tag.

        SamplesPerPixel = 1. SHORT. The value of 1 denotes a bi-
                level, gray scale, or palette color image.

        StripByteCounts. SHORT or LONG. SHORT recommended. For each
                strip, the number of bytes in that strip. If a page is
                expressed as one large strip, this is the total number
                of bytes in the page after compression.

        Stripoffsets. SHORT or LONG. For each strip, the offset of
                that strip. The offset is measured from the beginning
                of the file. If a page is expressed as one large strip,
                there is one such entry per page.

NEW TAGS

        There are only three new tags for Class F. All three tags describe
        page quality. The information contained in these tags is usually
        obtained from the receiving facsimile hardware, but since not all
        devices are capable of reporting this information, the tags are
        optional.

        Some applications need to understand exactly the error content of the
        data. For example, a CAD program might wish to verify that a file has
        a low error level before importing it into a high- accuracy document.
        Because Group 3 facsimile devices do not necessarily perform error
        correction on the image data, the quality of a received page must be
        inferred from the pixel count of decoded scan lines. A "good" scan
        line is defined as a line that, when decoded, contains the correct
        number of pixels. Conversely, a "bad" scan line is defined as a line
        that, when decoded, comprises an incorrect number of pixels.


        BadFaxLines

             Tag = 326 (146 hex)

             Type = SHORT or LONG

        This tag reports the number of scan lines with an incorrect
        number of pixels encountered by the facsimile during reception
        (but not necessarily in the file).

                 Note: PercentBad = (BadFaxLines/ImageLength) * 100



        CleanFaxData



        TIFF CLASS F Revision 3: October 1, 1991 Page 4





             Tag = 327 (147 hex)

             Type = SHORT

            O Data contains no lines with incorrect pixel counts or
                regenerated lines (i.e., computer generated)


            1 Lines with an incorrect pixel count were regenerated by
                the receiving device


            2 Lines with an incorrect pixel count existed, but were
                not regenerated by receiving device

        Many facsimile devices do not actually output bad lines. Instead, the
        previous good line is repeated in place of a bad line. Although this
        substitution, known as line regeneration, results in a visual
        improvement to the image, the data is nevertheless corrupted. The
        CleanFaxData tag describes the error content of the data. That is,
        when the BadFaxLines and ImageLength tags indicate that the facsimile
        device encountered lines with an incorrect number of pixels during
        reception, the CleanFaxData tag indicates whether these lines are
        actually in the data or if the receiving facsimile device replaced
        them with regenerated lines.

             ConsecutiveBadFaxLines

             Tag = 328 (148 hex)

             Type = LONG or SHORT

        This tag reports the maximum number of consecutive lines containing an
        incorrect number of pixels encountered by the facsimile device during
        reception (but not necessarily in the file).

        The BadFaxLines and ImageLength data indicate only the quantity of
        such lines. The ConsecutiveBadFaxLines tag is an indicator of their
        distribution and may therefore be a better general indicator of
        perceived image quality.


RECOMMENDED TAGS

        BadFaxLines. LONG. The number of
        "bad" scan lines encountered by the facsimile during
        reception.

             CleanFaxData = O, 1, 2. BYTE. This tag
        indicates whether lines with incorrect pixel count are actually
        in the data or if the receiving facsimile device replaced them
        with regenerated lines.


             0 Data contains no lines with incorrect pixel counts or
                regenerated lines (i.e., computer generated)



        TIFF CLASS F Revision 3: October 1, 1991 Page 5






             1 Lines with an incorrect pixel count were regenerated by
                receiving device

             2 Lines with an incorrect pixel count existed, but were
                not regenerated by receiving device

         ConsecutiveBadFaxLines. LONG or SHORT. The maximum number of
                consecutive scan lines with incorrect pixel count
                encountered by the facsimile device reception.

        DateTime. ASCII. Date and time in the format YYYY:MM:DD
                HH:MM:SS, in 24-hour format. String length including
                NUL byte is 20 bytes. Space between DD and HH.

        DocumentName. ASCII. This is the name of the document from
                which the document was scanned.

        ImageDescription. ASCII. This is an ASCII string describing
                the contents of the image.

        orientation. SHORT. This tag might be useful for displayers
                that always want to show the same orientation,
                regardless of the image. The default value of l is
                "Oth row is visual top of image, and 0th column is the
                visual left." An 180-degree rotation is 3. See TIFF
                5.0 for an explanation of other values.

        Software. ASCII. The optional name and release number of the
                software package that created the image.

REQUIRED TAGS GROUPED CLASS

        Required Tags, all TIFF: NewSubFileType, ImageWidth, ImageLength,
                                  StripOffsets, RowsPerStrip,
                                  StripByteCounts, XResolution, YResolution,
                                  ResolutionUnit

        Required Tags, Class B: BitsPerSample, Compression,
                                  PhotometricInterp, SamplesPerPixel

        Required Tags, Class F: FillOrder, Group30ptions, PageNumber


                             FILE INTERCHANGEABILITY


        File portability among various TIFF F applications, regardless of
        platform or operating system, is a primary goal of TIFF Class F.
        The following tag values should be used to assure maximum
        portability:

        1. FillOrder is 2 (least-significant bit first).



        TIFF CLASS F Revision 3: October 1, 1991 Page 6




        2. Group30ptions = 4 (one-dimensional encoding).

        3. ImageWidth is 1728 (that is, an A4 page).

        4. ImageLength must not exceed 1084 for 98 dpi documents and 2167
            for 196 dpi documents (that is, an A4 page). See Note 2, below.

        5. PhotometricInterp is 0 (normal).

        6. ResolutionUnit = 2 (inches).

        7. XResolution is 204.

        8. YResolution tag is 98 or 196.


        Note 1: In order for a document to print at a one-to-one scale
        on U.S. plain-paper fax machines, its ImageLength must not
        exceed 1025 for 98 dpi documents and 2050 for 196 dpi
        documents.


TECHNICAL POINTS


        1. Strips
            Those new to TIFF may not be familiar with the concept of
            "strips" embodied in the three tags RowsPerStrip,
            StripByteCount, StripOffsets.

            In general, third-party applications that read and write
            TIFF files expect the image to be divided into "strips,"
            also known as "bands." Each strip contains a few lines of
            the image. By using strips, a TIFF reader need not load the
            entire image into memory, thus enabling it to fetch and
            decompress small random portions of the image as necessary.

            The dimensions of a strip are described by the
            RowsPerStrip and StripByteCount tags. The location in the
            TIFF file of each strip is contained in the StripOffsets
            tag.

            The TIFF documentation suggests using strips of an
            arbitrary size of about 8K. Although various application
            programs assert that they "prefer" banded images, 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.

            In fact, there may be a compelling reason to employ a
            strip size equal to the length of one A4 page (297 mm).


        TIFF CLASS F Revision 3: October 1, 1991 Page 7




        When a document is imaged, it may be of any length. Not
        all fax machines, however, can accept unlimited length
        documents. Worse,the remote machine's page-length
        capability is not known until the fax connection has been
        established. The solution is for the transmitting fax
        device to image long documents into A4-size strips, then
        seam them together at transmission, after the capabilities
        of the remote fax machine is known.

    2. Bit Order
        Although the TIFF 5.0 documentation lists the FillOrder tag
        in the category "No Longer Recommended," Class F resurrects
        it. Facsimile data appears on the phone line in bit-
        reversed order relative to its description in CCITT
        Recommendation T.4. Therefore, a wide majority of
        facsimile applications choose this natural order for
        storage. Nevertheless, TIFF Class F readers must be able to
        read data in both bit orders.

    3. Multi-Page
        Many existing applications already read Class F-like files,
        but do not support the multi- page tag. Since a multi-page
        format greatly simplifies file management in fax
        application software, Class F specifies multi- page
        documents (NewSubfileType = 2). A "multi-page document" may
        contain only one page.

    4. Two-dimensional Encoding
        PC Fax applications that wish to support two-dimensional
        encoding may do so by setting Bit O in the Group30ptions
        tag. Please see item 2 in the "Warnings" section.


    5. Example Use of Page-Quality Tags
        Here are examples for writing the CleanFaxData,
        BadFaxLines, and ConsecutiveBadFaxLines tags:

              A. Facsimile hardware does not provide page quality
                 information: write no tags.

              B. Facsimile hardware provides page quality
                 information, but reports no bad lines. Write
                 only BadFaxLines = O.

              C. Facsimile hardware provides page quality
                 information, and reports bad lines. Write both
                 BadFaxLines and ConsecutiveBadFaxLines. Also
                 write CleanFaxData = 1 or 2 if the hardware's
                 regeneration capability is known.

              D. Computer generated file: write CleanFaxData = 0.

    6. Although 300 and 400 dpi are, strictly speaking, Group 4
        resolutions, it is virtually certain that they will soon be
        added to Group 3 and, more important, are already in common
        use today capabilities through Group 3's NSF mechanism.
        Only the following resolutions are valid (horizontal x


    TIFF CLASS F Revision 3: October 1, 1991 Page 8




            vertical): 204 x 98, 204 x 196, 300 x 300, 400 x 400. Those
            who choose to store images at the #Group 4" resolutions
            risk incompatibility with other fax applications.


                      WHAT CONSTITUTES TIFF CLASS F SUPPORT


        Fax applications that do not wish to embrace TIFF Class F as a
        native format may elect to support it as import/export medium.

             Export The simplest form of support is a Class F writer
                     that produces individual single-page Class F files
                     with the proper NewSubFile and PageNumber tags.

             Import A Class F reader must be able to handle a Class F
                     file containing multiple pages.

  WARNINGS


        1. Class F requires the ability to read and write at least one-
            dimensional T.4 Huffman ("compressed") data. Due to the
            disruptive effect to application software of line-length errors
            and because such errors are likely in everyday facsimile
            transmissions, uncompressed data is not allowed. In other words,
            "Uncompressed" bit in Group30ptions must be 0.

        2. Since two-dimensional encoding is not required for Group 3
            compatibility, Class F readers may decline to read such files.
            Therefore, for maximum portability write only one- dimensional
            files. Although the same argument technically holds for "fine#
            (196 dpi) vertical resolution, only a tiny fraction of facsimile
            products support only 98 dpi. Therefore, 196-dpi files are quite
            portable in the real world.

        3. In the spirit of TIFF, all EOL's in data must be byte- aligned.
            An EOL is said to be byte-aligned when Fill bits have been added
            as necessary before EOL codes such that EOL always ends on a byte
            boundary, thus ensuring an EOL-sequence of a one byte preceded by
            a zero nibble: xxxx0000 00000001.

            Recall that Huffman encoding encodes bits, not bytes. This means
            that the end-of-line token may end in the middle of a byte. In
            byte alignment, extra zero bits (Fill) are added so that the
            first bit of data following an EOL begins on a byte boundary. In
            effect, byte alignment relieves application software of the
            burden of bit-shifting every byte while parsing scan lines for
            line-oriented image manipulation (such as writing a TIFF file).

        4. As illustrated in FIGURE l/T.4 in Recommendation T.4 (the "Blue
            Book," page 20), facsimile documents begin with an EOL (which in
            Class F is byte-aligned). The last line of the image is not
            terminated by an EOL.

        5. Aside from EOL's, TIFF Class F files contain only image data.
            This means that the Return To Control sequence (RTC) is


        TIFF CLASS F Revision 3: October 1, 1991 Page 9




            specifically prohibited. Exclusion of RTC's not only makes
            possible the simple concatenation of images, it eliminates the
            mischief failed communications and unreadable images that their
            mistreatment inevitably produces. (This view is reflected in the
            work of the EIA PN2388 committee, where the modem device attaches
            the RTC outbound and removes it inbound.)



                            REVISING THE TIFF CLASS F SPECIFICATION


        Changes in the specification that reflect changes in the underlying
        CCITT specifications as well as non-technical changes are incorporated
        by editorial fiat. Before substantial modifications are allowed,
        however, the author will consult members of the facsimile industry.

        The main goal in revision is to retain a specification that fulfills
        the original goals and serves the facsimile industry. It is
        especially important that Class F not be modified to accommodate
        unrelated goals. For example, there have been proposals to relax
        Class F tag requirements to make it more compatible with other
        flavors of TIFF. In particular, non-facsimile users seem to be vexed
        by the necessity to byte-align EOL's and to support the multi-page
        format. Such proposals inevitably originate with users outside the
        mainstream of facsimile vendors, in whose applications both of these
        features are vitally important. Non-facsimile users who find Class F
        too restrictive might better be served by designing a new TIFF classes
        to accomplish their ends.



  Manuscript of Proposed Revision


        Any person or group that wishes to propose an amendment to TIFF Class
        F should prepare the following manuscript:


        1. Name of the person or group making the request and their
            affiliation (business, academic, etc.).

        2. The revision date from which you are working.

        3. The reason for the request.

        4. A list of changes exactly as you propose that they appear in the
            specification. Do not submit an edited version of the entire
            specification. Use inserts, callouts, or other obvious editorial
            techniques to indicate areas of change and number each change.

        5. Referring to each change number, discuss its potential impact on
            the installed base. In particular address the effect on other
            standards that incorporate TIFF Class F (e.g., FaxBios).

        6. A list of phone numbers of persons outside your company who may
            support your position. Include their affiliation (business,


        TIFF CLASS F Revision 3: October 1, 1991 Page 10




        academic, etc.).

    This manuscript may be submitted to Joe Campbell, Everex Systems,
    Inc: (510) 540-5835 or (510) 841-5441, or via Compuserve Mail
    71331,1237.



                             REVISION HISTORY


    11/17/89: Initial Publication

    4/20/90: First Revision
    PageNumber tag was incorrectly illustrated as page one. The
    correct number for the first page i9 zero.


    5/1/91: Second Revision


    1. Added 300 and 400 valid values to to the XResolution and
        YResolution tags.

    2. Software tag moved from Bi-level Required (not true), to
        Recommended.

    3. ImageWidth tag values of 2482 was corrected to 2432.

    4. New ImageWidth tag values added to conform to the "Blue Book,":
        864, 1216.

    5. Corrected miscellaneous typographical errors.

    6. Added summary of required tags.

    10/l/91: Third #evision,

    1. Total page count needed only in first tag after IFD.


    2. Added MMR compression, modification procedure.









    TIFF CLASS F    Revision 3:  October 1, 1991         Page 11