Summary: | grayscale image with transfer function rendered incorrect on substractive devices | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Zoltán <birozoltan> |
Component: | Color | Assignee: | Ralph Giles <ralph.giles> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | CC: | zoltan |
Priority: | P3 | ||
Version: | 8.51 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Customer: | Word Size: | --- | |
Attachments: |
testfile for bug reproduction
patch patch |
Description
Zoltán
2005-11-02 03:54:22 UTC
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. |