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
June 1999

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

1999.06.03 19:48 "Large File Support", by Bruce Forsberg
1999.06.04 03:45 "Re: Large File Support", by Frank Warmerdam
1999.06.04 07:32 "Re: Large File Support", by Rob Tillaart
1999.06.07 07:05 "Re: Large File Support", by Rainer Wiesenfarth
1999.06.08 21:14 "Re: Large File Support", by Peter Smith
1999.06.08 21:58 "Re: Large File Support", by Ed Grissom
1999.06.08 22:52 "Re: Large File Support", by Peter Smith
1999.06.09 01:27 "Re: Large File Support", by Martin Bailey
1999.06.09 06:50 "Re: Large File Support", by Owen Pearn
1999.06.09 14:33 "Re: Large File Support", by Martin Bailey
1999.06.09 08:07 "Re: Large File Support", by Rob Tillaart
1999.06.04 18:35 "Re: Large File Support", by Bruce Forsberg
1999.06.07 13:03 "Re: Large File Support", by Frank Warmerdam
1999.06.09 03:05 "Re: Large File Support", by <glen@lumisys.com>
1999.06.09 13:13 "Re: Large File Support", by Ed Grissom
1999.06.09 13:33 "Re: Large File Support", by Frank Warmerdam
1999.06.09 14:08 "Re: Large File Support", by Ed Grissom
1999.06.09 18:50 "Re: Large File Support", by Chris Barker
1999.06.09 18:41 "Large File Support", by Chris Barker
1999.06.10 13:21 "Re: Large File Support", by Chris Hanson
1999.06.10 13:52 "Re: Large File Support", by Frank Warmerdam
1999.06.10 14:37 "Re: Large File Support", by John Aldridge
1999.06.10 15:10 "Re: Large File Support", by Peter Smith
1999.06.10 16:56 "Re: Large File Support", by Chris Barker
1999.06.14 11:16 "Re: Large File Support", by Martin Bailey
1999.06.14 14:58 "Re: Large File Support", by Tom Lane
1999.06.14 15:30 "Re: Large File Support", by Eric Shapiro
1999.06.14 16:27 "Re: Large File Support", by Chris Barker
1999.06.14 15:51 "Re: Large File Support", by Martin Bailey
1999.06.09 15:52 "Re: Large File Support", by Ed Grissom
1999.06.10 09:48 "Re: Large File Support", by Klaus Bartz
1999.06.10 13:05 "Re: Large File Support", by Chris Hanson
1999.06.11 01:48 "Re: Large File Support", by <glen@lumisys.com>

1999.06.14 14:58 "Re: Large File Support", by Tom Lane

Martin Bailey <martinb@harlequin.co.uk> writes:
> I've been pondering the idea of large file support, and especially the
> ideal of minimising the impact that any changes would have on existing
> readers etc. I see backward compatibility as extremely important to ensure
> that any changes would be acceptable both to application creators and to
> the user community.

I agree with that goal, but I think that Frank Warmerdam's idea (allow
multiple separate TIFF files to be logically "tiled" together to form a
huge image) is a more practical approach, for the reasons already
mentioned by him and John Aldridge.

If one takes seriously Frank's notion that existing non-huge-image-aware
apps should be usable to edit each of the component files, then it'd
probably be best to keep the linking information separate from the
individual component files --- that way, there's no risk of an editor
discarding tags that it doesn't recognize.  So what I'm visualizing
is a "control" file that contains pointers to other files and defines
their locations in the overall image, but is never touched except by
huge-image-aware apps.  The component "tiles" of the huge image are
each bog-standard TIFFs.

The control file could be any format we like, but I suppose we might as
well use TIFF IFD structure for it.  Possibly we'd still need to invent
LONG64 (and SLONG64?) data types, with an eye to using them for the tags
that give the huge image's overall dimensions and the offsets of the
component images within it.  But that could probably be put off a few
years yet --- I don't suppose anyone is really hard up against the
2^32-pixels-in-either-dimension limit.  Otherwise it's just a matter of
inventing a set of tags for referring to other files.

Another thing that would be worth offering in this "super tiled" format
is multiple resolution capability --- that is, it should be able to
link to several sets of component files that represent the same image
at different resolutions.  The lowest resolution would be a small
"thumbnail" (small by comparison at least); perhaps this could be kept
right in the control file, or maybe it would be better off as a separate
file.

			regards, tom lane