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

On Thu, Jan 26, 2012 at 1:13 PM, Christopher Cameron <ccameron@qnx.com> wrote:

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

Well, if you can read the input data twice (and know it will be exactly the same), you have the option of doing the compression twice: once to compute the strip sizes and once again to write the actual data. You can of course save as much of the compressed data as your memory will allow to make things faster.

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...

I haven't worked with the physical layout of a TIFF much but that's my understanding of the specification as well. I can't think of any way around it that would produce a reasonable TIFF file.

Olivier