Received: by cthulhu.engr.sgi.com (940816.SGI.8.6.9/911001.SGI)
	for tiff-list id PAA22443; Mon, 19 Sep 1994 15:41:21 -0700
Return-Path: <owner-tiff>
Received: from sgi.sgi.com by cthulhu.engr.sgi.com via ESMTP (940816.SGI.8.6.9/911001.SGI)
	for <tiff-relay@cthulhu.engr.sgi.com> id PAA22438; Mon, 19 Sep 1994 15:41:15 -0700
Received: from relay.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI)
	for <tiff@sgi.sgi.com> id PAA05773; Mon, 19 Sep 1994 15:41:12 -0700
Received: from giraffe.asd.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI)
	for tiff@sgi.sgi.com id AA28212; Mon, 19 Sep 94 15:41:06 -0700
Received: from flake.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI)
	for @relay.sgi.com:CRAIGJ@epub.ziff.com id AA27404; Mon, 19 Sep 94 15:40:32 -0700
Received: by flake.asd.sgi.com via SMTP (931110.SGI/911001.SGI)
	for @giraffe.asd.sgi.com:tiff@sgi.sgi.com id AA28117; Mon, 19 Sep 94 15:46:49 -0700
Message-Id: <9409192246.AA28117@flake.asd.sgi.com>
To: Craig Jackson <CRAIGJ@epub.ziff.com>
Cc: tiff@sgi.sgi.com
Subject: Re: Now that you mention bit order... 
In-Reply-To: Your message of "Mon, 19 Sep 1994 12:34:25 CDT."
             <01HHAOWY6J3G9S4TZ8@epub.ziff.com> 
Date: Mon, 19 Sep 1994 15:46:48 PDT
From: Sam Leffler <sam@flake.asd.sgi.com>
Sender: owner-tiff@sgi.sgi.com
Precedence: bulk

    To:  tiff@sgi.sgi.com
    Subject:  Now that you mention bit order...
    Cc:  Craig Jackson <CRAIGJ@epub.ziff.com>
    Date: Mon, 19 Sep 1994 12:34:25 CDT
    From:  Craig Jackson <CRAIGJ@epub.ziff.com>

    Actually, the desirable "host" bit order depends on the application.
    I would suggest that there is no natural bit order in any system implementing
    C, because bits are not addressable in C.
    
Huh?  The issue is that if I think I know what (byte & 0x1) should be
then I'll want each byte of decoded data to be in an appropriate bit
order for my application--irrespective of how the data was stored in
the TIFF.

    However, there are times when a MSB-to-LSB order is convenient for
    processing, especially on big-endian machines.  There are other times
    when a LSB-to-MSB order is more convenient.  These cases may be more
    frequent on little-endian machines, but not restricted to them.
    
    Would it be possible to have this be a settable parameter, without
    causing too much of a performance hit?
    
The only issue is what to do with uncompressed image data that has
been written with a FillOrder tag whose value is opposite to some
expected bit order.  I say this because compressed data must have the
bit order corrected prior to decoding or the decoder must be capable
of handling data whose FillOrder is opposite to an expected value.

I'll think about this request.  This is getting dangerously close to
the "let's have the library do data formatting and unformatting" rathole
that I've tried very hard to avoid...  On the other hand, I'm sensitive
to apps having to undo something the library did just 'cuz there's no
way to disable it--this is the sort of problem that makes folks avoid
using existing software.

    Sam




