- 2004.02.24 15:39 "Re: [Tiff] Support for 16-bits per sample images", by Andrey Kiselev
- 2004.02.24 15:41 "Re: [Tiff] Support for 16-bits per sample images", by Frank Warmerdam
- 2004.02.24 15:54 "Re: [Tiff] Support for 16-bits per sample images", by Bob Friesenhahn
- 2004.02.25 11:02 "Re: [Tiff] Support for 16-bits per sample images", by Mayank
2004.02.24 19:46 "Re: [Tiff] Support for 16-bits per sample images", by Bob Friesenhahn
What the other guys have told you on this list is that libtiff is capable of producing the original 16-bit data, but the interfaces require that you parse the data in your own application. Care must be taken since 16-bit TIFF can be big or little endian and the data is not re-ordered for you.
If that is the case, that would be a major bug in LibTIFF -- because differencing predictors have to be applied/removed in native byte order.
LibTIFF should always convert the image data to native byte order before handing it off.
I suspect that you are right. I do know that ImageMagick/GraphicsMagick includes code to re-order these bytes to big-endian order, but that may be for ease of implementation since it always reads the data as an octet stream and never as 'unsigned short'.
Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen