2005.01.13 13:41 "Re: [Tiff] JPEG (T.30-E, fax) in TIFF", by Joris Van Damme

Lee,

I've now tried setting TIFFTAG_PLANARCONFIG as PLANARCONFIG_CONTIG explicitly, and unfortunately there is no improvement. As best I can tell, it looks like a bug in libtiff creating three values for StripByteCounts and StripOffsets when it is not supposed to. I suppose that the next step to take on this one is to file a bug report?

Yes, I agree.

Okay, following your advice as best as I can I have come up with:

http://gateway.howardsilvan.com/fax000003470.tif

>From a quick superficial look, it seems fine. Except for the count of the strip tags, of course. I'll try and look at it in greater depth later this week. (Pretty swamped right now.)

Also, notice that the HylaFAX-specific tags (SGI) are not present even though they were "set" with TIFFSetField(), as I mention below.

Another bug report then.

Yeah. Looks like I'll need to file a bug report on this one, also. Or is Andrey listening in and does he work on these kinds of things without a bug report?

I should think Andrey's reading all this. Nevertheless, there's much traffic here sometimes, and it's not quite as useful to him as a good to-do-list. That's why he prefers to see these things in the bugzilla interface too. (Andrey, I gladly stand corrected if anything I'm saying here is not true.) For ideal crossreference and usefulness to bugzilla users as well as mailing list subscribers and mailing list archive users, it's best to add a link to the archived thread in the bugzilla entries (http://www.asmail.be/msg0054884586.html), and to next post a message in this thread with the URLs of the new bugzilla entries.

Well, the situation is like this... the fax sender will deliver to HylaFAX the image in a byte-by-byte stream of data that is interrupted by fax protocol every 64KB. Because the SOF marker comes before the DNL marker, and because the SOF marker does not indicate the image length, it is requisite that, when the DNL marker is encountered, that we "go back" and "fix" the SOF marker to indicate the page length. So, we have to buffer all of that data *somewhere*, and because we don't know how much total data we'll actually receive I didn't want to get into any risks of buffer overflows using RAM, and I didn't want to have to complicate the process by opening up a temp file on disk (yet another file to open and unlink later), and so chose to do what I did - storing the data as-it-comes in the already-open TIFF and then overwriting it later.

Perfect reasoning. My previous remarks were based on your example code, were you seemed to be working with a single complete JPEG memory buffer.

But still, the triple stripoffsets/counts have to come from somewhere, and this weird usage TIFFWriteRawStrip is probably the best candidate... How about doing it like this:

as you receive bits and pieces of the JPEG stream, use TIFFWriteRawStrip, to append them to the single strip 0. Meanwhile, also do your line-counting here, so as to end up with the number you need to fix the DNL issue
next use TIFFGetField to get the strip's offset
next directly call the file writing and reading functions to modify the stream.

That should amount to the same, but it's a little less suspicious, maybe. The usage of TIFFWriteRawStrip in this scheme is like it is documented, simply appending data to the strip, and doesn't serve in any modification of the appended data. Let me know if you try this.

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html