2017.04.03 17:05 "[Tiff] Reading images with bits per pixel not a multiple of 8", by Dinesh Iyer

2017.04.05 15:50 "Re: [Tiff] Reading images with bits per pixel not a multiple of 8", by Charles Auer

TIFFIsByteSwapped returns a non-zero value if the image data was in a different byte-order than the host machine. Zero is returned if the TIFF file and local host byte-orders are the same. Note that TIFFReadTile(), TIFFReadStrip() and TIFFReadScanline() functions already normally perform byte swapping to local host order if needed.


I'm not sure if this is helpful.



From: tiff-bounces@lists.maptools.org <tiff-bounces@lists.maptools.org> on behalf of Dinesh Iyer <dsi.maillist@gmail.com>

Sent: Tuesday, April 4, 2017 2:00 PM
To: Bob Friesenhahn
Cc: TIFF mailing list

Subject: Re: [Tiff] Reading images with bits per pixel not a multiple of 8

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?

On Mon, Apr 3, 2017 at 2:46 PM, Bob Friesenhahn <bfriesen@simple.dallas.tx.us<mailto:bfriesen@simple.dallas.tx.us>> 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.


Bob Friesenhahn

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

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


Tiff mailing list: Tiff@lists.maptools.org<mailto:Tiff@lists.maptools.org>