When -dUseCIEColor is used with a CMYK output device and we have an SMask in the contents, the rendering is wrong. This is likely due to the use of the K channel in the SMask data. Adding simple examples.
Created attachment 4367 [details] UseCIEColorExample.pdf Simple example from Adobe Illustrator showing problem. Run using tiff32nc device with and without -dUseCIEColor.
Created attachment 4368 [details] Output.jpg Comparison of output.
So the issue with this bug is as suspected. When we have -dUseCIEColor with the CMYK device (and input CMYK color space for the SMask) we have the following mappings occur during concretization (gx_default_remap_color) from image_render_color: 1) The image CMYK values are mapped from CMYK to RGB using the definition of the default CMYK Color space array defined in \Resource\ColorSpace and using the sRGB CRD defined in gs_lev2.ps. 2) These RGB values are then mapped to the device color space, which in this case is CMYK. The mapping is performed using the process color model, which is a UCR/BG mapping defined in gs_init.ps. This function ends up mapping to composite black (no K values). 3) In gdevp14.c the K channel of the image is used for obtaining the luminance for the SMask (line 863) mask = additive ? mask_ptr[x]: 255 - mask_ptr[x + 3 * mask_planestride]; Since there is no variation in that channel and it is always 0, the mask value is 255 and the color(s) are drawn with no effect from the mask. What is SUPPOSED to occur is that a luminance value should be computed from the Smask CMYK data. This really cannot occur until AFTER the mask is popped. See page 547 of the specification "G can be any kind of group, isolated or not, knockout or not, producing various effects on the C (color) result in each case." Therefore, we really need to draw it completely before we convert and obtain the luminosity, otherwise we will not be able to properly "blend" between what was already put down and what is getting drawn. When doing -dUseCIEColor, we are currently mapping our SMask data to the device color, through the process color model. This is really not correct. Technically for the SMask data we should be going through the default CMYK Color space array defined in \Resource\ColorSpace and obtaining the luminance value. Technically once the data goes through the CRD portion of the JointCIE Mapping (and definitely once we go through the process color model) we have lost the real "luminance" information. We can recover from this however, by putting a reasonable luminance value into the K channel when a CMYK SMask is popped. If we just did that, we would get a decent output, even though it was based upon a device dependent calculation of luminance. It would be better to do it at that time I would think rather than at the time of compositing. I welcome discussion on this performance issue.
This renders properly with the soft mask branch.
As noted, fixed with the merge of the softmask branch.