[bug-gs] Incorrect rendering for type 1 images whenInterpolate==true

[Dan Coby]

Zoltan,

Thanks for sending a test file.  It has been somewhat useful.

In my last reply I incorrectly identified the psdcmyk device as spotpsd.
You are
correct.  I was referring to the psdcmyk device.

I am still not having very much luck in recreating your situation.  Short of
creating a
new device driver to match yours, I may not get there.

The changes that you proposed in src/gdevdbit.c are definitely appropriate
for a
device which uses gx_default_copy_color and uses more than 32 bits per
pixel.
I am going to include them in our sources.

There are two more things that you may want to consider for your device.  If
you
are using bit_put_params, or a routine which is based upon it.  I just
checked
in some changes to increase the possible number of bits per component in
this
routine.  This change can be found at:

http://www.ghostscript.com/pipermail/gs-cvs/2003-November/003766.html

There is also a second routine in src/gdevdbit.c called
gx_copy_color_unaligned.
This routine also has code which is specific for pixel size. If you are
using this
routine or a routine based upon it then changes may be required.

Checking other routines in these files, I see that the routine
gx_default_copy_alpha
has the required modifications for pixels sizes greater than 32 bits.


Dan


-----Original Message-----
From: bug-gs-bounces at ghostscript.com
[mailto:bug-gs-bounces at ghostscript.com]On Behalf Of BÍRÓ Zoltán
Sent: Friday, November 14, 2003 4:00 PM
To: dan.coby at artifex.com
Cc: bug-gs at ghostscript.com
Subject: Re: [bug-gs] Incorrect rendering for type 1 images
whenInterpolate==true


Dan,

| The value of depth is limited to 1,2,4,8,16,24,32,40,48,56, and 64.

Drivers.htm says: "For copy_color, the number of bits per pixel is given by
the color_info.depth parameter in the device structure: the legal values are
1, 2, 4, 8, 16, 24, or 32.". Unfortunately -- as you can see in
gdevdbit.c -- gx_default_copy_color() does "respect" this restriction, that
is, only the above mentioned cases are implemented.

| I am unable to reproduce this problem.  I have been testing using the
| spotpsd device with three or four spot colors.
| My difficulty in reproducing the problem may be due to the test file that
| I am using.

I couldn't found spotpsd device so I think it must be the psdcmyk with some
spot colors defined. I've tried the attached test page using the following
command line:

C:\gs\gs8.11\bin\gswin32c.exe -sDEVICE=psdcmyk -r150 -c "<<
/SeparationColorNames [ /Spot1 /Spot2 /Spot3 /Spot4] >>
setpagedevice" -f -sOutputFile=c:\gauguin.psd c:\gauguin.ps

I am not sure how psdcmyk works, but I haven't noticed any calls of
gx_default_copy_color() through processing. I know little about printer
drivers (like psdcmyk) but I think they may by-pass the
gx_default_copy_color() function, at least for this type of ps files
(containing type 1 images with interpolate = true). My driver is not a
printer driver, so obviously here is the difference (and the difficulty in
reproducing the problematical behavior).

In case of you still aren't sure about the problem and about my proposed
patch, you may try non printer
devices able to work with 12 or 16 bits per component to reproduce the bug;
Russel's display device may be suitable for this.

Best regards,
Zoltán