2004.09.19 16:43 "Re: [Tiff] BigTIFF Tag Value Count issue", by Joris
I originally wrote:
Chris and I have been discussing BigTIFF, as the current Wiki specifies, and we've come to a subject that we both would like more comments and opinions on.
The thing that is now up for debate is the third member, the 'Count' member, the member that specifies the number of values. We are unsure as to whether we really want to keep it 4 bytes, or extend this member to 8 bytes, as well.
In order to try and help ensuring a final conclusion, here is a overview of the founded opinions sofar. I've decided to even eliminate discussions about alignment from this overview, since, by now, it is totally clear that the two issues are not related, because we can/could add pad bytes wherever we want or extend other members or whatever. That also eliminates the original argument pro 4 bytes that I gave in the very first mail, and further narrowes down the discussion quite a bit.
- Joris, in the very first mail, wrote that one argument pro 8 bytes in simply plain logic and consistency. Tag values of private tags are opaque to the specification, are said to be 'anything'. It is logical for a file format that is specifically designed to break the 4 gig boundary, to acknowledge that any 'anything' may need to break that boundary.
- Frank wrote he prefered a 4 byte tag count, basically because 8 byte tag counts can lead to major trouble in current LibTiff design where tag values get read and written in a single go.
- Bob, however, argued that 4 byte tag counts does not eliviate this problem. It's just as easy to efficiently bomb LibTiff writing tag values of say even merely 2 gig, which fits perfectly fine in a 4 byte tag count specification. Limiting tag counts to 4 bytes may help in ignoring the LibTiff problem, it does not help in making it go away.
- Rob wrote that he preferred 8 byte tag counts, since private tags could want to store additional information about every single pixel. Whilst his example included things that may be more suitably stored in extra channels, I can see the general statement might hold for eg per-pixel variable size data.
- Andrey pointed out tiles can have be a single pixel wide and single pixel high, yielding a number of tiles that equals the number of pixels in the image. To store StripOffsets and StripByteCounts in that case (or far less extreme variants), we need an 8 byte tag count.
- I would now like to add an opinion of my own. First off, the more I think about it, the more the original argument pro 8 byte tag counts seems to make sense. It is logical for a 64 bit offset variant of TIFF to acknowledge the need for breaking the 4 gig boundary when it comes to opaque data. Secondly, while I acknowledge the need for BigTIFF to be as little as possible different from TIFF classic, so as to extend current libraries as easy as possible, and so as to extend the specification as painlessly as possible, it seems to me that the nature of the extension is such that we also need it to be future-proof. I fear that in five or maybe even less years from now, we might start to regret it, if we should now prefer a 4 byte tag count.
- Chris asked at one time 'Can you think of a situation that needs an 8 byte count?'. I would like to turn that around, and answer to that we learned from the past such situations are bound to arise, probably sooner rather then later, even if it is rarely thinkable five years earlier. Therefore, if we cannot come up with a legit reason to limit things to 4 byte tag counts, we should eliminate the limitation in BigTIFF, now that we have the chance to do so relatively painlessly.
- I tried to install an 'advisory voting' tag in this thread. I would now like to add my own vote, pro 8 byte tag counts. I would like to add that, in the event there would be no further discussion, I'm hoping Frank, Chris and Steve make the final decision at their earliest convinience. I really need this, preferably sooner rather then later. I do want to make sure that I comply with the future spec, preferably without many additional discussion about god, the universe, the maining of life, and the continued adventures of shell extension building.
Joris Van Damme
Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html