pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pdf-devel] Bugfix in prediction filter


From: Georg Gottleuber
Subject: Re: [pdf-devel] Bugfix in prediction filter
Date: Thu, 17 Nov 2011 19:38:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20111101 Thunderbird/7.0.1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I made another patch version for the prediction filter:

I have done some more bug fixes:
* PNG predictor filters processed streams byte
after byte. This is wrong, because the corresponding bytes per pixel
have to be processed (1st byte of pixel x with 1st byte of pixel x+1,
2nd ... with 2nd ...,  and so on). I introduced a new state variable
"bpp" (bits per pixel) and corrected all PNG predictors like they are
described in PNG RFC-2083.
* In the decoder it can happen that there is still something in the
input buffer but output is full. I think what I have overseen this
because it only happens if multiple filters are connected (I have not
tested predictor filter with another filter before). So I added the
same main loop condition as in the encoder:
+  while (!pdf_buffer_eob_p (in) && !pdf_buffer_full_p (out));
+
+  if (pdf_buffer_full_p (out) && !pdf_buffer_eob_p (in))
+    return PDF_STM_FILTER_APPLY_STATUS_NO_OUTPUT;
* It was possible to jump from PNG to TIFF prediction in the same
image decoding call. I caught this and decoding now fails with an
error message.

And some refactoring:
* changed all (pdf_char_t*)  to (pdf_uchar_t*)
* added a paeth predictor function, to beautify enc/decode_row_paeth

I have tested these changes with following pictures (PDFs produced by
pdflatex and tested against mupdfs pdfshow):
* 8x8 Pixel, 1 color/component,   4 bits per component
* 8x8 Pixel, 1 colors/components, 8 bits per component
* 8x8 Pixel, 3 colors/components, 24 bits per component
* 32x32 Pixel, 3 colors/components, 24 bits per component
* 1555x633 Pixel, 3 colors/components, 24 bits per component
(all encoded with gimp, which uses optimum prediction and thus uses
different predictors; in fact all but row_up, which is the only one I
didn't change because it works already on corresponding pixels)

Please merge the patch.

Regards,
Georg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7FVKYACgkQ5sLITM1qIaJ3jwCgo351nvJaWEvtKuC782bHrEzq
BXAAn3R2b1Namk7xYcbUzn/MAh50wZbi
=EfUg
-----END PGP SIGNATURE-----

Attachment: pdf-stm-f-pred-v2.patch
Description: Text Data


reply via email to

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