2017.04.04 15:14 "Re: [Tiff] Reading images with bits per pixel not a multiple of 8", by Bob Friesenhahn
Currently, in my code, when I read 16-bit images, I just treat the buffer returned by TiffReadEncodedStrip as uint16_T and read the data. It appears that is incorrect because it will give the wrong result for big-endian files. Am I correct?
I don't think so. As mentioned before, libtiff automatically swaps sample sizes of 16, 24, 32, and 64 to native host order before returning the buffer. It also swaps bit order if necessary.
On Mon, Apr 3, 2017 at 2:46 PM, Bob Friesenhahn < email@example.com> wrote:
Except for depths 8, 16, and 24 (which are swapped to "native" endianness by libtiff), the data is always ordered in most-significant-bit order
so you need to start with the top bits.
What about 32, 48 and 64 bit variants which are all multiples of these specially handled sizes?
Just wondering because I am not currently doing any special case handling for 32-bit and higher sizes.
You are correct. I should have mentioned 32 and 64 bit sizes as well. I am not sure about 48.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/