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

2007.01.15 03:42 "Re: [Tiff] bigtiff", by Frank Warmerdam

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?

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?)

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.

For instance moving to 128 bit uuids for tag identities would complicate API interfaces that are currently only accepting ints for tag ids.

You are correct that it isn't to late to change some things about BigTIFF, (though it is nearly too late) but so far nothing you have suggested really appeals to me as something I would want to do. Perhaps others will feel different.

Best regards,

I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam

and watch the world go round - Rush    | President OSGeo, http://osgeo.org