LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2004
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
2004.09.17 04:39 "Re: BigTIFF Tag Value Count issue", by Chris Cox
> > > > Option 0: stick with 4 byte tag count members (alignment, tag > > > > data <= 4 gig, Frank's choice) > > > > Option 1: make it an 8 byte tag count (no alignment, tag data > 4 > > > > gig allowed) > > > > Option 2, courtesy of Bob: make it 8 byte tag count, add 4 padding bytes > > > > (alignment, tag data > 4 gig allowed) > > > > > > > > Can I put you down as an option 2 vote, or were you merely signalling the > > > > option? > > > > > > Sure, there should always be a second option so put me down for > > > option 2. :-) > > > > Can you think of a situation that needs an 8 byte count? > > Or do you just want the size increased on general principles? > > The idea was to consume 8 bytes for alignment purposes but use 4 > bytes out of those 8 bytes to support the value. Perhaps I > misunderstood the problem. I don't have a strong opinion either > way, but do believe that the format should be aligned to work well > with memory-mapping. I'm not sure we can guarantee 8 byte alignment of the IFD, so how can we guarantee that the items will be aligned in memory? > > Do you think that increasing the count to 8 bytes would be a > > problem in libTIFF? > > I don't have the libtiff knowledge to properly answer that. If the > availability of a native 64-bit storage type can be assumed (pretty > safe if 32-bit processors are the new baseline) then it doesn't > sound like an 8 byte value would be a problem. I was thinking more of logic changes necessary. In Photoshop the count field is well isolated - it would take about 80 lines of code to change the count from 4 to 8 bytes. (mostly range checking and increasing the size of loop variables) Chris