[Top][All Lists]
[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-----
pdf-stm-f-pred-v2.patch
Description: Text Data