Bug 689246

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.