1999.06.03 19:48 "Large File Support", by Bruce Forsberg

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

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