2005.04.12 03:48 "Re: [Tiff] TIFF Technote 3, draft 1", by Joris Van Damme

Chris,

It's not just Motorola (it's almost everyone other than Intel ;-). Any data value with more than 8 bits and that has a length that is a multiple of 8 bits has to be byte order swapped.

Please be patient with me. You do mean 'a length that is 2**x with x>=4', do you not? 24 bits qualifies as 'a length that is a multiple of 8 bits', and thus needs byteswapping according to your comment, but I don't think it does, does it? It doesn't qualify what I think you meant since it is not a power of 2 at all.

That applies to integer, float, and even to "unknown" values.

I've been doubtful about this for as long as I can remember. Thank you very much for clearing this up for me.

Am I seeing correctly now that, with the predictor in use, the image data is equal in both byteorder flavour TIFFs?

After going through the predictor, in the file - yes.

Understood. Thank you!

Are there any test images available in both byte orders, preferably both combined with and without predictor scheme, that would allow me to test my understanding?

I have some, but it's about 160 Meg total. (30 Meg for 16 bit, 42 Meg for 24 bit, and 57 Meg for 32 bit)

Are you willing and able to share these? Do you have access to some FTP space that can dig 'em?

Abusing the fact that I have your attention, I'd like to ask something that is only remotely related, in that it also shares my confusion surrounding byte order in image data... Say you have 3 channels, 12, 13, and 16 bits wide, in ordinary TIFF, with ordinary integer SampleFormat. That means the 16bits channel does not even start on a byte boundary for most columns. Is it nevertheless subject to byteswapping?

You can't interleave mixed bit depths.

Surely you mean that LibTiff doesn't support it. The TIFF file format doesn't have any such limitation. The BitsPerSample tag has a count that is equal to the SamplesPerPixel tag value. And I'm always reading (and writing) LibTiff doesn't support mixing bitdepths, which would be a foolish statement if TIFF didn't.

And more conclusively, in the TIFF specification, Section 8, Baseline field reference, BitsPerSample field:

<quote>

Note that this field allows a different number of bits per component for each component corresponding to a pixel. For example, RGB color data could use a different number of bits per component for each of the three color planes.

</quote>

I'm not sure about the meaning of 'corresponding to a pixel' in that quote, and the word 'planes' at the end is again confusing, but since no definite reference is made to PlanarConfiguration, I take that word to merely mean 'channels'. So I think I should read this to mean different channels can have different bitdepths. If not, I've definitely been living in the Twilight Zone last couple of years... but I've often suspected as much for plenty of unrelated reasons, so it's definitely a possibility. ;-)

And anything that isn't a multiple of 8 bits goes in natural bit order - aka BigEndian.

That is understood.

Assuming we agree that mixed bitdepths are possible in the TIFF file format, as opposed to supported in LibTiff... As to the case I presented, SamplesPerPixel=3, BitsPerSample=[12,13,16], SampleFormat=default, integer.

The third channel in this case, 16bits wide, is byteswapped, even though it doesn't even start on a byte boundary (most of the columns), right?

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html