2009.04.26 17:22 "[Tiff] Packbits worst case encoded length", by Simon Berger
-
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.26 17:22 "[Tiff] Packbits worst case encoded length", by Simon Berger
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)?
Thanks in advance.