2006.08.29 23:56 "Re: [Tiff] TiffReadEncodedStrip", by Joris Van Damme

Richard,

  From what I have read in the current man pages and programs in the

tools directory, I assume that I can simple compute the start of each row as an offset from the beginning of the buffer. For 1 bit per sample data with one sample per pixel, something like ImageWidth / 8 bytes would be returned into the read buffer for each row in the image and the offset would be (row * IMAGEWIDTH) / (8 /bps) * samples per pixel for contiguous planes. This seems to imply that the last byte of a scanline is padded out to fill that byte. Is this correct?

The last statement is correct, but the formulae before that is not. Scanlines are padded out with fillbits up to a byte boundary.

The correct expression to use goes something like this. A scanline length is (imagewidth*bitsperpixel+7)/8. Think about it, if imagewidth is 1 and bitsperpixel is 1, that'll round things up to 1 byte per row. If imagewidth is 8 and bitsperpixel is 1... still 1 byte per row.

So if you need an offset for (column,row), the byteoffset would be

row*((imagewidth*bitsperpixel+7)/8)+(column*bitsperpixel/8)

and if bitsperpixel is not a multiple of 8, you'll need a bit offset too...

((column*bitsperpixel)%8)

In the above, I assume / to have its C meaning, i.e. rounding down integer divide when operands are integers. Also, a 'bit offset' as per above is quite the inverse of what we are used to regard as bit number, i.e. bit offset 0 is the start of the byte, i.e. the get a single bit value at bit offset 1, you'd need to shift 6 bits to the right.

There's a good reason for the above, it is not just arbitrary. The good reason is that this exact padding is also in effect in uncompressed data in TIFF. So the uncompressed decoder, really is a null operation.

Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html