[
https://issues.apache.org/jira/browse/PDFBOX-6260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18117809#comment-18117809
]
valery commented on PDFBOX-6260:
--------------------------------
With the current algorithm, the colors are very close to what Adobe displays.
The test was conducted as follows: the file was opened in MS Edge, which uses
an Adobe Acrobat-based PDF viewer engine; a screenshot was taken, and the image
colors were analyzed.
Method: I generated a PDF (attached: CalGrayPatches.pdf) with 6 CalGray color
spaces and flat patches for the values 0.0, 0.1 ... 1.0. I opened it in Edge,
took a screenshot, and read the middle of every patch. We compared that with
PDFBox (trunk with PDFBOX-6260, i.e. r1938392) and with the code before it.
Rows (whitepoint/gamma):
A: 0.46409 1 0.42501 / 1.73225 (the space of CalGray.pdf from the Ghostscript
bug)
B: D65 / 2.2 C: D65 / 1.0 D: D50 / 1.0
E: 1 1 1 / 1.0 F: 1 1 1 / 2.2
Gray value (0-255) for the input 0.0, 0.1 ... 1.0:
A Adobe 0 36 70 98 124 149 172 193 214 235 254
trunk 0 37 70 99 125 149 172 194 215 235 255
before 0 26 51 77 102 128 153 179 204 230 255
C Adobe 0 89 123 148 169 187 203 217 231 243 254
trunk 0 89 124 149 170 188 203 218 231 243 255
before 0 26 51 77 102 128 153 179 204 230 255
B and F (gamma 2.2): Adobe 0 18 47 75 102 128 154 179 205 230 254,
trunk 0 19 48 75 102 128 154 180 205 230 255
Across all 66 patches, the current trunk differs from Adobe by an average of
0.48, with a maximum difference of 1. The code prior to the change showed an
average difference of 16.5 and a maximum of 72 (rows A–D: the white point was
not [1, 1, 1], so the gamma was ignored). In Adobe, all patches are neutral
gray, and the result depends solely on the gamma, not the white point: C, D,
and E are identical, as are B and F. This is the behavior PDFBox now exhibits
following chromatic adaptation and white point scaling.
I then considered the possibility that Java might be rounding color values
during mathematical calculations. Claude analyzed the data and reached the
opposite conclusion: that the Adobe engine truncates colors. I applied changes
locally based on Claude's hypothesis, but the result was worse, with a 56%
mismatch in white pixels. The issue was resolved through scaling; I scaled all
channels by 65534/65535 to replicate the 16-bit artifact found in Adobe.
It should be noted that I used a screenshot from Edge rather than the Adobe
Acrobat application itself; therefore, my conclusions regarding the colors may
not be entirely accurate.
This is a screenshot of a table comparing the accuracy of the current code
version against the code implementing the color value rounding algorithm:
!screenshot-1.png!
> CalRGB color regression
> -----------------------
>
> Key: PDFBOX-6260
> URL: https://issues.apache.org/jira/browse/PDFBOX-6260
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
> Affects Versions: 2.0.37, 3.0.8 PDFBox
> Reporter: Tilman Hausherr
> Assignee: Tilman Hausherr
> Priority: Minor
> Labels: CalRGB
> Fix For: 2.0.38, 3.0.9 PDFBox, 4.0.0
>
> Attachments: PDCIEDictionaryBasedColorSpace.java, PDCalGray.java,
> PDCalGrayTest.java, gs-bugzilla686749-CalRGB-reduced.pdf, screenshot-1.png
>
>
> This is about this "unrealistic" CalRGB file of this GS issue
> https://bugs.ghostscript.com/show_bug.cgi?id=686749
> Rendering has different colors since PDFBOX-5079.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
