Unpaper or its underlying libraries don't seem to accept pnms with an
odd integer width. Although it's not clear if this is the issue at all.
In any case, keeping the image a PNG works around the issue. unpaper
only accepted PNM input in the past, which is why we send it PNM.
Since it now accepts PNG, we might as well use PNG.
Unpaper can write PNG as output too, but this added a few seconds to
the test suite was not committed.
Related issues:
https://github.com/ocrmypdf/OCRmyPDF/issues/887https://github.com/ocrmypdf/OCRmyPDF/issues/665https://github.com/unpaper/unpaper/issues/82
Fixes#974 when used in conjunction with Python 3.10.
Reviewed other uses of TemporaryDirectory in ocrmypdf and decided it
was not worth fixing them since neither are exactly production code.
Specifying option --oversample tends to introduce upsampling in rendering
by rasterizing page to an higher DPI.
This upsampling improves OCR results, but a correct choice of interpolation
method can increase even more the OCR quality.
Ghostscript seems to use a nearest interpolation as default choice for pdf.
This method doesn't average new introduced pixels with original pixels
resulting in an almost similar image but with more pixels.
Providing -dInterpolateControl=-1 force switching interpolation on.
In this commit the above option is passed to all ghostscript rendering
calls.
After testing, rendering a page at same DPI with interpolation
enabled does not introduce significant time overhead.
time (repeat 40 gs -dQUIET -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m \
-dFirstPage=1 -dLastPage=1 -r100.000000x100.000000 \
-dInterpolateControl=-1 -o /dev/null -dAutoRotatePages=/None -f pzII.pdf)
7,66s user 0,33s system 99% cpu 8,012 total
time (repeat 40 gs -dQUIET -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m \
-dFirstPage=1 -dLastPage=1 -r100.000000x100.000000 \
-o /dev/null -dAutoRotatePages=/None -f pzII.pdf)
7,42s user 0,39s system 99% cpu 7,808 total
Ghostscript interpolation control reference:
https://www.ghostscript.com/doc/current/Use.htm