2007.08.25 22:29 "[Tiff] 24-bit samples in TIFF", by Bob Friesenhahn

2007.08.28 14:09 "Re: [Tiff] 24-bit samples in TIFF", by Toby Thain

On 28-Aug-07, at 11:37 AM, Frank Warmerdam wrote:


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.

Bob / Chris,

I'm a bit confused on this topic, but I think I agree with Chris. I think Bob's point is that since 24bit float isn't a native type it isn't meaningful for libtiff to do any byte swapping on the data as it is loaded to put it into local machine byte order since local machine byte order doesn't really mean anything for a pseudo-datatype like 24bit float.

But my initial opinion is that I still expect libtiff to apply byte swapping to local machine order.

You guys are really making heavy weather of this.

Unless I've missed the point of the discussion, there are 2 questions?

  1. defined format on disk (which would follow TIFF file's ordering)
  2. access to host native value (which obviously cannot be 24 bit, but

would be decoded 32 bit).

What's the problem?


What does libtiff do now with 24 bit integer values? Presumably we should do the same thing with this and with the 24bit float values, right? I'm afraid I don't know what that is, though with some help from Bob I did manage to muddle my way through implementing support for tiff files with odd bit depths in my application.

Best regards,

-----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?
> --
> ---------------------------------------
> +--------------------------------------

I set the clouds in motion - turn up   | Frank Warmerdam,  warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam

> and watch the world go round - Rush    | President OSGeo, http:// 

> osgeo.org

> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/