TIFF and LibTiff Mail List Archive


2000.11.29 14:18 "more G4", by Andy
2000.11.29 18:44 "Re: more G4", by Joel Schumacher
2000.11.29 18:36 "Re: more G4", by Andy

2000.11.29 18:44 "Re: more G4", by Joel Schumacher

I had a similar problem about a year ago (Oct 99). I'm not really using libtiff, but was using version 3.5.2 and the utilities to test some images that another piece of software was blowing up on and found libtiff had the same bug. But, programs like Paint Shop Pro read the images just fine.

At that time, libtiff was not recognizing the EOFB (end of facsimile block) codeword. It's a 24-bit codeword:


Basically what this codeword is saying is: this is the end of the page. The rest of the page is all white-space, no need to encode every line, just fill the rest of the page with white dots and you're done.

By not recognizing this codeword, it interpreted it differently, and from then on you're out of sync and you're bound to run into something that'll give you an error.

Some helpful folks like Frank Cringle sent some code fixes to the list, but to my knowledge, they never were incorporated into libtiff.

You might have an entirely different problem, but it sounded similar to the error messages I was getting.

Can anybody confirm? Has the G4 support for the EOFB codeword been added to libtiff?

Andy ( wrote:

I get some images from a "Life*ODIN" system that are not being read by the libtiff code, nor by other programs, for example Kodak Imaging. This is only some, not all of the files from them. This is using libtiff-3.4beta037.

These images purport to GroupIV TIFF. They are structurally sound TIFF files, but the Group IV data is being illegible. The libtiff decoder is able to get from the single image data strip the upper portion of the data, for example the first couple hundred scan lines, the rest is blank.

There is a "Fax4Decode Warning" emitted, it says "R136711.TIF: Premature EOL at scanline 864 (got 1581, expected 3323)". Then another, "R136711.TIF: Premature EOL at scanline 865 (got 0, expected 3323)". This continues:

scanline 866(got 0, expected 3323)
scanline 867(got 0, expected 3323)

Then there is another warning for each remaining scanline in the image.

The images have two private tags, 34645 (0x8755) and 34646 (0x8756)

So, I go to Fax codec and see where this is emitted, to see if I can get it to skip the special case and extract the bulk of the image data. So I go to tif_fax3.c. This warning is kicked off by the function Fax3BadLength. Fax3BadLength is defined into the badlength macro. I define FAX3_DEBUG and recompile. Now it is providing considerably more verbose output as it decompresses.

Joel Schumacher JCPenney Co. - UNIX Network Systems              12700 Park Central Pl   M/S 6021

(972) 591-7543                     Dallas TX  75251