I want to convert a CMYK-PDF into a rgb-PNG using ghostscript.
This is what I use so far:
gs -sDEVICE=pngalpha -dBATCH -dNOPAUSE -dCompatibilityLevel=1.4 -dColorConversionStrategy=/sRGB -dProcessColorModel=/DeviceRGB -dUseCIEColor=true -sOutputFile=out.png -r300 pdf/input.pdf
The issue is however that the color is not converted accurately. I'm using a Mac OS Catalina MacBook and when I look at the original PDF in the built in preview tool the color is not as saturated as the converted color.
So my question is what am I doing wrong with this? I'm not an expert with color management.
Thanks!
Well, clearly the colours cannot be the 'same' because one is expressed in a subtractive 4 colour model, and the other in an additive 3 colour model.
Firstly you are using three command line switches which are not going to have any effect at all:
-dCompatibilityLevel is only used for the pdfwrite device to set the maximum version of PDF support, it has no effect on any other device and certainly won't affect the PNG output devices.
-sColorConversionStrategy only works with the pdfwrite device, which is capable of handling nearly the full range of colour models. Most devices, such as PNG only support a single colour model, so you don't need to specify the colour conversion, it all has to be converted to that colour space.
You should never set -dProcessColorModel. That has to remain correct for the device; in the case of high level devices it is ignored, or set appropriately to the same as ColorConversionStrategy.
Finally and most importantly; you have set -dUseCIEColor. This is an ancient PostScript colour management control; it causes all colours to be converted into CIE spaces, either CIEBasedA, CIEBasedABC, CIEBasedDEF or CIEBasedDEFG. From there the colour is converted to the destination space. Using this will pretty much break the ICC profile colour management in Ghostscript.
So drop all four of those and try again. Note that when you compare the PNG result with the PDF you are comparing the colour conversion performed by Ghostscript with the colour conversion (CMYK->RGB) performed by the PDF consumer, presumably the built-in Mac Quartz code. I'd have to express some reservations about the quality of that conversion.
It is entirely possible for you to control the colour management performed by Ghostscript. There are default RGB and CMYK profiles which are used to convert the CMYK components into the CIE XYZ calibrated space, and then from there to RGB. Each of these uses on ICC profile. If you don't like the default ones you can substitute another one of your choosing for either or both. The ICC profiles can be found in the ghostpdl/iccprofiles directory, you can use -sDefaultCMYKProfile=<...path...> to specify a different profile to use to convert CMYK into CIE-XYZ and -sOutputICCProfile=<...path...> to specify a different ICC profile to use for the final space (RGB in your case).
For properly colour managed workflow you should know the characteristics of the specified input colour model (eg SWOP CMYK) and use the correct ICC profile to map from CMYK to CIE-XYZ and you should know the characteristics of the output colour model (eg Sony Trinitron, to use an old monitor example) to create the closest matching output colour.
You may have an ICC profile for your monitor, I doubt you know what the CMYK values in the original PDF file represent. To match whatever PDF consumer you are using you would need to know what CMYK and RGB output profiles it is using and use the same ones in the Ghostscript rendering process.
NB all the above assumes that the original PDF, which is not supplied, actually specifies the colours in CMYK, and not in an ICCBased colour space, or other similar device-independent colour space.
From the comment:
Following your argumentation it should be identical
No. In the case of the PDF consumer it is doing a CMYK->RGB conversion in order to display the content. When rendering to PNG Ghostscript is also doing a CMYK->RGB conversion. Actually because you are using -dUseCIEColor it's doing a CMYK->CIEBasedDEFG->RGB conversion, but lets assume you dropped that so it's just doing CMYK->RGB.
Now, if the two conversions are fully colour managed, lets assume for now ICC profiles as the colour management technique, and the two conversions are using the same ICC profiles, that is assuming the same characterised space, then yes the result will be identical.
Without seeing your PDF file I can't tell how the colours are actually specified within it. You say they are 'CMYK' but CMYK is not a characterised space. There are many different CMYK inks and they are printed to many different kinds of paper with different reflectivity and absorbency. So SWOP and Euroscale are both CMYK printing processes, but their characteristics are different.
So if we treat your CMYK values as SWOP and convert them to an RGB space we should expect different RGB values than when those same CMYK values as if they were Euroscale. That's because the same CMYK quad printed to a SWOP process would be different to the appearance on a Euroscale process.
Similarly when it comes to creating the RGB values. RGB is also not a characterised space, there are many different RGB output devices and they differ in how they display a given RGB triplet.
Now I don't know how your PDF consumer does the CMYK->RGB conversion. I'd like to think it uses ICC profiles to characterise the spaces but it might not. There's a long standing (quick and dirty) conversion method from the PostScript Language Reference which it might use instead.
However, a modern colour managed workflow would use ICC profiles.
When dealing with an uncharacterised space such as 'CMYK' or 'RGB' the only thing Ghostscript can do is use a generic profile. It uses a general purpose CMYK profile to convert the incoming CMYK into the CIE XYZ space (which is device-independent) and then a generic RGB profile to convert the CIE XYZ components into RGB. You can change the assumptions about the input and output colour spaces.
In effect you can say 'I happen to know that the CMYK values were intended for an HP Indigo, so use the HP Indigo ICC profile' and that will then map the CMYK into XYZ as the original creator intended. Similarly you can say 'I'm using a Sony wide gamut RGB monitor, so use that ICC profile' and that will give the best possible representation of the XYZ colours on that device.
But if tomorrow you viewed it on a low end Iiyama monitor you could tell it to use a different appropriate profile, and you would see (as far as possible) the same colours as on the expensive device.
So to try and summarise; the problem is that you are using uncharacterised spaces. The two consumers are not set up to use the same default colour management paths, so you can expect to see differences. To avoid this you need to use the same profiles on both PDF consumers (preview and Ghostscript).
I can't remember if PNG allows you to save an ICC profile in the file. If it does then you can carry the PNG to another computer with a different monitor and it will still look the same. If it doesn't (and I think it doesn't) then viewing the RGB output on different monitors will look different.