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?
You should attach the source PDF file here as well.
Created attachment 14441 [details] input pdf, simple black rectangle The input file, which I tried to convert to cmyk using icc profile.
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.
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?
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?
(In reply to richard.hartware from comment #4) > 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) > 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.
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?
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.