2002.07.24 16:20 "Re: CCITT Group 4 assistence needed for HylaFAX", by Sam Leffler

I'm needing some help with getting HylaFAX to support MMR-encoded (Group 4) faxes. I've got a nearly complete patch for HylaFAX which does this, but I've run into a couple of snags which are rooted in code incompatibility with the differences between Group 3 and Group 4 TIFF image data. As I'm not TIFF-savvy, I'm seeking for help on this.

However, even if you don't have this kind of time, I wouldn't mind some general outlines on how these two procedures should be altered for Group 4 faxes (i.e., how to count lines and how to image a tagline on top of an existing image).

Disclaimer: I am not familiar with HylaFAX, so I may be making some wrong assumptions in that area. As I understand it, when HylaFAX receives a G3 fax, the modem reports the number of lines in the fax in a status report. In practice, G3 faxes are often damaged in transmission so HylaFAX counts the number of lines actually received and records that value in the tiff header instead of (or as well as?) the expected value.

Yes and no. (Been a long time and doing this from memory so beware...) One receipt HylaFAX decodes the data on the fly so it can do several things: count lines, do error detection and repair (since some modems don't or don't do it right), and to insure properly encoded data (again more bugs in fax modem firmware).

The typical report from a modem of the number of lines received is meaningless (e.g. some modems return a fixed number on "successful receipt" because some braindamaged PC software can't grok a correct number).

A damaged G4 fax is useless, or at least it can only be interpreted up to the first error. So we must assume an error free (or error correcting) channel for transmission of G4 faxes. In that case the sender should be able to tell the receiver how many lines are in the fax. That would make counting after reception redundant.

Probably true. I thought there were some options to G4 for things like embedded EOL's and unencoded data that might make it psosible to resynchronize, but I suspect no fax machine supports them.

If you really need to count the lines in a G4 image, you need to know the precise width and then run through all the data, interpreting each code bitstring as you go.

As mentioned elsewhere the width and length of a fax is negotiated prior to the actual data transfer. The only potential unknown is the length--it may be negotiated as "unlimited"; e.g. when sending to/from a roll of paper.

As to adding or replacing initial lines, the easiest way would be to expand the image into a bitmap, replace the lines and then re-encode the image. Doing it more efficiently by just replacing the relevant part of the raw data should be possible but rather fiddly. I don't recall off hand whether G4 allows padding bits to be inserted, to avoid repacking all the bytes after the transition from new to old data.

The logic involved in tag handling in HylaFAX is quite gnarly. It does a partial decoding of the G3 image using the EOL tags as "anchors". This decoding locates the piece of the encoded data that should be discarded and/or replaced. A new tag line image is then imaged and encoded using the 1D encoding only (if I recall) and spliced into the image in place of the original data. I chose this approach because at the time machines were not necessarily fast enough and/or had enough memory to do the more straightforward decode-into-memory, overlay, re-encode and still maintain the performance I required.

Hope this helps. Haven't looked at libtiff or HylaFAX in many years.

Sam