Received: by cthulhu.engr.sgi.com (940816.SGI.8.6.9/911001.SGI)
	for tiff-list id QAA10778; Thu, 22 Sep 1994 16:40:51 -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 QAA10765; Thu, 22 Sep 1994 16:40:42 -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 QAA09293; Thu, 22 Sep 1994 16:40:40 -0700
Received: from oxford.chez.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI)
	for tiff@sgi.sgi.com id AA07471; Thu, 22 Sep 94 16:40:37 -0700
Received: by oxford.chez.sgi.com via SMTP (931110.SGI/930416.SGI)
	for tiff@sgi.sgi.com id AA06847; Thu, 22 Sep 94 16:49:11 -0700
Message-Id: <9409222349.AA06847@oxford.chez.sgi.com>
To: John M Davison <davisonj@ecn.purdue.edu>
Cc: tiff@sgi.sgi.com
Subject: Re: Now that you mention bit order... 
Reply-To: Sam Leffler <sam@asd.sgi.com>
In-Reply-To: Your message of "Thu, 22 Sep 1994 17:50:54 CDT."
             <199409222250.RAA16796@en.ecn.purdue.edu> 
Date: Thu, 22 Sep 1994 16:49:10 PDT
From: Sam Leffler <sam@oxford.chez.sgi.com>
Sender: owner-tiff@sgi.sgi.com
Precedence: bulk

    To:  tiff@sgi.sgi.com
    Subject:  Re: Now that you mention bit order...
    Cc:  wagner@itek.com
    Date: Thu, 22 Sep 1994 17:50:54 CDT
    From:  John M Davison <davisonj@ecn.purdue.edu>

            Scott Wagner (wagner@itek.com) writes:
    >And that, IMHO, is the bit-order confusion story in a nutshell.
    
            Mr. Wagner left out one fact, namely that the notion of "native machine
    bit order", as it exists in Sam Leffler's TIFF interface software, is
    nonsensical.
    
            While a "bit order" issue certainly does come up when dealing with
    rendering/scanning systems that erroneously permute bits, the handling of this
    erroneous behavior is the responsibility of the associated drivers, not of any
    device-independent TIFF interface software (such as what Leffler has written).
    
            Thus, the notion of "native machine bit order" should be expunged from
    Sam Leffler's TIFF interface software.  Leffler's software has no business
    whatsoever worrying about rendering/scanning device "bit order".

Come on folks, enough of this crap already.  As I've repeatedly
explained; the library handles the FillOrder tag as necessary for image
data that's encoded.  For data that is uncompressed it does its best to
return the data to the application program in the appropriate bit+byte
order for the application to directly interpret sample values (consider
the case where IEEE floating point samples are to be exchanged between
hosts with CPUs that use different bit+byte order).  The library has
done this for many years and I've yet to receive a single solid example
of what it's doing wrong.  I intend to provide a mechanism whereby the
library's behaviour for uncompressed data can be defeated so that an
application does not have to undo work in order to make use of the
data.  This should close the one obvious loophole in the API.

If you or someone else has a specific example where the library does
something wrong, please send me mail directly.  Please do not send me
hypothetical examples, send me something real.

	Sam



