Detected with a.pdf using same method as described in the bug 687342. Likely 119-10.ps, 119-47.ps and many others have same problem. Likely chess.ps have same problem when drowing a cached character raster "(\265) 72 474 T". Likely 455690.pdf have same problem as chess.ps . Use CVS HEAD after gxfill.c revision 1.116 .
Created attachment 530 [details] chess-.ps A reduced chess.ps .
Oops, chess-.ps is a different problem. Please ignore it here together with 455690.pdf .
See bug 687348 about chess-.ps . 455690.pdf has a problem related to this bug.
Created attachment 534 [details] 455690-.pdf Attached a reduced 455690-.pdf with a single bitmap.
Testing using 455690-.pdf - No differences. (both with and without interpolation) Testing using 119-10.ps - At 300 dpi, a single line of differences.
This may be related to the image interpolation problem described in bug 687039.
Ignore comment #6, please. It was submitted to the wrong bug.
As in comment #5 I found that there is no difference with the simplified 455690-.pdf. However I did find a 2 areas of difference (Diff Count: 12) with the original full PDF 455690.pdf. Unlike comment #5 I did not see any difference with 119-10.ps. Used r8170/Mac OS X/commands as described in bug 687342.
like bug 687342 the output is correct if high level images are disabled. I did not investigate further. As noted the problem is not reproducible in the diminutive test case, but 455690.pdf in the comparefiles directory of the regression suite does show the problem.
Created attachment 3763 [details] 455690-1.pdf Another reduced test that reproduces the problem with current HEAD.
Commands to reproduce : ..\..\gs-hd\bin\gswin32c.exe -IF:/AFPL/gs-hd/lib;f:\afpl\fonts -r300 - dMaxBitmap=100000 -dNOPAUSE -dBATCH -dNOOUTERSAVE -sDEVICE=ppmraw - sOutputFile=cur-b.ppm -dLastPage=1 decompr-455690-1.pdf ..\..\gs-hd\bin\gswin32c.exe -IF:/AFPL/gs-hd/lib;f:\afpl\fonts -r300 - dMaxBitmap=100000000 -dNOPAUSE -dBATCH -dNOOUTERSAVE -sDEVICE=ppmraw - sOutputFile=cur-n.ppm -dLastPage=1 decompr-455690-1.pdf F:\AFPL\fuzzy\Debug\fuzzy.exe -t 0 -w 1 -c cur-b.ppm cur-n.ppm diff.bmp Note it is not reproducible with default MaxBitmap. The attachment 534 [details] does not reproduce the problem with current HEAD, don't know why so.
The effect has no dependance on the value of MaxBitmap parameter. I tried 100000, 200000, 300000, 400000, 500000, 600000, 700000, 800000, 900000, 1000000, 2000000, 3000000, 4000000, 5000000, 6000000, 7000000, 8000000, 9000000, 10000000 - all gave same output. So I think the problem is not related to band boundary, but need to check how the image is placed on the page while working through clist.
clist_image_plane_data recieves image data devided into blocks with the source image reader buffering. Then clist_image_plane_data places each block to those bands which are covered by the block. I guess the block origin is rounded to integral pixels either when writing to clist, or when reading from clist. It can explain why no dependence on the band boundary : the rendering artifact can happen at a block boundary.
The file 455690-1.pdf demonstrates a problem with Interpolate=false. penum- >dda.row.y.step is different for banded anod nobanded rendering : Noband: dQ=254 dR=437 NdR=379 Banded: dQ=254 dR=437 NdR=380
Correction to the last comment : Noband: dQ=254 dR=438 NdR=379 Banded: dQ=254 dR=437 NdR=380
A partial fix to HEAD for image scaling only : http://ghostscript.com/pipermail/gs-cvs/2008-February/008101.html
One more patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-February/008106.html Now the list of banded/unbanded raster differences reduces to this : "034-01.ps" "148-11.ps" "A-12-3480-0109-5.pdf" "a.pdf" "Altona.Page_3.2002-09-27.pdf" "Altona_Technical_1v1_x3.pdf" "B-12-3077-1831-7-001.pdf" "Bug687840.pdf" "Bug688485.pdf" "chilis_black.pdf" "chilis_red.pdf" "Clarke Tate Manns Chinese.ai" "gradmesh.ai" "john_clippedimage.pdf" "jpx-flowcontrols.pdf" "Openhuis_pdf_zw.pdf" "rotate0.pdf" "rotate180.pdf" "rotate270.pdf" "rotate90.pdf" "SmoothShading.pdf" Some of them may be not images.
More patches to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-February/008112.html http://ghostscript.com/pipermail/gs-cvs/2008-February/008113.html http://ghostscript.com/pipermail/gs-cvs/2008-February/008114.html
One more patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-February/008120.html After this patch we still have the following banded-unbanded raster differences : Images : Bug687840.pdf john_clippedimage.pdf jpx-flowcontrols.pdf rotate0.pdf rotate180.pdf rotate270.pdf rotate90.pdf Not images : 034-01.ps Bug688485.pdf chilis_black.pdf chilis_red.pdf Clarke Tate Manns Chinese.ai gradmesh.ai Openhuis_pdf_zw.pdf SmoothShading.pdf
Problems with rotate*.pdf is not related to image rendering, but an image is necessary to show it. The reason for raster difference is that a clipping region appears different with banding and with no banding. Since it is not an image rendering, we'll not work on it within this bug.
With john_clippedimage.pdf raster difference dissappears when I remove clipping from the PDF file. So it is same problem as one in Comment #20.
Bug687840.pdf demonstrates same problem as one in Comment #21.
jpx-flowcontrols.pdf demonstrates same problem as one in Comment #21.
Thus we have no image problems now, so I'll close this bug. Will move resting problems to new bug 689715.
One more patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-February/008123.html
One more patch toi HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-February/008127.html
One more patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-February/008128.html