AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2006.06.02 15:22 "[Tiff] TIFFWriteRawStrip with multi-strip?", by
2006.06.02 16:35 "Re: [Tiff] TIFFWriteRawStrip with multi-strip?", by Joris Van Damme
2006.06.02 17:08 "RE: [Tiff] TIFFWriteRawStrip with multi-strip?", by
2006.06.07 08:50 "Re: [Tiff] TIFFWriteRawStrip with multi-strip?", by Gerben Vos
2006.06.07 11:48 "Re: [Tiff] TIFFWriteRawStrip with multi-strip?", by Joris Van Damme
2006.06.07 13:48 "RE: [Tiff] TIFFWriteRawStrip with multi-strip?", by
2006.06.02 17:20 "Re: [Tiff] TIFFWriteRawStrip with multi-strip?", by Joris Van Damme

2006.06.07 08:50 "Re: [Tiff] TIFFWriteRawStrip with multi-strip?", by Gerben Vos

Pallek, Bernie: #CIPO - OPIC wrote:

But this means I need to find the byte offsets within 'someBuffer' so I can call TIFFWriteRawStrip repeatedly, incrementing the strip number. The crux? Since the data is compressed, how in the crap will I know where each strip's data begins within 'someBuffer'? Each strip is going to vary in size.

Joris replied:

This type of compression, G4, encodes each scanline relative to previous scanline. The first scanline is encoded relative to a 'virtual' all-white line. So if you divide the block, the first part will make sense, the second will be corrupted. There's no way you can work around that.

...not to mention that G4 produces a stream of bits, not bytes, so the boundary between two strips will not fall on a byte boundary in most cases, and it is even less likely that it will be regular enough to determine a rows-per-strip number.

Gerben Vos.