You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Tilman Hausherr (Jira)" <ji...@apache.org> on 2020/05/12 17:36:00 UTC

[jira] [Commented] (PDFBOX-4831) Rounding errors when rendering non-interleaved binary CCITT image at 1:1 scale cause gray pixels in output

    [ https://issues.apache.org/jira/browse/PDFBOX-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17105628#comment-17105628 ] 

Tilman Hausherr commented on PDFBOX-4831:
-----------------------------------------

Could you please tell which "slow path" you mean? Please try also the latest changes (which may make some of the renderings even slower)
https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox-app/2.0.20-SNAPSHOT/

> Rounding errors when rendering non-interleaved binary CCITT image at 1:1 scale cause gray pixels in output
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: PDFBOX-4831
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-4831
>             Project: PDFBox
>          Issue Type: Bug
>          Components: Rendering
>    Affects Versions: 2.0.19
>            Reporter: Gábor Stefanik
>            Priority: Major
>         Attachments: 13._Korona_szallo_vegzes_13.09.26.eredeti.pdf
>
>
> I have a 300dpi scanned PDF file with a single CCITT-encoded black-and-white image in each page, spanning the whole page. The images all have a resolution of 2480x3504.
>  
> When I try to render a page from this PDF into a PNG at 300DPI, the resulting PNG has some pixels with colors #010101 and #fefefe. The PNG has the same 2480x3504 dimensions as the embedded CCITT images, but stepping through the PDFBox code reveals it's trying to downscale the image by a tiny fraction of a pixel (e.g. to 2479.999964573x3503.9999537378) using bicubic interpolation, introducing these "near-black" and "near-white" pixels due to rounding errors. Additionally, the actual image conversion code goes to a slow path intended for "proper" interpolated scaling, rather than hitting the fast path for copying 1:1-scale images.
>  
> For now, we worked around this by treating images containing only #000000, #010101, #fefefe and #ffffff as binary, but the performance hit from the slow path is still there.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org