Received: by whizzer.wpd.sgi.com (921026.SGI.NOSTRIP/911001.SGI)
	 id AA20820; Tue, 17 Aug 93 16:52:15 GMT
Received: from sgi.sgi.com by whizzer.wpd.sgi.com via SMTP (921026.SGI.NOSTRIP/911001.SGI)
	for /usr/people/sam/majordomo/wrapper resend -l tiff -h sgi.sgi.com -f tiff-owner -s -m "-oi -odq -om" tiff-list id AA20813; Tue, 17 Aug 93 09:52:12 -0700
Received: from [138.72.30.203] by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for tiff-relay@whizzer.wpd.sgi.com id AA24414; Tue, 17 Aug 93 09:52:10 -0700
Received: by spinach.pixar.com (/\==/\ Smail3.1.25.1 #25.8)
	id <m0oSUGJ-000F1hC@spinach.pixar.com>; Tue, 17 Aug 93 09:51 PDT
Message-Id: <m0oSUGJ-000F1hC@spinach.pixar.com>
Date: Tue, 17 Aug 93 09:51 PDT
From: mccoy@pixar.com (Dan McCoy)
To: tiff@sgi.sgi.com
Subject: Re: byte swapping 16- and 32-bit data
Sender: tiff-owner@sgi.sgi.com

I believe that I'm the one that brought up the problem.
I think the reason that this has not come up before is that there
are currently very few people who do both of:

    1. use bitspersample greater than 8
    2. transfer files between big-endian (sgi,mac,sun) and
       little-endian (pc,dec) machines.

I predict that there will be many more people doing both of these in the future.

Our products ship on macs, pcs and 6 different workstations.
We have tried the above and found that it is a problem.
As Sam stated, the library currently handles this problem transparently
for uncompressed data, but not for compressed data.
This is clearly not right, it is inconsistent.

What sam is suggesting is removing the byte-order independence from the
uncompressed code.

I think this is the wrong fix.

Adding byte order independence to all compression mode incurs NO extra
overhead in the normal case.  The extra expense of byte swapping will 
only be paid when the image file has been transferred to an opposite 
byte-order machine, such as mac to pc.

>I see little problem in asking application writers that want to
>deal with the case of >8bit data to wrap their calls to read
>data with code of the form:

I do.
For one, 90% of the applications will develop and test on a single platform 
and get it wrong.

We've got dozens of programs that read tiff files.
99% of the time, they read files that were written on the same platform
as they are being read on.
I don't want to spread the machine dependent code through all of those
applications to handle the last 1%. It makes much more sense, and is much
more "orthogonal", to just make the library handle the data the same way
it handles the tags, in a machine independent way.

I would vote for making all the compression routines handle >8 bits per
sample data the way that the uncompressed routines currently do.

Dan McCoy    mccoy@pixar.com


