AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2002.07.23 22:50 "CCITT Group 4 assistence needed for HylaFAX", by Lee Howard
2002.07.24 07:46 "Re: CCITT Group 4 assistence needed for HylaFAX", by Frank D. Cringle
2002.07.24 11:44 "Re: CCITT Group 4 assistence needed for HylaFAX", by Lee Howard
2002.07.24 12:51 "Re: CCITT Group 4 assistence needed for HylaFAX", by Frank D. Cringle
2002.07.25 09:16 "Re: CCITT Group 4 assistence needed for HylaFAX", by Lee Howard
2002.07.24 16:20 "Re: CCITT Group 4 assistence needed for HylaFAX", by Sam Leffler
2002.07.24 15:35 "Re: CCITT Group 4 assistence needed for HylaFAX", by Joel Schumacher
2002.07.24 16:09 "Re: CCITT Group 4 assistence needed for HylaFAX", by Frank D. Cringle

2002.07.24 15:35 "Re: CCITT Group 4 assistence needed for HylaFAX", by Joel Schumacher

In HylaFAX's faxd/CopyQuality.c++ there is a rather large function, FaxModem::recvPageDLEData(), which (among other things) determines the number of lines received in the received TIFF image data by counting EOLs. This is obviously a flawed approach when dealing with MMR/Group 4 TIFF image data. Consequently HylaFAX ends up believing that it receives a zero-line TIFF image, and this is written into the TIFF tags. This EOL-counting mechanism may appear elsewhere in the code, also.

I'm by no means an expert at G4, but from what I can tell, I assumed length and width had to be someplace else. I seem to recall in the old days, it was assumed to be an 8.5 x 11 sheet of paper being faxed. Divide that up by the resolution and you have your default width and height. When it's wrapped up in the TIFF format, width and height are stored apart from the raw data.

Just going through the data to count lines without some assumptions can prove problematic. When the rest of the image is all white, the encoder has the option of using an End-Of-Facsimile-Block codeword (EOFB). Which basically says "no more use encoding a bunch of white space, the rest of the page from here on is white". Theoretically, it seems you could use this right away to transmit a blank page. If the raw data consists entirely of a single EOFB codeword, how long is the image?

In order to do that, it seems you'd need to know the length ahead of time. Or at least assume a length, like 11 inches * vertical resolution.

Anyone?

In HylaFAX's faxd/TagLine.c++ there is yet another large function, FaxModem::imageTagLine(), which strips a few lines from the top of the image and replaces them with created lines which image the facsimile tagline information. It does this in accordance with Group 3 protocol (i.e., with EOLs) rather than Group 4.

I would assume you'd have to decode the entire image then re-encode it. Since this type of encoding is based on changes from line to line, any small change can affect the rest of the image. Like somebody else said, a single error ruins the rest of the image. A single bit change at the top will do the same.

What's more, encoding what you have to encode will, in most cases, encode at a different size than what was there to begin with.

Like somebody said, *IF* G4 has pad bits and you can get away with encoding something smaller, you might be able to put it in there (not that it wouldn't screw up the rest of the image, but...). My guess is that most paper has margins and is mostly white space at the edge of the page. It sounds like what your application is going to do is place some sort of text or header there, which by common sense is going to encode larger than white space. So it's not going to fit in the same area you're replacing.

I'm thinking the only way to do it might be to leave the start of the image the same, but then prepend your raw data with your new data. Just be sure there is a blank white line after your data. This may work because G4 assumes an imaginary white line above the first line. It uses this as a reference and encodes line 1 based on how it differs from a white line. So, if the last line of your prepended data is a white line, the rest of the image *should* decode properly.

The only problem with this is the length of the image. You're now adding x-number of lines to it, not replacing the top x lines.

And if you want to shorten the bottom, you're back to decoding the raw data again to cut off the bottom.

______________________________________________________________________

Joel Schumacher                    JCPenney Co. - UNIX Network Systems
jschumac@jcpenney.com              12700 Park Central Pl   M/S 6021
(972) 591-7543                     Dallas TX  75251

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If the reader of this message is not the intended recipient,
you are hereby notified that you have received this message in error and
that any review, dissemination, distribution or copying of this message
including any attachments is strictly prohibited. If you received this
in error, please contact the sender and delete the material from any
computer.