Michael Lachmann
2011-Aug-03 07:25 UTC
[Rd] one way to solve bad looking density plots in postscript
Hi, When R generates density plots and these are exported to postscript( a=matrix(1:100,10,10);image(a,col=rainbow(100);dev.copy2eps(file="image.eps") ) The result often looks bad when rendered on screen. The help page states that this is because programs use anti-aliasing. That seems to be true - turning off anti-aliasing for gs (-dGraphicsAlphaBits=1) of in OSX's preview makes the plots look really smooth, but makes everything else look bad (personal opinion..). The plots do look ok in acrobat reader. I think it would be much better if R corrected this problem - even if it is not totally R's fault. It seems that using the option useRaster=T in image() solved this problem, but creates other problems for OSX's Preview (it seems that OSX's preview first anti-aliases the raster, and then scales it... creating a mess). Density plots produced by gnuplot do not seem to have this problem: --- set pm3d map set pm3d at b set ticslevel 0.8 set isosample 40,40 set output "gtest.eps" set term postscript eps color splot [-3:3] [-3:3] x*x*exp(-x*x)*y*y*exp(-y*y) -- But I haven't figured out why that is. Maybe someone who understands more about postscript can. Maybe it is something about the order that the rectangles are rendered? I did notice that rectangles are plotted with slightly different sizes - 50, 51, 50, 51 and so on. Is that it? After a lot of experimentation, I found that a small change in the eps file can correct the output. If in the eps file produced above, you change the line /p2 { gsave bg fill grestore newpath } def with /p2 { bg gsave fill grestore stroke newpath } def and add 0.0001 setlinewidth two lines before the next p2 - i.e. before we start plotting the rectangles of the image: change: /bg { 1 0 0 setrgb } def 59.04 73.44 41.47 37.15 r p2 to: 0.0001 setlinewidth /bg { 1 0 0 setrgb } def 59.04 73.44 41.47 37.15 r p2 What this does is plot the outline of each rectangle in addition to filling it. The page at: http://pages.uoregon.edu/noeckel/MathematicaGraphics.html#ExportGraphics Claims that Mathematica also has/had this problem, and how it can be solved there (sadly, I don't know enough Mathematica to understand that solution) The output of the image would look even better if the axes were drawn AFTER the density rectangles, not before. That would cause the rectangles not to overwrite part of the lines of the axes. But that is probably a change in the image() routine, not in the postscript driver.... Thanks for listening, Michael Lachmann
Michael Lachmann
2011-Aug-03 12:23 UTC
[Rd] one way to solve bad looking density plots in postscript
Some more digging. 1. The following code will fix density plots for me: --- .ps.prolog=grDevices:::.ps.prolog i=grep("/p2",.ps.prolog) .ps.prolog[i] = "/p2 { bg gsave fill grestore 0.001 setlinewidth stroke newpath } def" --- 2. It seems that it doesn't matter where in image.default() the box is drawn, before or after .Internal(image(as.double(x), as.double(y), as.integer(zi), col)) is called, the resulting eps has the box in front. Michael On 3 Aug 2011, at 9:25AM, Michael Lachmann wrote:> When R generates density plots and these are exported to postscript( > a=matrix(1:100,10,10);image(a,col=rainbow(100);dev.copy2eps(file="image.eps") > ) > The result often looks bad when rendered on screen. The help page states that this is because programs use anti-aliasing. That seems to be true - turning off anti-aliasing for gs (-dGraphicsAlphaBits=1) of in OSX's preview makes the plots look really smooth, but makes everything else look bad (personal opinion..). The plots do look ok in acrobat reader. I think it would be much better if R corrected this problem - even if it is not totally R's fault. > It seems that using the option useRaster=T in image() solved this problem, but creates other problems for OSX's Preview (it seems that OSX's preview first anti-aliases the raster, and then scales it... creating a mess). > > Density plots produced by gnuplot do not seem to have this problem: > --- > set pm3d map > set pm3d at b > set ticslevel 0.8 > set isosample 40,40 > set output "gtest.eps" > set term postscript eps color > splot [-3:3] [-3:3] x*x*exp(-x*x)*y*y*exp(-y*y) > -- > But I haven't figured out why that is. Maybe someone who understands more about postscript can. Maybe it is something about the order that the rectangles are rendered? I did notice that rectangles are plotted with slightly different sizes - 50, 51, 50, 51 and so on. Is that it? > > After a lot of experimentation, I found that a small change in the eps file can correct the output. > If in the eps file produced above, you change the line > /p2 { gsave bg fill grestore newpath } def > with > /p2 { bg gsave fill grestore stroke newpath } def > and add > 0.0001 setlinewidth > two lines before the next p2 - i.e. before we start plotting the rectangles of the image: > change: > /bg { 1 0 0 setrgb } def > 59.04 73.44 41.47 37.15 r p2 > to: > 0.0001 setlinewidth > /bg { 1 0 0 setrgb } def > 59.04 73.44 41.47 37.15 r p2 > > What this does is plot the outline of each rectangle in addition to filling it. > The page at: > http://pages.uoregon.edu/noeckel/MathematicaGraphics.html#ExportGraphics > Claims that Mathematica also has/had this problem, and how it can be solved there (sadly, I don't know enough Mathematica to understand that solution) > > The output of the image would look even better if the axes were drawn AFTER the density rectangles, not before. That would cause the rectangles not to overwrite part of the lines of the axes. But that is probably a change in the image() routine, not in the postscript driver.... > > Thanks for listening, > > Michael Lachmann > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > >