Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2005-07-21 12:16:03
|
Well, it looks to me that it must be a bug in ghostscript -- some rounding
of positions or whatever. Below is a simplest postscript code that
demonstrates spurious lines in a pm3d-like image:
%!
/M {moveto} bind def
/L {lineto} bind def
/R {rmoveto} bind def
/V {rlineto} bind def
/C {closepath} def
% Change the position, and spurious lines may move!!!
-50 20 translate
1 1 translate
1 setlinewidth
0.5 setgray
/y {100} def
newpath 100 y M 100 0 V 0 100 V -100 0 V closepath fill
newpath 200 y M 100 0 V 0 100 V -100 0 V closepath fill
newpath 300 y M 100 0 V 0 100 V -100 0 V closepath fill
newpath 400 y M 100 0 V 0 100 V -100 0 V closepath fill
newpath 500 y M 100 0 V 0 100 V -100 0 V closepath fill
/y {300} def
newpath 100 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill
newpath 200 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill
newpath 300 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill
newpath 400 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill
newpath 500 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill
showpage
You can change the resolution "-r50" and see how the spurious lines are
moving.
a=demo2.ps
A="-dGraphicsAlphaBits=4"
D=png16m
#D=png256
gs -q -r50 $A -sDEVICE=$D \
-dSAFER -dNOPAUSE -dBATCH -sOutputFile=$a.png $a -quit
gqview $a.png
Questions to postscript gurus:
1. Is it a gs bug?
2. Can gnuplot overcome it? (Ignore antialiasing, ...)
---
PM
|
|
From: Robert H. <en...@no...> - 2005-07-21 13:32:01
|
On Thu, 2005-07-21 at 14:15 +0200, Petr Mikulik wrote: > Questions to postscript gurus: > 1. Is it a gs bug? Yes I think so. Acrobat Distiller seems to be able to do the right thing. I've also seen similar bugs in output from various other programs. > 2. Can gnuplot overcome it? (Ignore antialiasing, ...) In your example, I modified the coordinates to give a slight overlap (making each rectangle 100.1 points wide) Whether it would be practical to do this in the postscript terminal is another matter. (I guess you'd have to find the centroid of each polygon, and then scale all the coordinates. Maybe there are other approaches, but I suggest leaving it - people can either a) live with it b) turn of antialiasing or c) wait until ghostscript fix the bug. You might want to post a bug on bugs.gnuplot.com Rob -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-21 13:46:06
|
Petr Mikulik wrote: > Well, it looks to me that it must be a bug in ghostscript -- some > rounding of positions or whatever. Below is a simplest postscript code > that demonstrates spurious lines in a pm3d-like image: I don't fully agree that those lines are "spurious". Since you only fill-ed the paths, but didn't stroke them, there are technically gaps of zero pixel width between adjacent tiles. And just like lines of width zero are not exactly the same thing as no lines at all, gaps of width zero are not the same as no gap at all. For this to be a meaningful test, the paths could have to be both filled and stroked. |
|
From: Petr M. <mi...@ph...> - 2005-07-21 14:32:55
Attachments:
demo3.ps
|
>> Well, it looks to me that it must be a bug in ghostscript -- some rounding >> of positions or whatever. Below is a simplest postscript code that >> demonstrates spurious lines in a pm3d-like image: > > I don't fully agree that those lines are "spurious". Since you only > fill-ed the paths, but didn't stroke them, there are technically > gaps of zero pixel width between adjacent tiles. And just like lines of > width zero are not exactly the same thing as no lines at all, gaps of width > zero are not the same as no gap at all. For this to be a meaningful test, > the paths could have to be both filled and stroked. It does not help. Try to play with /F in the attached example. Also added blue background. And tested with different direction of stacked boxes. > Fill-ing and stroke-ing gives much better results: the lines occur less > frequently, and with less intensity. I don't think so. Try to render the result into a png file (command in my previous mail), not onto x11 display. --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-22 13:06:15
|
Petr Mikulik wrote: > It does not help. Try to play with /F in the attached example. Also > added blue background. And tested with different direction of stacked > boxes. On of this windows box (GSview 4.6, AFPL Ghostscript 8.14, resolution 300 dpi, "Zoom Resolution" 300 dpi), I get no gaps with the script as sent (third version of /F active) --- but they appear if I select the first version (no stroke), and they also re-appear if I reduce the 'setlinewidth' to zero. So yes, the fix does appear to work. |
|
From: Petr M. <mi...@ph...> - 2005-07-22 12:31:12
|
> Petr Mikulik wrote: >> It does not help. Try to play with /F in the attached example. Also added >> blue background. And tested with different direction of stacked boxes. > > On of this windows box (GSview 4.6, AFPL Ghostscript 8.14, resolution 300 > dpi, "Zoom Resolution" 300 dpi), I get no gaps with the script as sent (third > version of /F active) --- but they appear if I select the first version (no > stroke), and they also re-appear if I reduce the 'setlinewidth' to zero. So > yes, the fix does appear to work. Please try it with other resolutions. Try also rastering to png. --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-22 14:15:42
|
Petr Mikulik wrote: > Please try it with other resolutions. *Which ones*? I tried with both resolution at 50 dpi (the one you used in your PNG tests), and it didn't make a difference. > Try also rastering to png. That almost certainly doesn't make a difference. The gaps are produced in ghostscript's rastering engine, not in the output to some file format. |
|
From: Petr M. <mi...@ph...> - 2005-07-22 12:52:32
|
>> Please try it with other resolutions. > > *Which ones*? I tried with both resolution at 50 dpi (the one you used in > your PNG tests), and it didn't make a difference. 17, 23, 32, 75, ... whatever random sequence. For some of them, you will see it. At least I do. >> Try also rastering to png. > > That almost certainly doesn't make a difference. The gaps are produced in > ghostscript's rastering engine, not in the output to some file format. Not gnuplot's "set term png", but ghostscript's "-sDEVICE=pngXXXX -rNN". See the script (command) in a previous mail. --- PM |
|
From: Theo H. <th...@ph...> - 2005-07-21 16:46:17
|
Hans-Bernhard Broeker wrote: > Petr Mikulik wrote: > >> Well, it looks to me that it must be a bug in ghostscript -- some >> rounding of positions or whatever. Below is a simplest postscript code >> that demonstrates spurious lines in a pm3d-like image: > > > I don't fully agree that those lines are "spurious". Since you only > fill-ed the paths, but didn't stroke them, there are technically > gaps of zero pixel width between adjacent tiles. And just like lines of > width zero are not exactly the same thing as no lines at all, gaps of > width zero are not the same as no gap at all. For this to be a > meaningful test, the paths could have to be both filled and stroked. I just tried this. Fill-ing and stroke-ing gives much better results: the lines occur less frequently, and with less intensity. It seems to me that if filled polygons were stroke-d with a line width just slightly over the nominal value, the anti-aliasing problem with Ghostscript could be worked around. Unfortunately, I don't know enough Postscript to be able to test this. THeo |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-21 18:49:04
|
Petr: You mentioned problems with both gs 7.07 and 8.something. I have gs -v ESP Ghostscript 7.07.2 (2003-11-19) After running your suggested test script through the current cvs version of gnuplot, I do not see the artifacts you describe - viewing in gv works fine - converting to pdf via ps2pdf and viewing in acrobet works fine - converting to png via ImageMagick's "convert" command works fine. (This calls gs, but I don't know the specific options it uses). I don't what this means, exactly, but I offer it as possible evidence that the bug is restricted to some very specific gs versions. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-07-22 07:09:21
|
> I have > gs -v > ESP Ghostscript 7.07.2 (2003-11-19) I have 7.07.1 and 8.50 > After running your suggested test script through the > current cvs version of gnuplot, I do not see the > artifacts you describe > > - viewing in gv works fine Try to change scaling. > - converting to png via ImageMagick's "convert" command > works fine. (This calls gs, but I don't know the specific > options it uses). Try "convert -density 23" (play with the number) and it will appear. > evidence that the bug is restricted to some very specific > gs versions. I don't think so, it depends on the output image resolution. --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-07-22 15:28:59
|
On Friday 22 July 2005 12:09 am, you wrote: > > I have > > gs -v > > ESP Ghostscript 7.07.2 (2003-11-19) > > I have 7.07.1 and 8.50 > > > After running your suggested test script through the > > current cvs version of gnuplot, I do not see the > > artifacts you describe > > > > - viewing in gv works fine > > Try to change scaling. I have done so. No problems. Same for scaling in Acrobat after conversion to pdf. > > - converting to png via ImageMagick's "convert" command > > works fine. (This calls gs, but I don't know the specific > > options it uses). > > Try "convert -density 23" (play with the number) and it will appear. density less than 72 never works well. This has nothing to do with gnuplot. If you need to convert to a smaller image, you should do something like "convert -density 150 -geometry 20%" so that anti-aliasing is used. > It depends on the output image resolution. I believe you. But that suggests that the undesired white lines are 1 pixel wide, and as you reduce the resolution that "1 pixel" becomes proportionally larger. That does indeed sound like it could the result of fill-with-no-stroke. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2005-07-27 16:07:10
|
I have filled in this bug report: http://bugs.ghostscript.com/show_bug.cgi?id=688243 Summary: Spurious lines between joined filled rectangles and antialiasing --- PM |
