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
-------------------------------------------------------------------
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