AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1999.10.14 00:48 "Bad G3 TIFF file or LIBTIFF bug?", by Sam Ohzawa
1999.10.14 03:31 "Re: Bad G3 TIFF file or LIBTIFF bug?", by Niles Ritter
1999.10.14 11:11 "Re: Bad G3 TIFF file or LIBTIFF bug?", by Klaus Bartz

1999.10.14 11:11 "Re: Bad G3 TIFF file or LIBTIFF bug?", by Klaus Bartz

Hi Sam, hi Niles,

the file is a little bit more bogus as you hope :-).

This file is viewable correctly by "Imaging for Windows Preview" made by Kodak for Microsoft on Win98.

No, it is NOT correctly viewable.

In fact, the file has 3 pages; the first page is not referenced.

Hack into byte 4   0x8f  and into byte 5   0x37  

then you can see page one ; if you look to the page "this is a first page", you see at top the entries

No. 1142 P.2 Page 2 of 3

Do you need not the from/to date/time information of your sended FAX??

The first IFD beginns at offset 14223, the third at offset 48263. About that, it is not a TIFF file in the meaning of revision 6.0; at page 13 there is written

"... but must begin on a word boundary. ..."

FillOrder: lsb-to-msb should be used only in
           special-purpose applications. ( Rev. 6.0 p. 32 ).

if you call

tiffcp hacked3_good.tif nice.tif

the size changes from 48461 to 37190 bytes ( with g4 to 15172 ). A cmp differs completly.

Why that??

If you look with a hex editor to the file, you see at white lines entries like ( reverse binary dump about lsb-to-msb ).

      EOL --|| wr 1728|| wr 0  ||- -------- -- fill zero bits -------- --------

001128  00001010 01101100 11010100 00000000 00000000 00000000 00000000 00000000 
        ||-- EOL ----|| wr 1728|| wr 0  ||- -------- fill zero bits -- --------
001136  00000000 00001010 01101100 11010100 00000000 00000000 00000000 00000000 
        -------- ||-- EOL ----|| wr 1728|| 
001144  00000000 00000000 00001010 01101100 

and at the converted file ( tiffcp frozen the lsb-to-msb shit)

        | wr 1728| wr 0   |fi||--- EOL ---| | wr 1728| wr 0   |fi||--- EOL ---|
001128  01001101 10011010 10000000 00000001 01001101 10011010 10000000 00000001 
        | wr 1728| wr 0   |fi||--- EOL ---| | wr 1728| wr 0   |fi||--- EOL ---|
001136  01001101 10011010 10000000 00000001 01001101 10011010 10000000 00000001 
        | wr 1728| wr 0   |fi||--- EOL ---| | wr 1728| wr 0   |fi||--- EOL ---|
001144  01001101 10011010 10000000 00000001 

EOL := end of line marker 
wr  := white run
fi  := fill zero bits

The problem is the interpretation of tag
T3Options: EOL padding (4 = 0x4)
Rev 6.0 means

"... thus ensuring an EOL-sequence of 1 byte preceded by a zero nibble: xxxx-0000 0000-0001." ( page 52).

tiffcp makes a file with this behavior; bad.tif contains an other fill. If you lock to blue book volume VII.3 of the CCITT at page 23 point 4.1.3, there is a description for a Fill to guaranty the minimum transmission time. Big nonsense for TIFF; no EOL padding.

Be happy, that a decoder can read this ugly file. Good that the decoder ignores any fill bits and do not relying on EOL padding.

Klaus

Niles Ritter wrote:

-- 
-------------------------------------------------------------------
Dr. Klaus Bartz                                     bartzkau@ina.de
COI GmbH / Abt. KOS3    Industriestr. 1-3    D-91072 Herzogenaurach
Tel: +49 (9132) 82-3433                        Fax: +49-9132-824959