2016.11.12 20:16 "[Tiff] Libtiff 4.0.7 release pending ...", by Bob Friesenhahn
-
2016.11.21 19:36 "Re: [Tiff] 12 bit byte format", by Aaron Boxer
-
2016.11.21 19:29 "Re: [Tiff] 12 bit byte format", by Kemp Watson
- 2016.11.21 19:07 "[Tiff] 12 bit byte format", by Aaron Boxer
- 2016.11.21 19:32 "Re: [Tiff] 12 bit byte format", by Aaron Boxer
- 2016.11.21 19:43 "Re: [Tiff] 12 bit byte format", by Bob Friesenhahn
- 2016.11.21 19:42 "Re: [Tiff] 12 bit byte format", by Aaron Boxer
-
2016.11.21 19:29 "Re: [Tiff] 12 bit byte format", by Kemp Watson
2016.11.21 19:36 "Re: [Tiff] 12 bit byte format", by Aaron Boxer
On Mon, Nov 21, 2016 at 2:31 PM, Bob Friesenhahn <
bfriesen@simple.dallas.tx.us> wrote:
> On Mon, 21 Nov 2016, Aaron Boxer wrote:
>
>>
>> Is this related to the fill order?
>>
>
> Fill order is about the ordering of bits in a byte. If the fill order is > wrong, then there is no resemblance to original values.
>
> My understanding is that 12-bits (and any other depth not matching a
> stored "word" size) should always be stored in big-endian byte order. 16, > 24, 32, and 64-bits would be stored in the indicated byte order.
>
> If you are using libtiff, then you will find that libtiff swaps data to > native order for 16, 24, 32, and 64-bits, but otherwise not.
>
Thanks. I guess I don't want to mess with fill order.