AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
August 2006

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2006.08.29 20:44 "TiffReadEncodedStrip", by Richard Nolde
2006.08.29 23:56 "Re: TiffReadEncodedStrip", by Joris Van Damme
2006.08.30 22:01 "Re: TiffReadEncodedStrip", by Richard Nolde
2006.08.31 00:36 "Re: TiffReadEncodedStrip", by Joris Van Damme

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

Richard,

Richard Nolde wrote:
> 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