
2009.04.29 14:28 "Re: [Tiff] Packbits worst case encoded length", by Toby Thain

2009.04.30 07:41 "Re: [Tiff] Packbits worst case encoded length", by Albert Cahalan

2009.04.30 13:58 "Re: [Tiff] Packbits worst case encoded length", by Toby Thain
 2009.04.30 19:12 "Re: [Tiff] Packbits worst case encoded length", by Albert Cahalan

2009.04.30 13:58 "Re: [Tiff] Packbits worst case encoded length", by Toby Thain

2009.04.30 07:41 "Re: [Tiff] Packbits worst case encoded length", by Albert Cahalan
 2009.04.29 18:07 "Re: [Tiff] Packbits worst case encoded length", by Simon Berger
 2009.05.05 19:13 "Re: [Tiff] Packbits worst case encoded length", by Albert Cahalan
2009.04.29 14:28 "Re: [Tiff] Packbits worst case encoded length", by Toby Thain
On 26Apr09, at 1:22 PM, Simon Berger wrote:
I implemented the packbits encode/decode functions of libtiff. It works great overall, but sometimes the worst case formula:
srcByteLen + (srcByteLen + 126) / 127
doesn't work. On a 24 bit image with big width I got 1  15 higher output. Is this due to a non standard implementation and is there any length I can safely use instead of any flushing inside the function (I cut the block off)?
If you mean "largest compressed data size that might expand to srcByteLen bytes," then the worst case PackBits representation is srcByteLen*2. Your formula above is assuming the compressor is packing as best it can.
If you need your code to be robust against corrupt input then you should stop decompressing when the row is full, though of course you will lose sync with the input.
(Here is a working decompressor, which I use for PSD, btw: http://www.telegraphics.com.au/svn/psdparse/trunk/unpackbits.c )
Toby
>