LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
January 2005
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2005.01.13 13:41 "Re: 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