2005.04.12 03:55 "Re: [Tiff] TIFF Technote 3, draft 1", by Chris Cox

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?

I mean (BitsPerSample > 8) && ((BitsPerSample & 7) == 0)

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?

Yes, it does.

It doesn't qualify what I think you meant since it is not a power of 2 at all.

I didn't say power of 2. I said a multiple of 8 bits.

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?

I just sent you the URLs. Unfortunately it's on my private domain site, so I can't just have everyone download them.... (and Adobe takes too long to post new material)

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.

No, I mean you should never interleave mixed bit depths - partly because too many things are undefined when you try that.

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.

But you can do that if you write the data in planar order....

It's just interleaving that's a problem.

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,

planes == channels
pixel = collection of all channels at a given spatial location

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. ;-)

According to the spec. it is not explicitly disallowed. But it is a REALLY BAD IDEA (TM) and I'll try to clarify that in the next spec. revision.

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?

In theory, yes.

But that's part of why mixing bit depths and interleaving is a REALLY BAD IDEA (TM).

Chris