Summary: | Radial gradation issue | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
Component: | Color | Assignee: | Michael Vrhel <michael.vrhel> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 8.60 | ||
Hardware: | All | ||
OS: | All | ||
Customer: | 190 | Word Size: | --- |
Attachments: |
SimpleGradMag.pdf
noicc.tif ok.tif bad.tif Bug689961_patch.diff |
Description
Marcos H. Woehrmann
2008-07-10 08:10:55 UTC
Created attachment 4203 [details]
SimpleGradMag.pdf
Created attachment 4204 [details]
noicc.tif
Created attachment 4205 [details]
ok.tif
Created attachment 4206 [details]
bad.tif
Additional information from the customer (including a command line, which should satisfy Henry): First, I've found the reason why I couldn't reproduce the problem with tiff32nc: it's because the gradation, in the file, is in a DeviceN colorspace, having only one component, "Magenta". And since tiff32nc uses the default get_color_comp_index procedure (gx_default_DevCMYK_get_color_comp_index), it identifies "Magenta" as one of it's colorant, so it uses gx_concretize_DeviceN(), and then finally cmap_devicen_direct(), to map all colors of the gradations. In my first attempt, I had tried to redefine the mapping proc CMYK->CMYK of tiff32nc, because I thought that the file was pure CMYK. God knows why, when you have a gradation in Illlusrator CS3 with only process CMYK colors, it always create the gradation in a DeviceN colorspace, when the output is PDF. Now, the reason our CMYK devices works differently than tiff32nc is that our get_comp_color_index() always return -1 for process inks. And the reason for that is, precisely, to force DeviceN colorspaces to be processed like DeviceCMYK, so that our mapping procs (which make an ICC conversion) are always used. Well, stricly speaking, the initial motivation was to disable overprint on process colors (that was a suggestion of Dan Coby a few years ago). I found out later that this has this rather happy side effect, too. Anyway, I finally could reproduce the initial problem with tiff32nc, by: a) redefining get_color_comp_index() to always return -1. b) redefining the cmyk mapping proc in such a way that it returns exactly the same values than my own device (with a look-up table). I attach the modified gdevtsep.c (my modifications are in #ifdef DO_MY_CMYK), for version 8.62. To produce the buggy TIFF, use the following command: gs -sDEVICE=tiff32nc -sOutputFile=a.tif -r60 -f SimpleGradMag.pdf (I attach again the problematic PDF file). As far as I can see, the problem is in gx_cspace_is_linear_in_triangle(). At first glance, it wrongly decides, at a certain point, that no more subdivisions are needed (besides, when I force gx_cspace_is_linear_default() to always return 0, I immediately get rid of the problem). However, I'm not so sure because if that was the case, I should normally end with a wrong gradation (wrong colors), but at least a smooth one. So maybe there is something else. Now, the real reason of the problem might be that our device declares itself as "separable and linear" whereas, in fact, it's not linear (ICC conversions, especially with digital printers, are almost never linear). But if that's the case then our device is buggy since the beginning. And I think that when tiff32nc processes an RGB gradation, it doesn't always make a strictly linear RGB->CMYK conversion. So maybe this bug is potentially present with the standard GS devices. Created attachment 4207 [details]
gdevtsep.c
I can replicate the problem with the tiff32nc device using the modified code that the customer provided. I am looking a bit more at this. My intuition is telling me that the customer's comment about there being an assumption of linearity when there it really is not, is going to be the issue, as the output shows every sign of this. Created attachment 4265 [details] Bug689961_patch.diff I believe this should fix the issue. There was a problem with the testing to determine if a color space mapping was linear within a triangle and along a line. The old code assumed the number of components was the same in the client and device color space. In general this is not true, especially if we have a DeviceN color space with one color and a CMYK output device, which was the test case given. The customer reports the patch in comment #8 does fix the problem. Please commit. |