LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
April 2009
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
Thread
2009.04.29 14:28 "Re: 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 > > Thanks in advance. > _______________________________________________ > Tiff mailing list: Tiff@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/tiff > http://www.remotesensing.org/libtiff/