- 2009.10.06 23:19 "Re: [Tiff] SourceForge terms changes, heads up", by Graeme Gill
-
2009.10.07 20:11 "Re: [Tiff] Wrong Native Bit Order on Intel x86_64", by Eskandar Ensafi
- 2009.10.07 19:25 "[Tiff] Wrong Native Bit Order on Intel x86_64", by Eskandar Ensafi
- 2009.10.07 20:24 "Re: [Tiff] Wrong Native Bit Order on Intel x86_64", by Toby Thain
- 2009.10.07 21:26 "Re: [Tiff] Wrong Native Bit Order on Intel x86_64", by Bob Friesenhahn
- 2009.10.08 15:09 "Re: [Tiff] SourceForge terms changes, heads up", by Ron
2009.10.07 20:28 "Re: [Tiff] Wrong Native Bit Order on Intel x86_64", by Edward Lam
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?
My (probably incorrect) understanding of HOST_FILLORDER is that it does not matter. I found this on the net,
http://www.remotesensing.org/libtiff/internals.html
"Native CPU byte order is determined on the fly by the library
and does not need to be specified. The HOST_FILLORDER and
HOST_BIGENDIAN definitions are not currently used, but may be
employed by codecs for optimization purposes. "
This seems to supercede somewhat the discussion previously on this mailing list:
http://www.asmail.be/msg0054849001.html
I also have an old note though saying that the HOST_FILLORDER just dictates the order in which the bits get saved into the .tiff file and that libtiff will correctly interpret the bits when reading the .tiff file according to the HOST_FILLORDER it was written with.
Regards,
-Edward