Bug 690535 - Images rendered in wrong color and badly
Summary: Images rendered in wrong color and badly
Status: NOTIFIED DUPLICATE of bug 691157
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Color (show other bugs)
Version: master
Hardware: Macintosh MacOS X
: P2 normal
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-11 17:15 UTC by Marcos H. Woehrmann
Modified: 2011-10-02 02:35 UTC (History)
1 user (show)

See Also:
Customer: 190
Word Size: ---


Attachments
ghostscript.png (41.49 KB, image/png)
2009-06-11 17:17 UTC, Marcos H. Woehrmann
Details
acrobat.png (103.56 KB, image/png)
2009-06-11 17:17 UTC, Marcos H. Woehrmann
Details
bug690535_simple2.pdf (428.70 KB, application/pdf)
2009-06-19 23:37 UTC, Michael Vrhel
Details
screenshot.png (223.70 KB, image/png)
2010-07-19 02:25 UTC, Marcos H. Woehrmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2009-06-11 17:15:18 UTC
The customer reports and I've verified that Ghostscript renders the attached PDF file differently than 
Adobe Acrobat 9 Pro.  In specular reflection are missing and the Euro symbol is rendered in black instead 
of orange (this is with gshead (r9788), with gs8.64 all of the text is rendered in black).

The command line I'm using for testing:

  bin/gs -sDEVICE=png16m -o test.png -r300 ./BANDOS_d.png
Comment 1 Marcos H. Woehrmann 2009-06-11 17:16:29 UTC
Created attachment 5092 [details]
BANDOS_d.pdf
Comment 2 Marcos H. Woehrmann 2009-06-11 17:17:21 UTC
Created attachment 5093 [details]
ghostscript.png

Ghostscript head (r9788) generated PNG file.
Comment 3 Marcos H. Woehrmann 2009-06-11 17:17:44 UTC
Created attachment 5094 [details]
acrobat.png

Acrobat 9 Pro generated PNG file.
Comment 4 Michael Vrhel 2009-06-14 18:23:58 UTC
Wow.  For such a simple file, there are a lot of groups created in this.  I 
have it partly narrowed down.  I suspect I will have a fix for this somewhat 
soon for head. 
Comment 5 Michael Vrhel 2009-06-15 19:29:24 UTC
Created attachment 5113 [details]
bug690535_simple.pdf

A simplified file that narrows down the problem.
Comment 6 Michael Vrhel 2009-06-15 19:41:01 UTC
Looking for another set of eyes on this one, perhaps Ray or Ken.  The issue is 
in object 20.

What I don't understand is why with AR the Euro text is not blown away by the 
cyan fill that follows the BT ET object.  Perhaps there is some aspect of 
pattern filling of text that I don't understand with respect to the graphic 
state.

If I remove the /GS2 gs line, then the Euro is blown away with AR.  

20 0 obj
<</Resources<</Font<</C0_0 150 0 R>>/ExtGState<</GS0 123 0 R/GS2 151 0 
R>>/ColorSpace<</CS0 66 0 R>>/ProcSet[/PDF/Text]/Pattern<</P0 153 0 
R>>>>/Group 154 0 R/Subtype/Form/Length 245/Matrix[1 0 0 1 0 0]/BBox[254.543 
100.582 317.007 68.3555]>>
stream
BT
/CS0 cs /P0 scn
/GS0 gs
/C0_0 1 Tf
0 Tc 0 Tw 0  Ts 100  Tz 0 Tr 41.3808 1.8067 -1.8067 41.3808 256.1508 69.1966 Tm
<0025>Tj
ET
1.0 0.0 0.0 0 k
/GS2 gs
q 1 0 0 1 254.3709 98.0692 cm
0 0 m
30.353 1.325 l
31.664 -28.698 l
1.311 -30.023 l
h
f
Q

endstream
endobj
Comment 7 Ken Sharp 2009-06-16 01:05:30 UTC
> What I don't understand is why with AR the Euro text is not blown away by the 
> cyan fill that follows the BT ET object.  Perhaps there is some aspect of 
> pattern filling of text that I don't understand with respect to the graphic 
> state.

The job isn't using a pattern at this point, the '1.0 0.0 0.0 0 k' changes the
colour space to DeviceCMYK for the rectangle.

> If I remove the /GS2 gs line, then the Euro is blown away with AR.  

GS2 is object 151, which is an ExtGState:

151 0 obj
<</AIS true/BM/Multiply/OP false/ca 1/SA true/SMask/None/op
false/Type/ExtGState/OPM 1/CA 1>>
endobj

Note that AIS is true, so 'Alpha is Shape', not opacity. Since the SMask entry
is None this means that (p550 of the 1.7 reference) the mask shape 'is
implicitly 1 everywhere'. I've never been entirely sure what the point of that
is....

