[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdf-devel] Predictor filter
From: |
Jose E. Marchesi |
Subject: |
Re: [pdf-devel] Predictor filter |
Date: |
Sun, 23 Jan 2011 23:36:11 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) |
On 22 January 2011 21:07, Jose E. Marchesi <address@hidden> wrote:
> You can find several unit tests for the currently implemented filters in
> both torture/unit/base/stm/pdf-stm-read.c and
> torture/unit/base/stm/pdf-stm-write.c. I guess that a similar approach
> could be used to test the predictor filters.
The ones I looked at mostly encode a simple string, which can't be
done for the predictor stuff because it's explicitly binary
scanlines.
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
Knowing that pgm uses 8 bits per pixel, we can easily infer the result
of applying the Sub predictor:
Sub (x) = Raw (x) - Raw (x - bpp)
(Consider Raw(x) = 0 when x < 0)
P2
6 3
10
2 0 1 0 0 0
2 0 1 0 0 0
2 0 1 0 0 0
Now, using the pnmcat tool is easy to get the raw version of the
previous bitmaps:
$ pnmcat -tb ascii.pbm > bin.pbm
These raw values can be then either encoded in C strings in the unit
tests source files or in files under testdata/.
The predictor filter can be passed the raw version of the first bitmap
(with Colors=1 BitsPerComponent=1 and Columns=6 in this case) and should
generate the raw version of the second bitmap.
Pixmaps (P3 pbms) can be used to test the filter with other values for
Colors.
--
Jose E. Marchesi address@hidden
GNU Project http://www.gnu.org