Received: from mailgate009.isp.belgacom.be (mailgate009.isp.belgacom.be [195.238.6.2])
	by maildelivery019.isp.belgacom.be (Postfix) with ESMTP id E8F9C8404B
	for <joris.at.lebbeke@skynet.be>; Tue, 28 Aug 2007 19:01:01 +0200 (CEST)
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 28 Aug 2007 19:01:01 +0200
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l7SEAWex032635;
	Tue, 28 Aug 2007 10:10:52 -0400
Received: from toronto2.smartgames.ca (toronto2.smartgames.ca [204.15.192.18])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l7SEAKWx032632
	for <tiff@lists.maptools.org>; Tue, 28 Aug 2007 10:10:21 -0400
Received: from [10.143.176.18] (unknown [10.143.176.18])
	by toronto2.smartgames.ca (Postfix) with ESMTP id A8E31EC8;
	Tue, 28 Aug 2007 10:12:44 -0400 (EDT)
In-Reply-To: <46D43313.4010903@pobox.com>
References: <Pine.SOC.4.60.0708251722130.922@blade.simplesystems.org>
	<3B96007137B4CE4E85114278E640DC330131C790@namail3.corp.adobe.com>
	<46D43313.4010903@pobox.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <774AB6A3-CE13-4ABA-BBEB-AE23FC792A20@smartgames.ca>
Content-Transfer-Encoding: 7bit
From: Toby Thain <toby@smartgames.ca>
Subject: Re: [Tiff] 24-bit samples in TIFF
Date: Tue, 28 Aug 2007 11:09:23 -0300
To: Frank Warmerdam <warmerdam@pobox.com>
X-Mailer: Apple Mail (2.752.2)
Cc: Tiff List <tiff@lists.maptools.org>
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.00002774
X-MSP-STORE: Tue, 28 Aug 2007 19:01:02 +0200
Status: RO


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/

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