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
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



Valid HTML 4.01!



Thread

2009.04.26 17:22 "Packbits worst case encoded length", by Simon Berger
2009.04.29 14:28 "Re: Packbits worst case encoded length", by Toby Thain
2009.04.29 18:07 "Re: Packbits worst case encoded length", by Simon Berger
2009.04.29 19:17 "Re: Packbits worst case encoded length", by Toby Thain
2009.04.29 19:43 "Re: Packbits worst case encoded length", by Simon Berger
2009.04.30 07:41 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.04.30 13:58 "Re: Packbits worst case encoded length", by Toby Thain
2009.04.30 19:12 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.04.30 19:25 "Re: Packbits worst case encoded length", by Toby Thain
2009.04.30 19:31 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.04.30 22:30 "Re: Packbits worst case encoded length", by Toby Thain
2009.05.01 06:34 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.05.01 14:21 "Re: Packbits worst case encoded length", by Toby Thain
2009.05.05 16:39 "Re: Packbits worst case encoded length", by Bob Friesenhahn
2009.05.05 18:09 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.05.05 18:32 "Re: Packbits worst case encoded length", by Bob Friesenhahn
2009.05.05 19:13 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.05.05 22:57 "Re: Packbits worst case encoded length", by Graeme Gill
2009.05.05 18:42 "Guard pages - was Re: Packbits worst case encoded length", by Toby Thain
2009.04.30 19:25 "Re: Packbits worst case encoded length", by Simon Berger

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

On 30-Apr-09, at 3:41 AM, Albert Cahalan wrote:

> On Wed, Apr 29, 2009 at 10:28 AM, Toby Thain  
> <toby@telegraphics.com.au> wrote:
>> On 26-Apr-09, at 1:22 PM, Simon Berger wrote:
>

(Attribution is incorrect, I wrote the lines you're quoting.)


>> 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.
>
> There is no "if".

There must be a lot of code out there that assumes good input. And if  
you're writing a quick hack, not a general purpose library, you might  
choose to do the same (hence "if"). Since the RLE code I have written  
could be used in scavenging a bad file, naturally I used one or more  
of the strategies you mention.

(Relying on memory protection to save you is not a portable strategy,  
so again unsuitable for a general purpose library.)

--Toby

>
> If the row doesn't come out even, you have 4 choices:
> ...