2007.09.24 05:56 "Re: [Tiff] G3 fax: EOL needed at the beginning of each strip?", by Joris Van Damme
I'm using libtiff 3.8.2 to decode tiffs containing fax images.
Recently I received TIFFs showing white lines in the image.
I decoded them and detected that only the first strip started with an EOL but not the others.
The decoding of a strip always starts with SYNC_EOL() which eats up the first line of the strip if there's no EOL.
The result is that at the end of the strip one line is missing, which is filled up with white pixels.
I'm not sure what the TIFF specification tells. Do all strips have to start with EOL?
Or should the decoder be more relaxed and check if a strip starts with an EOL and skip it but not eating the line up to the first EOL?
Just to say these TIFFs do not show the white lines in tools provided with Windows XP but in others like Irfanview and my tool.
Could anybody who is more experienced in this area provide a patch?
The spec clearly indicates strips have to start with EOL. Unfortunately, I've a reasonable amount (i.e. not just a fluke) of testimages where garbage data preceeds the G3 block. LibTiff succeeds on these images by skipping to the first EOL. If we were to change LibTiff to start decoding right away, more unexpected stuff will happen on these images with preceeding garbage data that might just be more frequent.
In AsTiff, what I do if the strip or tile doesn't start with an EOL, is actually test and see if a line of desired length can successfully be decoded from the preceeding data, and if that data then is followed by an EOL. If so, I regard that the first line. If not, the code starts at the first EOL instead. This works on both the testimages with random preceeding data, and the testimages that just lack the first EOL. But the LibTiff fax decoder being as it is, a heap of macro's with embedded macro's that nobody at this stage can easilly decipher, it may be hard to make it behave equally intelligent.
Joris Van Damme
Download your free TIFF tag viewer for windows here: