AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
October 1999

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



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:
> 
> Sam Ohzawa wrote:
> 
> > Our customer has brought in a G3 TIFF file that libtiff
> > has trouble decoding.  And I am stuck debugging through libtiff.
> >
> > Could you take a look at the file?:
> > http://www.fastio.com/bad.tif
> >
> > (66kb)
> >
> > and determine what is at fault?
> 
> Yes.
> 
> >
> >
> > Actually, this is a 2-page TIFF file, and libtiff succeeds in
> > decoding page 1, but fails on page 2.
> >
> > For example, "tiffsplit bad.tif" shows the error:
> >
> > TIFFReadRawStrip: bad.tif: Read error at scanline 4294967295; got 17843
> > bytes, expected 48213.
> 
> Your error message is exactly right. The size of the file is 48461 bytes,
> and a tiffdump reveals for the second image directory:
> 
> StripOffsets (273) LONG (4) 1<30618>
> ...
> StripByteCounts (279) LONG (4) 1<48213>
> 
> so, if you go to offset 30618 in the file, you only have 17843 bytes
> left in the file, contradicting the next line that the data for the (only)
> 
> strip in the image has 48213 bytes, just like the error message said.
> 
> The imaging for windows software has not had the best track
> record for a TIFF implementation; in fact it sucks.  It has been known to
> write bad noncompliant TIFF  (it does not use libtiff), and it wrote a
> bad file in this case.  I think this was the one that used to write bogus
> JPEG-TIFF files, but I could be confusing it with the Wang Imaging
> product (unless they merged evil forces).
> 
> >
> >
> > Tiffdump does not show anthing unusual about the  tags.
> >
> > This file is viewable correctly by "Imaging for Windows Preview"
> > made by Kodak for Microsoft on Win98.
> 
> I am willing to bet that the data is okay, but that the bogus software
> wrote the wrong byte size (or didn't update the value after doing
> the compression). In fact, I'll bet the code has a bogus hack that
> someone put into IWP when they realized that their byte counts are wrong,
> which simply ignores the byte count if it can get a full image out of the
> data they do have.
> 
> The proof of this will be to hack the byte offset to 17843 and see if
> libtiff can upack it. ...
> 
> [hack hack...]
> 
> Okay, I just hacked the bytes and both images come through
> tiffsplit just fine.  The first image says "this is a first page", and
> the second says "I received your fax!" and a bunch of other
> stuff.    You may find a copy of the hacked file in
> 
>        http://home.earthlink.net/~ritter/tiff/good.tif
> 
> Run tiffdump and tiffsplit and see for yourself.
> 
> Like I said; the MS imaging package sucks.  I vaguely recall
> being on the phone with them to try to convince their programmers
> to do a better job, but they didn't seem to care (this was several years
> ago).
> 
> I don't know if it's worth it to put yet another workaround in libtiff
> to try to unpack less data than it is supposed to have or not.  My
> preference would be for a lot of folks to harangue whoever owns
> the blasted imaging thing now and tell them I said it *still* sucks.
> 
> --Niles.

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