
Thread

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
--
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>
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/