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 inmx010.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j3C3tuo8011839
        for <joris.at.lebbeke@skynet.be>; Tue, 12 Apr 2005 05:56:01 +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 3E82C1C0EAAD; Mon, 11 Apr 2005 23:55:27 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from psmtp.com (exprod6og4.obsmtp.com [64.18.1.124])
	by xserve.flids.com (Postfix) with SMTP id 985EF1C0EA89
	for <tiff@remotesensing.org>; Mon, 11 Apr 2005 23:55:23 -0400 (EDT)
Received: from source ([192.150.20.142]) by exprod6ob4.obsmtp.com
	([64.18.5.12]) with SMTP; Mon, 11 Apr 2005 20:55:22 PDT
Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236])
	by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
	j3C41PTK002321
	for <tiff@remotesensing.org>; Mon, 11 Apr 2005 21:01:25 -0700 (PDT)
Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193])
	by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id
	j3C3jLe2014755
	for <tiff@remotesensing.org>; Mon, 11 Apr 2005 20:45:21 -0700 (PDT)
Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com
	(iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
	with ESMTP id <0IET00LPVEW8QP@mailsj-v1.corp.adobe.com> for
	tiff@remotesensing.org; Mon, 11 Apr 2005 20:55:20 -0700 (PDT)
Received: from [153.32.48.223] (noname.corp.adobe.com [153.32.48.223])
	by mailsj-v1.corp.adobe.com
	(iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
	with ESMTP id <0IET004Z0EW7U9@mailsj-v1.corp.adobe.com> for
	tiff@remotesensing.org; Mon, 11 Apr 2005 20:55:20 -0700 (PDT)
Date: Mon, 11 Apr 2005 20:55:17 -0700
From: Chris Cox <ccox@adobe.com>
Subject: Re: [Tiff] TIFF Technote 3, draft 1
In-reply-to: <004601c53f12$7b878f50$6cb6f551@dfgrrxsknr4e>
X-Sender: ccox@mailsj.corp.adobe.com
To: Joris <joris.at.lebbeke@skynet.be>,
        Tiff mailing list <tiff@remotesensing.org>
Message-id: <p05210619be80f5ad1a0f@[153.32.48.223]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
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]>
	<004601c53f12$7b878f50$6cb6f551@dfgrrxsknr4e>
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.000000cf
X-MSP-STORE: Tue, 12 Apr 2005 05:56:14 +0200
Status:   

At 5:48 AM +0200 4/12/05, Joris wrote:
>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?

I mean (BitsPerSample > 8) && ((BitsPerSample & 7) == 0)


>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?

Yes, it does.


>  It doesn't qualify what I think you meant since it is not a power of 2 at
>all.

I didn't say power of 2.  I said a multiple of 8 bits.



>  > > 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?

I just sent you the URLs.
Unfortunately it's on my private domain site, so I can't just have 
everyone download them....
(and Adobe takes too long to post new material)


>
>>  > 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.

No, I mean you should never interleave mixed bit depths - partly 
because too many things are undefined when you try that.


>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.

But you can do that if you write the data in planar order....

It's just interleaving that's a problem.


>
>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,

planes == channels
pixel = collection of all channels at a given spatial location



>  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. ;-)

According to the spec. it is not explicitly disallowed.
But it is a REALLY BAD IDEA (TM) and I'll try to clarify that in the 
next spec. revision.



>  > 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?

In theory, yes.
But that's part of why mixing bit depths and interleaving is a REALLY 
BAD IDEA (TM).

Chris

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