2005.04.11 00:03 "[Tiff] TIFF Technote 3, draft 1", by Chris Cox

2005.04.11 23:20 "Re: [Tiff] TIFF Technote 3, draft 1", by Joris Van Damme


Thanks for your clarification.

Without the predictor, you do have to byte swap the image data for floating point data that has BitsPerSample equal to a multiple of 8. Yeah, that should be obvious.

I appologise for my stupidity. I am totally unaware of the Motorola platform, for all I knew IEEE floats could have been orderer exactly the same there as on the Intel platform, as opposed to integer 16bit values, and contemplating that possibility confused the issue for me.

With this predictor, you don't need to do that extra step, because the predictor does byte reordering as part of the prediction process. (which complicates the TIFF pipeline a little, but does help compression quite a bit).

I've had an extra look at the sample code, and together with your clarification, I *think* I understand now, but I'm still not entirely sure. Am I seeing correctly now that, with the predictor in use, the image data is equal in both byteorder flavor TIFFs? 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?

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?

Thanks again for your clarification, and kind patience.

Joris Van Damme
Download your free TIFF tag viewer for windows here: