Summary: | Parasitic transparent device pixels in Type 3 images | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | François Robert <frobert> |
Component: | PS Interpreter | Assignee: | Robin Watts <robin.watts> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P4 | ||
Version: | 9.02 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Customer: | Word Size: | --- | |
Attachments: | GS 9.02 image window screenshot |
Description
François Robert
2011-05-24 15:09:55 UTC
Moving over for Robin to take a look. I strongly suspect this problem is down to us breaking the image down into a series of rectangles, and them not quite lining up correctly after rotation. Will investigate some more. In order to plot masked images, for each scanline we: * plot the transformed pixels from the mask data into a mask bitmap. * use this bitmap in a clipping device through which we... * plot the transformed pixels from the (color) image data. The bug is occurring because there is a mismatch between the outline of the pixels from the mask and from the image. This mismatch occurs because of an optimisation in the mask bitmap plotting routines; rather than plot every pixel individually, the code gathers up 'runs' of pixels and plots them all at once. The image code, by contrast has a comment in it saying that it does not do this deliberately to avoid rounding issues. The fix is simply to avoid this optimisation in the masked (but not portrait or landscape) case. I have checked that this doesn't cause any double pixel plotting problems. Fixed in git commit: commit 31174084f95474f9c0edfd4c534c3b1654c02255 Author: Robin Watts <Robin.Watts@artifex.com> Date: Fri Jun 3 17:33:51 2011 +0100 Fix bug 692226; stray pixels in skewed masked image When painting a masked image, we first plot a scanlines worth of mask pixels to a mask plane. This is then used in a clipping device to clip the image pixels that follow thereafter. In the code that plots the masked pixels it currently gathers up 'runs' of identical pixels and plots them all at once. This works fine for portrait and landscape images, but for skewed ones has problems due to rounding errors. By plotting large runs of pixels at once, we can a) get gaps between subsequent rows of masked pixels, and b) get a mismatch between the pixels covered by the mask and the image. These manifest as holes in the image. The image code already has a comment in it to the effect that we cannot amalgamate large blocks due to rounding errors. This fix therefore extends this policy (of not amalgamating) to skewed masked images too. 426 non-pdfwrite/pswrite differences expected. 79 pdfwrite. 31 ps2write. Checked with bmpcmp and all seem either progressions or neutral. |