Bug 694842

Sample command line that demonstrates the problem:

  bin/gs -sDEVICE=tiffg4 -o test.tif -r300 ./E1150xx.pdf

Created attachment 10460 [details]
E1150xx.tif

Original file saved as 300 dpi G4 TIFF from Acrobat.

Created attachment 10461 [details]
E1150xx.pdf

Simplified version of original file.

As was mentioned in the description this is a regression.  There are actually two commits which changed the output, the first caused a few halftoning dots to appear in the background of the signature, the second caused more to appear:


commit e03db2c2530cbd41a16513824d5aadcc5c611a26
Author: Michael Vrhel <michael.vrhel@artifex.com>
Date:   Thu Mar 3 17:51:48 2011 +0000

    Enabling of thresholding code as default image rendering of monochrome/indexed images for monochrome devices.  This will result in about 2432 difference
    
    git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@12232 a1074d23-0009-0410-80fe-cf8c14f379e6



commit 1da2a46ed9f6ae0b0afc5fd4417943a36e532171
Author: Robin Watts <Robin.Watts@artifex.com>
Date:   Wed Aug 31 18:39:24 2011 +0100

    More work on bug 690538: introduce macros for color rounding.
    
    Introduce new macros to gxcvalue.h header file that defines helpful macros
    for colour depth changing.
    
    COLROUND macros do rounding (16->n bits), COLDUP macros do bit duplication
    (n->16 bits). Use these macros in various places throughout the code.
    
    Also tweak the gx_color_value_to_byte macro to round in the same way.
    
    Colors for devices that use these functions are now rounded in the same way
    that lcms does.
    
    Change as many encode_color routines as I can find to use this new code
    rather than simply truncating.

Created attachment 10462 [details]
E1150xx3.pdf

Further simplified version.

The original version had various watermarks/fonts in that didn't actually do anything. I've removed them. For the image it used an indexed colorspace with an ICC base for sRGB with a deviceRGB alternate. I've removed the ICC space, and resolved the indexed colorspace so we just have a direct 8bpp DeviceGray image. The same problem exhibits.

So we have an 8bpp device gray image that gs renders with some of it's background pixels non white, where acrobat renders the background entirely white.

The image in question has a background color of 253 rather than the 255 you would expect to see for a full white image. This can be confirmed by exporting the image as a contone and examining the background. Thus having some pixels set in the background of a monochrome rendering of the image is correct.

So, why do gs and acrobat render this differently?

Well, gs is using an 8x8 dither pattern. This can represents 65 possible levels, ranging from 0 pixels set in the dither to 64 pixels set in the dither.

We need to distribute these 65 levels as evenly as possible across the 0..255 range, and so we pick:

0     0,1
1     2,3,4,5
...
63    250,251,252,253
64    254,255

Accordingly, the '253' value in there is sent as 63 white pixels, and 1 black pixel - hence the 'shadow' seen in the background.

If we used a 4x4 dither instead, we'd have 17 possible levels, which would be distributed as:

0     0-7
1     8-23
...
15    232-247
16    248-255

This would leave us with a white background. I suspect Acrobat is using a 4x4 or  smaller dither.

Actually, we are using an 8x4 dither, which results in 33 possible values. We should still be showing that as white. A patch is forthcoming.

(In reply to comment #0)
> PDF documents with an embedded graphic (the signature of our company
> president) render with a grey shadow boundary box.  The same PDF rendered
> with Adobe Acrobat Reader (all reasonable versions) does not have this
> shadow.  I can say for sure that Ghostscript 8.70 does not have this issue
> either.  I tried both 9.07 & 9.10 and they do have this issue.  I have
> unfortunately not tried any of the older 9.xx versions.  Also,
> unfortunately, we have literally 1,000s of individual PDF documents with
> this same embedded graphic, so fixing the PDFs to work around this problem
> is not practical at this time.

Are Pacific Life a supported customer? If you're relying on Ghostscript as part of your business workflow, it probably makes sense for you to be. Not to mention that warm fuzzy feeling of supporting the software you use! >8*)

Created attachment 10465 [details]
e1150-with-stocht.tif

While there may be a problem with the definition of the low quality default
halftone used by Ghostscript, we have a much higher quality stochastic dither
halftone screen that does not exhibit the problem.

The attached output from the original file looks OK, and the "SPECIMEN"
watermark is much smoother without the 45 degree angle grid effect.

This was produced with:

   gs -sDEVICE=tiffg4 -o e1150.tif -r300 -Ilib stocht.ps e1150.pdf

We may continue to look into the default halftone settings, but this seems
to be an acceptable (or even preferable) workaround.

The default halftone generation code is fixed in:

commit 300c3ea8f2c82471c5e57655bd13549f1172c38a
Author: Robin Watts <robin.watts@artifex.com>
Date:   Mon Dec 16 18:13:03 2013 +0000

    Bug 694842: Fix threshold table generation.

    When we generate threshold tables for dithering, we should expect them
    to be 'evenly distributed'. This is not the case currently. In the
    example given in this bug, we generate an 8x4 dither table. This
    contains 32 pixels, all of which can be on or off, hence we have 33
    levels, ranging from 0 on to 32 on.

    We would further expect our input range to be evenly divided into these
    levels - i.e. roughly 256/33 in each band.

    This is not the case. The threshold table generated is:

    threshold array row   0=  88 120 152 184 176 144 112  80
    threshold array row   1= 192 224 208 168  72  40  56  96
    threshold array row   2= 232 255 240 136  32   8  24 128
    threshold array row   3= 216 248 200 104  48  16  64 160

    The operation of our thresholding code is to set a pixel if
    contone(x,y) < threshold(x,y), hence our inputs divide into:
    0-7,8-15,...240-254,255

    Not only does this not have the required 256/33 per region, the top
    and bottom regions are far from being even (8 vs 1 entries).

    Ideally we should fix this code so generate the correct distribution -
    an enhancement bug will be opened for this. For now we will satisfy
    ourselves by offsetting the thresholds slightly so that the top and
    bottom ranges are at least even. The new code gives:

    threshold array row   0=  84 116 148 180 172 140 108  76
    threshold array row   1= 188 220 204 164  68  36  52  92
    threshold array row   2= 228 252 236 132  28   4  20 124
    threshold array row   3= 212 244 196 100  44  12  60 156

This threshold array is still not perfect, but it's better. I will open an enhancement bug to look at making it perfect. Also, we should double check the behaviour of this code with multi-level dithering.

Enhancement has been opened as bug 694850.