When using pdfwrite for RGB->CMYK pdf conversion, it is not possible to set all necessary color conversion parameters. In particular, it is not possible to specify output icc profile, and render intent. The docs do not explicitly specify which specific values are hardcoded (e.g. which icc profile). It would be nice if there would be a way to do that. Previous discussion: -------------------- https://ghostscript.com/irclogs/2019/04/02.html https://ghostscript.com/irclogs/2019/04/03.html https://ghostscript.com/irclogs/2019/04/09.html https://ghostscript.com/irclogs/2019/04/12.html https://ghostscript.com/irclogs/2019/04/13.html https://ghostscript.com/irclogs/2019/04/16.html What is documented: ------------------- * The "Ghostscript 9.21 Color Management" http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=doc/GS9_Color_Management.pdf;hb=ebfaa2db4cb518a2bc99c1532d4429201a13dfab provides a nice description of the Color Management parameters. They do work OK for `tiff32nc`. In particular, it mentions `-sOutputICCProfile` and `-dRenderIntent`. * It is documented in "VectorDevices.htm" http://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=doc/VectorDevices.htm;h=13b90ecd18017360f305e5de54fff215be69b9e5;hb=284ba1a6491088ab8ea9985f5df882c43bd3ca12#l566 that > while pdfwrite uses the same CMS as the rendering devices, > this does not mean that the entire suite of options is avialable * it also says > The colour management code has no effect at all unless either > ColorConversionStrategy or ConvertCMYKImagesToRGB is set, or > content has to be rendered to an image (which is demonstrated in experiments here: https://ghostscript.com/irclogs/2019/04/12.html ) Consequences: ------------- * There's no simple way to produce a pdf, with embedded output intent (PDF/X-3) and simultaneously actually convert to that icc profile * There's no simple way to avoid color clipping. E.g., by default, both rgb(255,0,0) and rgb(240,0,0) produce cmyk(0,1,1,0). * ... Severity: --------- I understand that this does not seem to be the most requested feature. No one actually cares. Maybe "Won't fix" or something. But still I'd like to file this, * for a future reference * to sum up those discussions * in a hope that Dr. Michael Vrhel would correct me, if I'm wrong Related: -------- This issue might be somewhat related to https://bugs.ghostscript.com/show_bug.cgi?id=700929 - maybe that one is caused by "color conversion parameters being passed incorrectly" too.
Created attachment 17430 [details] Experiments, mentioned in irc logs (input, output, tex code) Attaching files from experiments, mentioned in irc logs.
Just for reference, here's a doc that describes some experiments with Color Management in gs: https://github.com/i3v/GS_ColorManagement_and_pdfOutput/blob/master/README.md The "Exp 2" and "Exp 3" there are particularly related to RGB->CMYK conversion. There's also a result, produced by Acrobat, that cannot be reproduced with gs.
I will look this over. There is some disconnect between the behaviour of the high level pdfwrite device compared to the raster devices in terms of what is practical or useful to do.
Created attachment 22206 [details] Small patch to have the `-sOutputICCProfile` option work on RGB-to-CMYK PDF conversion. Hello, I've toyed a bit with the source code of Ghostscript 9.55.0, trying to understand why color management options were not taken into account by the `ps2write` and `pdfwrite` devices. I found two small issues which were quite easy to fix, and which allowed me to successfully use the `-sOutputICCProfile` and `-dRenderIntent` options. I don't know if this is the right way to fix this, but I'm putting it there, just in case :) In the following, I assume GS was called on an RGB PDF document with the options `-sColorConversionStrategy=CMYK` and `-sOutputICCProfile=/path/to/whatever.icc` to the `ps2write` or the `pdfwrite` device. The `-dProcessColorModel=/DeviceCMYK` option is not necessary. First of all, it turns out that `gsicc_init_device_profile_struct()`, in charge of initializing the device ICC profiles, is called several times by the device driver, as part of the `gdev_pdf_put_params_impl()` function: - A first time via the call to `gdev_psdf_put_params()` (devices/vector/gdevpdfp.c:729), which ends up calling `gx_default_put_icc()` when `OutputICCProfile` is set, and then `gsicc_init_device_profile_struct()`, where the specified output profile is installed, as expected. - A second time directly by `gdev_pdf_put_params_impl()` (devices/vector/gdevpdfp.c:762) -- although with a NULL profile this time --, because of the `-sColorConversionStrategy=CMYK` option. This second call to `gsicc_init_device_profile_struct()` replaces the specified ICC profile by a default one (`default_cmyk.icc`), due to the NULL parameter for `profile_name`, even though a valid profile is already present. This is strange behavior, as one would expect the initialization procedure not to replace an existing profile with a default one. Therefore, I've changed this function's behavior so that it would replace an existing ICC profile if and only if another ICC profile was explicitly specified. This is what the first part of the proposed patch does: if there is already a valid current profile (i.e., if `curr_profile->name` is not NULL), replace it only if `profile_name` is not NULL; otherwise, leave it as is. This makes GS correctly use the specified output ICC profile for the RGB-to-CMYK conversion instead of the default one. However, a final call to `gdev_pdf_put_params_impl()` will first release the device profile because of a change in the `ProcessColorModel` (devices/vector/gdevpdfp.c:643), then initialize it again. However, this second time around, path control is now active, but the path to the `OutputICCProfile` file was not added to the `permit_reading` list. Consequently, GS can't open the ICC profile and fails at this point. It seems that this can be fixed by adding the value of `OutputICCProfile` to the `permit_reading` list (when it is defined) in the `Resource/Init/gs_init.ps` script. This is what the second part of the proposed patch does. Hoping that this will help! :) Thanks! Jérémie.