LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
January 2007
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
2007.01.15 06:00 "Re: bigtiff", by Albert Cahalan
On 1/14/07, Frank Warmerdam <warmerdam@pobox.com> wrote: > Albert Cahalan wrote: > > I've written some tiff read/write code, by hand (w/o libtiff), > > and I've been looking at bigtiff. > > > > The design looks like it got pulled between the conflicting desires > > of compatibility and sanity, getting rather bent out of shape in the > > process. It's not too late to reconsider. > > Albert, > > You proposed a number of adjustments to the BigTIFF specification. > > The first was to provide better backward compatibility - however, it > wasn't exactly clear to me how much backward compatibility it was going > to give. Was the intention that TIFF applications could read an image? > Just some of the image characteristics? With no modifications, just some image characteristics. This could be very little (we have a TIFF) or it could include things such as compression, size, and colorspace. It could also be nothing, if the magic number changes. More importantly, it was intended that software modifications be easy. Keeping the data structures the same size (particularly the IFD entry structs and the main header) lets TIFF-handling software be upgraded with very little change. The same data structures may be used. > For the latest "cruft removal", you proposed relaxing the alignment > requirement, or possibly enforcing it by actually shifting offsets. > I would agree that the alignment requirements currently are somewhat > pointless since I don't believe they are actually adhered to (even by > libtiff?) Enforce it or kill it. Both SSE and AltiVec have instructions that require 16-byte alignment. Handling unaligned data is slow. If the programmer doesn't handle it, SSE will fault and AltiVec will round off the addresses. > The UUID for tags has some advantages I suppose. > > But overall, all these fly in the face of what I think is most important > about BigTIFF. That is that it is in all respects the same as TIFF > except for changing some required values to be 64bit to handle large > data. It is exactly this similarity to the existing TIFF spec that > I think is important for easy adoption. No, bigtiff already broke things severely by changing struct layouts. If you're going to break things to that extent, you may as well take the opportunity to clean up some of the ugly things. > For instance moving to 128 bit uuids for tag identities would complicate > API interfaces that are currently only accepting ints for tag ids. An initial implementation could simply require that all but the first (or last) 16 bits be zero. Call this "base level" support if you wish. You could even just say the extra 14 bytes are reserved padding bytes for future expansion. It's very nice to eliminate the problem of tag collisions, but the 8-byte IFD entry alignment is itself quite useful for performance.