2012.01.26 18:13 "Re: [Tiff] TIFFClientOpen() output stream/encoding behaviour", by Christopher Cameron

As this can be deployed on a device with limited memory, buffering the whole image first would be undesirable.

And I suppose the strip offsets / byte counts can't simply come before each strip right?

Then the file would be formatted, e.g.

Header -> IFD 0 -> Strip Offset 0 Strip Byte Count 0 -> Strip 0 -> Strip Offset 1 -> Strip Byte Count 1 -> Strip 1 ->...

But I think I read that the strip offsets and bytecounts are contiguous blocks...

Chris

On 12-01-26 12:56 PM, "Olivier Paquet" <olivier.paquet@gmail.com> wrote:

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 stream which can be an output written

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.