Bug 692378 - Differences in tiffsep output
Summary: Differences in tiffsep output
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Color (show other bugs)
Version: master
Hardware: PC All
: P2 normal
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-27 07:49 UTC by Marcos H. Woehrmann
Modified: 2011-10-02 02:26 UTC (History)
1 user (show)

See Also:
Customer: 393
Word Size: ---


Attachments
simplified example (25.08 KB, application/pdf)
2011-08-26 15:24 UTC, Ken Sharp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2011-07-27 07:49:23 UTC
As can be seen in the attached screenshot.png our output for the cutter separation differs from the one produced by Adobe Illustrator; Ghostscript renders the bottom two blocks gray instead of black (ignoring the fact that the cutter layer is red in Illustrator).

Note that this is with Ghostscript head (68a0f6217428daf297d73589821b62ba2e862d0f), earlier versions of Ghostscript generate entirely incorrect output.

The command line I'm using for testing:

  bin/gs -sDEVICE=tiffsep -o test -r300 ./RBR1101382.pdf

Note that the cutter file is test.s4.tif.

Also, the test.s1.tif, test.s2.tif, and test.s3.tif separations are also wrong in the same way, but the test.s0.tif file is correct.
Comment 3 Alex Cherepanov 2011-07-28 04:57:35 UTC
Yes, this is a bug in Ghostscript.
I changed all "1 scn" and "1 SCN" operators to "0 scn" and "0 SCN" and
partly shaded objects have disappeared. This cannot be right.

Apparently, /Separation/All color inherits some of tint values from specific
separations, drawn earlier.
Comment 4 Michael Vrhel 2011-08-09 03:00:56 UTC
I stepped through the logic used when we have an All separation color and it seems to be working correctly.   Need to simplify this file to narrow down the issue.
Comment 5 Michael Vrhel 2011-08-09 16:10:27 UTC
It appears that the set color is getting messed up at some point.  The tint values to the right of springfield solutions seem to be inherited from that path of text and the star like drawing above it.    Since the c code is handling the all filling with a sep color space correctly I am passing to alexcher to take a look to make sure set color is working properly.
Comment 6 Ken Sharp 2011-08-26 15:24:30 UTC
Created attachment 7838 [details]
simplified example

Much simplified example file. The 'FILE No.' at bottom left should be black and is rendered in a shade of gray. Note that there is no text in this file, the text has all been converted to outlines.
Comment 7 Ken Sharp 2011-08-27 08:45:40 UTC
Assigning back to Michael as this does seem to me to be a colour problem. 

Using the attached simplified example, I set a break point in zfill(). 

On the first occurrence (the grey star shape) I followed the code into gx_set_dev_color and then into gx_remap_Separation. I see that the separation colour (the parameter pcc) is 0.2, as expected.

On the second occurence (the 'text') I again followed the code into gx_set_dev_color and into gx_remap_Separation. In this case I see that the separation colour value is 1.0, again as expected.

So the PDF interpreter seems to be working correctly. As a further clue that its not the interpreter, two of the spot separations show the 'text' in gray, but one of them shows it as 100% black, as do the 4 CMYK plates. There is no way that this should happen for /All separations.

I'm afraid I don't know enough about the colour code to understand how one of the separation plates is getting the wrong colour. I hope it's something simple.
Comment 8 Ken Sharp 2011-09-14 08:57:00 UTC
Like bug #692494 the display device correctly shows the output, so it does seem to be a problem specific to the tiffsep device, and it may well be the asme problem in both cases.
Comment 9 Michael Vrhel 2011-09-27 05:56:08 UTC
I have made a bit of progress in tracking this one down.  Thanks to Ken for making the simplified example!  What occurs is that we do properly correctly convert /All such that the fill would occur across all the colorants.  However, we encode the color during the remap with a compressed color encoding (using tiffsep_encode_compressed_color).  Later during the mem_true64_fill_rectangle we take the compressed color encoding and rather than perform a compressed color decode, we simply unpack it as if it were not compressed.  This is clearly wrong.  Will chat a bit with everyone on this topic after the Tuesday meeting.
Comment 10 Ray Johnston 2011-09-27 17:02:45 UTC
As discussed on the phone just now, the mem64 device just fills a rectangle
with whatever 64-bits are in the gx_color_index -- never attempts to determine
what colorants are what.

It is in the tiffsep_print_page that "devn_unpack_row" is used to turn the
compressed color back into the individual components.
Comment 11 Michael Vrhel 2011-09-27 17:32:05 UTC
Right.  It appears that the devn_unpack_row may be the culprit.  Tracking that down now.