[gs-bugs] [Bug 691305] Touched areas not rendered properly

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Sat May 15 08:56:41 UTC 2010


http://bugs.ghostscript.com/show_bug.cgi?id=691305

Ken Sharp <ken.sharp at artifex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #6 from Ken Sharp <ken.sharp at artifex.com> 2010-05-15 08:56:39 UTC ---
(In reply to comment #5)

> In "Only test case" you find only input file, output file and batch file used
> for output generation.

The output file in the original file does not seem to have been generated with
GraphicsAlphaBits, the edges of the objects are not smoothed and the paler
orthogonal lines are not apparent, unlike the later attachment, where the
problem can indeed be clearly seen.


> The command line is:
> "C:\Program Files\gs\gs8.71\bin\gswin32c.exe" -sDEVICE=pngalpha
> -sOutputFile=test_output.png -r200 -dEPSCrop -dTextAlphaBits=4
> -dGraphicsAlphaBits=4 -dUseCIEColor -dBATCH -dNOPAUSE test.eps

The problem looks like the use of GraphicsAlphaBits to smooth the output, the
fact that objects are butted together and compounded by a rather large scaling
factor. 

This is probably intended to provide accuracy while using integer values to
define objects but since Ghostscript, in common with most (if not all) other
PostScript interpreter, uses a fixed precision format to represent real
numbers, large multiplication and division of integers simply results in
rounding errors and precision being dropped.

What happens is that the objects are scaled up, rendered, and then sampled down
to produce the smoothed output, which is then combined with the existing
rendered objects on the page. Depending on exactly how the objects in user
space end up on the device pixel grid they may not butt up exactly. This is
exacerbated by rounding errors and the scaling required for the higher
resolution rendering.

It looks to me like the edges of the two objects do not align precisely in
device space, leading to the two partially transparent edges overlapping and
combining to produce a slightly lighter edge between them. When rendered
without smoothing the edge does not appear, because the pixel separating the
two objects is at least partially covered and is therefore rendered using the
current dark colour.

I would suggest that if you want to do this, you render to the higher
resolution and then filter the entire rendered page in an image manipulation
application to achieve smoothed output.

Alternatively, ensure there is some overlap between adjacent objects which are
intended to butt seamlessly, but this is probably not practical.


> You must zoom output image to see the problem. In attached image "Problem
> description" I've added screenshot of zoomed image and also comparation to
> output from Adobe Photoshop, which rasters file corretly.

This is much more helpful. In fact I did zoom the original PNG file to try and
see a problem but was unable to see this artefact, even knowing what to look
for.


> BTW do you have any idea why output file has white background instead of
> transparency?

PostScript has an opaque imaging model, untouched areas of the page are
nominally white. To be more specific, the PostScript model starts any program
by filling the entire canvas with a specific colour, usually white, drawing
commands are then executed as specified by the program and rendered to the
canvas. As a result unmarked areas are white by definition.


I believe the behaviour is not unexpected, and I don't think there's anything
we can realistically do to prevent this. Closing as wontfix, if someone
(perhaps Michael) is interested please reopen and assign to yourself.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list