AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

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



Valid HTML 4.01!



Thread

2007.08.25 22:29 "24-bit samples in TIFF", by Bob Friesenhahn
2007.08.27 17:24 "Re: 24-bit samples in TIFF", by Chris Cox
2007.08.28 14:09 "Re: 24-bit samples in TIFF", by Toby Thain
2007.08.28 14:37 "Re: 24-bit samples in TIFF", by Frank Warmerdam
2007.08.28 14:57 "Re: 24-bit samples in TIFF", by Andrey Kiselev
2007.08.28 15:02 "Re: 24-bit samples in TIFF", by Bob Friesenhahn

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

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

> 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.

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?

--Toby


>
> 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
>
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/