AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2012.01.26 16:41 "[Tiff] TIFFClientOpen() output stream/encoding behaviour", by Christopher Cameron
2012.01.26 17:56 "Re: [Tiff] TIFFClientOpen() output stream/encoding behaviour", by Olivier Paquet
2012.01.26 18:13 "Re: [Tiff] TIFFClientOpen() output stream/encoding behaviour", by Christopher Cameron
2012.01.26 18:26 "Re: [Tiff] TIFFClientOpen() output stream/encoding behaviour", by Olivier Paquet
2012.02.01 18:12 "Re: [Tiff] TIFFClientOpen() output stream/encoding behaviour", by Christopher Cameron
2012.01.26 18:24 "Re: [Tiff] TIFFClientOpen() output stream/encoding behaviour", by Bob Friesenhahn
2012.01.26 19:02 "Re: [Tiff] TIFFClientOpen() output stream/encoding behaviour", by Joris Van Damme
2012.01.26 20:30 "Re: [Tiff] TIFFClientOpen() output stream/encoding behaviour", by Thomas Richter

2012.01.26 16:41 "[Tiff] TIFFClientOpen() output stream/encoding behaviour", by Christopher Cameron

Hello,

I am writing a TIFF codec for an image library. We have decided to use libtiff as the basis for that codec.

The image library provides access to an output stream which can be written to only forward. Once data is written, it's written and the stream pointer can only go forward.

I am noticing however that libtiff will occasionally attempt to seek back to data, and occasionally ask for the size of the file, while encoding. Is there a way to disable this random access for output streams? Perhaps by enabling something where libtiff will cache the metadata that has already been written? Or by forcing libtiff to write all the metadata first, followed by the image data?

I have noticed this thread http://www.asmail.be/msg0054976899.html where the author fixed part of what I am describing by making read/size return 0 always, but I have my doubts whether this is the correct solution. Also, his seek function was still capable of doing standard seek, something that my output stream prohibits.

Thanks,

Chris