[gs-bugs] [Bug 698828] - Ghostscript - Solid gray pattern in cairo's pdf output is interpreted differently by ghostscript depending on whether an intermediate pattern is explicitly used

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698828

Bug ID: 698828
Summary: Solid gray pattern in cairo's pdf output is
interpreted differently by ghostscript depending on
whether an intermediate pattern is explicitly used
Product: Ghostscript
Version: 9.22
Hardware: PC
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P4
Component: Color
Assignee: ***@artifex.com
Reporter: ***@gmail.com
QA Contact: gs-***@ghostscript.com
Word Size: ---

Consider the following pycairo example

from cairo import *

surf = PDFSurface("/tmp/test1.pdf", 5, 5)
cr = Context(surf)
cr.rectangle(0, 0, 5, 5)
cr.set_source_rgba(.5, .5, .5, 1)
cr.fill()

pat_surf = ImageSurface(Format.ARGB32, 5, 5)
cr = Context(pat_surf)
cr.rectangle(0, 0, 5, 5)
cr.set_source_rgba(.5, .5, .5, 1)
cr.fill()
pat = SurfacePattern(pat_surf)
surf = PDFSurface("/tmp/test2.pdf", 5, 5)
cr = Context(surf)
cr.set_source(pat)
cr.paint()

In the first case, I directly write a solid 50% gray pattern to a pdf file. In
the second case, I explicitly create a SurfacePattern with the same gray
filling and transfer it to the pdf file.

Let's rasterize the resulting pdfs with ghostscript and query the results,
using (for example) matplotlib's imread (any other png binding would work):

python /tmp/test.py
for f in test1 test2; do
gs -q -sDEVICE=png16m -dNOPAUSE -dBATCH -sOutputFile=/tmp/$f.png
/tmp/$f.pdf
python -c "from pylab import *; print(imread('/tmp/$f.png'))"
done

This shows that the first image (direct write) is rasterized to a gray value of
0.498, which is reasonable (=127/255). The second image, however, is
rasterized to a gray value of 0.573 (in fact, likely 146/255).

**I believe that this is a bug in ghostscript and not in cairo because mupdf
does not show the same discrepancy.**

The pdfs are available at
https://filebin.ca/3lQRS1OTGuax/test1.pdf
and
https://filebin.ca/3lQRqNHQqcoF/test2.pdf
(not added as attachments as unless I'm mistaken I can only attach *one* file).

Relevant software versions: cairo 1.15.8, ghostscript 9.22, Arch Linux.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698828

--- Comment #1 from Ken Sharp <***@artifex.com> ---
(In reply to Antony Lee from comment #0)

Post by b***@artifex.com
This shows that the first image (direct write) is rasterized to a gray value
of 0.498, which is reasonable (=127/255). The second image, however, is
rasterized to a gray value of 0.573 (in fact, likely 146/255).
**I believe that this is a bug in ghostscript and not in cairo because mupdf
does not show the same discrepancy.**

Depends, at least in part, on which version of MuPDF you are using. Only the
most recent version of MuPDF includes an ICC colour workflow.

Clearly the PDF files have been created with different colour specifications
(or there would be no difference). If, for example, one is created as a R=G=B
in RGB colour space, while the other is created as an ICCBased 3-component
space where all components are equal, old versions of MuPDF will treat the
3-component space as RGB (ignoring the ICC profile) and produce the same RGB
colour as the RGB case. Ghostscript, and MuPDF, 1.12 will however read and use
the ICC profile which may well result in different output.

Post by b***@artifex.com
The pdfs are available at
https://filebin.ca/3lQRS1OTGuax/test1.pdf
and
https://filebin.ca/3lQRqNHQqcoF/test2.pdf
(not added as attachments as unless I'm mistaken I can only attach *one* file).

Please attach relevant files here. It can be some time before anyone can get to
look at problems and URLs often go stale before then, making it impossible to
investigate the problem.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698828

--- Comment #2 from Antony Lee <***@gmail.com> ---
Created attachment 14546
--> http://bugs.ghostscript.com/attachment.cgi?id=14546&action=edit
Direct write of solid 50% gray.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698828

--- Comment #3 from Antony Lee <***@gmail.com> ---
Created attachment 14547
--> http://bugs.ghostscript.com/attachment.cgi?id=14547&action=edit
Write of solid 50% gray via explicit pattern.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698828

--- Comment #4 from Antony Lee <***@gmail.com> ---
Attached relevant files.
The mupdf version was indeed 1.12.0.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698828

James Cloos <***@jhcloos.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@jhcloos.com

--- Comment #5 from James Cloos <***@jhcloos.com> ---
If you look at those two files after running them thru mupdfcloen -d -a,
you see that the first has:

4 0 obj
<<
/Length 55
stream
1 0 0 -1 0 5 cm
q
0.5 0.5 0.5 rg /a0 gs
0 0 5 5 re f
Q
endstream
endobj

whereas the 2nd has:

6 0 obj
<<
/Length 52
/BitsPerComponent 8
/Type /XObject
/Subtype /Image
/Width 5
/Height 5
/ColorSpace /DeviceGray
/Interpolate true
/Filter /ASCIIHexDecode
stream
80808080808080808080808080808080808080808080808080>
endstream
endobj

So this is a vector art with rgb 0.5/0.5/0.5 vs pixmap with gray 0x80 issue.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698828

Robin Watts <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@artifex.com

--- Comment #6 from Robin Watts <***@artifex.com> ---
(In reply to James Cloos from comment #5)

Post by b***@artifex.com
So this is a vector art with rgb 0.5/0.5/0.5 vs pixmap with gray 0x80 issue.

Indeed, and 0x80/0xff = 0.502 not 0.50

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698828

--- Comment #7 from Robin Watts <***@artifex.com> ---
(In reply to Robin Watts from comment #6)

Post by b***@artifex.com
(In reply to James Cloos from comment #5)

Post by b***@artifex.com
So this is a vector art with rgb 0.5/0.5/0.5 vs pixmap with gray 0x80 issue.

Indeed, and 0x80/0xff = 0.502 not 0.50

That was badly expressed. I meant to say that even if we changed the vector
example to use gray 0.5, it may not exactly match.

I'll attach a corrected example now. Do you still see the problem with it?

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698828

--- Comment #8 from Robin Watts <***@artifex.com> ---
Created attachment 14548
--> http://bugs.ghostscript.com/attachment.cgi?id=14548&action=edit
test1-gray-50.pdf

Corrected example to use gray colorspace.