Bug 688360 - grayscale image with transfer function rendered incorrect on substractive devices
Summary: grayscale image with transfer function rendered incorrect on substractive dev...
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Color (show other bugs)
Version: 8.51
Hardware: PC Windows XP
: P3 normal
Assignee: Ralph Giles
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-02 03:54 UTC by Zoltán
Modified: 2008-12-19 08:31 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
testfile for bug reproduction (35.04 KB, application/zip)
2005-11-11 04:08 UTC, Zoltán
Details
patch (5.16 KB, patch)
2007-07-29 05:06 UTC, Alex Cherepanov
Details | Diff
patch (5.55 KB, patch)
2008-04-27 22:06 UTC, Alex Cherepanov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Zoltán 2005-11-02 03:54:22 UTC
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.
Comment 1 Dan Coby 2005-11-02 09:15:20 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.
Comment 2 Dan Coby 2005-11-07 21:29:03 UTC
Please note that I will close this bug due to insufficient information unless 
some more information is supplied.
Comment 3 Zoltán 2005-11-08 01:06:13 UTC
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!
Comment 4 Zoltán 2005-11-11 04:08:44 UTC
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.
Comment 5 Dan Coby 2005-11-12 22:23:38 UTC
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.
Comment 6 Zoltán 2005-11-13 00:38:18 UTC
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.
Comment 7 Dan Coby 2005-11-13 10:40:01 UTC
>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.
Comment 8 Alex Cherepanov 2007-07-29 05:06:05 UTC
Created attachment 3227 [details]
patch

With the help of check_cmyk_color_model_comps() identification of CMYK devices
is quite straightforward.
Comment 9 Tor Andersson 2008-03-06 04:39:48 UTC
Comment on attachment 1759 [details]
testfile for bug reproduction

attachment file type misidentified
Comment 10 Alex Cherepanov 2008-04-27 22:06:39 UTC
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.
Comment 11 Alex Cherepanov 2008-04-27 22:23:28 UTC
The patch is committed as a rev. 8666.
The sample file is added to the public sample file collection by rev. 8667.