2007.09.24 07:24 "Re: [Tiff] G3 fax: EOL needed at the beginning of each strip?", by ComSquare Martin Osieka
The spec clearly indicates strips have to start with EOL.
But notin TIFF 6.0, or?
A line (row) of data is composed of a series of variable length code
words. Each code word represents a run length of all white or...
No EOL code words are used. No fill bits are used, except for the
ignored bits at the end of the last byte of a row. RTC is not used.
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.
This approach is much better than my one.
Because the algorithm implemented in libtiff works line oriented (Macro EXPAND1D) it should not be to difficult to implement your approach with the existing macros.
May I ask you for a reference file containing garbage at the beginning of strips?