Received: from sgi.sgi.com (192.48.153.1) by cerious.com
 with SMTP (Apple Internet Mail Server 1.1.1); Fri, 13 Dec 1996 16:43:01 -0500
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA04982; Fri, 13 Dec 1996 13:38:34 -0800
Received: (from daemon@localhost) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id TAA18666 for tiff-list; Fri, 13 Dec 1996 19:27:52 GMT
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA18655 for <tiff-relay@relay.engr.sgi.com>; Fri, 13 Dec 1996 11:27:50 -0800
Received: from iems.jpl.nasa.gov (iems.jpl.nasa.gov [137.79.1.40]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09281 for <tiff@sgi.com>; Fri, 13 Dec 1996 11:27:48 -0800
Received: from tazboy.JPL.NASA.GOV (tazboy.jpl.nasa.gov [128.149.24.99]) by iems.jpl.nasa.gov (8.6.12/8.6.6) with SMTP id KAA27683; Fri, 13 Dec 1996 10:43:13 -0800
Received: by tazboy.JPL.NASA.GOV (4.1/SMI-4.1+DXRs2.3)
	id AA00829; Fri, 13 Dec 96 11:08:24 TAN
Date: Fri, 13 Dec 96 11:08:24 TAN
From: ndr@tazboy.jpl.nasa.gov (Niles Ritter)
Message-Id: <9612131808.AA00829@tazboy.JPL.NASA.GOV>
To: frankkim@server.net
Subject: Re:  fillorder of decoded strips
Cc: tiff@sgi.com
Sender: owner-tiff@relay.engr.SGI.COM
Precedence: bulk

> [...]
>  So now I'm quite confused about how TIFFReadEncodedStrip works.  From a
>  few experiments I've done it seems the decoded data I get back from
>  doing a TIFFReadEncodedStrip has a fill order of MSB2LSB.  Should I
>  assume it will always be like that as the TIFFOpen documentation
>  implies?  Is there someway to know for sure what the fill order is of
>  what TIFFReadEncodedStrip returns?

To add to the confusion, I challenge anyone to define "native bit order"
of a computer. You can try to insist that byte-order implies bit-order,
but that is not a warranted assumption. The real question is, "ordered
by what?" In a FAX machine, there is a natural hardware ordering, 
dictated by how the bit streams get stored in the online memory
(which are presumably bytes).  Section 11 of the TIFF spec discusses
the hardware issues in detail.  In the host cpu proper there is no 
natural addressing mechanism for bits (byte order is dictated by the natural 
ordering of address space). 

You may try to insist that something like:

  struct mybits {
	int bit1 : 1;
	int bit2 : 1;
	...
	int bit8 : 1;
 }

imposes a natural ordering, but the above structure is compiler
dependent, not host-cpu-dependent.

The TIFF spec strongly discourages the use of LSB2MSB, regardless
of the native byte-order of the cpu. I believe libtiff supports
this by performing bit-swapping if and only if FillOrder=2 is explictly
defined, for either byte-order. This means that you can always
use (128,64,32,16,8,4,2,1) as your set of byte-masks to get the correct
sequence of bits. Life is simpler that way.

And let's not even get into the  0=black/white issue...

  --Niles.
