[gs-bugs] [Bug 698723] - Ghostscript - convert rgb pdf to cmyk with icc profile yields wrong black

[b***@artifex.com]

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

Bug ID: 698723
Summary: convert rgb pdf to cmyk with icc profile yields wrong
black
Product: Ghostscript
Version: unspecified
Hardware: PC
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P4
Component: Color
Assignee: ***@artifex.com
Reporter: ***@googlemail.com
QA Contact: gs-***@ghostscript.com
Word Size: ---

I'm trying to convert an RGB-pdf to an CMYK-pdf using PSOcoated_v3.icc as
outputProfile (see
https://stackoverflow.com/questions/46819584/ghostscript-cmyk-black-value-in-pdf).
When using ghostscript to write a PDF file the black looks washed out so I
decided to dig into the PDF file and grab the cmyk color value.

The situation is as follows: I start with an RGB-pdf exported from Inkscape
which is simply a black rectangle filling up the entire page; lets name that
file black.pdf. Now I convert the pdf via

gs -dBATCH -dNOPAUSE -dNOCACHE \
-sDEVICE=pdfwrite \
-sProcessColorModel=DeviceCMYK \
-sColorConversionStrategy=CMYK \
-sOutputICCProfile=PSOcoated_v3.icc \
-sDefaultRGBProfile=sRGB2014.icc \
-dOverrideICC=true \
-dRenderIntent=1 \
-sOutputFile=black.cmyk.pdf\
black.pdf

and examine the content of the resulting pdf. The print commands for the
rectangle look different whether I use gs9.20 from the debian repository or
gs9.22 binary from ghostscript website.

in case of version 9.20 I get

q 0.1 0 0 0.1 0 0 cm
/R7 gs
0.722 0.675 0.671 0.882 k
0 0.0195313 10902.9 7748.55 re
f
Q

and for version 9.22

q 0.1 0 0 0.1 0 0 cm
/R7 gs
1 1 1 0 k
0 0.0195313 10902.9 7748.55 re
f
Q

In both cases the cmyk-black value is different from [0.83, 0.67, 0.51, 0.95]
which I would expect using the PSOcoated_v3 profile and relative colorimetric
intent.

Simply changing to sDevice=tiff32nc yields the expected cmyk representation for
black.

Any ideas?

[b***@artifex.com]

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

--- Comment #1 from Ken Sharp <***@artifex.com> ---
You should attach the source PDF file here as well.

[b***@artifex.com]

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

--- Comment #2 from ***@googlemail.com ---
Created attachment 14441
--> http://bugs.ghostscript.com/attachment.cgi?id=14441&action=edit
input pdf, simple black rectangle

The input file, which I tried to convert to cmyk using icc profile.

[b***@artifex.com]

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

Michael Vrhel <***@artifex.com> changed:

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

--- Comment #3 from Michael Vrhel <***@artifex.com> ---
I looked through this. The source document has an DeviceRGB fill. The way
pdfwrite is currently designed, DeviceGray, DeviceRGB, and DeviceCMYK fills
always do the PostScript color conversion methods. If the source color space
is ICC based, then the ICC based methods will be used.

Two possibilities.

1) Make sure your source documents have all color spaces defined in terms of
ICC profiles. Example, convert them to a PDF-A type document. Then do the
conversion you want to do.


2) Check with Ken about the possibility of adding an option to honor the ICC
profiles defined for DeviceGray, DeviceRGB and DeviceCMYK in the color
conversion strategy. Likely this could be done with a change in
pdf_reset_color where csi2 is determined, forcing the conversion through the
ICC remapping methods.

Assigning to Ken to see what he wants to do.

[b***@artifex.com]

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

--- Comment #4 from ***@googlemail.com ---
Thanks for the replay. I will check out the first proposal soon.

However, to understand things better. What is meant by "The way pdfwrite is
currently designed, DeviceGray, DeviceRGB, and DeviceCMYK fills always do the
PostScript color conversion methods."?

Second, I forgot to mention, that about a year ago I did the same thing and
things worked out. I just examined the cmyk pdf which have the correct rich
black for the black graphic element. Since then I updated my system and things
are screwed up. Unfortunately I do not recall the gs version. Any ideas on
that?

