| | <<<Back 1 day (to 2019/04/08) | 20190409 |
| i3v | @kens | 00:23.50 |
| | > That's a general question about RGB to CMYK conversion, not a question regarding PDF/X3 conversions. | 00:23.56 |
| | It looks like RGB to CMYK conversion works much the same, regardless of the `-dPDFX`, according to my experiments... | 00:24.02 |
| | The only difference is that with `-dPDFX` it is possible to embed the "Output Intent" ICC profile. (I'm only considering `-dPFDX` together with conversion to CMYK here.) | 00:24.08 |
| | Here's an example pdf: https://1drv.ms/b/s!Anqmq2Ex7NSPnVS9ZO8DgIx5p6TR and here's the source tex: https://www.overleaf.com/read/mydkkdcxrgxf . | 00:24.25 |
| | Consider the following 3 commands: | 00:25.12 |
| | >> gswin64c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dHaveTransparency=false -r20 -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -sOutputFile=colorbar_cmyk.pdf colorbar.pdf | 00:25.17 |
| | >> gswin64c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dHaveTransparency=false -r20 -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -dPDFX -sOutputFile=colorbar_cmyk_x3.pdf PDFX_cmyk_renderintent.ps colorbar.pdf | 00:25.23 |
| | (where PDFX_cmyk_renderintent is like "lib/PDFX_def.ps" example from 9.26, but uses "cmyk_des_renderintent.icc") | 00:25.29 |
| | >> gswin64c -dBATCH -dNOPAUSE -sDEVICE=tiff32nc -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -sOutputICCProfile=default_cmyk.icc -dRenderIntent=1 -sOutputFile=colorbar.tiff colorbar.pdf | 00:25.46 |
| | All 3 commands convert rgb(255,0,0) and rgb(240,0,0) to cmyk(0,1,1,0). | 00:25.53 |
| | Output pdfs might look a bit different (in saturation) in a pdf viewer that takes OutputIntentICC into account (e.g. Adobe Acrobat Reader DC). | 00:26.01 |
| | But there's nothing like those "only cyan" or "only magenta" effects, that are demonstrated in https://www.ghostscript.com/doc/9.26/GS9_Color_Management.pdf . | 00:26.11 |
| | AFAIU, this is because pdf viewer uses AToB1 conversion (which is like normal in "cmyk_des_renderintent.icc"), while the "to only magenta" conversion happens in "BToA1" (which was not used at all in this experiment). | 00:26.19 |
| | I've also noticed that "Resource/ColorSpace/DefaultRGB" contains exactly the same values as "iccprofiles/default_rgb.icc" - maybe if I change something there, `-dPDFX` would behave differently. I've not tried that. | 00:26.37 |
| | > the device independent colours are then mapped back to CMYK using the CMYK default profile I believe, though I would have to do some investigation to check this | 00:26.53 |
| | The colors I get in tiff (3rd command) are equal to those I get in pdf. (And we know that "sOutputICCProfile" works for "tiff32nc"). Thus, indeed, it looks like "default_cmyk.icc" was implicitly used in the first two commands as well. | 00:26.59 |
| | 1) AFAIU, "DeviceIndependent->DeviceCMYK" is where saturated colors clipping happens, right? | 00:27.09 |
| | 2) AFAIU, there's no way to select a different profile (or a different intent) for this conversion, e.g. to avoid clipping, right? | 00:27.15 |
| | 3) The only possible workaround is to create a special "narrow_rgb.icc" (and use it like "-sDefaultRGBProfile=narrow_rgb.icc"), | 00:27.21 |
| | which would map original DeviceRGB colors into narrow-enough subspace of DeviceIndependent colors. (But that won't work if objects in the original pdf do have ICC profiles already, unless you override them.) Is that correct? | 00:27.27 |
| | PS Sorry for that many characters. | 00:27.54 |
| kens | i3v my point wasn't specifically about PDF/X-3 conversion, more that if I don't have a context then I'm going to assume the most general case. The OutptuIntent profile is not used in colour management. It is embedded into the final PDF file. This profile is used by conforming consumers to do the 'reverse' lookup. Given a colour in the PDF file, in the space covered by the profile, it allows the consumer to turn the colour compon | 07:00.33 |
| | ents into a device-independent colour. | 07:00.33 |
| | So the profile supplied to OutptuIntent should be the profile used to create the colour components. | 07:01.12 |
| | Now in a fully managed workflow you would have control over the colour space and components throughout, and its entirely reasonable that you would have an RGB PostScript file which you would supply to GS to conert into a RGB PDF file. And the OutputIntent Profile would be whatever characterised space you were using, Note that in this case there is **NO** colour conversion taking place, and yet you still need to supply an OutptuIntent. | 07:03.03 |
| | If you are using pdfwrite to colour manage the output, then you should supply whatever profile is being used to create the output components as teh OutputIntent. In this case the OutputIntent is indeed used in the colour management, but not because its the OutptuIntent. | 07:04.53 |
| | I'm not the correct person to discuss your final 3 points, but.... | 07:05.18 |
| | DeviceIndependent->DeviceCMYK will (I believe) use the default_cmyk.icc prfile to create teh CMYK components. | 07:05.52 |
| | I believe you can indeed use a different profile, that's the default. You can supply a different DefaultCMYKProfile I think. | 07:06.20 |
| | Off the top of my head I think your point 3 is rather moot. Since RGB is a wider gamut than CMYK there is no way to avoid some kind of clipping or compression. Its always going to be the case that two different RGB inputs will result in the same CMYK output. That can either be clipping at a maximum or by compressing in the middle of the gamut. | 07:07.58 |
| | If that's what you want then you will need to supply either a different input profile (for mapping the device spaxce to CIE) or a different outptu profile (to map the CIE apace into device colours). Of the two I would alter the output conversion profile myself, I feel yhat's likely to give better control. | 07:09.11 |
| camelopard | Can Ghostscript evaluate PDF-style functions from PostScript? I want to verify my functions, and this seems to be the easiest way. | 20:07.49 |
| Robin_Watts | camelopard: Well, the PDF interpreter is currently written in postscript, so yes. | 22:42.09 |
| | Forward 1 day (to 2019/04/10)>>> | |
Log of #ghostscript at irc.freenode.net.