AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.03.15 23:58 "[Tiff] libtiff and streams", by Dimitar Gospodinov
2004.03.16 00:14 "Re: [Tiff] libtiff and streams", by Bob Friesenhahn
2004.03.16 00:43 "Re: [Tiff] libtiff and streams", by Joris
2004.03.16 01:38 "Re: [Tiff] libtiff and streams", by Dimitar Gospodinov
2004.03.16 02:08 "Re: [Tiff] libtiff and streams", by Joris
2004.03.16 06:56 "Re: [Tiff] libtiff and streams", by Andrey Kiselev
2004.03.16 12:16 "Re: Re: [Tiff] libtiff and streams", by dimitar
2004.03.16 04:30 "Re: [Tiff] libtiff and streams", by Frank Warmerdam
2004.03.16 08:00 "Re: [Tiff] libtiff and streams", by Rob van den Tillaart
2004.03.16 08:25 "Re: [Tiff] libtiff and streams", by Andrey Kiselev
2004.03.25 15:56 "Re: [Tiff] Jpeg compressing a file", by Andrey Kiselev
2004.03.29 11:42 "[Tiff] Jpeg compressing a file", by Carl J. Collin
2004.03.29 13:01 "Re: [Tiff] Jpeg compressing a file", by Andrey Kiselev

2004.03.16 04:30 "Re: [Tiff] libtiff and streams", by Frank Warmerdam

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.

Do you think this is an easy change? For example using new switch for "stream i/o"?

Dimitar,

I can only repeat and support what Joris has said and verify that it should be possible to write TIFF files to a stream (since writing *normally* happens sequentially) but that libtiff is not set to read from non-seekable streams. As noted, the TIFF format makes extensive use of file offsets to connect different structures, and places few requirements on the order of sections of the file making general reading of libtiff files from a stream pretty much impossible without caching the file somewhere.

However, there is a standard (EXIF? TIFF-IT?) which states a particular order of sections in a TIFF file which guarantees it is possible to read the file from a stream. Basically this is accomplished by ensuring that all pointers point forward in the file. Libtiff isn't setup to take advantage of this or to generate this type of file.

I would note that by default libtiff will write the imagery right after the 8bit header, and then flush out the directory at the end of file on closing, which makes it impossible to read the files in "streaming" form.

P.S. I tried to use libtiff with streams and everything worked, except get file size.

I'm not sure what file size getting is referred to. Is this the code that figures out where new stuff will be written based on current file size? I believe libtiff uses seek and tell to figure out where stuff will be written rather than keeping track of file length internally.

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    | Geospatial Programmer for Rent