2009.10.06 22:07 "[Tiff] SourceForge terms changes, heads up", by Bob Friesenhahn

2009.10.07 20:24 "Re: [Tiff] Wrong Native Bit Order on Intel x86_64", by Toby Thain

On 7-Oct-09, at 4:11 PM, Eskandar Ensafi wrote:

A run-time check would be nice, but I too am not sure how to implement it. I seem to recall that "bit order" (unlike "byte order") is not something that you can detect in C.

I think you are right.

Hopefully, this tag is not being used by most applications because it would mean that when you write an image on a 64-bit system and try to view it on a 32-bit system, or vice versa, then the bits will be reversed and the image data will become rubbish. I'm not so sure if "bit order" really matters, does it?

IMHO, I agree, native order is irrelevant. You could choose any default here.

The same is true of byte order, more or less, but it's easy to sniff so easy to write the same order as platform.

--Toby

>

-----Original Message-----
From: Bob Friesenhahn [mailto:bfriesen@simple.dallas.tx.us]
Sent: Wednesday, October 07, 2009 1:00 PM
To: Eskandar Ensafi
Cc: tiff@lists.maptools.org

Subject: Re: [Tiff] Wrong Native Bit Order on Intel x86_64

On Wed, 7 Oct 2009, Eskandar Ensafi wrote:

>

> I noticed that when I tried to compile tiff-4.0.0-beta4, the

>> native bit

order on 64-bit x86_64 systems was > determined to be FILLORDER_MSB2LSB (not correct as far as I know) whereas on 32-bit x86 systems, it is > correctly determined to be FILLORDER_LSB2MSB. I checked my current tiff-3.8.2 installation (the standard > package provided in Red Hat Enterprise Linux 5.4), and the same discrepancy existed in tiff-3.8.

This is very interesting. It seems like there should be some efficient way to determine this at run-time rather than via the configure script. I am not sure how to test for native fill order though.

Bob
--
Bob Friesenhahn

> bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/
> bfriesen/

GraphicsMagick Maintainer, http://www.GraphicsMagick.org/