Created attachment 7528 [details] GS 9.02 image window screenshot When painting a skewed, Type 3 image on a colored background, some device pixels incorrectly keep the background color even though they are covered by opaque pixels of the raster. Simple test case : %!PS 1 0 0 setrgbcolor 0 0 200 200 rectfill 0 setgray 50 50 translate [ 0.959281 0.294750 -0.071813 1.032109 0 0 ] concat 70 70 scale << /ImageType 3 /InterleaveType 1 /DataDict << /ImageType 1 /Interpolate false /Decode [0 1] /BitsPerComponent 8 /Width 64 /Height 64 /ImageMatrix [ 64 0 0 -64 0 64 ] /DataSource <00ff> >> /MaskDict << /ImageType 1 /Interpolate false /Decode [0 1] /BitsPerComponent 8 /Width 64 /Height 64 /ImageMatrix [ 64 0 0 -64 0 64 ] >> >> image %%EOF Attached a screenshot of the screen output (Windows XP). The set of extra transparent pixels vary if the CTM is set differently (by supplying different value to "scale", "concat" for instance)
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.