Anyway, the ExtGState also specifies a 'Multiply' blending mode, which is pretty
much what I see when I open the file with Acrobat. If you remove the ExtGState,
then you remove the blending mode, thereby removing the transparency and causing
the cyan rectangle to obscure the Euro. I guess they are using this to 'darken'
the colour of the Euro, If I remember correctly its drawn with *numerous* layers.

I can get the same obscuring effect by removing the /BM/Multiply from the ExtGState.

The Ghostscript output looks like it simply isn't honouring the Blending Mode
from the ExtGState.
Comment 8 Michael Vrhel 2009-06-16 08:03:36 UTC
Ken,  Thank you.   The multiply blend mode has to be the issue.  I will dig 
into that.  
Comment 9 Michael Vrhel 2009-06-17 08:56:16 UTC
Created attachment 5119 [details]
bug_690535_simple.pdf

A better example of the problem.  Basically, the initial graphic state has a
soft mask which has a text shape drawn in it (the Euro symbol).  We then run
the form which sets a graphic state without a soft mask and draws the Euro text
with a CMYK redish fill.  We then set a new graphic state that includes an
image softmask and then draw a solid rectangle fill with a black CMYK black
fill.  This last fill should have occured through the image soft mask, but it
does not occur through it for some reason and so we end up with black where we
should have had a reddish text.
Comment 10 Michael Vrhel 2009-06-18 10:59:13 UTC
Found the problem with this one.  There is a softmask that does not intersect 
with the parent transparency group.  This makes the rect empty for the 
softmask and the buffer that would hold the softmask is never allocated and so 
it is NULL.  When the group is eventually popped, the softmask entry is NULL 
which is taken to mean that there is NO softmask.  In fact what should occur 
is that the areas outside of the softmask should be treated with a mask that 
is given by the luminosity of the BC entry (background color) of the softmask.
If there is no BC entry (it is optional) then black is used as the default 
which means Nothing in the group should be drawn.  This is what should occur 
to the drawing of the black euro letter. We should be using the BC of the 
softmask which is 0 since the intesection is 0.  Looking at the current code, 
it appears that the background color is not used.  Instead an entry 
GrayBackground is used to set the background alpha of the mask. I don't 
understand where exactly GrayBackground would come from in the PDF content.  
It is not specified in PDF1.7 but I see it being referred to in pdf_draw.ps 
around line 406. In the current code, this alpha value is assigned to the 
mask's alpha value, and during pdf14_compose_group it is assigned to the 
mask_bg_alpha which is NOT used.  There are two things we need to do. First is 
we need to make sure we get the proper background value which should be 
computed using the luminosity calculation.  The second thing is that if the 
mask_buffer is not null and we are outside of the mask_buffer pointer in our 
rendering during pdf14_compose_group we should use the background value as the 
alpha value.
Comment 11 Michael Vrhel 2009-06-19 23:10:42 UTC
So, I have a fix for the black overwriting, which was caused by the fact that 
the softmask did not intersect with the transparency group.  However, I now 
see that the issue is that the softmask SHOULD be intersecting with the group, 
since that is what is giving us the nice highlight look on the text.  Note 
that in the ghostscript.png file given above, the highlights on the text are 
missing.  These highlights are created by the softmask.  So, I need to figure 
out why the geometry of the mask rect is not correct.
Comment 12 Michael Vrhel 2009-06-19 23:37:01 UTC
Created attachment 5130 [details]
bug690535_simple2.pdf

So this file shows the problem of the missing softmask.  The second softmask
push is the one that fails.  First softmask is the outline of the euro symbol.
Second soft mask is the highlight image.
Comment 13 Masaki Ushizaka 2009-08-13 23:15:55 UTC
Reproduced with r9980 on Mac OS X.
Also wanted to add, Acrobat 6 rendered BANDOS_d.pdf (with version warning) very similarly to gs except 
black Euro sign.
Comment 14 Michael Vrhel 2009-09-09 15:18:42 UTC
Black Euro is fixed with rev 10063
Comment 15 Marcos H. Woehrmann 2010-07-19 02:25:14 UTC
Created attachment 6509 [details]
screenshot.png

I've reopened this bug since r10063 only partially resolved this bug.  The black euro symbol was fixed by that revision, but the output image is still missing its highlights (see attached screenshot comparing head, r11519, to Acrobat 9.3.3).

The command line used to generate head.tiff:

  bin/gs -sDEVICE=tiff24nc -o head.tiff -r300 ./BANDOS_d.pdf
Comment 16 Chris Liddell (chrisl) 2010-11-24 18:36:59 UTC

*** This bug has been marked as a duplicate of bug 691157 ***