I've unassigned this task and reverted the progress to 0. I'm not going to have time to do this. Sorry for wasting your time.
On 23 January 2011 22:36, Jose E. Marchesi <[email protected]> wrote: > You could write little bitmaps by hand to test the predictors. Consider > for example the following gradient (the P2 identifies the pbm as an > ASCII portable bitmap, 6 3 are the dimensions and the 10 is the number > of gray values between black and white). > > P2 > 6 3 > 10 > 2 2 1 1 0 0 > 2 2 1 1 0 0 > 2 2 1 1 0 0 Of course, I could. But this doesn't really get to the bottom of the problem. It doesn't test any of the assumptions the code makes, it merely tests that the assumptions are implemented correctly, which is the most basic confirmation above testing something compiles. I tried using an LZW stream stacked with the predictor stream (as it would need to be) to read real PDF streams, but that didn't work at all. I also had trouble generating real PDF streams with known bitmaps - because I don't have a program that will compress small bitmaps when it embeds them in PDF. I could've checked the leading few pixels with time, but I haven't had that time. I wanted to put here some notes as a help to whoever ends up doing this. The critical problem is buffering. The buffer size is not settable by the filter itself. That means the buffer will not in general contain a whole number of scanlines (or indeed an entire scanline). I believe that the easiest way to handle this is to hold a partial scanline carried from the previous buffer as part of the filter. It would be better to split the implementation into DEC and ENC parts as other filters do. This is already nearly present in the code and not difficult to do. It simplifies things considerably. There should be a note somewhere that PNG is not really PNG but PDF-PNG which uses different constants (and allows TIFF!). I hope this helps someone. Best of luck, Ed
