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

On 26-Apr-09, 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

>