1993.08.17 14:55 "Re: byte swapping 16- and 32-bit data", by Sam Leffler

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