AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1993.08.17 00:06 "byte swapping 16- and 32-bit data", by Sam Leffler
1993.08.17 13:32 "Re: byte swapping 16- and 32-bit data", by Gaile G. Gordon
1993.08.17 13:54 "Re: byte swapping 16- and 32-bit data", by Quincey Koziol
1993.08.17 14:55 "Re: byte swapping 16- and 32-bit data", by Sam Leffler
1993.08.17 16:51 "Re: byte swapping 16- and 32-bit data", by Dan McCoy
1993.08.17 18:19 "Re: byte swapping 16- and 32-bit data", by Sam Leffler
1993.08.17 19:44 "Re: byte swapping 16- and 32-bit data", by Rick Richardson
1993.08.17 19:29 "Re: byte swapping 16- and 32-bit data", by Dan McCoy
1993.08.18 01:57 "Re: byte swapping 16- and 32-bit data", by Craig Hockenberry
1993.08.18 17:57 "Re: byte swapping 16- and 32-bit data", by Dan McCoy
1993.08.18 19:11 "Re: byte swapping 16- and 32-bit data", by Sam Leffler
1993.08.17 20:45 "Re: byte swapping 16- and 32-bit data", by Richard Minner

1993.08.18 17:57 "Re: byte swapping 16- and 32-bit data", by Dan McCoy

I, for one, am very concerned with the speed of the library. I'm dealing with large (over 50 mb), multi-band imagery. As Sam points out, any operations that can be combined while getting this data to the display makes a big difference.

To date, this has only been done on big-endian machines. We are doing a port on Alpha at the moment...

It doesn't seem right having a special case. It will only work when your data is uncompressed and multi-sample. I'd think that the naive user would really be at a loss to understand why his data comes in one format when it's uncompressed and another when it's compressed.

It looks like there is still some confusion in the issues.

  1. The problem has nothing to do with multiple samples, it has to do with samples that are deeper than 8-bits. Very few applications actually read or write these now, most people never use more than 8-bits per sample.
  2. It has nothing to do with the byte order of an individual machine. It only matters when the byte order of the machine reading the file does not match the byte order of the machine that wrote the file.
  3. Nobody is suggesting that you should get different data depending on compression. That is the case now, and that is what we are discussing a fix for. The two suggestions for how to fix this are:

    Sam A: you get correct data for files written on a similar machine and byte-swapped data for files written on a machine of the opposite byte-order. A routine is provided to check whether or not you need to fix up the data.

    Me B: you always get correct data no matter where the file was written. The speed for files written on a similar machine is the same as above. There is a minor performance hit for files written on a machine of the opposite byte-order.

I also suggested that if performance is enough of an issue, you could add an option to toggle between approaches A and B. Sam has strongly nixed the option. (Fine with me.) It does sound like he is implementing approach B.

If you are worried about performance for files that will be read more than once, pass the file through tiffcp on the machine that needs to read the data, that will fix the byte order.

Dan mccoy@pixar.com