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
March 2004

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

2004.03.15 23:58 "libtiff and streams", by Dimitar Gospodinov
2004.03.16 00:14 "Re: libtiff and streams", by Bob Friesenhahn
2004.03.16 00:43 "Re: libtiff and streams", by Joris Van Damme
2004.03.16 01:38 "Re: libtiff and streams", by Dimitar Gospodinov
2004.03.16 02:08 "Re: libtiff and streams", by Joris Van Damme
2004.03.16 06:56 "Re: libtiff and streams", by Andrey Kiselev
2004.03.16 12:16 "Re: libtiff and streams", by <d_sf@cox.net>
2004.03.16 04:30 "Re: libtiff and streams", by Frank Warmerdam
2004.03.16 08:00 "Re: libtiff and streams", by Rob Tillaart
2004.03.16 08:25 "Re: libtiff and streams", by Andrey Kiselev

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

Dimitar Gospodinov wrote:
> Hi,
> 
> 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