LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 2005
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2005.04.12 03:55 "Re: 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