2004.03.16 00:43 "Re: [Tiff] libtiff and streams", by Joris Van Damme
How difficult would be to modify libtiff to support streams-like operations? Having random access files is not always possible - for example when reading from sockets, the file size is unknown.
One of the things that should change, if streams are to be supported, is get file size functions. They can not be used.
I think/thought such a thing is completely incompatible with the TIFF specification. It's quite possible and compliant with the specification that the header points to the first IFD being at the end of the file, which points to data spread throughout the file, and may point to a second IFD that follows the header immediatelly. Plus, applications could be interested in page 10 to begin with, and develop an interest in page 1 afterwards. (OK, finding IFD for page 10 implies passing through IFD for page 1, but I mean, the actual raster decoding activity of page 1 should not be necessary at this stage, and yet still possible at any later stage.) So how can this scheme possible be combined with sequential access of the TIFF?
I must be missing something basic and hope that someone will be so kind as to correct me.
If I'm not mistaking, there's a kind of sub-specification somewhere, that does impose extra rules as to the actual order of the data blocks inside the TIFF file, mainly to work around this incompatibility of TIFF specification and stream-line sequential decoding. I seem to remember there's an RFC about this. But I could very well be mistaking.
P.S. I tried to use libtiff with streams and everything worked, except get file size.
Perhaps in this particular attempt both TIFF file and application requests where in some specific order?
I've never understood LibTiff's need for file size. That is *not* a logical consequence of the TIFF specification, I think. But again, I gladly stand corrected.
Joris Van Damme
Download your free TIFF tag viewer for windows here: