When a grayscale type 1 image is rendered on substractive device (e.g. spotcmyk) and no or just identity transfer function is active, the image is rendered on the black plate, az expected. But, when the image comes with a non-identity transfer function, the image figures on unused plates too, as all black pixels. That is, speaking about substractive devices, the driver's gray color mapping procedure should return frac_0 for all unused plates of the images. However, the encode_color driver procedure is already called with 0xffff (max. tint value) for these unused components. The bug may be caused due to ignoring the different approach of using transfer functions on additive and substractive devices respectively. Unfortunately the test page is unreasonable large (about 40 MB compressed) so i'll upload it just if you cannot reproduce the bug in other way.
Please give an example command line, and a sample file. (Probably the easiest way would be to post a URL for the sample file. If it is private, then email the URL to me.) Please include your non identity transfer function.
Please note that I will close this bug due to insufficient information unless some more information is supplied.
Wait just a few days more, please. I'm very busy in these days, the test file is huge and I couldn't manage to isolate the faulty image yet. Thanks!
Created attachment 1759 [details] testfile for bug reproduction Well, this testfile is tiny and shows exactly what happens. The transfer function is a linear, negative one, f(x) = 1 – x; x from [0...1] (at least az I think), but every non-identical transfer function shows the same behavior. gswin32c.exe -sDEVICE=spotcmyk -r1200 -sOutputFile=c:\temp\transfer %1 Any substractive device will get the same result, not just spotcmyk.
On this topic, section 7.3 of PRLM-3rd (page 494) says: Note: When the current color space is DeviceGray and the output device’s native color space is DeviceCMYK, the interpreter uses only the gray transfer function. The normal conversion from DeviceGray to DeviceCMYK produces 0.0 for the cyan, magenta, and yellow components. These components are not passed through their respective transfer functions, but are rendered directly, producing output containing no colored inks. This special case exists for compatibility with existing applications that use settransfer to obtain special effects on monochrome devices, and applies only to colors specified in the DeviceGray color space. There is a similar comment in section 6.3 of the PDF 1.6 spec. (page 456). I also note that the Acrobat 6.0 Pro gives different results in "separation preview" mode. I will look into this problem.
Agree. The problem is – at least as I think – that "The normal conversion from DeviceGray to DeviceCMYK" is performed in a faulty way. E.g. tint 1.0 means white for DeviceGray but black for DeviceCMYK, therefore a TintCMYK = 1 - TintGray conversion should be made to get the appropriate tint. However not sure, I suggest to check out whether this conversion is really made or not.
>The problem is – at least as I think – that "The normal conversion from >DeviceGray to DeviceCMYK" is performed in a faulty way. No, the conversion from Gray to CMYK is producing the proper value for black. The problem is that the tint transform functions are being applied to all of the colorants. Logically this is how it should be done. However, as I noted in my previous comment, Adobe put in an 'exception' for converting DeviceGray to DeviceCMYK. This exception is not implemented in Ghostscript.
Created attachment 3227 [details] patch With the help of check_cmyk_color_model_comps() identification of CMYK devices is quite straightforward.
Comment on attachment 1759 [details] testfile for bug reproduction attachment file type misidentified
Created attachment 3965 [details] patch Implement spacial handling of transfer functions during Gray to CMYK conversion: ignore transfer functions for non-black components. Regression testing shows no differences.
The patch is committed as a rev. 8666. The sample file is added to the public sample file collection by rev. 8667.