5

I need to convert RGB PDF into CMYK PDF.

I need to have pure black color for texts.

It seems (thanks to comments below) term "black point compensation" is wrong. I took it from Adobe Acrobat where it works exactly how i need. I thought gs has same feature.

I use ghostscript 9.16

If i got it right there is -dBlackPtComp option, but it does not work for me. Ghostscript command I have tried is:

"c:/Program Files/gs/gs9.16/bin/GSWIN64C.EXE" -o testing_black_cmyk.pdf -sColorConversionStrategy=CMYK -sDEVICE=pdfwrite -dOverrideICC=true -sOutputICCProfile=c:/Windows/System32/spool/drivers/color/JapanColor2002Newspaper.icc -dTextBlackPt=1 -dBlackPtComp=1 test2.pdf

Igor
  • 1,359
  • 19
  • 34
Ivan Gusev
  • 252
  • 5
  • 10
  • You do not have -sTextICCProfile set therefore -dTextBlackPt is kind of void. Could you give an example of how the output looks incorrect? Also check this answer http://stackoverflow.com/a/3423503/1328439 – Dima Chubarov Feb 24 '16 at 08:26
  • 1
    Ok i just tried with -sTextICCProfile, but it seems has no effect at all. Output result i simply check with Acrobat and instead of 100% for black i see 88% (instead of 0% for other colors i see 72% 67% 67%) – Ivan Gusev Feb 24 '16 at 08:46
  • 2
    1. [BPC](http://www.color.org/AdobeBPC.pdf) has nothing whatsoever to do with your problem. 2. I think GS high-level devices (`pdfwrite`, too) still perform their own 'hard-coded' color management, i.e. ignore most CMS-related switches. E.g. any `-sOutputICCProfile` will give the same result -- i.e. if you expected your `JapanColor2002Newspaper.icc` to be applied (for photographs, etc.) -- beware, it wasn't. 3. The workaround is to use `-sSourceObjectICC` with control file, and [device-link profiles](http://www.argyllcms.com/doc/collink.html). Make yourself a couple of DL-profiles, ... – user2846289 Feb 25 '16 at 23:07
  • ...simple (rather, use the `-G` switch) for images (photos), and one for text and maybe graphics (use `-f` switch). Then your RGB black text will convert to CMYK 0/0/0/100, and your color will, indeed, convert to `JapanColor2002Newspaper.icc` (assuming that's what you need) – user2846289 Feb 25 '16 at 23:08
  • Great thanks for help! Unfortunately i tried what you suggest and result is same, i have updated question, please check – Ivan Gusev Feb 26 '16 at 05:37
  • Just to answer this point; no the pdfwrite device (and the other vector, or high-level devices) do **not** do their own colour conversion, they rely on the CMS. in this case Little CMS 2. – KenS Feb 26 '16 at 09:18

2 Answers2

4

Try this:

collink -v -G AppleRGB.icc JapanColor2002Newspaper.icc apple_to_jNP_photo.icc

collink -v -f AppleRGB.icc JapanColor2002Newspaper.icc apple_to_jNP_neutrals.icc

control.txt:

Image_RGB   apple_to_jNP_photo.icc       0   1   0
Graphic_RGB apple_to_jNP_neutrals.icc    0   1   0
Text_RGB    apple_to_jNP_neutrals.icc    0   1   0

and 

gswin32c -q -sDEVICE=pdfwrite -o out.pdf -sColorConversionStrategy=CMYK -sSourceObjectICC=control.txt in.pdf

Then the DeviceRGB in source PDF is converted to DeviceCMYK, and RGB 0/0/0 becomes (as I'm checking now) the DeviceGray 0, which should be OK (and all other neutral RGB shades are mapped to true grayscale, too).

The reason we are using different DL-profiles for different objects, is because, though saturated colors (far from neutrals) will be converted to the same CMYK through both profiles, nevertheless you probably don't want color suddenly switch to 0/0/0/n in continuous tone photographs, if color happens to be near neutral -- it'll look terrible on the press.

If your "images" are e.g. rasterized graphics (diagrams, etc.) with 0/0/0 RGB, then you can consider using apple_to_jNP_neutrals.icc for these images too.

If your page has a mix of both real images and rasterized graphics (text) - bad luck, you'll have to compromise.

The reason we use -G instead of fast and simple Simple Mode, is because -f (for second profile) implies the "Gamut Mapping Mode using inverse outprofile A2B", and we want 2 profiles to produce the result (for saturated colors) as close to each other as possible.

user2846289
  • 2,185
  • 13
  • 16
  • Thanks for very "guidance" answer! Question, if i keep only "Text_RGB" rule in control.txt, then what happen to images? – Ivan Gusev Feb 26 '16 at 10:01
  • Then, I think, the `default_rgb.icc` will be implicitly assigned to `DeviceRGB` source, which then will be converted to `default_cmyk.icc`, which are `Artifex Software sRGB ICC Profile` and `Artifex CMYK SWOP Profile` by their description tags. This conversion is done using the `Colorimetric BPC` RI, it seems. And this is **regardless** of other CL switches, **including** control file non-DLP lines. That's why I say high-level devices behaviour is "hard-coded". BTW, I think any BPC should be removed from the title, maybe "preserving pure Black for text" will be better. – user2846289 Feb 26 '16 at 10:33
  • Ok, thanks. I'm comparing result with Acrobat-converted version and it seems images in gs-converted version has less contrast. – Ivan Gusev Feb 26 '16 at 10:59
  • Sadly, this doesn't work for me with gs9.27 x64, collink v2.1.1, on [this](https://www.ghostscript.com/doc/9.27/GS9_Color_Management.pdf) example pdf ([details here](https://github.com/i3v/GS_ColorManagement_and_pdfOutput/tree/master/gs_SO_collink)). If I simplify the command to just `gswin64c -sDEVICE=pdfwrite -o out.pdf -sColorConversionStrategy=CMYK -sDefaultRGBProfile=apple_to_jNP_neutrals.icc GS9_Color_Management.pdf`, it produces multiple error messages, but some output file is still created. Many objects inside are missing, though. Any idea what's wrong here? – Igor Jul 27 '19 at 16:48
  • This helped me as well and worked fine! Just a headsup for everbody else: I specifically installed `colllink`software to generate the icc-profiles `apple_to_jNP_photo.icc` and `apple_to_jNP_neutrals.icc` from the original AppleRGB and JapanColor2002Newspaper icc-profiles via the comand line comment at the top. After generateing the new icc profiles, and using the control.txt file, this worked flawlessly! – Webchen Apr 07 '20 at 11:33
  • hi, I followed exactly the steps. When I run the command `gswin32c -q -sDEVICE=pdfwrite -o out.pdf -sColorConversionStrategy=CMYK -sSourceObjectICC=control.txt in.pdf`, I get the error message:Error: /undefinedfilename in (control.txt). I have already downloaded the icc files and put them into the gs iccprofiles directory. Please help me with this. – scarcer Apr 10 '21 at 06:20
0

From the description on black point compensation on the Little CMS page:

"Black point compensation (BPC) is a technique used to address color conversion problems caused by differences between the darkest levels of black achievable on different media/devices."

In other words, BPC has nothing to do with your problem and if you want proper answers, you should remove it from this question.

If you want black to be preserved (or pure / secondary colors in general), you basically have two options you can look at:

1) Create a proper DeviceLink profile to do your conversion. This devicelink profile should take your input ICC Profile and the destination you want to convert to and should contain proper exception rules to keep black / gray / secondary / tertiary colors as required.

2) Use a color conversion engine that supports exceptions while doing regular ICC Profile conversion. Little CMS for example has an intents flag ("INTENT_PRESERVE_K_ONLY_RELATIVE_COLORIMETRIC") that can be set to instruct the engine to preserve black during conversion.

David van Driessche
  • 6,602
  • 2
  • 28
  • 41