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:48 "Re: 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