Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx010.isp.belgacom.be (inmx010.isp.belgacom.be [195.238.2.73])
        by mailst035.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id j0E2LahO011013
        for <joris.at.lebbeke@skynet.be>; Fri, 14 Jan 2005 03:21:36 +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 inmx010.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j0E2LJii032282
        for <joris.at.lebbeke@skynet.be>; Fri, 14 Jan 2005 03:21:21 +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 39BDF5BB07E; Thu, 13 Jan 2005 21:20:49 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from outmx006.isp.belgacom.be (outmx006.isp.belgacom.be
	[195.238.2.99])
	by xserve.flids.com (Postfix) with ESMTP id 3B6375BB05B
	for <tiff@remotesensing.org>; Thu, 13 Jan 2005 21:20:46 -0500 (EST)
Received: from outmx006.isp.belgacom.be (localhost [127.0.0.1])
	by outmx006.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with
	ESMTP id j0E2KbOC009037
	for <tiff@remotesensing.org>; Fri, 14 Jan 2005 03:20:37 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (34-163.245.81.adsl.skynet.be [81.245.163.34])
	by outmx006.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with SMTP
	id j0E2KZCu009002; Fri, 14 Jan 2005 03:20:36 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <004501c4f9df$e230d1d0$22a3f551@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: Fri, 14 Jan 2005 03:22:20 +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 mailing list <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: 6550baebec5a816ab7d055f6a0b19c56

Lee,

> Okay, following your advice as best as I can I have come up with:
>
>    http://gateway.howardsilvan.com/fax000003470.tif

It took a while, but I was finally able to decode the TIFF with code that does
not depend on LibTiff, for crosstesting. I'll privatly send you a reduced
resolution ordinary YCbCr jpeg of the result in the copy to you, for
checking.

** StripOffsets/StripByteCounts **

The count of these tags is wrong, but you already knew.

** FillOrder **

This value is wrong. It should instead be default, or not be there at all.
LibTiff might be forgiving of this wrong value, but that's a flaw rather then a
feature - I suspect it just doesn't care when combined with JPEG compression,
and it should, because the fillorder handling is a step in the decoding process
that is theoretically completely independent, even if some of the decompressors
can more optimally handle it together with decompressing.

** YCbCrSubsampling **

This value is wrong. In JPEG-style notation, the subsampling is 2:1:1, and that
corresponds to the TIFF-style YCbCrSubsampling values 2,2. This is the default,
so if you're sure that all your source JPEGs will have the same subsampling, you
could just ignore this tag and not set it at all.

** Decode **

I haven't (yet) been able to check whether the source JPEG contains the APP
marker used to specify Decode parameters other than the ITULAB default, because
I seem to have misplaced the spec that explained that APP marker and can't find
any old code and can't remember, either. But, using the default to decode your
image yields visually pleasing results, and I know from past experience that
non-default Decode parameters are rare at best. So I guess we now know
reasonably sure that you can probably ignore the Decode tag, too.

** More general **

Unless, of course, you are set out to build yourself a solution that works for
*any* ITULAB color-fax-jpeg, as opposed to the ones from the same single source,
in that case you'll probably have to detect proper values for the
YCbCrSubsampling and Decode tags from your JPEG stream. Let me know if that is
the case, and I shall try and find time to help out if I may, this is all very
interesting...

Plus, I'm still keen on the general JPEG to JPEG-in-TIFF converter... I'm
thinking of a general scheme, something like
- sequentially add blocks of JPEG data to the single strip (so that the scheme
fits a slow JPEG reception without temp buffer, like you want it)
- while doing so, also sequentially feed these blocks to LibJpeg, which should
be linked in LibTiff anyway, so as to read all relevant properties like color
space, subsampling, etc, from the JPEG stream. At this stage, also especially
note DNL, and if so, remember position to write fix-up and count lines
- when that's done, fill in the tags with the info read from the JPEG stream.
- also do the DNL fix-up now, if necessary

I'm unsure, however, how much of tag setting LibTiff allows to be postponed
untill after the strip writing stage.

I you or anyone on this list wishes to join in to explore this further, now
would be a good time to say so.

In any case, please keep us informed whatever happens next. It's not the first
time ITULAB related stuff comes up in this list, so it would be nice to see and
archive where this is going.

Like you, I'm also hoping to hear from anyone who wishes to extend tiffcp to be
able to deal with these ITULAB tiffs. It should be possible to build a new
testfile that is more correct, since the FillOrder and YCbCrSubsampling mistakes
should be easy to correct, and Decode should be as easy to ignore as before. All
that remains is the Strip tags count bug, but we could even work and extend
tiffcp from a TIFF testfile that is buggy in that regard, since LibTiff seems to
automatically compensate by 'trimming' those tag values.


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
