Received: by whizzer.wpd.sgi.com (921026.SGI.NOSTRIP/911001.SGI)
	 id AA17746; Tue, 17 Aug 93 14:48:11 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 AA17733; Tue, 17 Aug 93 07:48:07 -0700
Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for tiff-relay@whizzer.wpd.sgi.com id AA03354; Tue, 17 Aug 93 07:48:04 -0700
Received: from oxford.chez.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI)
	for tiff@sgi.sgi.com id AA11081; Tue, 17 Aug 93 07:47:54 -0700
Received: from localhost.chez.sgi.com by oxford.chez.sgi.com via SMTP (920330.SGI/921111.SGI.AUTO)
	for tiff@sgi.sgi.com id AA26203; Tue, 17 Aug 93 07:55:46 -0700
Message-Id: <9308171455.AA26203@oxford.chez.sgi.com>
To: tiff@sgi.sgi.com
Subject: Re: byte swapping 16- and 32-bit data 
In-Reply-To: Your message of Tue, 17 Aug 93 09:32:44 -0400.
             <9308171332.AA09229@tango.Read.TASC.COM> 
Date: Tue, 17 Aug 93 07:55:46 PDT
From: Sam Leffler <sam@oxford.chez.sgi.com>
Sender: tiff-owner@sgi.sgi.com

    To:      sam@flake.asd.sgi.com
    Subject: Re: byte swapping 16- and 32-bit data
    From:    gaile@tango (Gaile G. Gordon)
    Cc:      tiff@sgi.sgi.com
    Date:    Tue, 17 Aug 93 09:32:44 EDT

    Actually, machine independence, and the fact that I don't need to
    worry about byte swapping is one of the big advantages in my mind to
    using the tiff library.  Although I wouldn't mind if you added the no
    byte swap as an option for cases were efficiency is the primary
    concern, I would not be happy if I had to add byte swapping to all my
    tiff code.

The mail that I've received indicates my original note was
not clear enough.

1. The issue is entirely what to do with sample data that is
   wider than one byte.  A sample is NOT a pixel.  The packing
   of samples within a pixel is NOT at issue.  The problem is
   that when samples themselves are say 16 bits that each sample
   itself has a byte order that may need to be corrected.  The
   meta data in the TIFF directory structure is NOT the issue;
   it will continue to be delivered to the application in the
   correct byte order.
2. The existing code in the library already requires that applications
   do byte swapping.  If the image data has samples >8bits wide and
   is compressed with a compression algorithm other than #1 (the
   no compression algorithm), then the application should be doing
   byte swapping of individual samples.  This has not been seen
   because the number of TIFF images with multi-spectral data
   with samples wider than 8 bits is small (and likely to be
   processed on machines with identical architectures).

I have lots of experience with building image manipulation
code and I believe strongly that not amortizing the cost of
the byte swapping over some other operation (such as a doing
a memory-to-memory copy) will mean that users will avoid the
library because it's too costly to use.  Having work done 
optionally can be problematic, but is a possibility.  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:

if (TIFFReadEncodedStrip(...)> 0) {
    if (...data needs 16-bit byte swapping...)
        TIFFSwapShorts(...);
    else if (...data needs 32-bit handling...)
        TIFFSwapLongs(...);
}

or more likely, do the byte swapping together with some other
work, such as preparing the data for image display.

What I'm really asking is, is there a problem with my removing
the existing code that does the byte swapping in the one special
case of >8 bit sample data that has no compression?

Of course, folks are free to pitch in and send me fixes to
the library to do this "right".

	Sam




