2007.01.15 17:34 "Re: [Tiff] bigtiff", by Joris
The waste is less than a millionth of the file size, or 0.0001 %. At "ten times", it's still only 1/100000 of the file size, or 0.001 %.
Ah, is it?
Say an image is 32x32 pixels. You have those, in TIFF. Say there are ten tags in the IFD that are just over 4/8 bytes in size and don't fit the IFD, and five others. Let's be generous and do you the favour of not compressing the image, and say all pixels have four bytes.
The BigTIFF size is 16+8+15*20+8+10*8+32*32*4. The size of what you propose in the first of your two proposals that seem to be pulled between the conflicting desires of compatibility and sanity, is RoundUpToMultipleOf4096(16) + RoundUpToMultipleOf4096(8+15*20+8) + 10*RoundUpToMultipleOf4096(4096) + RoundUpToMultipleOf4096(32*32*4). Give or take a few bytes, as this is just from the top of my head, you end up with at least 10 times as much, with the exact same image data in there.
With bit shifting, there is no need to worry. The writer shifts values to the right. The reader shifts values to the left. There is no way to create a reader or writer that is semi-compatible. Either it works or it does not.
You seem to miss the point, BigTIFF *is* TIFF. There is no such bitshifting to get rid of insignificant bits in offsets, in TIFF.
I would agree though that the requirement to align is one of the most redundant rules in TIFF and BigTIFF alike. It is also one of the most violated. And its violation is no problem, at all. My own codec does align, but I came very close to deciding otherwise.
So I just don't see the benefit of ensuring it, nor do I see the benefit or killing it, nor do I see what is the big deal to 'worry' about as opposed to bitshifting. What I do see, is advantage to keeping BigTIFF totally as close as possible to TIFF.
Clearly the spec has been overly difficult to implement and/or just not all that desirable.
That's just not the case.
Joris Van Damme
Download your free TIFF tag viewer for windows here: