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

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

There is will to change our streams to support proper seek() so we will be doing that and making an exception such that TIFF images cannot be opened unless random access is permitted.

Thanks to everyone who responded to my question!

Chris Cameron
Software Developer - Multimedia/Camera
ccameron@qnx.com

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

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.