AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.02.24 20:02 "[Tiff] Support for 16-bits per sample images", by Mayank
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.24 19:14 "Re: [Tiff] Support for 16-bits per sample images", by Chris Cox
2004.02.24 19:46 "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.25 05:59 "Re: [Tiff] Support for 16-bits per sample images", by Andrey Kiselev

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