[b***@artifex.com]

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

--- Comment #5 from ***@googlemail.com ---
I have tried to create a PDFA using

gs -dBATCH -dNOPAUSE -dNOOUTERSAVE \
-sDEVICE=pdfwrite \
-dPDFA \
-sColorConversionStrategy=RGB \
-sOutputICCProfile=sRGB2014.icc \
-sOutputFile=black_pdfa.pdf \
my_PDFA_def.ps \
black.pdf

with my_PDFA_def.ps

/ICCProfile (sRGB2014.icc) % Customise
def

[ /Title (black) % Customise
/DOCINFO pdfmark

% Define an ICC profile :

[/_objdef {icc_PDFA} /type /stream /OBJ pdfmark
[{icc_PDFA}
<<
/N currentpagedevice /ProcessColorModel known {
currentpagedevice /ProcessColorModel get dup /DeviceGray eq
{pop 1} {
/DeviceRGB eq
{3}{4} ifelse
} ifelse
} {
(ERROR, unable to determine ProcessColorModel) == flush
} ifelse

/PUT pdfmark

[{icc_PDFA} ICCProfile (r) file /PUT pdfmark

% Define the output intent dictionary :

[/_objdef {OutputIntent_PDFA} /type /dict /OBJ pdfmark
[{OutputIntent_PDFA} <<
/Type /OutputIntent % Must be so (the standard requires).
/S /GTS_PDFA1 % Must be so (the standard requires).
/DestOutputProfile {icc_PDFA} % Must be so (see above).
/OutputConditionIdentifier (sRGB) % Customize

/PUT pdfmark

[{Catalog} <</OutputIntents [ {OutputIntent_PDFA} ]>> /PUT pdfmark


When I convert the resulting black_pdfa.pdf to cmyk I get the same (unexpected)
rich black composition: 0.722 0.675 0.671 0.882 k

I guess it is not working, or am I doing something wrong?

[b***@artifex.com]

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

Ken Sharp <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement

--- Comment #6 from Ken Sharp <***@artifex.com> ---
(In reply to richard.hartware from comment #4)

Post by b***@artifex.com
Second, I forgot to mention, that about a year ago I did the same thing and
things worked out. I just examined the cmyk pdf which have the correct rich
black for the black graphic element. Since then I updated my system and
things are screwed up. Unfortunately I do not recall the gs version. Any
ideas on that?

No, not really. You can use Git to bisect the code and find out which commit
caused the change. I don't recall changing anything relevant recently.

(In reply to richard.hartware from comment #5)

Post by b***@artifex.com
I have tried to create a PDFA using
gs -dBATCH -dNOPAUSE -dNOOUTERSAVE \
-sDEVICE=pdfwrite \
-dPDFA \
-sColorConversionStrategy=RGB \
-sOutputICCProfile=sRGB2014.icc \
-sOutputFile=black_pdfa.pdf \
my_PDFA_def.ps \
black.pdf

You are still converting to RGB, NOT to ICCBased, which is what Michael
suggested.

You would need to set ColorConversionStrategy to DeviceIndependentColor. It
need not be a PDF/A file, and PDF/A need not contain colours purely defined in
ICCBased space.

I'm uncertain without looking into the code how this would work out using
pdfwrite anyway. I strongly suspect that you can't use pdfwrite to do this,
because if you could, you wouldn't need to, the RGB conversion would work.

[b***@artifex.com]

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

--- Comment #7 from ***@googlemail.com ---
ok, thanks so far.

Then the overall question remains: How do I convert my RGB pdf to an cmyk pdf
ready for offset printing, preferably with the PSOcoated_v3 icc profile?

[b***@artifex.com]

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

Ken Sharp <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED

--- Comment #8 from Ken Sharp <***@artifex.com> ---
I believe that commit 775e9d28f78b4b0b5b41a24f4c9fc7f19a9326e3 and
5c851a410c3469860a171420240eb92331dcda9e resolve this.

You probably only need commit 5c851 but its best to have both.

For me the CMYK components in the output PDF file are the same as those in a
TIFF file produced using -sDEVICE=tiff32nc. I do believe there is more work to
be done in this area, so if you find any more oddities please open new bug
reports.