The customer reports: When the install function for the ICCbased color space returns true, the subsequent calls to the remap function go to the DeviceRGB function not to the ICCbased. As a result all the graphic elements in the image come out black (see test.tif). There seems to be a problem with the handling of ICCbased color spaces for some PDF 1.4 files. (maybe transparency related) If you use the attached file (gsncdummy.c) in your build and use the same command line as for the last problem, you will see what I mean. It doesn't matter what the ICCbased remap function does, because it won't be called. The DeviceRGB remap function is also no help because it always gets the RGB values 0 0 0 as input color. The gsncdummy.c file is attached. The command line used to reproduce the problem report was: gs -sDEVICE=tiff32nc -o logosvlb.tif -r72 -c "<< /CustomColorCallback 128 string .pantonecallback >> setsystemparams" -f LogoSVLB.pdf Note that the customer's gsncdummy.c was put in the src directory and the ENABLE_CUSTOM_COLOR_CALLBACK was set to 1, then: make clean ; make (testing actually on Windows).
Created attachment 2975 [details] gsncdummy.c
Created attachment 2976 [details] LogoSVLB.pdf Test File
Note that if I add the option: -dUseCIEColor then the entire image is black.
It looks like there is a design flaw in this where the remap function is not called until the color has already been concretized from ICC to device space. Also, when the user installs a handler for the ICC based colorspace the colorspace is not established completely in a way that it can be successfully concretized. Since the user callback should be doing any conversion, the concretization should be bypassed altogether.
REQUIREMENTS CONFUSION. Why is OBJECT_TYPE_EXAMPLE defined in the client? The customer needs callbacks for devicen and separation color spaces only. Right?
The customer (#330) requires that ALL colors are processed using the color callback, Device* CIEBased* and (PDF) ICCBased as well as Separations (named) colors. They perform their own color management/correction for all color spaces. BTW, I recommend testing with transparency as well using the files from Bug 689494: http://bugs.ghostscript.com/attachment.cgi?id=3435&action=view and from bug 689493: http://bugs.ghostscript.com/attachment.cgi?id=3433&action=view The first is a simple CMYK transparency example. The second is transparency with spot colors. The target device should include the tiffsep device when testing. I'm assuming that this issue will be among those addressed by the new color handling.
Created attachment 3893 [details] interptest.pdf Hand-made PDF test file with image interpolation between black and white with various gamma values. The image is 4x2 pixels, half black and half white. The file is designed to detect whether a renderer does interpolation in the Image or Device colorspace.
Created attachment 3894 [details] interptest.png Screenshot comparing the rendering of interptest.pdf on Acrobat Reader 8 and Ghostscript r8609 (both on MacOS X). It appears Acrobat Reader is interpolating in the Image space, while Ghostscript interpolates in the device space. Apple's renderer (Preview.app) also interpolates in device space, and shows steps.
Assigning to Michael who's handling the interpolation issues.
Created attachment 4079 [details] Source_Color_Interpolation.diff This patch makes the interpolation occur in the source color space. With this fix, we avoid a concretization that that was occurring outside the custom color callback operations.
Created attachment 4080 [details] interptest-new.png Just a quick comment. I reran interptest.pdf with this patch and it looks like the source interpolation has some boundary issues.
Created attachment 4081 [details] Source_Color_Interpolation2.diff Fixed issue identified in interptest.pdf
Created attachment 4217 [details] Spatial_Interp_Source_Color.diff When run against the standard regression, this patch has expected differences in about 62 files with -dDOINTERPOLATE enabled. I went through these pages of those files and the differences all appear correct to me. Basically anytime you do interpolation in a nondevice space it will differ from the existing code. The current patch performs the spatial interpolation in the source color space. If the source color space is an indexed space, the base color space is used. Following interpolation, the color values are transformed to the concrete device space.
Created attachment 4233 [details] Source_Color_Interpolation4.diff Update of patch with recommended fixes and memory overrun fix.
The patch 4233 compiles with MSVC warnings : >.\src\gxiscale.c(295) : warning C4090: 'initializing' : different 'const' qualifiers 1>.\src\gxiscale.c(577) : warning C4090: '=' : different 'const' qualifiers 1>.\src\gxiscale.c(580) : warning C4090: '=' : different 'const' qualifiers 1
Fixed this issue with r8868. Interpolation is now performed in the source color space. Following interpolation the remap function occurs which properly calls the custom color callback.