|TIFF and LibTiff Mail List Archive|
LibTiff Mailing List
2004.09.16 19:12 "[Tiff] BigTIFF Tag Value Count issue", by Joris
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.
To eliminate chances of misunderstandings, please allow me to specify the full tag structure and mark the member in question.
Offset - Datatype - Value
0 - Word - Tag identifying code
For a more clear HTML table view on this and the two even more highest level structures, should you need a quick reminder, see http://www.awaresystems.be/imaging/tiff/faq.html#q3.
The current Wiki specifies there is only one difference between Classic TIFF and BigTIFF, as far as this structure is concerned, and that is, of course, that fourth, last member, the data/offset, that is 8 bytes wide in BigTIFF.
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.
Argument pro 4 bytes is that this keeps all 8 byte values in the TIFF file perfectly aligned on multiples of 8.
Argument pro 8 bytes is that tags may be private, meaning tag value is essentially opaque to the TIFF specification, meaning it's 'anything' as far as TIFF goes, meaning that we might want to acknowledge that it might need to grow beyond the 4 gig boundary. After all, we're having TIFF itself grow beyond that boundary, for good reason. 'Do upon others as you would like others to do upon yourself'. Or something. Academically speaking, it feels a bit weird the BigTIFF itself wouldn't fit in the space that BigTIFF reserves for the opaque 'anything'.
Not that there's much of a chance for the actual need, in practice, and that's why this may be poor argument too. I don't think we're ever going to see any tag grow beyond 4 gig, and we most probably will never see a TIFF tag that is a TIFF, since we've got the SubIFD scheme that covers this need.
Another thing to consider is what happens if we discard the need for 8byte values to be aligned... suddenly, the rationale behind having the 'number of tags' first member of each IFD grow to 8 bytes wide also becomes invalid, and we need to rethink that as well.
Another thing that may be 'spirit' related is the Tile/Strip ByteCounts... The current Wiki allows these to be specified with 8byte wide values. It seems that even though they are not related, they are somehow related, as the idea of having a single strip or tile growing beyond 4 gig is just as wild - or as carefull - as the idea of a single tag growing beyond 4 gig in size.
What do you all think?
Joris Van Damme