pdf-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]