Received: from mailgate002.isp.belgacom.be (mailgate002.isp.belgacom.be [195.238.6.87])
	by maildelivery010.isp.belgacom.be (Postfix) with ESMTP id CB8381DC006
	for <joris.at.lebbeke@skynet.be>; Fri,  1 Feb 2008 09:29:43 +0100 (CET)
Authentication-Results: in.mx.skynet.be; dkim=neutral (message not signed) header.i=none
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 01 Feb 2008 09:29:41 +0100
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m1185NDd030813;
	Fri, 1 Feb 2008 03:06:35 -0500
Received: from edna.telenet-ops.be (edna.telenet-ops.be [195.130.132.58])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m1185Gwd030810
	for <tiff@lists.maptools.org>; Fri, 1 Feb 2008 03:05:17 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by edna.telenet-ops.be (Postfix) with SMTP id 3C5B9E4030;
	Fri,  1 Feb 2008 09:05:13 +0100 (CET)
Received: from awaredfg964ezf (d54C59B62.access.telenet.be [84.197.155.98])
	by edna.telenet-ops.be (Postfix) with SMTP id 91D16E402C;
	Fri,  1 Feb 2008 09:05:10 +0100 (CET)
Message-ID: <003001c864a9$2dfd8860$0202a8c0@awaredfg964ezf>
From: "Joris Van Damme \(AWare Systems\)" <joris.at.lebbeke@skynet.be>
To: "Bob Friesenhahn" <bfriesen@simple.dallas.tx.us>,
        "Tiff List" <tiff@lists.maptools.org>
References: <Pine.SOC.4.64.0801312158110.3823@freddy.simplesystems.org>
Subject: Re: [Tiff] TIFF T.30 vs TIFF Class F
Date: Fri, 1 Feb 2008 09:05:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Cc: 
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.00002a4b
X-MSP-STORE: Fri, 01 Feb 2008 09:29:43 +0100
Status:   

Bob,

Bob Friesenhahn wrote:
> It seems that the T.30 FAX specification says to send the
> most-significant bits first while TIFF Class F
> (http://palimpsest.stanford.edu/bytopic/imaging/std/tiff-f.html)
> recommends (requires?) sending the least-significant bits first.
>
> I have people in both camps claiming that their specification is the
> right one to use and that it can't work any other way.
>
> Can someone please educate me in the ways of FAX and what the best way
> is to address this situation?

I don't remember a T.30, only a T.4 and T.6. But I assume we're likely
refering to the same thing with 'FAX specification'.

The compression scheme specification specifies a lot of stuff that is
instead specified on the IFD level in TIFF. Most obvious example is color
and dimensions: the FAX specification says some stuff about how wide images
are, and what is white and black, whilst in TIFF this is determined by the
IFD ImageWidth and IFD PhotometricInterpretation tags and can be anything.
The same does indeed also apply to bit order, if I remember correctly. Thus,
in TIFF either bit order is correct, and this applies to any compression
scheme and is always to be indicated by the FillOrder tag.

The general rule that applies, is that the TIFF specification is the higher
priority. From the FAX specification we need to read only and exactly what
is the compression scheme and does fit in TIFF without contradicting or
overwriting TIFF. Otherwise FAX compression would end up a mess similar to
the OJPEG mess, with tag meaning depending on compressed data properties, at
which point all TIFF hell breaks loose.

I've elaborated on the general rule and some specific applications, with
regard to FAX compression in TIFF, in this mailing list before, attempting
to help get the record straight. Please see
http://www.asmail.be/msg0054894761.html. In my experience, most people
comply with this point of view, I've seen very little of a second camp and
instead, fortunately, much good interchange.


Best regards,

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@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
