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

[Dan Coby]

Zoltan,

>Due to actual structure of gx_default_copy_color() [see gdevdbit.c] it
isn't
>possible to patch it for working properly with all values of color depth
>from 1 to 64. However it's easy to extend it to work with 48 and 64:

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

I am unable to reproduce this problem.  I have been testing using the
spotpsd
device with three or four spot colors.  Thus I get depths of 56 and 64 bits.

My difficulty in reproducing the problem may be due to the test file that I
am
using.  Would you please send a test file. If you would like the file to be
kept private, please send it either to support at artifex.com or directly to
me.


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: Tuesday, November 11, 2003 2:45 PM
To: dan.coby at artifex.com
Cc: bug-gs at ghostscript.com
Subject: Re: [bug-gs] Incorrect rendering for type 1 images when
Interpolate==true


Dan,

In meantime I think I've got it.
 In case of /Interpolate == true, -- at least as I can see -- the
interpolation is processed in an intermediate puffer, the resulting bitmap
being copied pixel-to-pixel using the driver's copy_color() procedure. (see
image_render_interpolate() from gxiscale.c).
Since the driver in question has no implementation for copy_color, the
gx_default_copy_color() is always used. On the other hand, in conformity
with drivers.htm, this procedure can handle only bitmaps of 1, 2, 4, 8, 16,
24, or 32 bit per pixel depth, and definitely not those with 48 or 64! It's
hardly surprising that undesirable effects (splitting the 48- or 64-bit
color values into bytes) can occur.

Due to actual structure of gx_default_copy_color() [see gdevdbit.c] it isn't
possible to patch it for working properly with all values of color depth
from 1 to 64. However it's easy to extend it to work with 48 and 64:

  switch (depth) {
      case 64:
   color = (color << 8) + *ptr++;
      case 56:
   color = (color << 8) + *ptr++;
      case 48:
   color = (color << 8) + *ptr++;
      case 40:
   color = (color << 8) + *ptr++;
      case 32:
   color = (color << 8) + *ptr++;
      case 24:
   color = (color << 8) + *ptr++;
      case 16:
   color = (color << 8) + *ptr++;
  }

or:

      case 64:
   color = (color << 16) + *(unsigned short *)ptr;
            ptr += 2;
      case 48:
   color = (color << 16) + *(unsigned short *)ptr;
            ptr += 2;
   ........

The proposed patches (especially the first) may slow down a bit the
procedure, but it isn't a really fast one, anyway :-)
Note that the bug 687131 (as a duplicate of the message posted in bug_gs)
may be solved using this patch.

It's no reason to attach a test file since you can test it by an arbitrary
ps file containing something like

<<
/ImageType 1
.....
/Interpolate true
>> image
4a1bec8c0b371a3a5c4d28.... etc.
.....
showpage

BTW, what happens with bug 687011?! Is more severe than the above one; it
has been reported on 08-27, and not even has been assigned for 3 monthes...

Best regards,
Zoltan


_______________________________________________
bug-gs mailing list
bug-gs at ghostscript.com
http://www.ghostscript.com/mailman/listinfo/bug-gs