Thread

Actually, the desirable "host" bit order depends on the application. I would suggest that there is no natural bit order in any system implementing C, because bits are not addressable in C.

Huh? The issue is that if I think I know what (byte & 0x1) should be then I'll want each byte of decoded data to be in an appropriate bit order for my application--irrespective of how the data was stored in the TIFF.

However, there are times when a MSB-to-LSB order is convenient for processing, especially on big-endian machines. There are other times when a LSB-to-MSB order is more convenient. These cases may be more frequent on little-endian machines, but not restricted to them.

Would it be possible to have this be a settable parameter, without causing too much of a performance hit?

The only issue is what to do with uncompressed image data that has been written with a FillOrder tag whose value is opposite to some expected bit order. I say this because compressed data must have the bit order corrected prior to decoding or the decoder must be capable of handling data whose FillOrder is opposite to an expected value.

I'll think about this request. This is getting dangerously close to the "let's have the library do data formatting and unformatting" rathole that I've tried very hard to avoid... On the other hand, I'm sensitive to apps having to undo something the library did just 'cuz there's no way to disable it--this is the sort of problem that makes folks avoid using existing software.

Sam