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 17:56 "Re: [Tiff] TIFFClientOpen() output stream/encoding behaviour", by Olivier Paquet

On Thu, Jan 26, 2012 at 11:41 AM, Christopher Cameron <ccameron@qnx.com> wrote:

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 output stream which can be written  an to only forward. Once data is written, it's written and the stream pointer can only go forward.

I don't think it's possible to write a TIFF that way, at all, if you use lossless compression. The header needs to point an IFD which needs to contain strip (or tile) offsets which you'll know only once you have compressed the entire image. It would in theory be possible using no compression or a lossy compression codec with a fixed compression ratio as you can predict the strip/tile sizes in the file. But libtiff isn't architectured for that very specific purpose.

The only way out I can see is to buffer up the TIFF output data for a whole image before writing it to your stream.

Olivier