[
https://issues.apache.org/jira/browse/PDFBOX-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888124#comment-13888124
]
John Hewson edited comment on PDFBOX-1870 at 1/31/14 8:26 PM:
--------------------------------------------------------------
The before and after images correspond to trunk {{r1563199}} and {{r1563210}}
respectively, so the problem has to be in {{PDFunctionType0.java}}.
EDIT: you can see the diff at http://git.io/at3nUg
was (Author: jahewson):
The before and after images correspond to trunk {{r1563199}} and {{r1563210}}
respectively, so the problem has to be in {{PDFunctionType0.java}}.
> PDFunctionType0 incorrect
> -------------------------
>
> Key: PDFBOX-1870
> URL: https://issues.apache.org/jira/browse/PDFBOX-1870
> Project: PDFBox
> Issue Type: Sub-task
> Components: PDModel
> Affects Versions: 2.0.0
> Reporter: Tilman Hausherr
> Priority: Minor
> Attachments: PDFunctionType0.patch, technical_v2_p9.before.jpg,
> technical_v2_p9.before.pdf, technical_v2_p91.after.jpg
>
>
> Type 0 (Sampled) Functions are described in 3.9.1 of the pdf spec and
> basically, its cheating: there's an n-dimensional grid of values ("samples")
> and the function shall return these values or something in-between.
> PDFunctionType0 has two bugs:
> 1) it does not do any interpolation. The function interpolate() is called
> several times, but only adjust values between ranges etc, not to calculate
> the color between 2^n samples - that part is "outputValues[i] =
> (outputValuesPrevious[i] + outputValuesNext[i]) / 2". The spec does not tell
> much, only that "Interpolation is used to determine output values from the
> nearest surrounding values in the sample table". I have done a
> linear/bilinear interpolation implementation for 1D/2D inputs. I did not do
> an interpolation implementation for 3D and higher, because its unclear
> whether this is actually used. Instead, I return random (!) values.
> 2) the sample bits are not collected correctly, the current code ignores the
> leftover bits when a row is done. The spec tells us "Successive values are
> adjacent in the bit stream; there is no padding at byte boundaries". Luckily,
> that one is easy to correct, three lines must be moved up. Alternatively, one
> might use the bit-io lib I mention in PDFBOX-615.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
