[
https://issues.apache.org/jira/browse/PDFBOX-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888229#comment-13888229
]
Tilman Hausherr commented on PDFBOX-1870:
-----------------------------------------
Tricky. The two functions I'd suspect first (calculation of the index, and
interpolation) seem to work like I expect. One mystery is that in the PDF file,
the samples stream is very long and has lots of different characters, but when
read only the first 24 entries are set, the rest is empty.
Btw two colors (the first two) are correct in the "after" rendering. They are
at position 3 and 12. I'll make a test with a different way of reading the
stream to see if there's a difference.
> 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: Devicen3.after.jpg, Devicen3.before.jpg, Devicen3.pdf,
> 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)
