AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

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



Valid HTML 4.01!



Thread

2007.01.15 01:09 "bigtiff", by Albert Cahalan
2007.01.15 03:42 "Re: bigtiff", by Frank Warmerdam
2007.01.15 06:00 "Re: bigtiff", by Albert Cahalan
2007.01.15 08:01 "Re: bigtiff", by Joris Van Damme
2007.01.15 09:13 "Re: bigtiff", by Rob Van Den Tillaart
2007.01.15 09:43 "Re: bigtiff", by Joris Van Damme
2007.01.15 16:12 "Re: bigtiff", by Albert Cahalan
2007.01.15 17:22 "Re: bigtiff", by Frank Warmerdam
2007.01.15 17:34 "Re: bigtiff", by Joris Van Damme
2007.01.16 06:17 "Re: bigtiff", by Albert Cahalan
2007.01.16 09:25 "Re: bigtiff", by Joris Van Damme

2007.01.15 03:42 "Re: bigtiff", by Frank Warmerdam

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?

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