2007.08.27 17:24 "RE: [Tiff] 24-bit samples in TIFF", by Chris Cox

Bob;

Even if no known CPU reads N*8 bit values, they still have a byte order -- and that has to be defined in the file and respected by the file reader.

It may not help any known host CPU, but it does help host code - which may store the values in memory in any order they desire.

Also, done correctly, it should simplify the pipeline between file values and host application values (becauase you always handle byte order for any bit depth where (N%8 == 0)).

So, it really is best of LibTIFF obeys the byte order of the host application and converts as necessary when reading and writing such files.

Chris

PS. Note that there are CPU supported 80 and 96 bit floating point formats.

-----Original Message-----

From: tiff-bounces@lists.maptools.org on behalf of Bob Friesenhahn

Due to statements in Chris Cox's draft specification, it seems that 24 bit values are now officially swapped to match the "host" endianness (a recent libtiff change). However, there is no "host" endianness for 24 bits for any known host on the planet since CPUs (other than perhaps some exotic DSP) do not have 24-bit words. I have not checked to see what libtiff is really doing, but it seems to me that it is best for the libtiff API user if 24-bits are presented in big-endian network-byte-order and not swapped into an order which does not help any type of host. If libtiff needs to swap data before it goes into the file in order to be complaint with Chris Cox's draft specification (and Photoshop CS2), then that is fine.

Opinions?