I'm trying to convert an RGB-pdf file created by Inkscape to a print ready cmyk-pdf using PSOcoated_v3.icc color profile. PDF generation works fine. However, I'd like to check for correct final colors, especially for the black. As I did not found any (free) tool to pick the cmyk color from the final pdf I thought as a first check I convert the RGB-pdf to cmyk-tiff and check the black value. Doing so using
gs -q -dBATCH -dSAFER -dNOPAUSE \
-sDEVICE=tiff32nc \
-sDefaultRGBProfile=sRGB2014.icc \
-dOverrideICC \
-sOutputICCProfile=PSOcoated_v3.icc \
-sProcessColorModel=DeviceCMYK \
-sColorConversionStrategy=CMYK \
-sOutputFile=rgb.pdf \
cmyk.tiff
yields a cmyk black value of [0.83, 0.67, 0.51, 0.95]. Contrarily, when I use libcms2 to convert rgb (0,0,0) to cmyk I get [0.92, 0.64, 0.45, 0.96] which matches (almost) some information about the PSOcoated_v3.icc profile I found here. To confirmed that the source RGB-file black reads (0,0,0) I convert the RGB-pdf to an RGB-tiff and do find the black to be (0,0,0).
Am I missing something in the command of might this be a gs bug?
If I take an RGB color of [0,0,0] in sRGB color space and convert it to the CMYK value defined by the PSO coated v3 ICC profile in Photoshop (using Adobe ACE CMM in Photoshop), I get exactly the CMYK values you are seeing with gs, that is [0.83, 0.67, 0.51, 0.95].
That was using a relative colorimetric rendering intent with black point compensation enabled. Those are the settings that gs would be using for lcms by default.
I suspect that when you use libcms2, it is using a different rendering intent. For example, when I use the perceptual rendering intent with Adobe ACE I get [0.90, 0.64, 0.45, 0.96].
Note that you can specify with gs what rendering intent you want to use with
-dRenderIntent=0/1/2/3 . See https://ghostscript.com/doc/current/Use.htm#ICC_color_parameters for details.
Related
I used instructions from here to convert an RGB PDF to CMYK using Ghostscript, and it's mostly OK except all the blacks are "rich" - they use not just K but also CMY inks.
Is there a way to convert such that all blacks are "flat" and just use K?
This is the code I used:
gs \
-o test-cmyk.pdf \
-sDEVICE=pdfwrite \
-sProcessColorModel=DeviceCMYK \
-sColorConversionStrategy=CMYK \
-sColorConversionStrategyForImages=CMYK \
test.pdf
Assuming your PDF file actually does use RGB (and not an ICC profile embedded in the PDF) then, in order to get R=G=B->C==M=Y=0, K=R, you need to set up a custom ICC profile link.
You'll need to tell Ghostscript to use a custom RGB profile in place of default_rgb.icc and a cuustom CMYK profile in place of default_cmyk.icc. You'll need to ensure that the mapping RGB->XYZ->CMYK results in pure K when R=G=B.
There's documentation in the Ghostscript 'doc' folder on the various colour management settings, but most of these will only be effective when rendering, not when outputting a PDF file. About the only things you can usefully alter when outputting PDF is the input and output profiles.
I try to convert a CMYK .pdf as CMYK .tif with the good CMYK percentages.
But i've a strange color conversion.
Colors:
Look some converted color to understand the "strange" conversion:
100% yellow in pdf was converted as 98% yellow the TIF:
PDF = C:0 M:0 Y:100 K:0
TIF = C:0 M:0 Y:98 K:0
100% Magenta in pdf was converted as 1C/100M/1Y the TIF:
PDF = C:0 M:100 Y:0 K:0
TIF = C:1 M:100 Y:1 K:0
black is good (and all gray tone like 10%,20%...):
PDF = C:0 M:0 Y:0 K:100
TIF = C:0 M:0 Y:0 K:100
but full 100 is not good !?:
PDF = C:100 M:100 Y:100 K:100
TIF = C:73 M:68 Y:66 K:89
and a C100/M20 wrong too (pdf total 120 tif total 121 ?):
PDF = C:100 M:20 Y:0 K:0
TIF = C:99 M:21 Y:1 K:0
files:
download the source PDF:
[https://drive.google.com/file/d/0Byc9qwtxxi1dSlo2eHJxM1hpMU0/view?usp=sharing][1]
download the converted TIF:
[https://drive.google.com/file/d/0Byc9qwtxxi1dVWN6NWlBUEF0Z2c/view?usp=sharing][2]
!!!Attention: Open the files in photoshop to correctly preview the
color and use the color picker to compare the value of each colors.
Cmd:
I search on google and read all the ghostscript doc since 2 weeks, and that's my best cmd :
gs -dNOPAUSE -dBATCH -dSAFER
-sDEVICE=tiff32nc
-sDeviceNProfile
-dKPreserve=2
-dRenderIntent=1
-dCOLORSCREEN=false
-dNOINTERPOLATE
-dUseCIEColor
-dNOTRANSPARENCY
-dGraphicsAlphaBits=4
-dTextAlphaBits=4
-dFirstPage=1
-dLastPage=1
-r600
-sOutputICCProfile=USwebCoatedSOWPv2.icc
-sOutputFile=CMYK.tif
CMYK.pdf
(Unix Ghostscript 9.10)
Doc:
http://www.ghostscript.com/doc/9.10/GS9_Color_Management.pdf
http://ghostscript.com/doc/current/Devices.htm#PDF
???
What do you think ? is a bug or a wrong cmd !?
Did anyone else have this experience?
Thanks,
UPDATE 1
I reduce the cmd at his minimal :
gs -dNOPAUSE -dBATCH -dSAFER
-sDEVICE=tiffsep
-dKPreserve=2
-sOutputFile=CMYK.tif
-r300
-dGraphicsAlphaBits=4
-dTextAlphaBits=4
-dFirstPage=1
-dLastPage=1
CMYK.pdf
And have the same wrong color convertion.
For me, the ICC profile can't change color percents... a 100% Yellow is a 100% Yellow ! not agree?
(in all cases, we have the same issue with or without icc profile)
UPDATE 2
At the beginning, i can't reproduce the colors "bug" in photoshop, I thought it was ghostscript.
But i found the difference between "assign" and "convert" icc profile in photoshop.
photoshop "assign" screencast : http://quick.as/r2jrTn4zw
photoshop "convert" screencast : http://quick.as/xQzaHZ9xp
And it is not a bug !
New issue
Can't we not use the icc profile when we convert a PDF to TIF ? or use
globally the same profile to cancel the convert effect ?
First, update to the current shipping version of Ghostscript. If you still think you see a problem, then open a bug report at httpss://bugs.ghostscript.com
If you open a bug please be sure to attach the specimen file, and give a complete (as simple as possible) command line to reproduce the problem. If you are using an ICC profile, you'll need to supply that as well.
By the way, I think you have a typo there as well '-sOutputICCProfile=USwebCoatedSOWPv2.icc'
Oh, and if you are intending to get decent colour management, under no circumstances should you be setting -dUseCIEColor.
I'm not clear on what you expect the CMYK values to be when you are using an ICC Profile to correct the output, you surely aren't expecting them to be unchanged ?
I'm so close... with this tiny poorly documented option: -dNOSUBSTDEVICECOLORS
gs -sDEVICE=tiff 32nc -dNOSUBSTDEVICECOLORS -sOutputFile=CMYK.tif
CMYK.pdf
In all of my test, the most uncatchable was the C100M100Y100K100... now is good like M100, K100, K50, M100C20, ... ! But only the Cyan100 and Yellow100 turn again on 99% !!!
I'll get it... on next...
I created color separations using
gs -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -r600x600 -sOutputFile=p%08d.tif input.pdf
The outputs are all greyscale separations as documented.
Questions
1. How do I combine just the CYAN and MAGENTA separations (or any combination of colors) to make a PDF file?
2. How do I make sure the output PDF from the combo is in color and not greyscale?
Thanks.
You should be able to use Imagemagick's convert to combine CMYK separations; references:
http://www.productionmonkeys.net/guides/ghostscript/examples
CMYK colors inverted with draw or annotate - ImageMagick forum
Combine 4 grayscale images into a final CMYK image - ImageMagick
Example: first, create RGB pdf with Latex (from https://softwarerecs.stackexchange.com/questions/19210/linux-gui-for-quick-browsing-of-cmyk-separations-of-multi-page-pdf); use this as test.tex:
\documentclass{standalone}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
\draw[fill=none,draw=black,line width=2pt] (0cm,0cm) rectangle (4cm,5cm);
\draw[fill=red] (1cm,1cm) circle (1cm) ;
\draw[fill=blue] (2cm,2.5cm) circle (1cm) ;
\draw[fill=green] (3cm,4cm) circle (1cm) ;
\end{tikzpicture}
\end{document}
... then build the PDF with:
pdflatex test.tex
Split RGB pdf into CMYK separations as tiff images using Ghostscript (see original softwarerecs thread for images), which will be called:
gs -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -r150x150 -sOutputFile=test%04d.tif test.pdf
Merge/combine CMYK separations into a CMYK color tiff using Imagemagick:
convert \
test0001\(Cyan\).tif \
test0001\(Magenta\).tif \
test0001\(Yellow\).tif \
test0001\(Black\).tif \
-set colorspace CMYK -negate -combine combined.tif
... and here is how the final combined.tif looks like (I had to do convert combined.tif combined.png to upload it here, else .tif alone is not accepted):
For comparison, here is a png derived from the original PDF (convert -density 150 -flatten test.pdf test.png):
Notice how the colors are slightly different, which is expected due to the colorspace roundtrip. Also, note that for more correct colors, you'll probably have to use ICC profiles during conversion...
Finally, you should find a way to convert/import the final CMYK color TIFF into a PDF... (probably either ghostscript or imagemagick could do that, but I haven't tried it..)
For just cyan and magenta - use a white image with the same size as the channel TIF separations, to insert it in place of the missing separations:
convert -size 240x299 xc:white white.png
... and then do the merge again:
convert \
test0001\(Cyan\).tif \
test0001\(Magenta\).tif \
white.png \
white.png \
-set colorspace CMYK -negate -combine combinedCM.tif
Here is the output (after convert combinedCM.tif combinedCM.png):
Open the separations in an image editor which supports CMYK channels (eg Photoshop), combine the channels as required, save as PDF (or PostScript and use GS to convert to PDF).
I am converting an RGB PDF to CMYK using the following command:
/usr/local/bin/gs -dSAFER -dBATCH -dNOPAUSE -dNOCACHE -sDEVICE=pdfwrite \
-sColorConversionStrategy=CMYK -sColorConversionStrategyForImages=CMYK \
-dProcessColorModel=/DeviceCMYK -dEncodeColorImages=false \
-dEncodeGrayImages=false -dEncodeMonoImages=false -sOutputFile=CMYK.PDF RGB.PDF
The resulting file is 100% CMYK, however anything that was 100% black in the RGB PDF is now:
C: 72%
M: 68%
Y: 67%
K: 89%
The result is that black is a slightly dark grey when really it should be black.
Is there anything I need to add to this command to ensure black remains as black during the conversion?
With the current version of pdfwrite you are restricted to the colour conversions in the software, and there is nothign you can do about this.
The colour management is undergoing serious revision, and the next release should make it possible to deal with this.
Examples of Ghostscript commands to convert PDF from sRGB or eciRGB_v2 to eciCMYK_v2 (FOGRA 59) while keeping black plain (K only), not rich (CMYK)
I managed to convert PDF file in RGB to CMYK while keeping RGB black #000000 plain K black, not rich CMYK black.
DeviceLink ICC had to be created from e.g. eciRGB_v2 (or sRGB, if your source is sRGB) profile to the appropriate CMYK profile using collink tool (from argyll package) with the "-f" attribute to hack the black colors.
Ghostscript is then called with a control file declaring use of the profile and its parameters.
Example of making the DeviceLink RGB to CMYK profile
collink -v -f eciRGB_v2.icc eciCMYK_v2.icc eciRGB_v2_to_eciCMYK_v2.icc
Example of a control file to map eciRGB_v2 to eciCMYK_v2
Image_RGB eciRGB_v2_to_eciCMYK_v2.icc 0 1 0
Graphic_RGB eciRGB_v2_to_eciCMYK_v2.icc 0 1 0
Text_RGB eciRGB_v2_to_eciCMYK_v2.icc 0 1 0
Sample ghostscript command to do the actual conversion
gs -o 2-output-cmyk-from-eciRGB.pdf \
-sDEVICE=pdfwrite \
-sColorConversionStrategy=CMYK \
-sSourceObjectICC=control-eciRGB_v2.txt \
1-input-rgb.pdf
This is related to:
Converting PDF to CMYK (with identify recognizing CMYK).
Script (or some other means) to convert RGB to CMYK in PDF?
... but a bit more specific here: say I have an RGB PDF, where the text color is "rich black" (R:0 G:0 B:0 gone to C:100 M:100 Y:100 K:100), and diverse images and vector graphics.
I would like to convert this to a CMYK PDF, using a free command line tool (so it is batch scriptable under Linux), which
has contents only in the black (K) channel:
Preserves vector graphics (+ text glyphs) - colors become grayscale in black (K) channel only
Images get converted to grayscale in black (K) channel only
Thanks in advance for any answers,
Cheers!
As hinted in my comment to #Mark Storer, it turns out that forcing a gray print only on the K plate in CMYK, may not be so trivial ... I guess it depends much on what is being used as "preflight" preview device - for Linux, the only thing I can find is ghostscript with tiffsep, which is what I use for 'sanity check' regarding CMYK separations.
Anyways, I got a lot of help in this thread on comp.lang.postscript:
PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? - comp.lang.postscript | Google Groups
... and one workflow that works for me is:
Convert PDF to PS using ghostscript's ps2write
Use ghostscript to convert this PS back to PDF, while executing replacement functions in HackRGB-cmyk-inv.ps
Use ghostscript's tiffsep to check actual separations
In respect to, say, this PDF generated by OpenOffice: blah-slide.pdf, the command lines would be:
# PDF to PS using `ps2write` device of `ghostscript`
gs \
-dNOPAUSE \
-dBATCH \
-sDEVICE=ps2write \
-sOutputFile=./blah-slide-gsps2w.ps \
./blah-slide.pdf
# PS to PDF using replacement function in HackRGB-cmyk-inv.ps
gs \
-dNOPAUSE \
-dBATCH \
-sDEVICE=pdfwrite \
-sOutputFile=./blah-slide-hackRGB-cmyk-inv.pdf \
./HackRGB-cmyk-inv.ps \
./blah-slide-gsps2w.ps
# check separations
gs \
-dNOPAUSE \
-dBATCH \
-dSAFER \
-sDEVICE=tiffsep \
-dFirstPage=1 \
-dLastPage=1 \
-sOutputFile=p%02d.tif \
blah-slide-hackRGB-cmyk-inv.pdf \
\
&& eog p01.tif 2>/dev/null
This should only work on RGB values where R=G=B (and hopefully grayscale values), and only on text colors, and it also flattens text information - but it should be possible to confirm via tiffsep that the text indeed ends up only on the K plate.
As mentioned in the newsgroup post, this is not extensively tested, but looks promising so far...
Cheers!
As an improvement to sdaau's great answer, I can recommend using pdftops from xpdf for converting pdf to ps, instead of ghostscript ps2write, because the latter e.g. causes the font to become staircasey, and is said to not preserve the original pdf accurately. Compare by zooming into text areas of the resulting pdfs.
I suggest you convert the PDF using GS twice. Once to a Shades Of Gray colorspace, and then to CMYK.
I'm not sure it'll work, but I'd be a bit surprised if it didn't. G->CMYK sounds like a brain-dead X -> 0 0 0 X conversion. At least if you stick to "device gray" and "device CMYK" instead of some calibrated color space that'll tweak things this way and that.