Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx009.isp.belgacom.be (inmx009.isp.belgacom.be [195.238.3.146])
        by mailst035.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id j0DDed1H024894
        for <joris.at.lebbeke@skynet.be>; Thu, 13 Jan 2005 14:40:39 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx009.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j0DDeO3B020329
        for <joris.at.lebbeke@skynet.be>; Thu, 13 Jan 2005 14:40:27 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id A9DE25B7F08; Thu, 13 Jan 2005 08:39:56 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from outmx005.isp.belgacom.be (outmx005.isp.belgacom.be
	[195.238.2.102])
	by xserve.flids.com (Postfix) with ESMTP id 4994D5B7EE1
	for <tiff@remotesensing.org>; Thu, 13 Jan 2005 08:39:54 -0500 (EST)
Received: from outmx005.isp.belgacom.be (localhost [127.0.0.1])
	by outmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with
	ESMTP id j0DDdpLg028261
	for <tiff@remotesensing.org>; Thu, 13 Jan 2005 14:39:52 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (132-183.245.81.adsl.skynet.be [81.245.183.132])
	by outmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with SMTP
	id j0DDdhCO028193; Thu, 13 Jan 2005 14:39:43 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <000f01c4f975$98d1c270$84b7f551@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "Lee Howard" <faxguy@howardsilvan.com>
References: <20050108163638.GK32383@bilbo.x101.com><003c01c4f5d6$4b84fe30$1daff551@dfgrrxsknr4e>
	<20050109054652.GC12383@bilbo.x101.com>
Subject: Re: [Tiff] JPEG (T.30-E, fax) in TIFF
Date: Thu, 13 Jan 2005 14:41:33 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Cc: tiff@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 8b5fcc8ce5b4cb36e5af6dd7c1151f5f

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

_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
