2007.01.15 01:09 "[Tiff] bigtiff", by Albert Cahalan

2007.01.15 06:00 "Re: [Tiff] 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.

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.