LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
August 2007
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2007.08.28 14:37 "Re: 24-bit samples in TIFF", by Frank Warmerdam
Chris Cox wrote: > 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. 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. 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 > Sent: Sat 8/25/2007 3:29 PM > To: Tiff List > Subject: [Tiff] 24-bit samples in TIFF > > 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