Return-Path: <tiff-bounces@remotesensing.org>
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx020.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j3C3lG30013575
        for <joris.at.lebbeke@skynet.be>; Tue, 12 Apr 2005 05:47:20 +0200
        (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 143B61C0EA29; Mon, 11 Apr 2005 23:46:52 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from outmx002.isp.belgacom.be (outmx002.isp.belgacom.be
	[195.238.3.52])
	by xserve.flids.com (Postfix) with ESMTP id 5753B1C0EA04
	for <tiff@remotesensing.org>; Mon, 11 Apr 2005 23:46:49 -0400 (EDT)
Received: from outmx002.isp.belgacom.be (localhost [127.0.0.1])
	by outmx002.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with
	ESMTP id j3C3kjs9006336
	for <tiff@remotesensing.org>; Tue, 12 Apr 2005 05:46:45 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (108-182.245.81.adsl.skynet.be [81.245.182.108])
	by outmx002.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with SMTP
	id j3C3kdi9006299; Tue, 12 Apr 2005 05:46:39 +0200
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <004601c53f12$7b878f50$6cb6f551@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "Chris Cox" <ccox@adobe.com>, "Tiff mailing list" <tiff@remotesensing.org>
References: <20050407074522.ZKYV1111.smtp05.retemail.es@smtp05><000901c53b62$f2ad61d0$db80f651@dfgrrxsknr4e><p05210606be7f6c4ce6a8@[153.32.48.223]><004c01c53e71$417488f0$08a0f651@dfgrrxsknr4e><p05210609be8095daa46a@[153.32.48.223]><000b01c53eed$1631c960$dfa2f551@dfgrrxsknr4e>
	<p0521060fbe80b9a1073a@[153.32.48.223]>
Subject: Re: [Tiff] TIFF Technote 3, draft 1
Date: Tue, 12 Apr 2005 05:48:22 +0200
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: 
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: 000000000023ceae.000000cc
X-MSP-STORE: Tue, 12 Apr 2005 05:47:29 +0200
Status:   

Chris,


> It's not just Motorola (it's almost everyone other than Intel ;-).
> Any data value with more than 8 bits and that has a length that is a
> multiple of 8 bits has to be byte order swapped.

Please be patient with me. You do mean 'a length that is 2**x with x>=4', do you
not? 24 bits qualifies as 'a length that is a multiple of 8 bits', and thus
needs byteswapping according to your comment, but I don't think it does, does
it? It doesn't qualify what I think you meant since it is not a power of 2 at
all.

> That applies to integer, float, and even to "unknown" values.

I've been doubtful about this for as long as I can remember. Thank you very much
for clearing this up for me.

> > Am I seeing correctly now that, with the predictor in use, the image data is
> > equal in both byteorder flavour TIFFs?
>
> After going through the predictor, in the file - yes.

Understood. Thank you!

> > Are there any test images available in both byte orders, preferably both
> > combined with and without predictor scheme, that would allow me to test my
> > understanding?
>
> I have some, but it's about 160 Meg total.
> (30 Meg for 16 bit, 42 Meg for 24 bit, and 57 Meg for 32 bit)

Are you willing and able to share these? Do you have access to some FTP space
that can dig 'em?

> > Abusing the fact that I have your attention, I'd like to ask something that
> > is only remotely related, in that it also shares my confusion surrounding
> > byte order in image data... Say you have 3 channels, 12, 13, and 16 bits
> > wide, in ordinary TIFF, with ordinary integer SampleFormat. That means the
> > 16bits channel does not even start on a byte boundary for most columns. Is
> > it nevertheless subject to byteswapping?
>
> You can't interleave mixed bit depths.

Surely you mean that LibTiff doesn't support it. The TIFF file format doesn't
have any such limitation. The BitsPerSample tag has a count that is equal to the
SamplesPerPixel tag value. And I'm always reading (and writing) LibTiff doesn't
support mixing bitdepths, which would be a foolish statement if TIFF didn't.

And more conclusively, in the TIFF specification, Section 8, Baseline field
reference, BitsPerSample field:

<quote>
Note that this field allows a different number of bits per component for each
component corresponding to a pixel. For example, RGB color data could use a
different number of bits per component for each of the three color planes.
</quote>

I'm not sure about the meaning of 'corresponding to a pixel' in that quote, and
the word 'planes' at the end is again confusing, but since no definite reference
is made to PlanarConfiguration, I take that word to merely mean 'channels'. So
I think I should read this to mean different channels can have different
bitdepths. If not, I've definitely been living in the Twilight Zone last couple
of years... but I've often suspected as much for plenty of unrelated reasons, so
it's definitely a possibility. ;-)

> And anything that isn't a multiple of 8 bits goes in natural bit
> order - aka BigEndian.

That is understood.

Assuming we agree that mixed bitdepths are possible in the TIFF file format, as
opposed to supported in LibTiff... As to the case I presented,
SamplesPerPixel=3, BitsPerSample=[12,13,16], SampleFormat=default, integer.

The third channel in this case, 16bits wide, is byteswapped, even though it
doesn't even start on a byte boundary (most of the columns), right?



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
